[Cuis] Ropes (functional strings)

[Casey Ransberger]

Hey cool. Just got around to reading this. I dig it. I've had some moments
staring out windows and daydreaming about what a more functional Smalltalk
might look like. I think we err on the side of mutable designs too often.

I'm curious: what's the difference WRT performance? Has anyone looked?
Wouldn't it be a kick to find out that object allocation and storage ended
up being faster/smaller than what we have with the mutable structures? I
kind of want to see the difference in performance between the interpreter,
the stack VM and Cog. I missed the original message, and it looks like the
thread got split (at least from my POV) so can you point me at the code?

TIA!

On Mon, Feb 11, 2013 at 8:08 PM, Ken Dickey <Ken.Dickey at whidbey.com> wrote:

> Juan wrote:
>
> > Yesterday I played a bit to see how quickly the system would break if
> > #at: and #at:put: were banned for Strings.
>
> I did a simple, prototype implementation of Ropes, functional strings, for
> Cuis.
>
> Ropes are _immutable_ (constant) strings, and #at:put: returns a new Rope.
>  Internal data structures hide the details.
>
> The basic idea is that I had a utf-8 Rope and #at:put: a utf-32 Chinese
> character into it, then we would NOT have to change the utf-8 part just
> because of one character.  We could have separate 8/16/32 bit char-arrays
> supporting Unicode and do mix 'n match as we needed.
>
>         https://github.com/KenDickey/Cuis-Ropes
>
> Invoking
>         Rope openTextEditor
> brings up a simple text editor with a rope instead of a string.
>
> This seems to work OK for me, but more knowledgeable people should take a
> look.
>
> As this is a prototype, Rope>>doesNotUnderstand writes a message to the
> Transcript and re-sends it to its stringRepresentation.
>
> So far, I have only seen sends to #encompassParagraph, which I don't yet
> understand and did not implement.
>
> Anyway, feel free to take a look and let me know if you think it is useful.
>
> Cheers,
> -KenD
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>



-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130213/79ad5da8/attachment-0002.html>