Control Structures I: given
Hi all. I missed out on the original RFC process; it was over before
I even heard of perl6. Anyway, there's something I want to contribute to the
Perl community. I've had an idea about control structures which I've never
seen anywhere else, so I guess I'm the inventor :). I hope this is the
appropriate forum to do it; it looks to me like it is, but I could be wrong.
I was planning to put them all in one message, but then I thought it
would be more useful to separate them, so I'll do that instead; they'll make
much more sense if you read them in order.
Anyway, the first part is the given statement modified to fit this
idea. It'd run something like this:
--
given ($this) {
when $that_happens { Have a party }
when $that_doesnt_happen { Sing }
all {
# Do something
}
any {
# Do something else
}
some {
# Do something other
}
none {
# Do something however
}
}
--
The basic idea is that you have two special variables which I will,
just for now, call $truecount and $falsecount. Basically, every time one of
the when clauses comes up true, it increments truecount; whenever one comes
up false, it increments $falsecount. The blocks below the given get evaluated
under the following conditions
all: $falsecount == 0
any: $truecount 0
some: $falsecount 0
none: $truecount == 0
So anyway, none replaces the old default option, and the others
can be useful from time to time too :).
Hope this is useful.
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: [EMAIL PROTECTED] | I am |
-
BEGIN GEEK CODE BLOCK
Version 3.1
GCS d? s: a-- C++$ US+ P++ L++ E- W+++ N+ w+ M-- V- Y+++
PGP-++ R(+) !tv B++ DI D+ G e++ h!/* y-
-END GEEK CODE BLOCK-
Control Structures II: loop
Here's the next part to the Control Structures message I sent before.
The next part is to apply the same idea to loop. Please note that
this syntax conflicts with stuff already in Perl, but it's a bit clearer what
I mean when I do it this way; the question is, do we scrap my idea, or the
other syntax? :)
I'll begin with a few words of explanation of what follows. First,
you normally wouldn't spread it out this much. Second, each line is
optional, except loop and { blockL }.
--
loop
parallel
first { BLOCKF }
each [ actual ] [ $key [ = $value ] ] (@array|%hash)
while ( EXPR )
count [ $autocount ] [ ($start, $end, $step) ]
nest { BLOCKT }
{ BLOCKL }
next { BLOCKX }
all { BLOCKA }
any { BLOCKB }
some { BLOCKS }
none { BLOCKN }
--
Anyway, in this one, the loop can function as anything. I'm calling
the each, while, and count lines iterator sections.
each:
each takes top priority. If it's present, the loop goes around
@array.end times. The actual means that if you modify $_ (or $key, or
whatever), then it modifies the array element too.
while:
If while is present it gets evaluated each time the loop goes around.
It takes second priority to each. If there is no each present, then when the
while is false, the loop exists. If there's an each present, the status of
the while expr only affects the $truecount and $falsecount variables.
count:
The count section sets the automatic counter variable, and the
parameters of the count. $start defaults to 0. $end defaults to infinity.
$step also defaults to 1. If the count reaches $end, but there is a while or
an each, then the autocount stops incrementing, but the loop keeps going.
nest:
Nest is the power loop thingy documented in Raphael Finkel's top notch
book Advanced Programming Language Design, near the end of the Control
Structures chapter -- this book is in PDF format:
http://www.nondot.org/sabre/Mirrored/AdvProgLangDesign/
post-loop structures:
The all|any|some|none set work exactly the same way as with the given
statement; they are based on the values of $truecount and $falsecount.
Anyway, I hope this makes sense.
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: [EMAIL PROTECTED] | I am |
-
BEGIN GEEK CODE BLOCK
Version 3.1
GCS d? s: a-- C++$ US+ P++ L++ E- W+++ N+ w+ M-- V- Y+++
PGP-++ R(+) !tv B++ DI D+ G e++ h!/* y-
-END GEEK CODE BLOCK-
String concatentation operator
Quoted from Seven Deadly Sins of Introductory Programming Language Design [1] by Linda McIver and Damian Conway: We have shown over one thousand novice programming students the C/C++ expression: the quick brown fox + jumps over the lazy dog and asked them what they believe the effect of the + sign is. Not one of them has ever suggested that the + sign is illegally attempting to add the address of the locations of the first two characters of the two literal strings. Without exception they believed that the + should concatenate the two strings. Makes perfect sense to me. Can we overload + in Perl 6 to work as both numeric addition and string concatenation, depending on the type of the operand on the left? I realise the answer is probably not, given the number/string ambiguity of Perl variables: my $a = 123; my $b = 456; $a + $b; # 579 or 123456? I quite like '_' as the string concatenation operator (so much so that I added it to the Template Toolkit some time ago, confidently telling people that it's what Perl 6 would use :-). It ties in nicely with the 123_456 numerical style. On the other hand, I'm not a big fan of using '~' to indicate string context. The tilde (aka wobbly operator) seems much better suited to smart matching, IMHO, being reminiscent of the almost equal to operator (which I would attempt to include here if I had the slightest clue how to make my keyboard speak Unicode). Another option: could we quote operators to indicate string context? $a + $b This would tie in nicely with using [ ] to indicate vectorised operators, although I realise that particular syntax has been disvogued of late. a [+] b A [1] http://www.csse.monash.edu.au/~damian/papers/ [2] [2] Good paper, well worth a read. That Conway chap seems to know his cookies. His name rings a bell, too...
Re: String concatentation operator
Andy Wardley wrote: Can we overload + in Perl 6 to work as both numeric addition and string concatenation ... Isn't there some nifty Unicode operator perl6 could enlist? ;) How about concatenating adjacent operands? ANSI C does this with string constants and it works very well. It would become one of those great Perl sound bites too: the community couldn't decide on the operator, so perl6 left it out. - Ken
Re: Control Structures I: given
On Fri, Nov 15, 2002 at 07:05:26AM +1100, Timothy S. Nelson wrote:
--
given ($this) {
when $that_happens { Have a party }
when $that_doesnt_happen { Sing }
all {
# Do something
}
any {
# Do something else
}
some {
# Do something other
}
none {
# Do something however
}
}
--
So, I was all set to show how this could work with junctions, but then
I realized that I don't understand them well enough, so here's what I
came up with:
$j0 = $that_happens | $that_doesnt_happen;
$j1 = !$that_happens | !$that_doesnt_happen;
given ($this) {
when $j0 ~~ $that_happens { ... }
when $j0 ~~ $that_doesnt_happen { ... }
when all($j0) { ... }
when any($j0) { ... }
when any($j1) { ... }# some Rare, I expect
when none($j0) { ... }
}
Is that right? Is there a better way? What happens when there's a
junction on either side of a smart match?
The basic idea is that you have two special variables which I will,
just for now, call $truecount and $falsecount. Basically, every time one of
the when clauses comes up true, it increments truecount; whenever one comes
up false, it increments $falsecount. The blocks below the given get evaluated
under the following conditions
all: $falsecount == 0
any: $truecount 0
some: $falsecount 0
none: $truecount == 0
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Control Structures I: given
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 15 Nov 2002 07:05:26 +1100 (EST)
From: Timothy S. Nelson [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Hi all. I missed out on the original RFC process; it was over before
I even heard of perl6.
Right. Me too. But, as you'll notice, this is certainly not keeping
it from changing :)
Anyway, there's something I want to contribute to the Perl
community. I've had an idea about control structures which I've
never seen anywhere else, so I guess I'm the inventor :). I hope
this is the appropriate forum to do it; it looks to me like it is,
but I could be wrong.
Yes, it is.
Anyway, the first part is the given statement modified to fit this
idea. It'd run something like this:
--
given ($this) {
when $that_happens { Have a party }
when $that_doesnt_happen { Sing }
all {
# Do something
}
any {
# Do something else
}
some {
# Do something other
}
none {
# Do something however
}
}
--
The basic idea is that you have two special variables which
I will, just for now, call $truecount and $falsecount. Basically,
every time one of the when clauses comes up true, it increments
truecount; whenever one comes up false, it increments $falsecount.
The blocks below the given get evaluated under the following
conditions
all: $falsecount == 0
any: $truecount 0
some: $falsecount 0
none: $truecount == 0
So anyway, none replaces the old default option, and the others
can be useful from time to time too :).
Well, it's an interesting idea, but I don't think it's necessary. I
honestly don't recall a time when this would be useful. Perhaps a
sane example could convince me otherwise...
(As a rule of thumb, always include sane, real-world-like examples in
proposals)
Luke
fonts (was Re: perl6 operator precedence table)
Sorry for the one-month-old response, but this message fell between the cracks and I was just reviewing all my old new mail In a message dated Sun, 20 Oct 2002, Me writes: Somebody fairly recently recommended some decent fixed-width typefaces. I think it may have been MJD, but I can't find the reference right now (could be at work). Michael Schwern recently suggested Monaco, Neep or, if you can find them, Mishawaka or ProFont. I investigated and found this link to be useful: http://www.tobias-jung.de/seekingprofont/ I really like the font I have on my iMac called QuickType. Unfortunately, I can't figure out where it comes from, as none of my font files have a name resembling anything like that. I need to find a utility that will identify what file a given font comes from. Trey
Re: Control Structures III: flow modifiers
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 15 Nov 2002 07:46:21 +1100 (EST)
From: Timothy S. Nelson [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
These are mostly not my ideas (except activate); hopefully not too
many of them have already been used.
In the same list as last, next, and redo, we should also have
- deeper (works with nest -- cf. II: loop)
- yield and resume (for co-routines)
Also useful could be:
activate blockname
deactivate blockname
Useful for optimising:
---
$first = 1;
foreach (@example) {
if($first) {
do_something;
$first = 0;
} else {
do_normal_stuff;
}
}
---
Can be done as:
---
LABEL: foreach(@example) {
OTHEREXAMPLE: {
do_something;
deactivate OTHEREXAMPLE;
next LABEL;
}
do_normal_stuff;
}
---
Also, it could be done as:
for @example { # the foreach keyword has gone away
FIRST {
do_something;
next;
}
do_normal_stuff;
}
Beautiful.
Deactivating blocks, on a more general scale (if you find it useful),
can be achieved because of the new concept of everything is a
closure:
our bit %inactive;
sub block ($name: block) {
block() unless %inactive{$name}
}
sub deactivate ($name) {
%inactive{$name} = 1
}
LABEL: foreach(@example) {
block 'OTHEREXAMPLE': {
do_something;
deactivate 'OTHEREXAMPLE';
next LABEL;
}
do_normal_stuff;
}
Re: String concatentation operator
On Thu, Nov 14, 2002 at 12:19:47PM +, Andy Wardley wrote:
Can we overload + in Perl 6 to work as both numeric addition
and string concatenation, depending on the type of the operand
on the left?
I realise the answer is probably not, given the number/string
ambiguity of Perl variables:
my $a = 123;
my $b = 456;
$a + $b; # 579 or 123456?
Its worse than that, what does this do:
sub add ($num1, $num2) {
return $num1 + $num2;
}
add($foo, $bar);
There are obvious simple cases
$foo = 23; $bar = 42; (perl can figure this one out easy)
$foo = foo; $bar = bar; (perl can figure ditto)
but it rapidly gets ambiguous
$foo = 23; $bar = 'bar';
$foo = '23'; $bar = 42;
so maybe you can solve it with types:
sub add (number $num1, number $num2) {
...
}
but what about this very simple case:
# We read in from a file, so should Perl consider them
# strings or numbers?
@numbers = slurp 'number_file'; chomp @numbers;
$total = $numbers[0] + $numbers[1];
then you have to do something like this:
number @numbers = slurp 'number_file'; chomp @numbers;
$total = $numbers[0] + $numbers[1];
and I really, really, really don't want to even have to think about types
for basic tasks.
No matter what you decide 23 + 'bar' should do (should it concat? should it
add? should it be an error?) it will be wrong to 2/3 of the population
because the add/concat idea violates the cardinal rule of overloading:
Don't make the same op do two different things.
While people might think string concatination is the same as numeric
addition, its really quite a different operation. If we were to try and
make + do similar things for both it would either be:
23 + 42 == 64;
'a' + 'c' == 'd';
or
'a' + 'c' == 'ac';
23 + 42 == 2342;
If you find yourself having to decide between two radically different
behaviors when a binary op is presented with two different types, something
is wrong.
The real question is: should adding two strings to anything at all?
And the real question below that one is: how far should type coercion go?
In Perl 5 it stops at a sane point:
$ perl -wle 'print bar + foo'
Argument foo isn't numeric in addition (+) at -e line 1.
Argument bar isn't numeric in addition (+) at -e line 1.
0
Ok, so string + string does something almost as odd as C does, but at least
it warns about it. And that's probably a good default way to handle it.
copout type=standardAnd you can always just change the behavior of
strings in a module./copout
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Monkey tennis
Re: String concatentation operator
On Thu 14 Nov, Michael G Schwern wrote: On Thu, Nov 14, 2002 at 12:19:47PM +, Andy Wardley wrote: Can we overload + in Perl 6 to work as both numeric addition and string concatenation, depending on the type of the operand on the left? There have been times when I have wondered if string concatination could be done without any operator at all. Simply the placement of two things next to each other as in $foo $bar or $foo$bar would silently concatenate them. But then I feel there are some deep horrors and ambiguities that I have failed to spot... Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst Services
Re: String concatentation operator
On Thu, Nov 14, 2002 at 09:10:07PM +, Richard Proctor wrote: There have been times when I have wondered if string concatination could be done without any operator at all. Simply the placement of two things next to each other as in $foo $bar or $foo$bar would silently concatenate them. But then I feel there are some deep horrors and ambiguities that I have failed to spot... Before this starts up again, I hereby sentence all potential repliers to first read: string concatenation operator - please stop http://archive.develooper.com/perl6-language;perl.org/msg06710.html and then read *all* the old proposals and arguments about why they won't work: s/./~/g http://archive.develooper.com/perl6-language;perl.org/msg06512.html Sane + string concat prposal http://archive.develooper.com/perl6-language;perl.org/msg06578.html YA string concat propsal http://archive.develooper.com/perl6-language;perl.org/msg06598.html Dot can DWIM without whitespace http://archive.develooper.com/perl6-language;perl.org/msg06627.html Another string concat proposal http://archive.develooper.com/perl6-language;perl.org/msg06639.html YAYAYA string concat proposal http://archive.develooper.com/perl6-language;perl.org/msg06650.html a modest proposal Re: s/./~/g http://archive.develooper.com/perl6-language;perl.org/msg06672.html -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Here's hoping you don't become a robot!
Re: String concatentation operator
On 2002-11-14 at 16:47:15, Michael G Schwern wrote: string concatenation operator - please stop http://archive.develooper.com/perl6-language;perl.org/msg06710.html BTW, the first link there - to the bikeshed story - is broken. This is the correct link: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING (note that there is no underscore in ISO8859). -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: String concatentation operator
Michael G Schwern wrote: Before this starts up again, I hereby sentence all potential repliers to first read: string concatenation operator - please stop http://archive.develooper.com/perl6-language;perl.org/msg06710.html The bike shed thing is like Godwin's Law. Only I don't know which side loses. ;) Wasn't one of the main problems with Jarkko's juxtaposition proposal that it would kill indirect objects? Have we chased our tail on this subject after the colon became required for indirect objects? If the assignment variant of the invisible concatentation operator could be solved, juxtaposition seems like a reasonable approach. (Line ending juxtaposition problems could be fixed with a special rule similar to the '} by itself' rule.) - Ken
Re: String concatentation operator
At 5:57 PM -0500 11/14/02, Ken Fox wrote: Michael G Schwern wrote: Before this starts up again, I hereby sentence all potential repliers to first read: string concatenation operator - please stop http://archive.develooper.com/perl6-language;perl.org/msg06710.html The bike shed thing is like Godwin's Law. Only I don't know which side loses. ;) Wasn't one of the main problems with Jarkko's juxtaposition proposal that it would kill indirect objects? Have we chased our tail on this subject after the colon became required for indirect objects? I dunno. Makes the direct object syntax interesting as well. What does: $foo = any(Bar::new, Baz::new, Xyzzy::new); $foo.run; do? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: String concatentation operator
From: Dan Sugalski [mailto:dan;sidhe.org] At 5:57 PM -0500 11/14/02, Ken Fox wrote: Wasn't one of the main problems with Jarkko's juxtaposition proposal that it would kill indirect objects? Have we chased our tail on this subject after the colon became required for indirect objects? I dunno. Makes the direct object syntax interesting as well. What does: $foo = any(Bar::new, Baz::new, Xyzzy::new); $foo.run; do? If you're wonder what Joe I can hardly keep up Blogg thinks... Assuming junctions have neither a property nor a method named 'run', I'd assume that $foo in a want method context would delegate the run method invokation to one of the object-eigenstates. But what would: $foo = all(Bar::new, Baz::new, Xyzzy::new); $foo.run; do? Invoke the run method against all of the object-eigenstates? And if not in a void context, return a junction containing their results? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: More junctions
Luke Palmer asked: When junctions collapse, Sigh, not another one of those dreadful reality TV shows: When animals attack When drivers collide When junctions collapse Next we'll get: When mailing lists explode When threads perpetuate When Piers summarize When Larrys make puns ;-) is that reflected back in the original junction, No. as it should be (QM-wise)? Except, of course, junctions aren't QM (hence the name change). They're inspired by, but not slavishly constrained by, the laws of Physics. ;-) $foo = 1 | 2 | 4 print $foo; # Foo is now just one of (1, 2, 4); i.e. not a junction Nope. $foo is still a conjunction. BTW, it's likely that printing $foo *won't* just randomly select one state; that it will call $foo.serialize and print whatever string that (standard) method returns. To get the select one at random behaviour, you need'll: print $foo.pick; If so, what is perl going to do about the computationally expensive entanglement thingy? Nothing. Unless Alex ports his Quantum::Entanglement module. $x = 0 | 1; $y = 0 | 1; $z = $x * $y; print $z; # 0 with 0.75 probability and 1 with 0.25 No. This probably just prints 0 1. # If 0 was printed, then $x | $y == 0 # If 1 was printed, then $x $y == 1 BTW, isn't that a seductive notation. ;-) Here, are $x and $y collapsed yet, or are they still in an entangled superposition? Neither. They're still two completely independent junctions. Damian
Re: Unifying invocant and topic naming syntax
Micholas Clarke asked:
If a subroutine explicitly needs access to its invocant's topic, what is so
wrong with having an explicit read-write parameter in the argument list that
the caller of the subroutine is expected to put $_ in?
Absolutely nothing. And perfectly legal. You can even call that rw parameter $_
if you like:
sub get($id_obj, $_ is rw) {
when who { return $id_obj.name }
when choose { return any($id_obj.features).pick }
when all { return $id_obj.features }
}
for «name choose all» {
print get($obj, $_);
}
If I understand all this correctly, as is, this access caller's topic
is an unrestricted licence to commit action at a distance.
Yes. As in Perl 5.
Accessing the caller's topic is the default in perl5. And there is still a
steady stream of bugs to p5p where core perl modules are doing something
(typically a while loop) which tramples on $_, and so makes something go
wrong in their caller. (possibly several levels down)
Yes. That's why it's not the default in Perl 6, and you have to specify
a verbose and slightly ungainly property in order to get the behaviour.
Damian
