Eliza RFC
Now that Clint has Eliza running on Parrot, I propose that from henceforth, Eliza shall field all newbie questions and take responsibility of the FAQ. Eliza should also field discussions concerning why we don't add new keywords such as "elloopo"; if you can convince Eliza, then the proposal shall be forwarded to Larry. . Including stackops.pasm Including alpha.pasm Including dumpstack.pasm Including tokenize.pasm Including basicvar.pasm Including basic.pasm Including instructions.pasm Including expr.pasm 4239 lines Ready LOAD eliza.bas Got and processing LOAD eliza.bas LOADING eliza.bas...DONE Ready RUN Got and processing RUN Please wait, initializing...(This will take a minute) I am Eliza, the Computer Psychiatrist Why have you requested this session? i want elloopo WHAT WOULD IT MEAN TO YOU IF YOU GOT ELLOOPO i would crush the rest of you DO YOU FEEL INTENSE PSYCHOLOGICAL STRESS? possibly WHAT DOES THAT SUGGEST TO YOU? that elloopo may be too important to me but i still want it I SEE. thank you please tell larry we need elloopo WE WERE DISCUSSING YOU NOT ME. we were DISCUSSING ELLOOPO! SYMBOL NAME TOO LONG: we were DISCUSSING ELLOOPO|1,1 Apparently this could be construed as convincing Eliza, I'm not sure though, I'll ask next session. -Melvin
Re: Loop controls
> Damian, now having terrible visions of someone suggesting C ;-) Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ... :-) -Miko
Re: Loop controls
On Tue, 30 Apr 2002, Miko O'Sullivan wrote:
> > Damian, now having terrible visions of someone suggesting C ;-)
>
> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
Ooh! Why don't we have a dont command! With several variants:
dont FILE
dont BLOCK
dont { print "Boo" }
Would print:
Luke
Re: Loop controls
On Tuesday, April 30, 2002, at 01:22 PM, Dan Sugalski wrote:
> At 1:07 PM -0400 4/30/02, Miko O'Sullivan wrote:
>> > Damian, now having terrible visions of someone suggesting
>> C ;-)
>>
>> Then may I also give you nightmares on: elsdo, elsdont, elsgrep,
>> elstry ...
>
> Has anyone brought up elselse or unlessunless yet?
All of this is a bit silly, but if loops in Perl6 had some sort of
boolean value of their own, then it seems the language already has a way
to approach this. Scoping might be a problem, but...
for @foo -> $bar {
...
} // print "The loop didn't... uh... loop.\n";
Just a thought.
Re: Loop controls
On Tue, 2002-04-30 at 13:07, Miko O'Sullivan wrote:
> > Damian, now having terrible visions of someone suggesting C ;-)
>
> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
Aaron, trying hard not to be a crackpot, but getting the impression
that's now just a dream :-/
If we all agree that the meaning of "els" is
clear, but we dislike adding insane numbers of keywords to the language,
let's step back and ask why it would have ever occurred to us to do such
a silly thing.
Since the beginning of this discussion, I've been happy to accept the
idea that "elswhile" is ugly and unmanageable, but I saw no other way,
given the if/elsif syntax.
I do think that unifying the if/loop syntax is wildly useful, but
there's no reason that we HAVE to put the burden on the loop constructs.
Why do we use "elsif"? Well, it seemed like the right choice at the
time, and avoided C's infamous ambiguity by allowing braces without
bogging down the programmer (Larry, jump in if that wasn't the
reasoning, it's been nearly a decade since I last saw you discuss the
topic).
What would happen if we had:
if expr {
...
} else if expr {
...
} else {
...
}
Not as a naked (i.e. un-braced) statement, but if "else if" were treated
as a single token (either at the tokenizer level or gathered together in
the parser, it doesn't really matter).
In this case, you could have all of the funky control structures you
want, but the user does not have to play string-concatenation games in
their head.
It's reasonably obvious what:
unless my $fh=$x.open {
die "Cannot open $x: $!";
} else while $fh.getline -> $_ {
print;
} else {
die "No lines to read from $x";
}
would mean, and it's also a pleasingly simple addition.
Then if you want "else when" or "else do", you're all set. It's an easy
change and there are no new keywords.
I think "else grep" would be pointless, as grep is not a flow-control
structure as such. You can always "else if grep {...} list { ... }"
This also resolves the long-standing question: why isn't there an
"elsunless", which has been asked since as long as I've been programming
in Perl. I see no reason for there not to be "else unless", does anyone
else? unless?
Re: Loop controls
Why not allow C while still allowing C as a synonym,
preserving backwards compatibility while still allowing all these weird
and varied constructs people seem to have use for?
In any case, I don't really see why C necessarily implies all
these other cases, too. Maybe they're useful in the real world, maybe
they're not, but C itself is pretty clearly useful. Perhaps
it's just the type of work I do (system administration), but dealing with
the "zero records" problem is something I have to do in nearly every
program I write, and it always adds an annoyingly inelegant bit of code.
I paste from a bit of code I wrote about a year before this discussion
got started...
my $recs = 0;
while (my $this = $db->getNext()) {
...
$recs++;
}
unless ($recs) { # because while can't tell me it didn't loop...
Now maybe C can. Hurray!
I'd hate to lose such a nice construction as C just because
of the slippery slope argument implied by C, etc. Anyone who's
taken oratory or participated in high school debate teams should know that
slippery slope arguments are always fallacious. :-)
Trey
Re: Loop controls
On Tue, 30 Apr 2002, Trey Harris wrote: > Why not allow C while still allowing C as a synonym, > preserving backwards compatibility while still allowing all these weird > and varied constructs people seem to have use for? Backwards compatability is pretty much a lost cause for Perl 6. You could argue that it's good to keep the people who are used to it happy, but in this case I don't think that's necessary. p52p6 should do all the backwards compatability work. Luke
Re: Loop controls
In a message dated Tue, 30 Apr 2002, Luke Palmer writes: > On Tue, 30 Apr 2002, Trey Harris wrote: > > > Why not allow C while still allowing C as a synonym, > > preserving backwards compatibility while still allowing all these weird > > and varied constructs people seem to have use for? > > Backwards compatability is pretty much a lost cause for Perl 6. You could > argue that it's good to keep the people who are used to it happy, but in > this case I don't think that's necessary. p52p6 should do all the > backwards compatability work. Oops, sorry. I didn't really mean "backwards compatibility." I meant "convention". C could still be the preferred way of writing it, while actually being a synonym for C. Even if there's a rationale here, I think we're really getting in to the realm of gratuitious changes (in the eyes of most Perl 5->6 migrants) if C changes to C. Trey
Re: Loop controls
> Then if you want "else when" or "else do", you're all set. It's an easy > change and there are no new keywords. Agree with everything else you said. One minor question: how would "else do" be different than "else"? do always does, doesn't it? -Miko
Re: Loop controls
so, assuming we have;
print 'you gave me: @wordlist = ';# single quote - no interpolation
for @words -> $it {
print;
FIRST { print '(' }# provisionally
NEXT { print ',' }
LAST {print ');' }
}
# and maybe
else {
print "();\n";
}
this yields:
you gave me: @wordlist = ();
or if (@wordlist) {
# (damn - i want to say orif ;-)
you gave me: @wordlist = (alpha,beta,gamma,);
whereas
print 'you gave me: @wordlist = (', join(',', @words), ")\n";
doesnt include the last comma.
if I remember the thread (now deleted, so cant be accurate)
the last comma would be in there, unlike if it were in a join.
cuz NEXT is a block terminator, not a block-inbetweener
this is vaguely unfortunate, as its not so simple to write
loops to generate SQL ( which isnt as friendly wrt to extra commas as
perl is )
separately ( to re-iterate earlier good thoughts ):
loop {} else {}
would be more visually distinct (easier to read) as
loop {} otherwize {}
esp when loop block is bigger than a screenful, new keyword keeps us
from looking for the if,
and it fits better with natural language (or at least dictionary language )
where the connotation is a final alternative to lots of choices.
http://webster.com/cgi-bin/dictionary?va=otherwise
Main Entry: *^1 oth·er·wise*
Pronunciation: -"wIz
Function: /pronoun/
Etymology: Middle English, from Old English (/on/) /Othre wIsan / in
another manner
Date: before 12th century
*:* something or anything else *:* something to the contrary
vs
Main Entry: *^1 if*
Pronunciation: 'if, &f
Function: /conjunction/
Etymology: Middle English, from Old English /gif; /akin to Old High
German /ibu /if
Date: before 12th century
*1 a* *:* in the event that *b* *:* allowing that * c* *:* on the
assumption that *d* *:* on condition that
*2* *: WHETHER
*
*3* -- used as a function word to introduce an exclamation expressing a
wish
*4* *:* even though
- *if anything* *:* on the contrary even *:* perhaps even
look ma, no typing..
Re: Loop controls
On Tue, 30 Apr 2002, Jim Cromie wrote:
> so, assuming we have;
>
> print 'you gave me: @wordlist = ';# single quote - no interpolation
>
> for @words -> $it {
> print;
> FIRST { print '(' }# provisionally
> NEXT { print ',' }
> LAST {print ');' }
> }
> # and maybe
> else {
> print "();\n";
> }
>
>
> this yields:
> you gave me: @wordlist = ();
> or if (@wordlist) {
> # (damn - i want to say orif ;-)
> you gave me: @wordlist = (alpha,beta,gamma,);
>
> whereas
>
> print 'you gave me: @wordlist = (', join(',', @words), ")\n";
>
> doesnt include the last comma.
>
> if I remember the thread (now deleted, so cant be accurate)
>
> the last comma would be in there, unlike if it were in a join.
> cuz NEXT is a block terminator, not a block-inbetweener
>
> this is vaguely unfortunate, as its not so simple to write
> loops to generate SQL ( which isnt as friendly wrt to extra commas as
> perl is )
I'd rather have an in-betweener block too. Loops like this are very
common, and I hate doing "prefix" commas, if you know what I mean. I
realize NEXT often used for cleanup, so maybe you could introduse Yet
Another block, BETWEEN (or SQUEEZE).
Or are we just going to have to deal with this fact?
>
> separately ( to re-iterate earlier good thoughts ):
>
> loop {} else {}
>
> would be more visually distinct (easier to read) as
>
> loop {} otherwize {}
It would be especially clear if it were spelled correctly ;)
> esp when loop block is bigger than a screenful, new keyword keeps us
> from looking for the if,
> and it fits better with natural language (or at least dictionary language )
>
> where the connotation is a final alternative to lots of choices.
Yes, I think that's a good idea also. I suppose C DWIMs better
though (I've taught people C++, and many times they wonder why they can't
put elses on loops). I think it's really a matter of opinion. Which is, I
suppose, why this list is here.
Luke
Re: Loop controls
Dan Sugalski wrote: > At 1:07 PM -0400 4/30/02, Miko O'Sullivan wrote: > >> > Damian, now having terrible visions of someone suggesting >> C ;-) >> >> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, >> elstry ... > > > Has anyone brought up elselse or unlessunless yet? > and since this line of conjecture keeps going, andif orif orelse
Re: Eliza RFC
At 11:11 AM 4/30/2002 -0400, Melvin Smith wrote: >Now that Clint has Eliza running on Parrot, I propose that >from henceforth, Eliza shall field all newbie questions >and take responsibility of the FAQ. [...] >WE WERE DISCUSSING YOU NOT ME. >we were DISCUSSING ELLOOPO! >SYMBOL NAME TOO LONG: we were DISCUSSING ELLOOPO|1,1 > >Apparently this could be construed as convincing Eliza, I'm not sure >though, I'll ask next session. The bug in BASIC/Eliza has been fixed and committed. It's unlikely you'll be able to convince Eliza to give you the elloopo feature now.
Re: Loop controls
Lots of people said:
>Lots of stuff about 'else' loops.
*Erik thunks himself some deep thought*
I see no true slippery slope here, especially if handled correctly. I suspect that an
explicit or implicit "why not" near the beginning of discussion lead to the feature
feeding frenzy and the slippery slope responses.
To my thinking, assuming this is a needed feature, the ELSE block method is not quite
adequate. We are approaching the limit to the number of implicit blocks within control
structures a mind can be reasonably expected to handle. Although we have made comments
on the placement of these blocks being hapahzard as is, there isn't necessarily a
clear position within the flow of code that is associated with the concepts behind
those blocks. 'ELSE' however seems to clearly need to be after the block to which it
represents an alternative. Scoping issues also tend toward the post block syntax.
The need for such a structure has been most clearly defined and argued for in the case
of 'loop'. While others have said 'I can see advantages' I generally cannot, save in
the case of loop where the synthetic code of the flag to check if the loop was passed
through is a hassle and not clear. Allowing a 'loop {...} else {...}' syntax seems to
fill this niche nicely.
I have always argued that any exceptions to the looping rules should be attatched to
while, as while already had special behavior for DWIM. Now that loop has gained this
behavior anyway, loop seems the most deserving canidate for that reason.
Finally, scoping issues seem to have mostly to do with aliasing. While plenty of
implicit aliasing occurs with 'loop <> {...}' explicit aliasing seems to occur with
'foreach'. By only allowing the else construct on the control structure least likely
to have scoping issues, it makes the learning of the syntax easier. Even if you don't
understand them, you're less likely to run into them. As far as implicit aliasing
goes, I think that it would be clear that the else block only executes if $_ hasn't
been assigned to by the diamond, making it unlikely anyone would be bit by subtle bugs
from the use of $_ in the else block. I hope :-)
So, all of these things seem to say to me that the case can be made for allowing
'loop' to have an 'else' block, and for no other structures to, and that this clock
should work like an if block, and not like the implicit blocks already extant.
-Erik
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: Loop controls
Luke Palmer wrote:
> Ooh! Why don't we have a dont command! With several variants:
> dont FILE
> dont BLOCK
>
> dont { print "Boo" }
>
> Would print:
>
>
You really *should* be more careful what you wish for Luke.
The following was just uploaded to the CPAN...
Damian
-cut--cut--cut--cut--cut--cut-
NAME
Acme::Don't - The opposite of `do'
VERSION
This document describes version 1.00 of Acme::Don't, released May 1,
2002.
SYNOPSIS
use Acme::Don't;
don't { print "This won't be printed\n" };# NO-OP
DESCRIPTION
The Acme::Don't module provides a `don't' command, which is the opposite
of Perl's built-in `do'.
It is used exactly like the `do BLOCK' function except that, instead of
executing the block it controls, it...well...doesn't.
Regardless of the contents of the block, `don't' returns `undef'.
You can even write:
don't {
# code here
} while condition();
And, yes, in strict analogy to the semantics of Perl's magical
`do...while', the `don't...while' block is *unconditionally* not done
once before the test. ;-)
Note that the code in the `don't' block must be syntactically valid
Perl. This is an important feature: you get the accelerated performance
of not actually executing the code, without sacrificing the security of
compile-time syntax checking.
LIMITATIONS
Doesn't (yet) implement the opposite of `do STRING'. The current
workaround is to use:
don't {"filename"};
AUTHOR
Damian Conway ([EMAIL PROTECTED])
BLAME
Luke Palmer really should be *far* more careful what he idly wishes for.
BUGS
Unlikely, since it doesn't actually do anything. However, bug reports
and other feedback are most welcome.
COPYRIGHT
Copyright (c) 2002, Damian Conway. All Rights Reserved. This module is
free software. It may be used, redistributed and/or modified under the
terms of the Perl Artistic License (see
http://www.perl.com/perl/misc/Artistic.html)
Re: Loop controls
So, after all our discussions, my thinking regarding alternate blocks for
loops is now running like this:
1. It would definitely be useful to be able to catch the failure of a
block to iterate.
2. This ability should be available for all three types of block: C,
C, and C.
3. The "obvious" syntax:
while condition() {
...
}
else {
...
}
is fraught with difficulty because C is already so closely
bound to C in the community consciousness.
4. Using C also encourages the expectation of C, C,
C, C, etc. But I don't believe the language can
comfortably bear the weight of such expectations. Or such keywords.
5. My preferred option would be to restrict the "alternative block" to
only being a simple block (i.e. no cascading), and to introduce it
with some other keyword.
6. C would seem to fit the bill rather nicely.
So, I guess if Larry were to ask my opinion, I'd suggest that we allow:
while condition() {
...
}
otherwise {
...
}
and:
for @list -> $next {
...
}
otherwise {
...
}
and:
loop ($i=0; i<$max; i+=2) {
...
}
otherwise {
...
}
I now confidently await Larry's coming up with an entirely different solution ;-)
Damian
Re: Loop controls
"Miko O'Sullivan" <[EMAIL PROTECTED]> writes: > > Damian, now having terrible visions of someone suggesting C ;-) > > Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ... To quote from the INTERCAL manual (and I doubt I'm the first to steal features from that powerful language): PLEASE ABSTAIN -- Ariel Scolnicov|http://3w.compugen.co.il/~ariels Compugen Ltd. |[EMAIL PROTECTED]"Sometimes people write an 72 Pinhas Rosen St.|Tel: +972-3-7658117 accidental haiku. Damn! Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555 It just happened!"
