Re: Apoc2 - concerns

[Stephen P. Potter]

Lightning flashed, thunder crashed and Larry Wall <[EMAIL PROTECTED]> whispered:
| Simon Cozens writes:
| : On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
| : > :  while ($STDIN) { ... }
| : > I'm wondering what this will do?
| : >$thingy = $STDIN;
| : > This seems to have two possibilities:
| : >1. Make a copy of $STDIN
| : 
| : This one. I see a filehandle in *boolean* context meaning "read to $_",
| 
| It would be $FOO.next, but yes, that's the basic idea.  It's possible

Urr?  How often do you dup filehandles as opposed to reading filehandles?
I think we would be much better off with

$thingy = $STDIN;

reading a line from $STDIN rather than duping it.  Otherwise, we'll be
constantly having to type five more characters (.next) for a very common
practice.

I'm also concerned about the confusion between C<$MARK.next> and C (of course, we haven't seen whether C is going to change).
At the very least,  wouldn't C<$STDIN.read> be better and more orthagonal
with C.

-spp

Re: Perl, the new generation

[Edward Peschko]

On Tue, May 15, 2001 at 03:01:47PM -0400, Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and Larry Wall <[EMAIL PROTECTED]> whispered:
> | Peter Scott writes:
> | : So, I wonder aloud, do we want to signify that degree of change with a more
> >  
> | : dramatic change in the name?
> | 
> | I'm inclined to think that people will be more likely to migrate if
> | they subconsciously think we're taking continuity into consideration.
> | Which we are, albeit not at a syntactic compatibility level.
> 
> It seems to me that recently (the last two years or so) and especially with
> 6, perl is no longer the SAs friend.  It is no longer a fun litle language
> that can be easily used to hack out solutions to problems.  It is now
> (becoming) a full featured language, quite at the expense of its heritage.

> 
> When we moved from 4 to 5, so people thought we should continue developing
> 4 without all the "useless" new stuff, like OO and threads and etc.  I
> wonder more and more if they weren't right.  I wonder if as 6 develops if
> we shouldn't split off the old 4 syntax and have two languages.

Umm.. and what good would this new language  be without CPAN?  Its not logical
to dislike the syntax for the sake of disliking the syntax... And like it or 
not, perl would be close to worthless if it didn't talk to the outside world
via OO. And as someone else said, if you don't like OO, don't use it.

Ed

Re: Damian Conway's Exegesis 2

[Edward Peschko]

On Tue, May 15, 2001 at 03:32:46PM -0600, Nathan Torkington wrote:
> Damian's writing a series of articles parallel to Larry's Apocalypses.
> These "Exegesis" articles will show full perl6 programs, with
> commentary exlaining the new features.
> 
> The first Exegesis (numbered 2, to keep in sync with Larry) shows a
> perl6 version of a binary tree program from the Perl Cookbook.
> 
>   http://www.perl.com/pub/2001/05/08/exegesis2.html
> 
> Nat

Ok, question here. Are these exegesises 'blessed'? What is open to debate on 
this?

For example, I see that 'use warnings' and 'use strict' are still at the top
of the page. And 

print "Post order: "; show($root,$post); print "\n";

would be better off written as:

print "Post order: &show($root, $post)\n";

wouldn't it?

Ed

Re: Must pseudo-hashes die?

[Peter Scott]

At 07:47 PM 5/15/01 +, Ton Hospel wrote:
> > PSEUDO-HASHES MUST DIE!
> >
>
>I happen to like them

I like the feature of a hash whose keys are fixed in the sense that you 
have to jump through a hoop to add a new one.  Without having to download 
Tie::SecureHash and accept the other features it provides.  I'd like to see 
this in Perl 6.

I detest the pseudo-hash implementation (the part that's exposed to the 
user, I mean).

--
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com

Re: Damian Conway's Exegesis 2

[Simon Cozens]

On Tue, May 15, 2001 at 02:59:07PM -0700, Edward Peschko wrote:
> Ok, question here. Are these exegesises 'blessed'?

It is impossible to answer this question without knowing what you mean by the
word. Larry has seen and edited the article; is that what you mean?

> What is open to debate on this?

Everything. In fact, everything's open to debate about the Apocalypses too,
unfortunately, or otherwise perl6-language would be nice and quiet.

> For example, I see that 'use warnings' and 'use strict' are still at the top
> of the page. 

Yes. Is there some point you want to make about that?

> And 
> print "Post order: "; show($root,$post); print "\n";
> would be better off written as:
> print "Post order: &show($root, $post)\n";
> wouldn't it?

Define "better" without breaching the spirit of TMTOWDTI and in keeping
with the didactical nature of the article.

-- 
When someone says "I want a programming language in which I need only
say what I wish done," give him a lollipop.

Re: Damian Conway's Exegesis 2

[Dave Storrs]

First of all:  Damian, thank you for putting this together.  This is a
really good way to dispell the concerns/doubts/pick-a-word that people
(including myself) have been having about whether Perl6 would be the
language that we all know and love.



There was a great deal of stuff in there and I for one am going to need
some time to digest it.  My initial reactions are as follows:  at first I
was alarmed and a bit appalled at a lot of the changes...e.g., the
'HASH $tree is rw' parameter declaration.  "Jesus," I thought "if I wanted
a typed languaged, I'd use C++."  The more I read, however, the more I
became convinced that these were actually elegant Perlisms...you can have
exactly as much freedom as you want, if you carry the responsibility for
it.  Alternatively, you can have Perl do more of the work for you, if you
are willing to live with constraints.  Elegant.  Perlish.  Good.

The only questions I have at this point are:  

- Is there a way to declare a property constant/final/choose your
keyword?

- Is there a way to do a read-only access on a property?

- A while ago, someone suggested that the word 'has' be an alias
for 'is', so that when you roll your own properties, you could write
more-grammatically-correct statements such as "my $var has
Colors(3)".  Since 'are' is being considered as a synonym, is there a
possibility that 'has' will make it too?

- Might it be possible to make properties prefix-able when being
used with types, so that it would be possible to say 'my constant int $foo
= 0;'  ??  It's a minor point, but it would make it easier for people from
C-based languages to transfer (whether that's enough of a reason is a
separate question.)  I understand it would be difficult, since properties
work off the 'is' keyword, which returns its left arg; still, I don't see
why this is harder (from a programming view) than making 'if' and 'unless'
capable of prefix or postfix usage.


Dave

Re: Damian Conway's Exegesis 2

[Nathan Torkington]

Dave Storrs writes:
> at first I was alarmed and a bit appalled at a lot of the
> changes...e.g., the 'HASH $tree is rw' parameter declaration.
> "Jesus," I thought "if I wanted a typed languaged, I'd use C++."
> The more I read, however, the more I became convinced that these
> were actually elegant Perlisms...you can have exactly as much
> freedom as you want, if you carry the responsibility for it.
> Alternatively, you can have Perl do more of the work for you, if you
> are willing to live with constraints.  Elegant.  Perlish.  Good.

Yes, it's important for everyone to understand that types are
OPTIONAL.  You use them when you want compile-time type checking or
storage efficiency or you need them for something you're doing with an
underlying VM, but you can always write untyped code.

Nat

Re: Damian Conway's Exegesis 2

[Simon Cozens]

On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote:
>   - A while ago, someone suggested that the word 'has' be an alias
> for 'is', so that when you roll your own properties, you could write
> more-grammatically-correct statements such as "my $var has
> Colors(3)".  Since 'are' is being considered as a synonym, is there a
> possibility that 'has' will make it too?

It would be disappointing if a substantial proportion of the built-in
keywords were merely syntactic sugar for each other. is|are|has|: seem
like far too many ways to express exactly the same concept.

-- 
Those who do not understand Unix are condemned to reinvent it, poorly.
- Henry Spencer, University of Toronto Unix hack

Re: Damian Conway's Exegesis 2

[Nathan Torkington]

Edward Peschko writes:
> Ok, question here. Are these exegesises 'blessed'? What is open to
> debate on this?

As Simon says, ask whatever questions you want.

>   print "Post order: "; show($root,$post); print "\n";
> would be better off written as:
>   print "Post order: &show($root, $post)\n";
> wouldn't it?

Yes, except that you're relying on show() not returning a value there.
If show() was written so that it happened to have a print statement as
the last thing in the sub, then you'd get random 1s in your output.

That's a style difference, though, not a language capabilities issue.

Nat

Re: Damian Conway's Exegesis 2

[Mark Koopman]

Simon Cozens wrote:

> On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote:
> 
>>  - A while ago, someone suggested that the word 'has' be an alias
>>for 'is', so that when you roll your own properties, you could write
>>more-grammatically-correct statements such as "my $var has
>>Colors(3)".  Since 'are' is being considered as a synonym, is there a
>>possibility that 'has' will make it too?
>>
> 
> It would be disappointing if a substantial proportion of the built-in
> keywords were merely syntactic sugar for each other. is|are|has|: seem
> like far too many ways to express exactly the same concept.
> 
> 


i think that's the idea...they have similar meanings, so they should do
similar things.  hey it's the English language, i'll leave it up to someone
else to come up with the 7 other ways to prove ownership of a property :)


-- 
#!/usr/local/bin/perl

## Mark Koopman
## Software Engineer
##
## WebSideStory, Inc
##
## 10182 Telesis Court
## San Diego CA  92121
## 858.546.1182.##.318
## 858.546.0480.fax

Exegesis2 and the "is" keyword

[Nathan Wiger]

So, I finally got around to reading the link Nat sent out:

   http://www.perl.com/pub/2001/05/08/exegesis2.html

First off, nice job Damian (as always), it looks excellent. I like the
examples of stuff like this:

   my int ($pre, $in, $post) is constant = (0..2);

Awesome. Simple, Perlish, easy to read, etc. Also, I see you took the
suggestion of:

   Access through...   Perl 5  Perl 6
   =   ==  ==
   Array slice @foo[@ns]   @foo[@ns]
   Hash slice  @foo{@ks}   %foo{@ks}

Which is kewl since it makes a good amount of sense IMO.

The only worry/problem/etc that I wonder about is the potential overuse
of the "is" keyword. It is a very nice syntactic tool, but when I see
something like this:

   $*ARGS is chomped;

I wonder if that wouldn't be better phrased as:

   autochomp $*ARGS;# $ARGS.autochomp

Or, if :: meant CORE, even:

   autochomp $::ARGS;

The thing I worry about is this: I don't think actions should be
declared using "is", necessarily. I know, one could argue that actions
are just a type of property, but I don't know if that's the most
sensible. In particular, it puts the action in the passive voice, and it
could also go too far:

   $STDERR is flushed;
   $var = $ARGS is read;
   $STDOUT is printed to "Hello, World!\n";

It seems actions should be active functions, so:

   autoflush $STDERR;   # $STDERR.autoflush
   $var = read $ARGS;
   print $STDOUT "Hello, World!\n";

Plus, this part bothers me a little:

: http://www.perl.com/pub/2001/05/08/exegesis2.html
:
:$ARGS prompts("Search? ");  # Perl 6
:while (<$ARGS>) {
:
: Technically, that should be:
:
:$ARGS is prompts("Search? ");
:
: but that grates unbearably. Fortunately, the "is" is optional in 
: contexts -- such as this one -- where it can be inferred.

I'd think I'd rather see that as:

   prompt $ARGS "Search? "; # $ARGS.prompt("Search? ")

Without the extra new ambiguity. Thoughts?

-Nate

Re: Damian Conway's Exegesis 2

[John Siracusa]

On 5/15/01 5:59 PM, Edward Peschko wrote:
> would be better off written as...

...speaking of which:

my int ($pre, $in, $post) is constant = (0..2);

What, no caps?

my int ($PRE, $IN, $POST) is constant = (0..2);

Looks nicer to me...or are all-caps vars reserved for
internal use in Perl 6?

-John

Re: Damian Conway's Exegesis 2

[Simon Cozens]

On Tue, May 15, 2001 at 06:49:53PM -0400, John Siracusa wrote:
> Looks nicer to me.

Did you know that other people might find other things nicer?
TMTOWDTI has not been ruled out for Perl 6.

-- 
Imbalance of power corrupts and monopoly of power corrupts absolutely.
-- Genji

Re: Damian Conway's Exegesis 2

[Simon Cozens]

On Tue, May 15, 2001 at 03:47:36PM -0700, Mark Koopman wrote:
> i think that's the idea...they have similar meanings, so they should do
> similar things.  hey it's the English language, i'll leave it up to someone
> else to come up with the 7 other ways to prove ownership of a property :)

Personally, I'd rather not deal with a toke.c that knows more of
/usr/dict/words than I do.

-- 
When your hammer is C++, everything begins to look like a thumb. 
-- Steve Haflich, comp.lang.c++

Re: Damian Conway's Exegesis 2

[John Siracusa]

On 5/15/01 6:54 PM, Simon Cozens wrote:
> On Tue, May 15, 2001 at 06:49:53PM -0400, John Siracusa wrote:
>> Looks nicer to me.
> 
> Did you know that other people might find other things nicer?
> TMTOWDTI has not been ruled out for Perl 6.

Yeah, yeah, but come on, who out there is running around typing:

use constant max_toads => 1024;

these days?  MAX_TOADS! :)

-John

Re: Damian Conway's Exegesis 2

[Edward Peschko]

> > For example, I see that 'use warnings' and 'use strict' are still at the top
> > of the page. 
> 
> Yes. Is there some point you want to make about that?

yes, that there shouldn't need to be - at least in the 'use warnings' 
department.

> > print "Post order: "; show($root,$post); print "\n";
> > would be better off written as:
> > print "Post order: &show($root, $post)\n";
> > wouldn't it?
> 
> Define "better" without breaching the spirit of TMTOWDTI and in keeping
> with the didactical nature of the article.

well, better in the sense that it shows off perl6's style and new features. And
is shorter and more concise.

Ed

Re: Damian Conway's Exegesis 2

[Dan Sugalski]

At 11:54 PM 5/15/2001 +0100, Simon Cozens wrote:
>On Tue, May 15, 2001 at 03:47:36PM -0700, Mark Koopman wrote:
> > i think that's the idea...they have similar meanings, so they should do
> > similar things.  hey it's the English language, i'll leave it up to someone
> > else to come up with the 7 other ways to prove ownership of a property :)
>
>Personally, I'd rather not deal with a toke.c that knows more of
>/usr/dict/words than I do.

Oh, didn't Larry tell you? We're making perl's parser locale-aware so it 
uses the local language to determine what the keywords are. I thought that 
was in the list of things you'd need to take into account when you wrote 
the parser... ;-P


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Damian Conway's Exegesis 2

[Simon Cozens]

On Tue, May 15, 2001 at 04:04:52PM -0700, Edward Peschko wrote:
> yes, that there shouldn't need to be - at least in the 'use warnings' 
> department.

Oh, you wanted warnings to be on by default? Oh well.

> well, better in the sense that it shows off perl6's style and new features.
> And is shorter and more concise.

Maybe. But what Damian wrote shows that you can write Perl 5 and it'll
still work; this is, perhaps, a far more importnat lesson.

-- 
>You stupid? All of Europe (maybe except those crazy Brits) prints on A4 paper.
Crazy we may be, but not foolscap.
-- James Kilfiger, ctt

Re: Damian Conway's Exegesis 2

[Nathan Torkington]

Simon Cozens writes:
> On Tue, May 15, 2001 at 03:47:36PM -0700, Mark Koopman wrote:
> > i think that's the idea...they have similar meanings, so they should do
> > similar things.  hey it's the English language, i'll leave it up to someone
> > else to come up with the 7 other ways to prove ownership of a property :)
> 
> Personally, I'd rather not deal with a toke.c that knows more of
> /usr/dict/words than I do.

Hmm, plug in WordNet and you've got a *real* DWIM parser!

Nat

Re: Damian Conway's Exegesis 2

[John Siracusa]

Okay, this part has me confused.  Here we build up a node hash:

my %node;
%node{LEFT}   = undef;
%node{RIGHT}  = undef;
%node{VALUE}  = $val is Found(0);
$tree = %node;

What has the Found property here?  I look at that and I think the value
associated with %node hash's VALUE key has the Found property.

But later, this property is set and retrieved from, seemingly, the hash
itself, with no reference to the VALUE key:

sub search (HASH $tree is rw, *@_)
{
  ...
  return $tree is Found($tree.Found+1);
}

Isn't the Found property on $tree{VALUE}?  Or is this a totally separate
Found property on the entire hash?  And if so, why is the other Found
property on the value associated with the VALUE key set at all, and then
never accessed again?

-John

Re: Damian Conway's Exegesis 2

[Edward Peschko]

On Wed, May 16, 2001 at 12:25:34AM +0100, Simon Cozens wrote:
> On Tue, May 15, 2001 at 04:04:52PM -0700, Edward Peschko wrote:
> > yes, that there shouldn't need to be - at least in the 'use warnings' 
> > department.
> 
> Oh, you wanted warnings to be on by default? Oh well.

Exactly. This has not been finalized in an Apocalypse - hence the question 
whether or not it has been 'blessed'.

So - has this decision been made?

> Maybe. But what Damian wrote shows that you can write Perl 5 and it'll
> still work; this is, perhaps, a far more importnat lesson.

fine.. except if it was about TMTOWTDI, both could have been included...

Ed

Re: Damian Conway's Exegesis 2

[Nathan Torkington]

Edward Peschko writes:
> Exactly. This has not been finalized in an Apocalypse - hence the question 
> whether or not it has been 'blessed'.
> 
> So - has this decision been made?

I've heard Larry saying things that make me think strict and -w
will not be on by default.  I'll leave it to him to confirm.  As yet
there's been no formal announcement that I can remember.

Nat

Re: Damian Conway's Exegesis 2

[Simon Cozens]

On Tue, May 15, 2001 at 04:55:41PM -0700, Edward Peschko wrote:
> fine.. except if it was about TMTOWTDI, both could have been included...

There's more than one way not to do it, too. :)

-- 
"Why waste negative entropy on comments, when you could use the same
entropy to create bugs instead?"
-- Steve Elias

Re: Exegesis2 and the "is" keyword

[Michael G Schwern]

On Tue, May 15, 2001 at 03:02:44PM -0700, Nathan Wiger wrote:
> The only worry/problem/etc that I wonder about is the potential overuse
> of the "is" keyword. It is a very nice syntactic tool, but when I see
> something like this:
> 
>$*ARGS is chomped;
> 
> I wonder if that wouldn't be better phrased as:
> 
>autochomp $*ARGS;# $ARGS.autochomp

Is that autochomp as a keyword or autochomp as an indirect method call
on $*ARGS?


> The thing I worry about is this: I don't think actions should be
> declared using "is", necessarily.
> 
>$STDERR is flushed;
>$var = $ARGS is read;
>$STDOUT is printed to "Hello, World!\n";

This could be argued 'round and 'round as to what's an action and
what's a property.  'chomped' and 'flushed' make sense as properties
as they are descriptive.  You're setting a property which the variable
will take into account in its actions.  Whereas things like 'read' and
'printed' are immediate actions.

I suppose the best distinction is right there in your example.
flushed and chomped don't do anything immediately, whereas read and
printed do.

TMOWTDI I suppose.


> Without the extra new ambiguity. Thoughts?

Put down the indirect object syntax and step away from the keyboard
with your hands up! ;)


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
 Hey Schwern! honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk, honk,
honk, honk, honk, honk, honk, honk, honk, honk, honk, honk!  

Re: Damian Conway's Exegesis 2

[Damian Conway]

Simon observed:

   > On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote:
   > >  - A while ago, someone suggested that the word 'has' be an alias
   > > for 'is', so that when you roll your own properties, you could write
   > > more-grammatically-correct statements such as "my $var has
   > > Colors(3)".  Since 'are' is being considered as a synonym, is there a
   > > possibility that 'has' will make it too?
   > 
   > It would be disappointing if a substantial proportion of the built-in
   > keywords were merely syntactic sugar for each other. is|are|has|: seem
   > like far too many ways to express exactly the same concept.

I agree. However, we envisage that the Perl 6 parser itself will be
highly mutable and comparatively painless to mutate, so it should be
easy to set up modules that create as many synonyms as you feel are
needed/necessary/required/essential/requisite/demanded/called for.

Indeed even in Perl 5 it would not be hard to write a module that let you:

use Keyword::Synonym 'are' => 'is', 'mv' => 'rename', 'become' => '=';

H. ;-)

Damian

Re: Damian Conway's Exegesis 2

[Mark Koopman]

Damian Conway wrote:

> Simon observed:
> 
>> On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote:
>> >- A while ago, someone suggested that the word 'has' be an alias
>> > for 'is', so that when you roll your own properties, you could write
>> > more-grammatically-correct statements such as "my $var has
>> > Colors(3)".  Since 'are' is being considered as a synonym, is there a
>> > possibility that 'has' will make it too?
>> 
>> It would be disappointing if a substantial proportion of the built-in
>> keywords were merely syntactic sugar for each other. is|are|has|: seem
>> like far too many ways to express exactly the same concept.
> 
> I agree. However, we envisage that the Perl 6 parser itself will be
> highly mutable and comparatively painless to mutate, so it should be
> easy to set up modules that create as many synonyms as you feel are
> needed/necessary/required/essential/requisite/demanded/called for.
> 
> Indeed even in Perl 5 it would not be hard to write a module that let you:
> 
>   use Keyword::Synonym 'are' => 'is', 'mv' => 'rename', 'become' => '=';
> 
> H. ;-)
> 
> Damian

now we can all be linguists!
monty

Re: Damian Conway's Exegesis 2

[Damian Conway]

John Siracusa wrote:

   > Okay, this part has me confused.  

And rightly so: it was a screw-up. I lost track of whether I was keeping
the property on the value or on the node reference and ended up doing both.

Interestingly, the code would still have *worked* since the (originally
unset) property on the node reference would have returned C which
would undergo the usual boolean conversion in the C, and the usual
promotion to zero in the numerical context of the increment.

Anyway, a patch is winging it's way to Simon even as I type.

Thanks for pointing out the snafu, John.

Damian

Re: Damian Conway's Exegesis 2

[Bryan C . Warnock]

On Tuesday 15 May 2001 21:07, Damian Conway wrote:
> John Siracusa wrote:
>> Okay, this part has me confused.
>
> And rightly so: it was a screw-up. I lost track of whether I was keeping
> the property on the value or on the node reference and ended up doing
> both.

What?  You didn't test it before you posted it?  For shame!   ;-)

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Damian Conway's Exegesis 2

[John Siracusa]

On 5/15/01 9:07 PM, Damian Conway wrote:
> Interestingly, the code would still have *worked* since the (originally
> unset) property on the node reference would have returned C which
> would undergo the usual boolean conversion in the C, and the usual
> promotion to zero in the numerical context of the increment.

Ah, Perl... :)

-John

Re: Damian Conway's Exegesis 2

[Simon Cozens]

On Tue, May 15, 2001 at 09:11:21PM -0400, Bryan C. Warnock wrote:
> What?  You didn't test it before you posted it?  For shame!   ;-)

Bah. Damian and I are working on ways of prototyping the Perl 6 interpreter in
Perl 5 for testing. We have the variable semantics sorted out, but properties
might be a little more difficult.

-- 
void russian_roulette(void) { char *target; strcpy(target, "bullet"); }

Re: Damian Conway's Exegesis 2

[Damian Conway]

Bryan C. Warnock sniped:

   > >> Okay, this part has me confused.
   > >
   > > And rightly so: it was a screw-up. I lost track of whether I was keeping
   > > the property on the value or on the node reference and ended up doing
   > > both.
   > 
   > What?  You didn't test it before you posted it?  For shame!   ;-)

Of course, I tested it! As I explained:

Interestingly, the code still *worked* since the (originally
unset) property on the node reference would have returned
C which would undergo the usual boolean conversion in the
C, and the usual promotion to zero in the numerical context
of the increment.

The point is that (as in Perl 5) neither of these two cases of undef
promotion trigger a warning, so there was nothing to alert me to the
fact that the initialization of the value was redundant!

;-)

Damian

Re: Damian Conway's Exegesis 2

[Bryan C . Warnock]

On Tuesday 15 May 2001 21:17, Simon Cozens wrote:
> On Tue, May 15, 2001 at 09:11:21PM -0400, Bryan C. Warnock wrote:
> > What?  You didn't test it before you posted it?  For shame!   ;-)
>
> Bah. Damian and I are working on ways of prototyping the Perl 6
> interpreter in Perl 5 for testing. We have the variable semantics sorted
> out, but properties might be a little more difficult.

my $surprise is zero;

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Damian Conway's Exegesis 2

[Russ Allbery]

Simon Cozens <[EMAIL PROTECTED]> writes:

> Personally, I'd rather not deal with a toke.c that knows more of
> /usr/dict/words than I do.

use thesaurus;

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Damian Conway's Exegesis 2

[Brent Dax]

Damian Conway wrote:
> 
> Simon observed:
> 
>> On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote:
>> >  - A while ago, someone suggested that the word 'has' be an alias
>> > for 'is', so that when you roll your own properties, you could write
>> > more-grammatically-correct statements such as "my $var has
>> > Colors(3)".  Since 'are' is being considered as a synonym, is there a
>> > possibility that 'has' will make it too?
>>
>> It would be disappointing if a substantial proportion of the built-in
>> keywords were merely syntactic sugar for each other. is|are|has|: seem
>> like far too many ways to express exactly the same concept.
> 
> I agree. However, we envisage that the Perl 6 parser itself will be
> highly mutable and comparatively painless to mutate, so it should be
> easy to set up modules that create as many synonyms as you feel are
> needed/necessary/required/essential/requisite/demanded/called for.

Here's a thought:

warn "half-(digested|baked) ideas ahead";

@a is constant; #sets @a to constant
@a has constant;#same thing

@a are constant;#sets *each element* of @a to constant
@a have constant;   #same thing

See the distinction?  This doesn't show well in the case of constant,
but consider a property that says "remember my old value whenever I'm
assigned to."  We'll call this 'undoable'.  In this case:

@a is undoable; #@a=() is noticed, @a[0] isn't
@a are undoable;#@a[0] is noticed, @a=() isn't (or maybe it is?)
#i could have used has/have instead, but is/are makes more sense here

--Brent Dax
[EMAIL PROTECTED]

Re: Must pseudo-hashes die?

[Dan Sugalski]

At 03:20 PM 5/15/2001 -0700, Peter Scott wrote:
>At 07:47 PM 5/15/01 +, Ton Hospel wrote:
>> > PSEUDO-HASHES MUST DIE!
>> >
>>
>>I happen to like them
>
>I like the feature of a hash whose keys are fixed in the sense that you 
>have to jump through a hoop to add a new one.  Without having to download 
>Tie::SecureHash and accept the other features it provides.  I'd like to 
>see this in Perl 6.

This should be in perl 6. It's a nice feature to have a hash with a 
fixed-set of keys, and the compiler can probably get a speed boost from it 
in some circumstances as well.

>I detest the pseudo-hash implementation (the part that's exposed to the 
>user, I mean).

I'm pretty sure that's slated to die a quick death.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk