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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
__
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
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
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
"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
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
> 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
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
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
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
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]>
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
27 matches
Mail list logo
