[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pika-dev] viewarch
From: |
Tom Lord |
Subject: |
Re: [Pika-dev] viewarch |
Date: |
Sat, 10 Jan 2004 23:01:34 -0800 (PST) |
> From: Matthew Dempsky <address@hidden>
> > on an unrelated note, these days i've nothing to hack on pika: as
> > always, suggestions are welcome! ;)
> If you don't have anything else to worry about, maybe now would be a
> good time to gather together some of Tom's emails from the srfi-50
> mailing list and stick them into the Pika notes under rationale for
> the FFI?
> On a side note, you should probably stay out of the
> libscm-numbers[-reps] directories if you're looking for something to
> do because I've done some serious remodeling in there. I'd recommend
> you download my scm--numbers branch, but it doesn't compile and a lot
> of the temporary names I've chosen were rather arbitrary until I could
> decide on better solutions -- some functions don't even exist as stubs
> yet.
Another possibility (jao): are you interested in strings?
I'm cranking (in bursts) some code in hackerlab in support of the
string type for Pika -- Unicode primitives and also stuff for
"edittable strings". I'm behind in writing test cases for that new
stuff and, if you'd like, I can try to split the (non-test) coding
tasks with you.
Very briefly: it's stuff related to unicode string manipulation and
also edittable text. My approach to edittable text is to represent
strings as splay trees (similar to "ropes" or "cords" -- c.f. Boehm
for examples and literature pointers). My approach to
splay-trees-for-strings is slightly novel [*] in that I'm using
_functional_ splay trees -- the splaying operation doesn't mutate an
existing tree but returns a new one (sharing structure with the old)
instead.
-t
[*] I say "novel" but, while I don't have a cite, I could swear that
this technique is one I picked up from 3rd hand rumours about lisp
machines.