pika-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pika-dev] Re: more on hackerlab strings


From: Andreas Rottmann
Subject: [Pika-dev] Re: more on hackerlab strings
Date: Fri, 19 Mar 2004 13:21:13 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Jose A Ortega Ruiz <address@hidden> writes:

> On Mon, Mar 15, 2004 at 10:24:29PM +0100, Jose A Ortega Ruiz wrote:
>> i still have to:
>> 
>> - finish the implementation of the 'bogus' encoding
>> - provide the udstr counterparts of most of scheme's string-foo
>> - move the buckybits stuff from pika to hackerlab
>> 
>
> ok, the latest patch in my hackerlab archive now contains barebones
> support for bogus32 encoding, and it is already used by the few fw
> functions that are in place. i've made a mild effort to keep the 
> documentation in synch (tom, did you read my comments regarding
> how we should extract docs from sources? any comments?)
> proper unit testing is still missing, though.
>
> what should come next? R5RS string functions? the missing ones are:
>
> - string-ref
> - string-set!
> - substring
> - string-append
> - string-fill!
>
> - comparison procedures (string<?, string-ci<?, etc.)
>
> do we need all of them? if not, which ones? should we have ustr and
> udstr versions or just the latter?
>
I'd say they are all best implemented at hackerlab level and only
wrapped in libscm, since they might be useful for non-Pika code
also. For Pika, since it uses udstr, only udstr functions are needed.

> or should i tackle buckybits and extended unicode chars first, and
> implement the string functions directly in terms of them?
>
Proceed at your convinience; I'll keep an eye at your patchflow.

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]