Re: Embrace polymorphic builtins, for they are cool.

2001-06-20 Thread Mark J. Reed
I would argue that eval BLOCK and eval STRING are closer than indicated by Mr. Schwern. In either case, you supply an argument which contains code, and that code is executed. As a small amount of protection from this dynamic element, fatal errors within the eval()ed code are trapped and prevente

Re: The internal string API

2001-06-20 Thread David L. Nicol
Dave Mitchell wrote: > some sort of clone method With tree strings, at clone time they get reorged into minimal number of nodes: back to one big block if they are all the same type, or back to one block for each type transition if it is tagged data. Having the basic string type support arbi

Re: Embrace polymorphic builtins, for they are cool.

2001-06-20 Thread David L. Nicol
> > Now look at eval. When acting on a string, it compiles and runs it as > code. When acting on a block, it traps any errors and prevents dying. > You may be able to come up with some weak analogies between the two, > but they're two different functionalities. i have nothing to add. you o

RE: The internal string API

2001-06-20 Thread Hong Zhang
> >> Taiwanese read traditional chinese characters, but PRC people read > > >> simplied chinese. Even we take the same data, and same program (code), > > >> people just read differently. As an end user, I want to make the decision. > > >> It will drive me crazy if Perl render/display the text fil

Re: The internal string API

2001-06-20 Thread Dan Sugalski
At 05:16 PM 6/20/2001 +, Nick Ing-Simmons wrote: >Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: > >> Taiwanese read traditional chinese characters, but PRC people read > >> simplied chinese. Even we take the same data, and same program (code), > >> people just read differently. As an end user,

Re: Embrace polymorphic builtins, for they are cool.

2001-06-20 Thread Michael G Schwern
On Mon, Jun 11, 2001 at 09:18:14PM -0500, David L. Nicol wrote: > But I'm digressing. What I want to talk about is overloaded builtins. > > I recently suggested that C be overloaded to make its argument, > when its argument is not a filehandle, become read-only. An objection > was made to this,

RE: The internal string API

2001-06-20 Thread Dan Sugalski
At 10:31 AM 6/20/2001 -0700, Hong Zhang wrote: > > The one problem with copy-on-write is that, if we implement it in >software, > > we end up paying the price to check it on every string write. (No free > > depending on the hardware, alas) > > > > Not that this should shoot down the idea of COW s

RE: The internal string API

2001-06-20 Thread Hong Zhang
> The one problem with copy-on-write is that, if we implement it in software, > we end up paying the price to check it on every string write. (No free > depending on the hardware, alas) > > Not that this should shoot down the idea of COW strings, but it is a cost > that needs considering. (I

Re: The internal string API

2001-06-20 Thread Nick Ing-Simmons
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: >> Taiwanese read traditional chinese characters, but PRC people read >> simplied chinese. Even we take the same data, and same program (code), >> people just read differently. As an end user, I want to make the decision. >> It will drive me crazy if P

Re: The internal string API

2001-06-20 Thread Dave Mitchell
Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 05:43 PM 6/19/2001 -0500, David L. Nicol wrote: > > set $B to copy-on-write mode, so future changes to $B do not > > affect $A > > The one problem with copy-on-write is that, if we implement it in software, > we end up paying the price to che

Re: The internal string API

2001-06-20 Thread Dan Sugalski
At 05:43 PM 6/19/2001 -0500, David L. Nicol wrote: > set $B to copy-on-write mode, so future changes to $B do not > affect $A The one problem with copy-on-write is that, if we implement it in software, we end up paying the price to check it on every string write. (No free depending on

Re: The internal string API

2001-06-20 Thread Dan Sugalski
At 03:17 PM 6/20/2001 +0200, Bart Lateur wrote: >On Tue, 19 Jun 2001 11:53:28 -0700, Hong Zhang wrote: > > >> * Do a substr operation by character and glyph > > > >The byte based is more useful. I have utf-8, and I want to substr it > >to another utf-8. It is painful to convert it or linear search

RE: The internal string API

2001-06-20 Thread Dan Sugalski
At 04:23 PM 6/19/2001 -0700, Hong Zhang wrote: >This is the common approach of complicated text representation, >the implemetations I have seen includes IBM IText and SGI >rope. For "rope", each rope is represented by either of a simple >immutable string, a simple mutable string, a simple immutab

Re: The internal string API

2001-06-20 Thread Bart Lateur
On Tue, 19 Jun 2001 11:53:28 -0700, Hong Zhang wrote: >> * Do a substr operation by character and glyph > >The byte based is more useful. I have utf-8, and I want to substr it >to another utf-8. It is painful to convert it or linear search for >charaacter >position. I tend to agree. I currently