Re: Loop exiting
coming from a c++ background, I constantly type break instead of last only
to be scolded by the syntax checker. If my faubles result in incorrectly
executing program ( a mysterious error at that!) then I and many other C++
programmers will waste a lot of time hunting down a trivial bug. I
understand the need for an implied given, but when faced with code like:
for @foo -> $bar {
when /this/ { ... break; ... }
when /that/ => { ... last; ... }
when /the other/ => { ... next; ... }
}
I get really jittery...To me, it looks like they affect the loop, but
instead one affects an implied given and the others affect the loop.
This should at least be a very stern warning.
Secondly,
for @list -> ($bar, $baz) {
when /this/ { ... }
}
is this equivalent to
if( ($bar, $baz) =~ /this/ ) { ... }
if so, what does that mean?
Finally,
if the correct syntax is:
for $a, $b -> $c, $d
then I would like to say that while this does mimic the C syntax, it
doesn't put identifiers and their values close to each other like
for $a -> $c,
$b -> $d
does. This is not to be construed as a bad thing...in fact, it might
promote people to not use the C< -> > for more than two or three values.
Tanton
- Original Message -
From: "Austin Hastings" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 25, 2002 3:43 PM
Subject: Re: Loop exiting
> Currently,
>
> given $foo -> $bar
> {
> }
>
> can be thought of as
>
> foreach my $bar ($foo)
> {
> }
>
> Given the way people with expectations will interpret break, setting
> break === last seems like the right thing to do.
>
> =Austin
>
> --- Larry Wall <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] writes:
> > : --- Larry Wall <[EMAIL PROTECTED]> wrote:
> > : > Simon Cozens writes:
> > : > : Larry Wall:
> > : > : > Not the same concept exactly. I think a C within a
> > C
> > : > loop
> > : > : > would be the same as a C, not a C.
> > : > :
> > : > : Doesn't this break C and Shell resonance?
> > : >
> > : > We've done that before. :-)
> > :
> > : Umm, doesn't break translate basically as "leave, now" rather than
> > as
> > : "hop to the loop nexus and consider leaving"?
> >
> > Sure, but it means "leave the switch now", not "leave the loop now".
> >
> > : What's your thinking in equating break w/ next?
> >
> > Only that
> >
> > for @foo {
> > ...
> > }
> >
> > can be thought of as shorthand for
> >
> > for @foo -> $temp {
> > given $temp {
> > ...
> > }
> > }
> >
> > I am also assuming that the break is only meaningful as a switch
> > control,
> > not a loop control. But I can see where it would be confusing.
> > Perhaps
> > C should be illegal inside a C, and the user forced to
> > choose
> > between C and C.
> >
> > Larry
>
> __
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
>
-> and .
Since Perl is changing from -> to . (a change I welcome). It might be
interesting to ask ourselves if there is any benefit from langauges like C++
or OCL that use both the -> and the .
>From OCL's point of view the -> is used for "meta" level things such as
iterations over collections. The . is used for actual object method calls.
>From C++'s point of view, there is really no need for two different
operators (one for pointers and the other for stack allocated). However,
the reason is primarily historical as it adopted the syntax from C.
Nevertheless, C++ benefits from this syntax becuase it allows things to
overload the -> operator thereby allowing smart pointers and such while the
.. operator cannot be overloaded to ensure correct binding semantics.
I was wondering if Perl6 could take advantage of this type of idea and have
some sort of way to overload operator "."
I could see something like:
method operator.( $self: $function ) {
if( $function eq "inc" ) { ++%self.funcount{$_[2]}; }
else { $self.inc( $function ) }
}
That would count how many times you called each function.
The problem then is when you call a method or access a data member inside
operator "." then it becomes infinitely recursive. Nevertheless it would be
really nice if this type of functionality could be achieved fairly simply.
Any ideas?
Tanton
Re: Loop controls
What about unless? Since we are giving els to loops, shouldn't we upgrade unless as well? That would be really weird if it were not upgraded. Tanton - Original Message - From: "Jonathan Scott Duff" <[EMAIL PROTECTED]> To: "Allison Randal" <[EMAIL PROTECTED]> Cc: "Aaron Sherman" <[EMAIL PROTECTED]>; "Perl6 Language List" <[EMAIL PROTECTED]> Sent: Monday, April 29, 2002 4:01 PM Subject: Re: Loop controls > On Mon, Apr 29, 2002 at 02:55:09PM -0500, Allison Randal wrote: > > I still don't like the idea of Cs on loops. I already do an > > instant double take with C of "Where's the if?" (with visions of > > old Wendy's commercials dancing in my head). > > Me too. That's why the looping "else" should be spelled "otherwise" > IMHO. > > -Scott > -- > Jonathan Scott Duff > [EMAIL PROTECTED] >
Re: Regex query
> > This kind of clever magic always makes me nervous: > > it introduces subtle bug potentials. > > > > (7,8,9) == 3 # true > > (7,8) == 2 # true > > (7) == 1 # false > > () == 0 # true? > > I believe the last two cases should be: > > (7,)== 1 > (,) == 0 > > Because its the perl6 comma that creates the list, not the parenthesis. > > ~ John Williams If this is the case, then can you also have: (,7) What is its length? Tanton
Re: Regex query
> > This kind of clever magic always makes me nervous: > > it introduces subtle bug potentials. > > > > (7,8,9) == 3 # true > > (7,8) == 2 # true > > (7) == 1 # false > > Why is this one false? I'd expect it to be true just as the others. (7) == 7 why? Otherwise, we couldn't use parens for mathematical expressions (3 + 4) == 7 -- the mathematical way (3 + 4) == 1 -- the length of the list ... BAD! Tanton
Re: Unifying invocant and topic naming syntax
> How about this: > >$_ # current topic >$__ # outer topic >$___ # outer outer topic > Unfortunately, or maybe fortunately, that is impossible to read correctly without having to move the cursor and count how many underscores exist. It seems to me, that in English, it is hard to correctly jump to a previous topic without being fairly explicit. If you start talking about trapeze artists and I change the subject to monkees, then if I say I like the way they swing, you should assume I am talking about monkees unless I have explicitly changed the topic back to trapeeze artists. I don't think there should be a shortcut to do this, an explict way, yes, but not a shortcut as it seems to break the English analogy. Tanton
any type
Has there been any discussion about having an "any" type. Something such as:
my any $x = "Hello";
$x = 17.3;
$x = Foo.new;
I realize that this can be accomplished with an untyped variable, but there may be a
reason not to do that. Namely, there most probably will be some sort of pragma like
"use strict 'type'" which will ensure every variable is typed. Furthermore, even it
typed programs it may be useful to have a datastructure that can contain different
types of values (e.g., hash of any, array of any). Therefore, it would be very
convienient to have an any type. It may be that UNIVERSAL's Perl6 counterpart plays
this role, but I would think that it would only hold objects, not things like int and
string (although they could be promoted ot Int and String automatically). Secondly,
if we do have an any type, there should be some way to figure out what the type really
is. Something like, but more powerful than, Perl5's ref function. It should tell the
user what the type is in an easily understandable fashion...it should also give the
user as much information as possible. For example:
my any %hash;
my any @arr;
my int @intarr;
my Foo $f;
%hash{arr} = \@arr;
%hash{intarr} = \@intarr;
%hash{Foo} = $f;
type_of( %hash{arr} ) == ("array", "any" );
type_of( %hash{intarr} ) == ("array", "int" );
type_of( %hash{intarr}[7] ) == ("int");
type_of( %hash{Foo} ) == ("Foo");
On a tangential note, how would you specify a hash of arrays of ints?
Comments?
Tanton
Re: purge: opposite of grep
> Damian Conway wrote: > > or even a arrayed form, when the corresponding index was implicit: > > > > (@foo,@bar,@zap) := part [/foo/, /bar/, /zap/], @source; > > That's kinda nifty. But admittedly, it's not to-die-for necessary, if > I'm the only one fond of it. I think this makes a nice specialization of the hash approach. However, I believe it will become cumbersome with anything other than trivial expressions. The hash approach, in that case, would be clearer. Tanton
Re: right-to-left pipelines
> As I said, I wasn't sure whether or not I was being serious at this point.
>
> > > > method bar($x, $y) {
> > > > method bar($z) { # note 1
> > > Oh, bringing in multimethods Just Isn't Fair.
> >
> > Those are multimethods? Migod, I feel like a person who's just
> > discovered for the first time in their life that the plate that gets
> > passed around in church is for putting money *onto*.
>
> Oh, if you have a method which does X when it gets one argument and does
> Y when it gets another, I'd call that a multimethod. But then, I am no
> OO wizard.
I would just call that overloading based on number of arguments
A multimethod is a mehtod that is overloaded based on types of arguments.
Moreover,
the types of the arguments are based on the dynamic, not static, type.
method foo( Derived1 $x, Derived2 $y ) { }
method foo( Derived2 $x, Derived1 $y ) {}
my Base $x = new Derived1;
my Base $y = new Derived2;
foo( $x, $y );
foo( $y, $x );
Since foo is a multimethod, the correct foo gets chosen each time, even
though the static type
of $x and $y is Base.
Re: "Arc: An Unfinished Dialect of Lisp"
> The problem with cons/car/cdr is that they're fundemental operations. > Graham *has* learned from perl, and is receptive to the idea that > fundemental operators should be huffman encoded (lambda -> fn). It > would be easy to simply rename car/cdr to first/rest, but that loses > the huffman nature of car/cdr. hmm...ML uses hd and tl. I believe that is pretty coded :)
