[Top][All Lists]
[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.
Re: [Pika-dev] Starting work on strings from the scm side, Tom Lord, 2004/03/15