Re: Mutable vs immutable strings

2002-07-11 Thread John Porter
Dan Sugalski wrote: > Piers "Fermat" Cawley wrote: > > Oh yes, and I recently wiped it (p5 port included) by accident. > > And didn't have a backup. Ah well... > > That's just a bit of self-preservation on the part of the universe, > I expect... ;-P Then the universe hasn't evolved to the point

Re: Mutable vs immutable strings

2002-07-11 Thread Dan Sugalski
At 7:04 PM +0100 7/11/02, [EMAIL PROTECTED] wrote: >Ashley Winters <[EMAIL PROTECTED]> writes: >> Yes, my Scheme interpreter written in Perl6 is coming along nicely. Muahaha! >> (kidding, obviously) > >It's already been done. Though I had to back port the design to perl 5 >to make sure it was co

Re: Mutable vs immutable strings + PMC docs, method dispatch

2002-07-11 Thread Dan Sugalski
At 10:46 AM -0700 7/11/02, Scott Walters wrote: > >> There were serialization/deserialization in the PMC vtables at one >> point, but that's gone. I think I may add it back in, though of >> course no PMC is required to provide them. > >Please ! -=) > >Hi everyone. I'm going to try to take on s

Re: Mutable vs immutable strings

2002-07-11 Thread Dan Sugalski
At 11:37 PM -0700 7/10/02, Ashley Winters wrote: >On Wednesday 10 July 2002 08:18 pm, Melvin Smith wrote: >> I was referring to the above situation where a lexical might be optimized >> away without being stored in a pad (for %MY). > >I would *hope* %MY is only modified at compile-time. I wouldn

Re: Mutable vs immutable strings

2002-07-11 Thread Dan Sugalski
At 9:54 AM -0400 7/11/02, Clark C . Evans wrote: >On Wed, Jul 10, 2002 at 11:21:10AM -0400, Dan Sugalski wrote: >| I'm not sure that the place to enforce read-onlyness is at the >| string/buffer level. Doing it at the PMC level is more likely the >| right place to do it. > >Therefore, "read-onlyne

Re: Mutable vs immutable strings

2002-07-11 Thread Dan Sugalski
At 5:39 PM -0400 7/10/02, Melvin Smith wrote: >Its almost as if the only optimization will be for > >foreach my $i (1...1) > >where we know the type ahead of time. > >We've built this register based VM upon which Perl will probably be >the most non-optimized language. Things like exposing your

Re: Mutable vs immutable strings

2002-07-11 Thread Dan Sugalski
At 2:13 PM -0700 7/10/02, John Porter wrote: >Dan Sugalski wrote: >> John Porter wrote: >> > but what about non-PMC variables? >> >> Generally speaking, there aren't any. Everything else (in this case >> the buffer/string things) is for internal use only. Languages aren't >> supposed to expos

Re: Mutable vs immutable strings

2002-07-11 Thread Clark C . Evans
On Wed, Jul 10, 2002 at 11:21:10AM -0400, Dan Sugalski wrote: | I'm not sure that the place to enforce read-onlyness is at the | string/buffer level. Doing it at the PMC level is more likely the | right place to do it. Therefore, "read-onlyness" would be a property of any ole object and not jus

Re: Mutable vs immutable strings

2002-07-10 Thread Ashley Winters
On Wednesday 10 July 2002 08:18 pm, Melvin Smith wrote: > I was referring to the above situation where a lexical might be optimized > away without being stored in a pad (for %MY). I would *hope* %MY is only modified at compile-time. I wouldn'd be upset if Perl ignored my attempts to access %MY a

Re: Mutable vs immutable strings

2002-07-10 Thread Melvin Smith
At 04:34 PM 7/10/2002 -0600, Luke Palmer wrote: >On Wed, 10 Jul 2002, Melvin Smith wrote: > > > At 02:13 PM 7/10/2002 -0700, John Porter wrote: > > > > >Dan Sugalski wrote: > > > > John Porter wrote: > > > > > but what about non-PMC variables? > > > > > > > > Generally speaking, there aren't any.

Re: Mutable vs immutable strings

2002-07-10 Thread Ashley Winters
On Wednesday 10 July 2002 02:39 pm, Melvin Smith wrote: > > Since Perl vars type-morph themselves, Perl will use PMC types everywhere > that there is an exposed interface. Internally you could use an I/S/N > register. > > I see no reason why > > foreach my $i (@nums) { > ... > } > > should not u

Re: Mutable vs immutable strings

2002-07-10 Thread Luke Palmer
On Wed, 10 Jul 2002, Melvin Smith wrote: > At 02:13 PM 7/10/2002 -0700, John Porter wrote: > > >Dan Sugalski wrote: > > > John Porter wrote: > > > > but what about non-PMC variables? > > > > > > Generally speaking, there aren't any. Everything else (in this case > > > the buffer/string things) i

Re: Mutable vs immutable strings

2002-07-10 Thread Melvin Smith
At 02:13 PM 7/10/2002 -0700, John Porter wrote: >Dan Sugalski wrote: > > John Porter wrote: > > > but what about non-PMC variables? > > > > Generally speaking, there aren't any. Everything else (in this case > > the buffer/string things) is for internal use only. Languages aren't > > supposed to

Re: Mutable vs immutable strings

2002-07-10 Thread John Porter
Dan Sugalski wrote: > John Porter wrote: > > but what about non-PMC variables? > > Generally speaking, there aren't any. Everything else (in this case > the buffer/string things) is for internal use only. Languages aren't > supposed to expose strings directly. Languages are only supposed to e

Re: Mutable vs immutable strings

2002-07-10 Thread Dan Sugalski
At 10:21 AM -0700 7/10/02, John Porter wrote: >Dan Sugalski wrote: >> I'm not sure that the place to enforce read-onlyness is at the >> string/buffer level. Doing it at the PMC level is more likely the >> right place to do it. > >Yes; but what about non-PMC variables? Generally speaking, there

Re: Mutable vs immutable strings

2002-07-10 Thread John Porter
Dan Sugalski wrote: > I'm not sure that the place to enforce read-onlyness is at the > string/buffer level. Doing it at the PMC level is more likely the > right place to do it. Yes; but what about non-PMC variables? -- John Douglas Porter __

Re: Mutable vs immutable strings

2002-07-10 Thread Dan Sugalski
At 7:34 AM -0700 7/10/02, John Porter wrote: >Florian Haeglsperger wrote: >> But isn't this partly addressed with COW? >> . . . >> Thus I don't see a very big performance win in introducing mutable >> strings. > >Good point. > >But some people maintain that there could be a need for truly >"co

Re: Mutable vs immutable strings

2002-07-10 Thread John Porter
Florian Haeglsperger wrote: > But isn't this partly addressed with COW? > . . . > Thus I don't see a very big performance win in introducing mutable > strings. Good point. But some people maintain that there could be a need for truly "constant" strings, that should never be modified, and any a

Re: Mutable vs immutable strings

2002-07-10 Thread Florian Haeglsperger
I'm following this list only for a very short time now, and I don't have very much programming experience, so tell me if all this is pure nonsense. But isn't this partly addressed with COW? The way I understood Copy On Write, it means that if you "copy" a string, only some pointers are copied and

Re: Mutable vs immutable strings

2002-07-10 Thread John Porter
"Clark C . Evans" wrote: > So, I propose that Parrot supports both of these attitudes > of reasoning by using a flag. Initially, all strings > are 'mutable'. I concur with Clark. What he's proposing is (it seems to me) nothing more than a "read-only" flag, and that's as immutable as a variab

Re: Mutable vs immutable strings

2002-07-09 Thread Clark C . Evans
On Tue, Apr 23, 2002 at 04:13:24PM -0400, Dan Sugalski wrote: | Should strings in parrot be mutable or immutable? Right now we've a | mix, and that's untenable. Sorry to comment so late. I think that the choice above isn't good enough. You need both strings and buffers. I say this beacuse ther

RE: Mutable vs immutable strings

2002-04-25 Thread Fisher Mark
> Should strings in parrot be mutable or immutable? Right now we've a > mix, and that's untenable. I've improved (read: got working) 2 C++ string libraries in the past, both with mutable strings. As performance was a primary consideration on both systems that used these libraries, I chose to co

Re: Mutable vs immutable strings

2002-04-24 Thread Joe Wilson
I vote for mutable strings. Anything but immutable strings please! Java sucks as a string manipulation engine because of their immutable String class. The best GC and JIT in the world can't save it. High performance Java parsers generally write their own mutable string class for this very reaso

RE: Mutable vs immutable strings

2002-04-23 Thread Brent Dax
Andrew J Bromage: # On Tue, Apr 23, 2002 at 01:18:23PM -0700, Brent Dax wrote: # # > Three questions: # > # > 1. Which'll be faster? # # It depends on the application, but my money is on mutable # strings built on top of an immutable buffer. That's based on # looking at my own string-based P

Re: Mutable vs immutable strings

2002-04-23 Thread Andrew J Bromage
G'day all. On Tue, Apr 23, 2002 at 01:18:23PM -0700, Brent Dax wrote: > Three questions: > > 1. Which'll be faster? It depends on the application, but my money is on mutable strings built on top of an immutable buffer. That's based on looking at my own string-based Perl code, a lot of which i

RE: Mutable vs immutable strings

2002-04-23 Thread Brent Dax
Dan Sugalski: # Okay folks, time to hash this out once and for all. # # Should strings in parrot be mutable or immutable? Right now we've a # mix, and that's untenable. Three questions: 1. Which'll be faster? 2. Which'll be simpler? 3. Which is more important? --Brent Dax <[EMAIL PROTECTED]>

Mutable vs immutable strings

2002-04-23 Thread Dan Sugalski
Okay folks, time to hash this out once and for all. Should strings in parrot be mutable or immutable? Right now we've a mix, and that's untenable. -- Dan --"it's like this"--- Dan Sugalski