Re: Unary dot
On Mon, Apr 15, 2002 at 11:03:15PM -0400, John Siracusa wrote:
> On 4/15/02 10:24 PM, Larry Wall wrote:
> > The main point of doing this isn't really the migration from Perl 5,
> > but a basic underlying philosophy of linguistics known as tagmemics.
> ("tagmemics"? ;)
Yay, tagmemics! :) Shall I offer an "Intro to Linguistics for Perl 6
Developers" class? That would be fun! We are, after all, rebirthing a
language here. Certainly it's an artificial language, but a language
used by humans and therefore subject to the same principles that govern
natural language.
Allison
Re: Unary dot
> Yay, tagmemics! :) Shall I offer an "Intro to Linguistics for Perl 6 > Developers" class? That would be fun! Please!!! -Miko "Wouldn't Know a Tagmemic if it Bit Him on the Parse" O'Sullivan
Re: Unary dot
On Sun, 2002-04-14 at 16:41, Dave Mitchell wrote:
> On Sat, Apr 13, 2002 at 05:07:37PM -0700, Larry Wall wrote:
[...]
> > my $self = invocant;
> >
> > or some such mummery. But that seems a bit retro.
>
> But now we have endless possibilities for
> $self.ish
> $self.less
> $self.centred
> $self.obsessed
our $haiku is easier;
for $self.less -> @friendship {
my $time is required but
frequently; 2 _ 'rare';
}
Re: Unary dot
On Tue, Apr 16, 2002 at 09:29:21AM -0400, Miko O'Sullivan wrote: > > "Wouldn't Know a Tagmemic if it Bit Him on the Parse" Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I like it! :) Allison
Tagmem* (was Unary dot)
> > "Wouldn't Know a Tagmemic if it Bit Him on the Parse" > > Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I > like it! :) You got it! I hope this isn't too off topic, but... is the word "tagmeme" somehow related to the urban legend concept of a cultural "meme"? -Miko
Re: Unary dot
On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
> So the main reason that objects can function as hashes is so that the
> user can poke an object into an interface expecting a hash and have it
> "make sense", to the extent that the object is willing to be viewed like
> that.
AKA the uniform access principle.
This was something that I was very keen to exploit in the Template Toolkit
where foo.bar is interpreted as "Do(t) The Right Thing" to access the
'bar' part of 'foo', be it the 'bar' key in the 'foo' hash or the 'bar'
method of the 'foo' object. The result is, of course, that you can use
a hash of static data one day (great for mocking up web pages for example)
and later upgrade it to an object which fetches/generates data on demand
(e.g. from a database) when you put your pages into production.
Alas, I also designed a flaw into the system by introducing "virtual
methods" that TT automatically applies onto various data types, equivalent
to various Perl functions, e.g. somehash.keys or somelist.size. As
convenient as this is, the problem lies in the fact that you can't
differentiate somehash.keys between the Perl equivalents of C
or C<$hash->{keys}>.
So my thought for version 3 of TT is to introduce somehash.{keys} as
a syntax to mean "only the 'keys' key/method of the 'foo' hash/object
but *NOT* the 'keys' virtual method" and to leave somehash.keys resolving
to the virtual method as it currently does.
Am I right in thinking that this would then be (roughly) consistent with
the Perl 6 syntax?
e.g.
TT3 Perl 6 Perl 5 (hash) Perl 5 (obj)
foo.keys $foo.keys keys %$foo $foo->keys()
foo.{keys} $foo.{keys} $foo->{keys} $foo->keys()
Hang on, now I'm a little confused - I thought that hashes were supposed
to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
But then that would then violate the uniform access principle because
hash/key access has a different syntax from object/method?
Have I missed a vital clue?
A
Hashes, Stringification, Hashing and Strings
In this example:
%hash = ($a=>$b);
$a can be anything. In fact, since Perl6 promises to retain the original
value of $a, we're rather encouraged to store complex data there. But,
this poses a problem. The key to use for hashing might not ideally be
the string representation.
For example, if I'm hashing a collection of special file objects, it
might be useful in one context to do:
method operator:qq () {
return read_whole_file();
}
But, if I have 100 of these objects, and I try to put them in a hash,
life could get ugly fast!
More helpful would be to have this builtin:
method operator:hash () {
return operator:qq();
}
and then allow me to override it in my class like so:
method operator:hash () {
return filename();
}
This allows me to specify separate hashing and stringification methods,
but retains Perl's original default of combining the two.
Re: Hashes, Stringification, Hashing and Strings
Aaron Sherman writes:
: In this example:
:
: %hash = ($a=>$b);
:
: $a can be anything. In fact, since Perl6 promises to retain the original
: value of $a, we're rather encouraged to store complex data there. But,
: this poses a problem. The key to use for hashing might not ideally be
: the string representation.
:
: For example, if I'm hashing a collection of special file objects, it
: might be useful in one context to do:
:
: method operator:qq () {
: return read_whole_file();
: }
:
: But, if I have 100 of these objects, and I try to put them in a hash,
: life could get ugly fast!
:
: More helpful would be to have this builtin:
:
: method operator:hash () {
: return operator:qq();
: }
:
: and then allow me to override it in my class like so:
:
: method operator:hash () {
: return filename();
: }
:
: This allows me to specify separate hashing and stringification methods,
: but retains Perl's original default of combining the two.
Yes, that's what we intend to do.
Larry
Re: Tagmem* (was Unary dot)
Miko O'Sullivan writes: : > > "Wouldn't Know a Tagmemic if it Bit Him on the Parse" : > : > Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I : > like it! :) : : You got it! : : I hope this isn't too off topic, but... is the word "tagmeme" somehow : related to the urban legend concept of a cultural "meme"? Not really. Pike predates Dawkins, who I believe made up the term. (Could be wrong about that.) They are similar concepts, however, in that a tagmeme is a psychological linguistic construct that propagates culturally. It's certainly possible that Dawkins read Pike. But it's also quite likely that he didn't, and made up "meme" as a portmanteau on "gene" and "memory". Doubtless the latest OED could shed some light on that. Larry
Re: Hashes, Stringification, Hashing and Strings
On Tue, 2002-04-16 at 12:21, Larry Wall wrote: > Aaron Sherman writes: > : This allows me to specify separate hashing and stringification methods, > : but retains Perl's original default of combining the two. > > Yes, that's what we intend to do. You can make a man feel so small ;-) Thanks for the confirmation!
Re: pasm.el and looping ops
At 8:21 PM +0200 4/14/02, Marco Baringer wrote: >i have written 4 different forms of looping ops with varying degrees >of usefullness. i think that if these were to are accepted the form >which gets used the most in real code should be renamed 'loop' (of >course, since most code is/will be machine generated this may be >completly irrelavent). > >comments/suggestions/criticisms regarding both pasm.el and the loop >ops would be greatly appreciated. I'm really glad the emacs mode is in--thanks for that one. I like the idea of the loop ops. I think we'll do them, but I want to sketch out a group of them first, for coherency. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Assembler Strings
Hey,
Clint brought a small assembler string but to my attention, and I found
another bug while fixing the first. Bugs were:
a) 'a"b"c' was turned into 'a[sc:1]c' before being turned into [sc:2]
b) 'a\"b' was printing being stored as a\"b and not a"b
Below patch fixes. Not sure if my use of the #" 'construct' is good or
bad. :)
Mike Lambert
Index: lib/Parrot/Assembler.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/Assembler.pm,v
retrieving revision 1.20
diff -u -r1.20 Assembler.pm
--- lib/Parrot/Assembler.pm 10 Mar 2002 21:15:50 - 1.20
+++ lib/Parrot/Assembler.pm 16 Apr 2002 17:32:55 -
@@ -679,8 +679,7 @@
sub replace_string_constants {
my $code = shift;
- $code =~ s{([NU])?"(((\\")|[^"])*)"}{constantize_string($2, $1)}egx;
- $code =~ s{([NU])?'(((\\')|[^'])*)'}{constantize_string($2, $1)}egx;
+ $code =~ s{([NU]?)(["'])((?:(?:\\\2)|(?!\2).)*)\2}{constantize_string($3, $1)}egx;
+#"
return $code;
}
@@ -1371,7 +1370,9 @@
'n' => "\n",
'r' => "\r",
't' => "\t",
-'\\' => '\\'
+'\\' => '\\',
+'"' => '"',
+"'" => "'",
);
sub constantize_string {
@@ -1384,7 +1385,7 @@
$s=~s/\\(0\d*)/chr(oct($1))/eg;
$s=~s/\\x([0-9a-fA-F]{1,2})/chr(hex($1))/ge;
-$s=~s/\\([anrt\\])/$escape{$1}/ge;
+$s=~s/\\([anrt\\'"])/$escape{$1}/ge; #"
if(!exists($constants{$s}{s}{$e})) {
push(@constants, ['s', $s, $e]);
Index: t/op/string.t
===
RCS file: /cvs/public/parrot/t/op/string.t,v
retrieving revision 1.19
diff -u -r1.19 string.t
--- t/op/string.t 14 Mar 2002 18:45:22 - 1.19
+++ t/op/string.t 16 Apr 2002 17:32:55 -
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 64;
+use Parrot::Test tests => 65;
output_is( <<'CODE', <
Re: Tagmem* (was Unary dot)
On Tue, 16 Apr 2002 09:34:36 -0700 (PDT), Larry Wall <[EMAIL PROTECTED]> wrote: > Pike predates Dawkins, who I believe made up the term. > (Could be wrong about that.) They are similar concepts, however, in > that a tagmeme is a psychological linguistic construct that propagates > culturally. It's certainly possible that Dawkins read Pike. But it's > also quite likely that he didn't, and made up "meme" as a portmanteau > on "gene" and "memory". On _THE SELFISH GENE_ Dawkins says he coined the term, which was a more euphonic version of "mimeme": http://www.santafe.edu/~shalizi/formerly-hyper-weird/memetics.html /L/e/k/t/u
Re: Hashes, Stringification, Hashing and Strings
Speaking of which, how do we ensure the immutability of keys being put
into the hash? I think Perl copied the string, so that:
$b = "aa";
$a{$b} = 1;
chop $b;
print $a{"aa"};
still works.
If we start storing full thingies into the keys of a hash, we either need
to make deep copies of these, or copy enough to ensure the hashing
function has all that it needs.
Say we do:
$b = new Cat();
$a{$b} = 1;
$b->somefunctionthatchangesthehashvalue();
$a{$b} doesn't find anything, since $b was hashed under it's old identity.
Also, Perl allowed this before:
$b = "aa";
%a{$b} = 1;
print $a{"aa"};
Will it allow this?
$b = new Cat();
%a{$b} = 1;
print $a{new Cat()};
If it does, how does it determine equality of two objects? What if Cat
includes a counter that determines which number it is in some total
ordering of cats. Will the above still work?
Java had all sorts of problems where they force immutability of an object
onto the user of their Collection API. It's a pain in the ass, and the
source of stupid bugs, where your object changes it's hash value without
being rehashed. How will perl handle this?
If it automatically rehashed objects in whatever tables they are stored in
(forget the speed hit for now), then we still have the problem of:
$a = "a";
%c{$a} = 1;
$b = "aa";
%c{$b} = 2;
chop $b;
print %c{"a"}; #what gets printed?
According to perl 5 semantics, this would print 1. But according to the
rehashing rule above, this is ambiguous. So that's not an option.
I personally liked the stringification of keys. It made things a LOT
simpler. :)
Finally, one last option is to hash based on some memory address, so that
when we store objects in there, we can be assured of no two of them
pointing to the same place, or worrying about the hash function changing.
Assuming we work around our copying GC some way to get a unique object
identity value, we still have the problem of two equivalent strings
hashing to different places, or two equivalent arrays hashing to different
values. I can make a case for the latter being a good thing, but not the
former, as it breaks perl5 semantics.
Two options I see are:
a) stringify everything, and make life simpler. I never really had a
problem with stringified keys...
b) strings get hashed like perl5. everything else gets hashed based
on some unique object identifier (memory address) that's constant
throughout the life of the object. This means that in order for an object
to be able to have equality work in hashtables, from two objects
constructed at different points in time, they'd need to overload the
operator:hash() function to return a string.
Or has this matter been thought through already?
Thanks,
Mike Lambert
Aaron Sherman wrote:
> Date: 16 Apr 2002 12:13:55 -0400
> From: Aaron Sherman <[EMAIL PROTECTED]>
> To: Perl6 Language List <[EMAIL PROTECTED]>
> Subject: Hashes, Stringification, Hashing and Strings
>
> In this example:
>
> %hash = ($a=>$b);
>
> $a can be anything. In fact, since Perl6 promises to retain the original
> value of $a, we're rather encouraged to store complex data there. But,
> this poses a problem. The key to use for hashing might not ideally be
> the string representation.
>
> For example, if I'm hashing a collection of special file objects, it
> might be useful in one context to do:
>
> method operator:qq () {
> return read_whole_file();
> }
>
> But, if I have 100 of these objects, and I try to put them in a hash,
> life could get ugly fast!
>
> More helpful would be to have this builtin:
>
> method operator:hash () {
> return operator:qq();
> }
>
> and then allow me to override it in my class like so:
>
> method operator:hash () {
> return filename();
> }
>
> This allows me to specify separate hashing and stringification methods,
> but retains Perl's original default of combining the two.
>
>
>
Re: Hashes, Stringification, Hashing and Strings
On Tue, 2002-04-16 at 14:00, Mike Lambert wrote:
> Speaking of which, how do we ensure the immutability of keys being put
> into the hash? I think Perl copied the string, so that:
>
> $b = "aa";
> $a{$b} = 1;
> chop $b;
> print $a{"aa"};
>
> still works.
>
> If we start storing full thingies into the keys of a hash, we either need
> to make deep copies of these, or copy enough to ensure the hashing
> function has all that it needs.
I thought about this myself, and I don't think Perl would do it that
way. Please, Larry, et al. correct me if I'm wrong.
I suspect it would involve:
1. Copying the key (which might be a reference) on insertion.
2. Hashing once, and caching the hash.
This means a minimum of overhead, so it's a good thing. It also means
that the structure of your hash would never need to re-compute if the
hash of a particular object changes (which I would imagine it could
easily do in any number of cases).
Re: Unary dot
Andy Wardley <[EMAIL PROTECTED]> writes:
> On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
>> So the main reason that objects can function as hashes is so that the
>> user can poke an object into an interface expecting a hash and have it
>> "make sense", to the extent that the object is willing to be viewed like
>> that.
>
> AKA the uniform access principle.
>
> This was something that I was very keen to exploit in the Template Toolkit
> where foo.bar is interpreted as "Do(t) The Right Thing" to access the
> 'bar' part of 'foo', be it the 'bar' key in the 'foo' hash or the 'bar'
> method of the 'foo' object. The result is, of course, that you can use
> a hash of static data one day (great for mocking up web pages for example)
> and later upgrade it to an object which fetches/generates data on demand
> (e.g. from a database) when you put your pages into production.
>
> Alas, I also designed a flaw into the system by introducing "virtual
> methods" that TT automatically applies onto various data types, equivalent
> to various Perl functions, e.g. somehash.keys or somelist.size. As
> convenient as this is, the problem lies in the fact that you can't
> differentiate somehash.keys between the Perl equivalents of C
> or C<$hash->{keys}>.
>
> So my thought for version 3 of TT is to introduce somehash.{keys} as
> a syntax to mean "only the 'keys' key/method of the 'foo' hash/object
> but *NOT* the 'keys' virtual method" and to leave somehash.keys resolving
> to the virtual method as it currently does.
>
> Am I right in thinking that this would then be (roughly) consistent with
> the Perl 6 syntax?
>
> e.g.
>
> TT3 Perl 6 Perl 5 (hash) Perl 5 (obj)
>
> foo.keys $foo.keys keys %$foo $foo->keys()
> foo.{keys} $foo.{keys} $foo->{keys} $foo->keys()
>
> Hang on, now I'm a little confused - I thought that hashes were supposed
> to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
> But then that would then violate the uniform access principle because
> hash/key access has a different syntax from object/method?
$foo = %hash; # Take a reference to %hash;
$foo.{keys} # get the value keyed by 'keys' in the hash refered
# to by $foo.
$bar = Object.new # Make an object
$bar.{keys} # Get the value of $bar's '$.keys' instance
# variable.
I think that the '.' is optional in this case too...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Scary things
Also known as constructs you wish you hadn't discovered.
So, I'm reading through Finkel and I came across the following, which
computes the greatest common divisor of a and b (recast into perl6ish
syntax)
while {
when $a < $b { $b -= $a }
when $b < $a { $a -= $b }
}
The idea is that the loop keeps on looping until none of the guard
conditions match. This can be redone in 'real' Perl 6 as
while 1 {
given 1 {
when $a < $b { $b -= $a }
when $b < $a { $a -= $b }
else { last }
}
}
I'm not sure about the 'break'ing behaviour of a C that isn't in
a C block so I've introduced a 'dummy' one here. Maybe Larry
can clarify.
So, do we want this monstrosity? I confess that I did find myself
using something like it occasionally when I was working on the scheme
evaluator, but it looks very weird indeed.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Hashes, Stringification, Hashing and Strings
On 4/16/02 11:00 AM, "Mike Lambert" <[EMAIL PROTECTED]> claimed:
> Speaking of which, how do we ensure the immutability of keys being put
> into the hash? I think Perl copied the string, so that:
>
> $b = "aa";
> $a{$b} = 1;
> chop $b;
> print $a{"aa"};
>
> still works.
>
> If we start storing full thingies into the keys of a hash, we either need
> to make deep copies of these, or copy enough to ensure the hashing
> function has all that it needs.
>
> Say we do:
> $b = new Cat();
> $a{$b} = 1;
> $b->somefunctionthatchangesthehashvalue();
> $a{$b} doesn't find anything, since $b was hashed under it's old identity.
But these aren't really equivalent, are they? In the first, you use a
variable ($b) to create the key, and then a constant ("aa") to reference it.
In the second example, you use the variable to both create and reference the
hash value. So really you should do the same for the Perl 5 example:
$b = "aa";
$a{$b} = 1;
chop $b;
print $a{$b}; # No key found (will it be autovivified, BTW?)
Or you should do the opposite, make the Perl 6 example equivalent.
# "aa" will be used for the hash key, as specified by Cat's
# C spec.
$b = new Cat("aa");
$a{$b} = 1;
$b->somefunctionthatchangesthehashvalue();
$a{"aa"}; # Key found.
> I personally liked the stringification of keys. It made things a LOT
> simpler. :)
I suspect that you'll still be able to do this.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Hashes, Stringification, Hashing and Strings
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Tue, 2002-04-16 at 14:00, Mike Lambert wrote:
>> Speaking of which, how do we ensure the immutability of keys being put
>> into the hash? I think Perl copied the string, so that:
>>
>> $b = "aa";
>> $a{$b} = 1;
>> chop $b;
>> print $a{"aa"};
>>
>> still works.
>>
>> If we start storing full thingies into the keys of a hash, we either need
>> to make deep copies of these, or copy enough to ensure the hashing
>> function has all that it needs.
>
>
> I thought about this myself, and I don't think Perl would do it that
> way. Please, Larry, et al. correct me if I'm wrong.
>
> I suspect it would involve:
>
> 1. Copying the key (which might be a reference) on insertion.
> 2. Hashing once, and caching the hash.
>
> This means a minimum of overhead, so it's a good thing. It also means
> that the structure of your hash would never need to re-compute if the
> hash of a particular object changes (which I would imagine it could
> easily do in any number of cases).
So you'd have:
%hash{$some_obj} = $aValue;
$some_obj.mutator;
exists %hash{$some_obj} # returns undef.
Somehow I *really* don't think that's going to fly.
Personally I'd like the default hash to return some immutable, unique
and probably opaque object id (something the like
'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but
probably not identical). This isn't going to change as an object's
contents change.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Scary things
At 05:51 PM 04-16-2002 +0100, Piers Cawley wrote:
>Also known as constructs you wish you hadn't discovered.
>
>So, I'm reading through Finkel and I came across the following, which
>computes the greatest common divisor of a and b (recast into perl6ish
>syntax)
>
> while {
> when $a < $b { $b -= $a }
> when $b < $a { $a -= $b }
> }
>
>The idea is that the loop keeps on looping until none of the guard
>conditions match.
I believe that it also has exactly one guarded clause executed per loop, no
matter how many guard conditions are true. So the following would be legal:
while {
when $a < $b {$b -= $a; print "First clause\n"; }
when $b < $c {$c -= $b; print "Second clause\n"; }
when $c < $a {$a -= $c; print "Third clause\n"; }
}
and if it started with ($a,$b,$c) = (3, 18, 24) there is no guarantee what
order it would print in, but it would stop when ($a, $b, $c) == (3,3,3).
>So, do we want this monstrosity? I confess that I did find myself
>using something like it occasionally when I was working on the scheme
>evaluator, but it looks very weird indeed.
It's weirder when you allow multiple guard conditions to be true with no
guarantee of evaluation order. But I see no reason to disallow it.
Re: Hashes, Stringification, Hashing and Strings
On 4/16/02 11:57 AM, "Piers Cawley" <[EMAIL PROTECTED]> claimed: > Personally I'd like the default hash to return some immutable, unique > and probably opaque object id (something the like > 'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but > probably not identical). This isn't going to change as an object's > contents change. I would agree that such a default would be preferable, as long as I could overload it with my own idea of what the hash key should be. This will be useful for database applications, where I could have two separate objects that loaded the same data from the database, and are therefore "the same object," even though they wouldn't have the same OID. So I'd want to be able to say, for hash keys, use a key I define (probably including a primary key ID from the database). Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Scary things
Piers Cawley writes:
: Also known as constructs you wish you hadn't discovered.
:
: So, I'm reading through Finkel and I came across the following, which
: computes the greatest common divisor of a and b (recast into perl6ish
: syntax)
:
: while {
: when $a < $b { $b -= $a }
: when $b < $a { $a -= $b }
: }
:
: The idea is that the loop keeps on looping until none of the guard
: conditions match. This can be redone in 'real' Perl 6 as
:
: while 1 {
: given 1 {
: when $a < $b { $b -= $a }
: when $b < $a { $a -= $b }
: else { last }
: }
: }
Well, it's "default", not "else", but it's redundant in any case, since
the Cs would fall through.
: I'm not sure about the 'break'ing behaviour of a C that isn't in
: a C block so I've introduced a 'dummy' one here. Maybe Larry
: can clarify.
Could be written:
loop {
when $a < $b { $b -= $a; next }
when $b < $a { $a -= $b; next }
last;
}
A C that is a boolean doesn't reference a given. It'd be nice to
get rid of the C, but C isn't naturally a topicalizer.
Could say:
for 0..Inf {
when $a < $b { $b -= $a }
when $b < $a { $a -= $b }
last;
}
The optimizer might well pick up that $_ is unreferenced and optimize
the 0..Inf away. Still, the first way looks cleaner to me.
: So, do we want this monstrosity? I confess that I did find myself
: using something like it occasionally when I was working on the scheme
: evaluator, but it looks very weird indeed.
Depending on whether we define -> as the "topicalizing arrow", we might
be able to go as far as
loop -> {
when $a < $b { $b -= $a }
when $b < $a { $a -= $b }
last;
}
That makes C and C special cases, in that they default to
C<< -> $_ >> when you don't supply the topic arrow. Defining ->
this way has the additional advantage of providing a clean way
to say "there is no topic for this closure". I believe the apo had
given () { ... }
but this way we could have
given -> { ... }
and guarantee that all the tests are boolean. Plus -> could be used
anywhere else that made sense to hang an argumentless block.
It could be argued that bare
-> { ... }
should default to
-> $_ { ... }
but I think the fact that C and C already default to $_
makes that not so important. Plus we'd have to write something like
-> () { ... }
to mean argumentless, and that's not so nice. So I think a bare topic
arrow means topicless. (Careful how you say that.)
Anyway, much of the time you want a topic, you'd want to write
-> $_ is rw { ... }
In fact, that's what C and C actually default to, I think.
Larry
Re: Hashes, Stringification, Hashing and Strings
On Tue, Apr 16, 2002 at 02:00:33PM -0400, Mike Lambert wrote: > Speaking of which, how do we ensure the immutability of keys being put > into the hash? I think Perl copied the string, so that: RFC266 talks about these issues, though it was just really my take on the problem at the time. http://dev.perl.org/rfc/266.pod
Re: Scary things
Buddha Buck writes: : It's weirder when you allow multiple guard conditions to be true with no : guarantee of evaluation order. But I see no reason to disallow it. Well, Perl would guarantee the order. I can see situations where it'd be better to force a random pick to avoid starvation problems. But the number of times I've needed such a construct can be counted on the thumbs of one hand, give or take an order of magnitude. Larry
Re: Hashes, Stringification, Hashing and Strings
Piers Cawley writes:
: Aaron Sherman <[EMAIL PROTECTED]> writes:
:
: > On Tue, 2002-04-16 at 14:00, Mike Lambert wrote:
: >> Speaking of which, how do we ensure the immutability of keys being put
: >> into the hash? I think Perl copied the string, so that:
: >>
: >> $b = "aa";
: >> $a{$b} = 1;
: >> chop $b;
: >> print $a{"aa"};
: >>
: >> still works.
: >>
: >> If we start storing full thingies into the keys of a hash, we either need
: >> to make deep copies of these, or copy enough to ensure the hashing
: >> function has all that it needs.
: >
: >
: > I thought about this myself, and I don't think Perl would do it that
: > way. Please, Larry, et al. correct me if I'm wrong.
: >
: > I suspect it would involve:
: >
: > 1. Copying the key (which might be a reference) on insertion.
: > 2. Hashing once, and caching the hash.
: >
: > This means a minimum of overhead, so it's a good thing. It also means
: > that the structure of your hash would never need to re-compute if the
: > hash of a particular object changes (which I would imagine it could
: > easily do in any number of cases).
:
: So you'd have:
:
:%hash{$some_obj} = $aValue;
:$some_obj.mutator;
:exists %hash{$some_obj} # returns undef.
:
: Somehow I *really* don't think that's going to fly.
:
: Personally I'd like the default hash to return some immutable, unique
: and probably opaque object id (something the like
: 'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but
: probably not identical). This isn't going to change as an object's
: contents change.
You guys are thinking in terms of a single $obj.hash method. I think
there will be more than one hashish (er...) method available, and each
hash will be able to choose at least whether it wants to hash by $obj._
(the default), by $obj.hash (mutable), or by $obj.id (immutable). The
hash function is not sufficient in cases of hash collision, so you also
need to think in terms of multiple comparison methods.
Since these are just properties of the hash, the hash could even have
properties containing closures that define the hash and/or comparison
functions. These properties can force the issue, regardless of whether
the object in question cooperates. So you could hash objects on any
attribute or combination of attributes, for instance.
But the default is gonna look a lot like Perl 5.
Larry
Re: Hashes, Stringification, Hashing and Strings
On 4/16/02 12:27 PM, "Larry Wall" <[EMAIL PROTECTED]> claimed: > You guys are thinking in terms of a single $obj.hash method. I think > there will be more than one hashish (er...) method available, and each > hash will be able to choose at least whether it wants to hash by $obj._ > (the default), by $obj.hash (mutable), or by $obj.id (immutable). The > hash function is not sufficient in cases of hash collision, so you also > need to think in terms of multiple comparison methods. Wow, that will be pretty cool, I think. > Since these are just properties of the hash, the hash could even have > properties containing closures that define the hash and/or comparison > functions. These properties can force the issue, regardless of whether > the object in question cooperates. So you could hash objects on any > attribute or combination of attributes, for instance. Yes, this sounds ideal to me. > But the default is gonna look a lot like Perl 5. That's certainly good enough for me! Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Unary dot
Piers Cawley writes:
: Andy Wardley <[EMAIL PROTECTED]> writes:
: > Hang on, now I'm a little confused - I thought that hashes were supposed
: > to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
: > But then that would then violate the uniform access principle because
: > hash/key access has a different syntax from object/method?
%foo is just a typed reference varaible. $foo works just about as well.
: $foo = %hash; # Take a reference to %hash;
I'd say "Copy a reference", since I think of %hash as a reference already.
: $foo.{keys} # get the value keyed by 'keys' in the hash refered
: # to by $foo.
: $bar = Object.new # Make an object
: $bar.{keys} # Get the value of $bar's '$.keys' instance
: # variable.
Mmm. I think it always calls the virtual method, which might or might
not map directly to $.keys, depending on how fancy the accessors get.
If you want a particular type's method regardless of the actual type of
the object, you have to do as in Perl 5 and say
$bar.This::Type::keys()
: I think that the '.' is optional in this case too...
Yes, as long as there's no whitespace before it. I imagine some style
guides will require the dot for that reason. I can just see some poor
schmuck walking out of a job interview because the company requires
dots on all hash subscripts. :-)
Larry
Re: Hashes, Stringification, Hashing and Strings
David Wheeler <[EMAIL PROTECTED]> writes: > On 4/16/02 11:57 AM, "Piers Cawley" <[EMAIL PROTECTED]> claimed: > >> Personally I'd like the default hash to return some immutable, unique >> and probably opaque object id (something the like >> 'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but >> probably not identical). This isn't going to change as an object's >> contents change. > > I would agree that such a default would be preferable, as long as I could > overload it with my own idea of what the hash key should be. This will be > useful for database applications, where I could have two separate objects > that loaded the same data from the database, and are therefore "the same > object," even though they wouldn't have the same OID. So I'd want to be able > to say, for hash keys, use a key I define (probably including a primary key > ID from the database). Ah yes. I'm currently doing something like that trick with a home rolled object store. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: pasm.el and looping ops
[Apologies to Marco if he's getting this twice; this message didn't seem to go out the first time I sent it.] On Sun, Apr 14, 2002 at 08:21:51PM +0200, Marco Baringer wrote: > > i have written 4 different forms of looping ops with varying degrees > of usefullness. i think that if these were to are accepted the form > which gets used the most in real code should be renamed 'loop' (of > course, since most code is/will be machine generated this may be > completly irrelavent). Could you describe better the need and usefulness of these ops? My immediate reaction is "Why not just code loops ourselves?" I think your ops can be implemented in two currently-existing opcodes apiece, and I'm guessing that JIT support for the more primitive ops is going to appear before support for the loop ops. On the other hand, I may be overlooking a good reason for adding these. The two reasons I can think of right now are (1) you've done benchmarking and combining these ops demonstrates a significant speedup or (2) some hardware architectures have native instructions for the loop ops that are measurably more efficient than the direct translation of the primitive op pair. (Though I doubt that; the primitives are at least as easy for the hardware to parallelize and neither possibility touches any more or less data memory.)
Re: PML - Parrot Mark Language
On Sat, Apr 13, 2002 at 01:55:30AM +0200, Marco Baringer wrote: > > sorry, the body of that message got lost: > > parrot is a cool technology, but it's s buzzword-lacking. well, > here's the solution: xml based assembler! For those of you who were as lazy as I was and didn't bother to untar this, I took the liberty of extracting the POD and pasting it below. I would nominate this for inclusion at parrot/languages/sick/sick/sick, but then we'd have to argue over exactly what level of that hierarchy should contain the BASIC interpreter. You guys scare me. --- =head1 NAME pmlc - Parrot Markup Language Compiler. =head1 SYNOPSIS ../pmlc prog.pml > prog.pasm ../assemble.pl prog.pasm > prog.pbc ../parrot prog.pbc =head1 DESCRIPTION Parrot assembler may be great for writing fast, dynamic, high level languages which allow for both rapid prototyping and industrial strength application development, but it's got one major problem which will stop it from gaining industry wide acceptence: it's not portable, in other words, it's not XML. PML is here to solve that problem. Advantages of using PML: =over =item Increased Productivity A panel of highly acclaimed industry accedemics were contacted to perform an in-depth analysis of how PML could increase programmer productivity, they determined that a simple program to add two numbers and print the result was a measly 9 lines of code in PASM, this same program written in PML turned out to be an incredible 60 (yes, you read right, I<60>) lines of code. That's a 666% increase in productivity, you'll be smashing the competition in no time. =item Increased Portability By using fully conformant XML PML ensures that no matter what operating system or underlying hardware you use to work with your PML code it will always be the same. Imagine being able to work on some code on your PDA while flying back from the caribean and then transfer the code to your desktop machine and continue your work, without ever worrying about big-endianess or network-order, or level 2 protocol compatibility problems! =item Increased Legibility XML is an industry wide standard which is being used in every sector of the IT world. By moving away from PASM's obselete line based formatting and using pure 100% XML you ensured that all of your programmers will understand and be able to use your code base. =item Fully defined syntax By using the DTD in pml.dtd and a validating parser all sytatic erros can be caught before the program is even compiled, theryby shortening the usual edit-compile-debug loop. =back =cut
Re: [PATCH] Assembler Strings
At 1:41 PM -0400 4/16/02, Mike Lambert wrote: >Clint brought a small assembler string but to my attention, and I found >another bug while fixing the first. Bugs were: >a) 'a"b"c' was turned into 'a[sc:1]c' before being turned into [sc:2] >b) 'a\"b' was printing being stored as a\"b and not a"b The patch for the first looks good, but I'm not sure about the second. Have we settled on the behavior of single-quoted strings? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] Assembler Strings
I've been using single-quoted strings in the assembler interchangeably with double-quoted strings only because I couldn't find an easier way to say: set S0, 'Dan said, "UGH!"' Unless I used \ sequences for the double-quotes. Personally, I'm in favor of keeping ' and " functionally equivalent in the assembler -- just delimiters. Building too much smarts in the assembler (What'll we do with `` ?) is misdirected effort...
Re: Hashes, Stringification, Hashing and Strings
On Tue, 2002-04-16 at 14:57, Piers Cawley wrote:
> Aaron Sherman <[EMAIL PROTECTED]> writes:
> > I suspect it would involve:
> >
> > 1. Copying the key (which might be a reference) on insertion.
> > 2. Hashing once, and caching the hash.
> >
> > This means a minimum of overhead, so it's a good thing. It also means
> > that the structure of your hash would never need to re-compute if the
> > hash of a particular object changes (which I would imagine it could
> > easily do in any number of cases).
>
> So you'd have:
>
>%hash{$some_obj} = $aValue;
>$some_obj.mutator;
>exists %hash{$some_obj} # returns undef.
>
> Somehow I *really* don't think that's going to fly.
>
> Personally I'd like the default hash to return some immutable, unique
> and probably opaque object id (something the like
> 'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but
> probably not identical). This isn't going to change as an object's
> contents change.
I don't see why your above example would behave as you suggest. Larry
has already put in his TMTOWTDI comment, but let's look back at what I
said, using your example:
%hash{$some_obj} = $aValue;
1. Copy the key (possibly a reference)
%hash.magic_key_store($some_obj)
2. Cache the hash of that key
%hash.magic_hash_store($some_obj.hash())
Now, you suggest:
$some_obj.mutator;
exists %hash{$some_obj} # returns undef.
Well, if you want that behavior, I'm sure you can get it by redefining
hash() (or whatever the operator/method/whatever is called), but I don't
suggest it in the normal case. By default, as I've suggested in previous
mail the string representation should be used for hashing, which would
lead to that second statement returning true, since $some_obj still has
the same string representation.
Then again, if you're hashing by (as in my previous example) file name,
then you might want to change the hash of your object when it represents
a different file (say, you call an open method on it). There's good
cause to want to do that.
What I was saying above, however, was that you don't want to have to
re-compute your internal hash structure on the fly, hence caching the
hash of your object. That way, if an object returns a 1k block from
/dev/random as it's hash, you don't re-build the entire hash every time
you access an element, which would be absurdly unfortunate. Is there
ever a reason to want to do that?
Re: Tagmem* (was Unary dot)
Juanma Barranquero wrote: > On _THE SELFISH GENE_ Dawkins says he coined the term, which was a more > euphonic version of "mimeme": On quickly scanning that message I read the last word as "mini-me", which brought up some *very* unlikely associations! :-) Damian -- "So, Mr. Evil..." "It's Dr. Evil, I didn't spend six years in Evil Medical School to be called 'mister', thank you very much."
Re: pasm.el and looping ops
Steve Fink <[EMAIL PROTECTED]> writes: > Could you describe better the need and usefulness of these ops? My > immediate reaction is "Why not just code loops ourselves?" I think > your ops can be implemented in two currently-existing opcodes apiece, > and I'm guessing that JIT support for the more primitive ops is going > to appear before support for the loop ops. yes, all of the looping constructs can be done with an inc/dec + eq/if. > On the other hand, I may be overlooking a good reason for adding > these. The two reasons I can think of right now are (1) you've done > benchmarking and combining these ops demonstrates a significant > speedup or (2) some hardware architectures have native instructions > for the loop ops that are measurably more efficient than the direct > translation of the primitive op pair. (Though I doubt that; the > primitives are at least as easy for the hardware to parallelize and > neither possibility touches any more or less data memory.) Neither (1) nor (2) was on my mind when i wrote the ops. it was a pruely a my-hand-written-pasm-code-would-be-cleaner-if kind of thing. it boils down to who is the byte-code aimed at? compilers or people? if parrot was truly aimed at compilers it would be RISCy and PMCs + multi-method ops wouldn't exist (at least not directly in Parrot). If parrot is aimed at people hand writing parrot assembler then the looping ops make sense. this being the real world parrot is somewhere in between these two, so i would like to put the question differently: loop and friends make my life as an assembler writer easier, do they have any detrimental effects on parrot? maybe the looping ops should be macros? regarding (2): vector processors would certainly benefit from having loops (espicially the ones over arrays of similar things (a large percentage of real world loops)) explicitly labeled as such. i'm sure the JIT compiler will be smart enough to figure this out by itself, by if i (or my compiler) know's its a loop why not mark it as such? -- -Marco Ring the bells that still can ring. Forget the perfect offering. There's a crack in everything. It's how the light gets in. -Isonard Cohen
[PATCH] String function tidy-up
This patch tidies up the formatting of string_substr and string_replace,
adds a bunch of comments, and moves a couple of assignments closer to
where the variables are actually used; none of the functionality should
be affected. All tests still pass (including the ones in a previous patch
that nobody's applied yet)
Simon
--- string.c.oldMon Apr 15 21:00:00 2002
+++ string.cTue Apr 16 17:00:03 2002
@@ -362,7 +362,6 @@
return string_make(interpreter, NULL, 0, src->encoding, 0, src->type);
}
-true_length = (UINTVAL)length;
if (offset < 0) {
true_offset = (UINTVAL)(src->strlen + offset);
}
@@ -371,18 +370,20 @@
internal_exception(SUBSTR_OUT_OF_STRING,
"Cannot take substr outside string");
}
+
+true_length = (UINTVAL)length;
if (true_length > (src->strlen - true_offset)) {
true_length = (UINTVAL)(src->strlen - true_offset);
}
substart_off = (const char *)src->encoding->skip_forward(src->bufstart,
- true_offset) -
-(char *)src->bufstart;
+ true_offset)
+ - (char *)src->bufstart;
+
subend_off =
-(const char *)src->encoding->skip_forward((char *)src->bufstart +
-substart_off,
-true_length) -
-(char *)src->bufstart;
+(const char *)src->encoding->skip_forward((char *)src->bufstart
+ + substart_off, true_length)
+ - (char *)src->bufstart;
dest =
string_make(interpreter, NULL, true_length * src->encoding->max_bytes,
@@ -428,37 +429,43 @@
INTVAL diff;
true_offset = (UINTVAL)offset;
-true_length = (UINTVAL)length;
-if(rep->encoding != src->encoding || rep->type != src->type)
-rep = string_transcode(interpreter, rep, src->encoding, src->type, NULL);
+/* If the offset is negative, then abs(offset) should not be larger
+ * than the length of the string. If it is, then the cast ensures
+ * that true_offset is larger than any possible string length (and
+ * hence will generate an exception in the next statement).
+ */
-/* abs(-offset) may not be > strlen-1 */
if (offset < 0) {
true_offset = (UINTVAL)(src->strlen + offset);
}
-/* Can replace 1 past end of string which is technically outside the string
- * but is same as a concat().
- * Only give exception if caller trys to replace end of string + 2
+/* Replacing one character past the end of the string has the
+ * same effect as string_concat(); therefore, only throw an
+ * exception if the caller tries to replace two or more characters
+ * past the end of the string
*/
if (true_offset > src->strlen) {
internal_exception(SUBSTR_OUT_OF_STRING,
"Can only replace inside string or index after end of string");
}
+
+true_length = (UINTVAL)length;
if (true_length > (src->strlen - true_offset)) {
true_length = (UINTVAL)(src->strlen - true_offset);
}
-/* Save the substring that is replaced for the return value */
-substart_off = (char *)src->encoding->skip_forward(src->bufstart,
- true_offset) -
-(char *)src->bufstart;
+/* Construct and save the substring that is replaced; this will be
+ * the function return value
+ */
+substart_off = (const char *)src->encoding->skip_forward(src->bufstart,
+ true_offset)
+ - (char *)src->bufstart;
+
subend_off =
-(char *)src->encoding->skip_forward((char *)src->bufstart +
-substart_off,
-true_length) -
-(char *)src->bufstart;
+(const char *)src->encoding->skip_forward((char *)src->bufstart
+ + substart_off, true_length)
+- (char *)src->bufstart;
if (subend_off < substart_off) {
internal_exception(SUBSTR_OUT_OF_STRING,
@@ -479,43 +486,54 @@
}
/* Now do the replacement */
+
+if(rep->encoding != src->encoding || rep->type != src->type)
+rep =
+ string_transcode(interpreter, rep, src->encoding, src->type, NULL);
/*
- * If the replacement string fits inside the original substring
+ * If the replacement string fits inside the original substring,
+ * or there's sufficient space left in the string buffer, then
* don't create a new string, just pack it.
*/
+
diff = (subend_off - substart_off) - rep->bufused;
if(diff >= 0
|| ((INTVAL)src->bufused - (INTVAL)src->buflen) <= diff) {
-
+
if(diff != 0) {
mem
Substr with a negative length
What should the substr ops produce if given a negative length argument? At the moment, the four-arg. form hands back an empty string, while the five-arg. form hands back a copy of the original string, ie: set S0, "abcdefg" substr S1, S0, 0, -1 print S1 print "\n" and set S2, "" substr S3, S0, 0, -1, S2 print S3 print "\n" produce "" and "abcdefg" respectively. The former seems more correct, but I thought I'd throw this out for comment before hacking string.c Simon
Re: [PATCH] Assembler Strings
On Tue, Apr 16, 2002 at 02:57:42PM -0400, Dan Sugalski wrote: > >b) 'a\"b' was printing being stored as a\"b and not a"b > > The patch for the first looks good, but I'm not sure about the > second. Have we settled on the behavior of single-quoted strings? Don't know about "settled" but I suggest that the previous behaviour was the correct one. The only characters that should be escaped in a single quoted strings are C<'> and C<\>. Anything else is literal. e.g. 'foo\'bar\\ping\"pong' => foo'bar\ping\"pong ^^ ^ yep yep nope A
Re: [PATCH] Assembler Strings
I think Andy's post is going through moderation, but I can still reply to it. :) > Date: Tue, 16 Apr 2002 21:01:11 +0100 > From: Andy Wardley <[EMAIL PROTECTED]> > To: Dan Sugalski <[EMAIL PROTECTED]> > Cc: Mike Lambert <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: [PATCH] Assembler Strings > > On Tue, Apr 16, 2002 at 02:57:42PM -0400, Dan Sugalski wrote: > > >b) 'a\"b' was printing being stored as a\"b and not a"b > > > > The patch for the first looks good, but I'm not sure about the > > second. Have we settled on the behavior of single-quoted strings? > > Don't know about "settled" but I suggest that the previous behaviour > was the correct one. The only characters that should be escaped in a > single quoted strings are C<'> and C<\>. Anything else is literal. > > e.g. > > 'foo\'bar\\ping\"pong' => foo'bar\ping\"pong >^^ ^ >yep yep nope You're arguing for an implementation of the previous behavior. What you describe is neither before nor after, but somewhere in the middle. :) Before, it did: foo\'bar\ping\"pong Now it does: foo'bar\ping"pong To implement the behavior you described (to match Perl5's behavior), you'd need to pass the delimiter around in Assembler.pm. Should I revisit my patch to adhere to the example above, or sit on it all until some form of proper assembler quoting behavior is defined? Mike Lambert
Re: Resync time...
On Mon, 15 Apr 2002, Dan Sugalski wrote: > At 10:26 PM +0200 4/15/02, Peter Gibbs wrote: > > > >Note that string_grow still has the problem with not bothering to allocate a > >new buffer if copysize is zero, e.g. if we are expanding a previously empty > >buffer. > > > >I have submitted a patch for this previously, but since string_grow has now > >changed, herewith a resynced patch. > > This has been applied too. There's something bugging me about it--I > think there may be issues, and I'd really like it if we made sure we > had a bunch of zero-length string tests in the test suite. Well, one issue with this patch is that Parrot will now segfault if (s>buflen + addlen) < 0. It doesn't seem possible to actually provoke this behaviour at the moment, however - string_grow is only called from one place in string_replace, and the code in string_replace ensures that addlen > 0. It's easy enough to add a test in string_grow to avoid the problem, but I'm not sure what we should return in that case: the input string s, or a newly created empty string? Simon
Re: pasm.el and looping ops
G'day all. On Tue, Apr 16, 2002 at 10:52:05PM +0200, Marco Baringer wrote: > regarding (2): vector processors would certainly benefit from having > loops (espicially the ones over arrays of similar things (a large > percentage of real world loops)) explicitly labeled as such. A few of comments: - Loops are very easy to detect. Just as well, because loops don't necessarily come from loop syntax. - I don't know how easy it is to detect parallelisable loops (never worked with vector processors before), but I suspect that the hard part is not detecting the loops. - Unless the language has loops over numbers as a primitive operation, these ops are hard to generate code for in the general case. This is not an argument against their existence, of course. Not every compiler is going to generate code containing every op. If there are measurable efficiency improvements in using them, it could well be worth going to the trouble to detect where they are useful. > i'm sure > the JIT compiler will be smart enough to figure this out by itself, by > if i (or my compiler) know's its a loop why not mark it as such? There are many things which the compiler knows which a JIT compiler or optimiser might want to know about it (hell, I want live variable information at the end of basic blocks), but I am inclined to think of that sort of information as metadata rather than data. Parrot bytecode will eventually need a flexible way to store compiler- originated metadata. Cheers, Andrew Bromage
C loop variations
In Exegesis 4, Damian writes:
It's important to note that writing:
for @a; @b -> $x; $y {...}
# in parallel, iterate @a one-at-a-time as $x, and @b one-at-a-time as
$y
is not the same as writing:
for @a, @b -> $x, $y {...}
# sequentially iterate @a then @b, two-at-a-time as $x and $y
Now, I love that the for loop can do both of these things, but the subtlety
of the difference in syntax is likely, IMO, to lead to very difficult-
to-find bugs. It's very easy to miss that I've used a comma when I meant to
use a semicolon, and vice versa. And what's the mnemonic again?
Is there any way the syntax could be made different? Could the two
approaches be differently named? Perhaps the first could be C, and
the second could be C, and they could both use commas. Or am I just
being paranoid?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
[PATCH] Remove redundant declarations
Compiling parrot with gcc's -Wredundant_decls option shows up a few
places where we're declaring functions twice in the same header file.
Patch below fixes.
Simon
--- include/parrot/chartype.h.old Tue Apr 16 22:33:46 2002
+++ include/parrot/chartype.h Tue Apr 16 22:31:56 2002
@@ -48,9 +48,6 @@
#define chartype_lookup Parrot_chartype_lookup
-CHARTYPE_TRANSCODER chartype_lookup_transcoder(const CHARTYPE *from,
- const CHARTYPE *to);
-
#endif
#endif
--- include/parrot/packfile.h.old Tue Apr 16 22:32:52 2002
+++ include/parrot/packfile.h Tue Apr 16 22:32:58 2002
@@ -119,8 +119,6 @@
opcode_t *packed,
opcode_t packed_size);
-opcode_t PackFile_Constant_pack_size(struct PackFile_Constant *self);
-
#endif /* PACKFILE_H */
/*
--- include/parrot/embed.h.old Tue Apr 16 22:38:01 2002
+++ include/parrot/embed.h Tue Apr 16 22:38:07 2002
@@ -32,8 +32,6 @@
Parrot_PackFile Parrot_readbc(Parrot, char *);
-void Parrot_setwarnings(Parrot, Parrot_warnclass);
-
void Parrot_loadbc(Parrot, Parrot_PackFile);
void Parrot_runcode(Parrot, int argc, char *argv[]);
--- runops_cores.c.old Tue Apr 16 22:48:36 2002
+++ runops_cores.c Tue Apr 16 22:48:42 2002
@@ -47,9 +47,6 @@
* With bounds checking.
*/
-void trace_op(struct Parrot_Interp *interpreter, opcode_t *code_start,
- opcode_t *code_end, opcode_t *pc);
-
opcode_t *
runops_slow_core(struct Parrot_Interp *interpreter, opcode_t *pc)
{
Re: [Applied] Remove redundant declarations
Applied, thanks. Had to change the chartype.h part a bit, as it didn't
want to apply on its own. I am not sure why.
Anyway, it's in. Is there a reason not to include -Wredundant_decls in
our default warnings flags?
--Josh
At 22:54 on 04/16/2002 EDT, Simon Glover <[EMAIL PROTECTED]> wrote:
>
> Compiling parrot with gcc's -Wredundant_decls option shows up a few
> places where we're declaring functions twice in the same header file.
> Patch below fixes.
>
> Simon
>
> --- include/parrot/chartype.h.old Tue Apr 16 22:33:46 2002
> +++ include/parrot/chartype.h Tue Apr 16 22:31:56 2002
> @@ -48,9 +48,6 @@
>
> #define chartype_lookup Parrot_chartype_lookup
>
> -CHARTYPE_TRANSCODER chartype_lookup_transcoder(const CHARTYPE *from,
> - const CHARTYPE *to);
> -
> #endif
>
> #endif
>
>
> --- include/parrot/packfile.h.old Tue Apr 16 22:32:52 2002
> +++ include/parrot/packfile.h Tue Apr 16 22:32:58 2002
> @@ -119,8 +119,6 @@
> opcode_t *packed,
> opcode_t packed_size);
>
> -opcode_t PackFile_Constant_pack_size(struct PackFile_Constant *self);
> -
> #endif /* PACKFILE_H */
>
> /*
>
>
> --- include/parrot/embed.h.oldTue Apr 16 22:38:01 2002
> +++ include/parrot/embed.hTue Apr 16 22:38:07 2002
> @@ -32,8 +32,6 @@
>
> Parrot_PackFile Parrot_readbc(Parrot, char *);
>
> -void Parrot_setwarnings(Parrot, Parrot_warnclass);
> -
> void Parrot_loadbc(Parrot, Parrot_PackFile);
>
> void Parrot_runcode(Parrot, int argc, char *argv[]);
>
>
> --- runops_cores.c.oldTue Apr 16 22:48:36 2002
> +++ runops_cores.cTue Apr 16 22:48:42 2002
> @@ -47,9 +47,6 @@
> * With bounds checking.
> */
>
> -void trace_op(struct Parrot_Interp *interpreter, opcode_t *code_start,
> - opcode_t *code_end, opcode_t *pc);
> -
> opcode_t *
> runops_slow_core(struct Parrot_Interp *interpreter, opcode_t *pc)
> {
>
Re: C loop variations
> Now, I love that the for loop can do both of these things, but the subtlety > of the difference in syntax is likely, IMO, to lead to very difficult- > to-find bugs. It's very easy to miss that I've used a comma when I meant to > use a semicolon, and vice versa. And what's the mnemonic again? Well, I made two (weak) mnemonics for myself. The first is somewhat idiomatic, that @a, @b concatenates the two lists, or, in Perl 5 it did. @a;@b doesn't do that, and it's rather easy to see. The second mnemonic is that I think of doing the two-at-a-time thing as traversing sequentially, or horizontally. Parallel seems more vertical. And semicolon seems a lot more vertical than comma. Yeah, they're stretching a little, but I can quickly tell the difference, and I haven't written a line of Perl 6 code. > Is there any way the syntax could be made different? Could the two > approaches be differently named? Perhaps the first could be C, and > the second could be C, and they could both use commas. I would say I wouldn't like that. I've always appreciated for and foreach being synonyms (in fact, I think well chosen synonyms are one of the keys to a highly readable language). So, if the rest of the world is me, you're just being paranoid. But we'll see if anybody else disagrees with me. Luke
Re: [Applied] Remove redundant declarations
On Tue, 16 Apr 2002, Josh Wilmes wrote: > Applied, thanks. Had to change the chartype.h part a bit, as it didn't > want to apply on its own. I am not sure why. > > Anyway, it's in. Is there a reason not to include -Wredundant_decls in > our default warnings flags? > I've just tried it out in Configure.pl, and it generates a bunch more warnings because the PMC init methods are declared in global_setup.h as well as in the PMC header files. Unlike the cases in the patch, this seems to be deliberate, but I'm not sure why we're doing this. Simon
[RELEASE] Parrot 0.0.5 is out of its cage.
It was the dawning of the second age of parrotkind, ten weeks after the great GC war. The Parrot Project was a dream given form. Its goal: To prevent language wars by creating an interpreter where perl and other languages could reside peacefully... It can be a dangerous place, but it's our last best hope for peace. This is the story of the latest of the Parrot releases. The year is 2002. The name of the tarfile is Parrot 0.0.5. [Apologies to J. Michael Straczynski] The Parrot Team is pleased to announce the release of Parrot 0.0.5, soon to be available on your local CPAN mirror as: CPAN/authors/id/J/JG/JGOFF/parrot-0.0.5.tar.gz >From the NEWS file: New in 0.0.5 - Full GC - Perl Scalar support in PMCs - Array and Hash types almost ready for prime-time - Internal support for keyed types - EMACS editing mode - New PDDs - New Language - BASIC - Regular expression compiler - More tests - Many, many bug fixes, enhancements, and speedups I'd personally like to thank everyone on the Parrot development team for contributing to what's turned out to be a great release. Parrot is finally starting to look like a stable platform for development, especially with the attention paid to GC and string issues. The BASIC language gives people more toys to play with, and Perl scalars help prove that we can indeed handle Perl6 when the design process is finished. Over the next few days, expect an updated roadmap as to where we see Parrot going. Complete support for keyed PMC types will be one of the first items to be checked off, followed shortly by regular expressions and symbol tables. If you want to join in on the fun, start by downloading a copy of parrot-0.0.5 at CPAN at one of the following URLs (or a mirror): http://www.cpan.org/authors/id/J/JG/JGOFF/parrot-0.0.5.tar.gz http://www.cpan.org/src/parrot-0.0.5.tar.gz To get the latest CVS version: http://cvs.perl.org/ has the information you need. Once you've unpacked Parrot, build it as follows: perl Configure.pl make make test After you've done that, look at docs/parrot.pod to learn more about it. Discussion of Parrot takes place on the perl6-internals mailing list, and patches should be sent there as well. If you're not subscribed, look at: http://lists.perl.org/showlist.cgi?name=perl6-internals for tips on how to subscribe. CVS commit access is given out to developers who consistently submit good patches to the mailing list. Have fun, and hack well. -- Jeff <[EMAIL PROTECTED]>
parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
Okay, I can't find any documentation on how to send problem reports, so I hope this is sufficient and useful. If not, let me know: I've included the scrollback from `perl Configure.pl`, and the first pageful or so from `make`. (`make test`, of course, bombs completely, even though `make` doesn't error out.) Mind you that this is Mac OS X 10.1.3, with a UFS root partition. This was compiled on the UFS partition. Interestingly, parrot 0.0.4 compiled okay. I recently tried compiling CVS parrot, but got similar errors to the below. I didn't have time to check it more, and as I appeared to be the only one to have this problem, I figured it was me just being broken. I dunno. ---BEGIN perl Configure.pl SCROLLBACK--- 01:18:39 [cogent@localhost] parrot-0.0.5>$ perl Configure.pl Parrot Version 0.0.5 Configure Copyright (C) 2001-2002 Yet Another Society Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking the MANIFEST to make sure you have a complete Parrot kit... Okay, we found everything. Next you'll need to answer a few questions about your system. Defaults are in square brackets, and you can hit enter to accept them. If you don't want the default, type a new value in. If that new value starts with a '+', it will be concatenated to the default value. What C compiler do you want to use? [cc] How about your linker? [cc] What flags would you like passed to your C compiler? [-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include -I/sw/include] What flags would you like passed to your linker? [-flat_namespace -L/usr/local/lib -L/sw/lib -flat_namespace ] Which libraries would you like your C compiler to include? [-ldb -lm -lc -ldl] How big would you like integers to be? [long long] And your floats? [double] What is your native opcode type? [long long] Now I have to find out what opcode files you would like to compile into your Parrot. The following opcode files are available: core.ops io.ops obscure.ops rx.ops vtable.ops WARNING: Bad Things may happen if the first file on the list isn't core.ops. WARNING: These file names will not be checked for spelling, and typing them wrong will force you to run Configure again. WARNING: I worry way too much about Configure users. Which opcode files would you like? [core.ops io.ops rx.ops] Determining if your C compiler is actually gcc (this could take a while): Your C compiler reports itself as gcc, major version 2, minor version 95. What gcc warning flags do you want to use? [ -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wno-shadow] Probing Perl 5's configuration to determine which headers you have (this could take a while on slow machines)... Determining C data type sizes by compiling and running a small C program (this could take a while): Building ./test.c from test_c.in... Hmm, I see your chosen INTVAL isn't the same size as your pointers. Parrot should still compile and run, but you may see a ton of warnings. Figuring out the formats to pass to pack() for the various Parrot internal types... Figuring out what integer type we can mix with pointers... We'll use 'unsigned int'. Building a preliminary version of include/parrot/config.h, your Makefiles, and other files: Building include/parrot/config.hfrom config_h.in... Building ./Makefile from Makefile.in... Building ./classes/Makefile from classes/Makefile.in... Building ./docs/Makefilefrom docs/Makefile.in... Building ./languages/Makefile from languages/Makefile.in... Building ./languages/jako/Makefile from languages/jako/Makefile.in... Building ./languages/miniperl/Makefile from languages/miniperl/Makefile.in... Building ./languages/scheme/Makefilefrom languages/scheme/Makefile.in... Building lib/Parrot/Types.pmfrom Types_pm.in... Building lib/Parrot/Config.pm from Config_pm.in... Checking some things by compiling and running another small C program (this could take a while): Building ./testparrotsizes.cfrom testparrotsizes_c.in... Still everything ok, let's check if we can use computed goto, don't worry if you see some errors, it will be all right, This could take a bit... Building ./testcomputedgoto.c from testcomputedgoto_c.in... testcomputedgoto.c:9: illegal expression, found `&&' testcomputedgoto.c:12: illegal statement, missing `identifier' after `goto' testcomputedgoto.c:12: syntax error, missing `;' after `*' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode Building ./Makefile from Makefile.in... Updating include/parrot/config.h: Building include/parrot/config.hfrom config_h.in...
RE: parrot-0.0.5 doesn't like me. Which isn't fair, really, because I rather like it.
David Hand:
# Okay, I can't find any documentation on how to send problem
# reports, so I hope this is sufficient and useful. If not,
# let me know:
#
# I've included the scrollback from `perl Configure.pl`, and
# the first pageful or so from `make`. (`make test`, of
# course, bombs completely, even though `make` doesn't error out.)
#
# Mind you that this is Mac OS X 10.1.3, with a UFS root
# partition. This was compiled on the UFS partition.
# Interestingly, parrot 0.0.4 compiled okay. I recently tried
# compiling CVS parrot, but got similar errors to the below. I
# didn't have time to check it more, and as I appeared to be
# the only one to have this problem, I figured it was me just
# being broken. I dunno.
Can you send the output of `make test' and attach the file
$parrot_directory/lib/Parrot/Config.pm? Thanks.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: Resync time...
Simon Glover wrote: > Well, one issue with this patch is that Parrot will now segfault if > (s>buflen + addlen) < 0. It doesn't seem possible to actually provoke > this behaviour at the moment, however - string_grow is only called > from one place in string_replace, and the code in string_replace > ensures that addlen > 0. > > It's easy enough to add a test in string_grow to avoid the problem, > but I'm not sure what we should return in that case: the input > string s, or a newly created empty string? Dan has since rewritten string_grow to use Parrot_reallocate; however, the problem still remains. In this particular case, based on the name, description and usage of the function, there seems to be no reason not to change addlen to be a UINTVAL. However, this raises a more general point regarding preconditions. At one point do we start/stop trusting ourselves? string_replace calls string_grow which calls Parrot_reallocate which calls mem_allocate. If we say that string_replace (or other string_* functions) cannot be trusted to call string_grow correctly, surely we must then modify mem_allocate to handle a negative request length. -- Peter Gibbs EmKel Systems
