Learning curve (was Re: Perl6 Operator List)
Chris Dutton wrote:
> So many operators...
Well, this seems a good as time as any to jump in with what's been
sticking in my brain for a while now. Last June, Simon C. wrote a
little philosophical thing, "Half measures all around", which generated
the appropriate amount of good discussion. I want to try and make a
case that's sortof tangential to that, but not, at the same time.
Here's my own argument for using "like/unlike", and "none", and a bunch
of other english-sounding things we haven't even talked about yet.
My general background is in tutoring/mentoring/educating/evangelizing
"new" programmers, where "new" either means new to programming, or new
to Perl5, or both. That's my little niche -- taking newbies, and
shoving them up the curve until they know the ins and outs. Pretty
successful at it too, I think. I mention this only because it seems to
be different from the experience of much of perl6-lang ... most of the
people here seem to be more of the "expert" level, people who you call
because they know Everything Perl, Always. :-) I'm typically more
focused on the beginning-level people.
Premise: So far, we've already gotten Perl6 to be much more powerful
than Perl5, and cleaned up a few of the more troublesome perl5
inconsistencies, but I don't think we've put much of a dent in the
"readability" complaints that non-perlers often voice (and we all know
I'm being generous in my phrasing, there.) I think we need to care
about these concerns a _lot_ more than we have in the past, simply
because of the cynical but obvious linkages:
1) I want to use Perl6, because I am confident that I can program
things faster in Perl6 than in any other mainstream language.
2) I only want "good" Perl6 programmers, so I don't give a, um, 'darn'
how much of the random population uses Perl6 in general, BUT...
3) The general population won't use it unless they can easily
understand it through self-study, and/or have been exposed
to it in an educational setting.
4) Joe Manager of Company X won't use it unless he can find
lots of programmers in the general population that know it.
5) If none of the Joe Managers in the other companies use it,
suddenly it puts a lot of pressure on me to explain why *we're*
using it, instead of, say, Java or C#. "It's better"
doesn't really fly, because the company's non-technical
staff judges "better" based primarily on the number of
magazine articles that mention the language.
6) Suddenly, my staff using Perl6 becomes a political issue, not a
technology one. I fight the battles, eventually quitting
the industry in disgust and moving to the California desert
where I put up "no trespassing" signs, dig a series of
inexplicable washing-machine sized holes, and wait for
the impending collapse of human civilization.
OK, that's why we care what the world thinks. Back on topic: so far
we've got conciseness, and a feature set that's essentially the
best-practices compilation of modern, successful programming concepts.
Pretty darn nice.
But understandable, we don't have yet.
Understandability in the large, certainly, is a matter of being able to
express common and/or complicated concepts in a concise enough way to
make the "big picture" of the program visible. So even though Perl6 is
full of nasty constructs such as '^.|=' and similar, I would argue that
(1) things quite that bad will be reasonably sparse in real programs,
and (2) they comprise so much functionality in such a little package
that the overall "flow" of what's happening in an algorithm is much more
understandable. Hence we have all hyperoperators, for example -- just
too much utility there *not* to do it.
But our version of "understandable" still means a steep, steep learning
curve. We need to soften that a bit more for the common cases. My own
solution would be, in part, that we offer english-word aliases like
"like", etc., even if they're only meant as training-wheel versions of
the more linenoisy things, wherever we can. So people can be trained on
the words, and graduate to the "professional" constructs as they become
more comfortable.
My bigger solution would be to reserve a lot more english-sounding
barewords, in all forms, towards the goal of making well-understood
concepts more obvious to newcomers. That's why I've been pushing for
architecturally unnecessary things like using "on" for events/callbacks/assertions:
my $v on get { ... }
on set { ... };
or using constructs like 'as' and 'from' to do very smart, but very
in-your-face-obvious casting/transformations between types/classes,
instead of relying on more ambiguous constructs:
class MyClass {
from OtherClass { ... } # 'alternate' constructors
from int{ ... }
as int { ... } # 'typecasting' multimethods
as str { ... }
as OtherClass { ... }
}
my MyClass $obj = MyClass.new;
print $obj; # as string
print $obj as int;# as int
...
Re: perl6 operator precedence table
Deborah Pickett wrote: Which looks better? if ($a == 1|2|3 || $b eq "x"|"y"|"z") or if ($a == 1||2||3 | $b eq "x"||"y"||"z" ? No question thatthe former works better. Lower precedence operators govern larger chunks, and so should themselves be larger (i.e. more easily detected). I just need some kind soul to pat me on the head and tell me it's OK. ;-) (Please excuse the Monash staff member, it's been a difficult week.) For ex-Monash staff members too. :-( Damian
Re: Perl6 Operator List, Take 2
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> & | ! - superpositional
> all any one (none?)
I don't understand this, on several levels. The lowest level on which
I don't understand it is that testing whether an array is full of threes:
@array & 3
makes sense, but how do you test if all of its elements are more than six?
@array & { $^a > 6 } # ?
If you can't do the latter with the same operator as the former, why have
the operator at all?
Suddenly, @array.all?({ |$a| $a > 6 }) seems a lot more appealing. :)
--
10. The Earth quakes and the heavens rattle; the beasts of nature flock
together and the nations of men flock apart; volcanoes usher up heat
while elsewhere water becomes ice and melts; and then on other days it
just rains. - Prin. Dis.
Re: Learning curve (was Re: Perl6 Operator List)
[EMAIL PROTECTED] (Michael Lazzaro) writes: > But our version of "understandable" still means a steep, steep learning > curve. It's worse than that; for practitioners of many languages, the learning curve has a 180 degree turn. Quick: what are the bitwise operators in Java, JavaScript, C, C++, C#, Perl 5, PHP, Ruby, and Perl 6? Which of these languages do we want to draw programmers from? Someone will now argue that bitwise operators aren't used very often anyway. Great, so we make a change that bites (NPI) people when they least expect it; that makes it all OK. -- BASH is great, it dumps core and has clear documentation. -Ari Suntioinen
Re: Learning curve (was Re: Perl6 Operator List)
On Sat, 26 Oct 2002, Michael Lazzaro wrote: > So lets have _lots_ of operators, and _lots_ of two-to-four-letter > barewords, so long as they each do something Big, or something > Universal. And let's locale-ize them, so that non-english-speakers can > use 'umu' to mean 'bool', etc. Hey, why the heck not? Why not? Here is my opinion about localized programming languages. As a non-native English speaker, I like it very much that I *don't* have the possibility to write: afficher pour @tableau;# note I used functions that map mon @uaelbat = retourner @tableau; # to single words in French ;-) And I suspect my non-native French speaker readers like it very much too. I suppose it's very doable to have a FrenchPerl6 editor/parser/whatever that makes most of this transparent, but the thing I like the most about programming languages it that their are foreign languages. And since most of them are based on English, they are just twice as foreign to me. So when I program, I can concentrate on what the syntax of the programming langage accepts, rather than on the sentences I could write if I were using a subset of French. And imagine the pain for all those programmer that do not speak very well their own mother tongue... Should I use "effacer", "efacer", "éfasser" when I want to remove a file? With programming languages as there are today, I just have to learn a new word (unlink), and this won't mess my already messy understanding of my own language (pity the one who will read the comments and documentation, though). I admit that knowing a little English can be helpful to guess a function name here and there, though. ;-) Also, remember Microsoft moved back specifically on that topic with the Excel and Word macro-language some years ago. Naturally, this has nothing to do with naming your variables as you like (even Unicode and stuff); variables are another matter entirely. Don't misunderstand me, I love the fact that Perl works like a natural language. It's just that I also understand the fact that it's its own natural (English-looking) language, and not a subset of English. -- BooK PS: I have troubles explaining this view in French as well; please forgive me if I didn't make much sense in English either. -- Philippe "BooK" Bruhat When you run from your problem, you make it that much harder for good fortune to catch you, as well. (Moral from Groo The Wanderer #14 (Epic))
Re: Learning curve
Simon Cozens <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Michael Lazzaro) writes: >> But our version of "understandable" still means a steep, steep learning >> curve. > > It's worse than that; for practitioners of many languages, the learning > curve has a 180 degree turn. > > Quick: what are the bitwise operators in Java, JavaScript, C, C++, > C#, Perl 5, PHP, Ruby, and Perl 6? Which of these languages do we > want to draw programmers from? > > Someone will now argue that bitwise operators aren't used very often > anyway. Great, so we make a change that bites (NPI) people when > they least expect it; that makes it all OK. It rather depends on how common the Superposition operators turn out to be doesn't it? If you're used to seeing | used to construct a superposition then you're not quite as likely to go trying to use it in a bitwise context, but if superpositions turn out not to be a common idiom then you're more likely to get caught out. Me? I think once we have convenient quantum operators, we're going to start using them all over the place, but it could just be that I'm weird. -- 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: Learning curve
[EMAIL PROTECTED] (Piers Cawley) writes: > It rather depends on how common the Superposition operators turn out > to be doesn't it? No. No, it doesn't. -- heh, yeah, but Aretha could be reading out /etc/services and kick just so much ass :)
Re: Perl6 Operator List, Take 2
On Fri, Oct 25, 2002 at 04:10:31PM -0700, Michael Lazzaro wrote: > > Here's try #2. Things that are not true operators or have other > caveats are marked, where known. LMKA. > methods and listops, uncategorized: > > my our > map grep > sqrtlogsin cos tan > lc lcfirstuc ucfirst > int ordoct hex (bin?) Why do sqrtlogsin cos tan int ordoct hex (bin?) count as methods, when perl5 has them as numeric functions? And based on perlfunc.pod, I think the uniops abs, log and exp are missing, and the listop atan2. (And is perl6 going to have other more unusual transcendental maths functions such as acos, asin, cosh, sinh, cosec, erf as builtin keywords?) Nicholas Clark -- INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Perl6 Operator List
On Sat, Oct 26, 2002 at 10:33:04AM +1000, Damian Conway wrote: > Brent Dax wrote: > >Which would create a superposition of all strings besides the given one, > >right? (Oh crap, I think I gave Damian an idea... :^) ) > H. Maybe C is starting to grow on me. Bwah-ha-ha-ha-hah! >;-) I'm worried. *I* thought Damian said that he was on (well earned) sabattical for 3 months, from the end of YAPC::Europe. That was (roughly) 1 month ago. So has he been taking his 3 months simultaneously in parallel universes thanks to some utterly diabolical invention? :-) I fear we don't want to know. Nicholas Clark -- Befunge better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Perl6 Operator List
On Sat, Oct 26, 2002 at 01:59:46AM +0200, Paul Johnson wrote: > On Fri, Oct 25, 2002 at 06:28:28PM -0400, Miko O'Sullivan wrote: > > From: "Larry Wall" <[EMAIL PROTECTED]> > > > : ? - force to bool context > > > : ! - force to bool context, negate > > > : + - force to numeric context > > > : - - force to numeric context, negate > > > : ~ - force to string context > > > > > > We're obviously missing the "force to string context, negate" operator. > > :-) > > > > Mr. Wall, may I be excused? My brain is full. Oh, I have to stick it out > > with everyone else? OK, um > > > > Just so I understand... why do we need "force to blah context" operators at > > all? Are we planning on doing a lot of context forcing? Isn't "a lot of > The negate operators we have already: > > perl -e '$x = "0"; print !$x' > perl -e '$x = "10.000"; print -$x' Here is something that maybe you'd forgotten: $ perl -lwe '$x = "Good"; print -$x' -Good $ perl -lwe '$x = "-Good"; print -$x' +Good $ perl -lwe '$x = -"Good"; print -$x' +Good $ perl -lwe '$x = "+Good"; print -$x' -Good Unary plus is actually irrelevant: $ perl -lwe '$x = +"Good"; print -$x' -Good Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Perl6 Operator List, Take 2
Simon Cozens wrote:
I don't understand this, on several levels. The lowest level on which
I don't understand it is that testing whether an array is full of threes:
@array & 3
Err...that's not what that does. What you wrote creates a scalar value that
superimposes the scalar values C< \@array > and C< 3 >.
To test if an array is full of 3's you'd write:
all(@array) == 3
makes sense, but how do you test if all of its elements are more than six?
@array & { $^a > 6 } # ?
No. What you wrote is the superposition of C< \@array > and (effectively)
C< sub($a){$a>6} >.
To test if an array is full of greater-than-6's you'd write:
all(@array) > 6
If you can't do the latter with the same operator as the former, why have
the operator at all?
The operator is for composing superpositions from separate elements. Such as:
$x & $y & $z == 3 # all three variables equal 3
$x & $y & $z < 6 # all three variables greater than 6
$x & $y | $z < 6 # either $x and $y greater than 6, or $z greater than 6
Suddenly, @array.all?({ |$a| $a > 6 }) seems a lot more appealing. :)
More appealing than:
all(@array) > 6
???
No wonder you put a smiley there. ;-)
Damian
Re: Perl6 Operator List
Larry mused: Now I'm wondering whether these should be split into: +&+|+! - bitwise operations on int +&= +|= +!= ~&~|~! - bitwise operations on str ~&= ~|= ~!= I think this is UME (Unnecessary Multiplication of Entities), especially given: +$x .| +$y ~$x .| ~$y Then we could allow @a ^.~|= @b; # hyper bitwise string or-equals Eek! Now, where did I put those dried frog pills??? I think a good case can be made for *not* defining the corresponding super assignment operators: &=, |=, and umm...I guess it would have to be !=, er... I suspect disjunctive superpositions will get a great deal of use as sets, and so the ability to add an element to an existing set: $set |= $new_element; might be appreciated. But it's no big thing. I'd still love to the double angles for a qw synonym. I was hoping we'd be able to generalize << from the heredoc introducer to the file slurp operator. But I can certainly see the attraction of: use enum <>; ;-) : (heredocs) - (exact format unknown) I have a paper (coming) on that. Damian
Re: Perl6 Operator List, Take 2
[EMAIL PROTECTED] (Damian Conway) writes:
> Err...that's not what that does. What you wrote creates a scalar value that
> superimposes the scalar values C< \@array > and C< 3 >.
>
> To test if an array is full of 3's you'd write:
> all(@array) == 3
Ah, I see. So (x & y) is equivalent to all(x,y) ?
> > Suddenly, @array.all?({ |$a| $a > 6 }) seems a lot more appealing. :)
>
> More appealing than:
>
> all(@array) > 6
Yes. But then, if I want Ruby, I know perfectly well where to find it.
--
The Blit is a nice terminal, but it runs emacs.
Re: Perl6 Operator List
On Sat, Oct 26, 2002 at 11:24:23AM +0100, Nicholas Clark wrote: > On Sat, Oct 26, 2002 at 01:59:46AM +0200, Paul Johnson wrote: > > On Fri, Oct 25, 2002 at 06:28:28PM -0400, Miko O'Sullivan wrote: > > > From: "Larry Wall" <[EMAIL PROTECTED]> > > > > : ? - force to bool context > > > > : ! - force to bool context, negate > > > > : + - force to numeric context > > > > : - - force to numeric context, negate > > > > : ~ - force to string context > > > > > > > > We're obviously missing the "force to string context, negate" operator. > > > :-) > > > > > > Mr. Wall, may I be excused? My brain is full. Oh, I have to stick it out > > > with everyone else? OK, um > > > > > > Just so I understand... why do we need "force to blah context" operators at > > > all? Are we planning on doing a lot of context forcing? Isn't "a lot of > > > The negate operators we have already: > > > > perl -e '$x = "0"; print !$x' > > perl -e '$x = "10.000"; print -$x' > > Here is something that maybe you'd forgotten: > > $ perl -lwe '$x = "Good"; print -$x' > -Good > $ perl -lwe '$x = "-Good"; print -$x' > +Good > $ perl -lwe '$x = -"Good"; print -$x' > +Good > $ perl -lwe '$x = "+Good"; print -$x' > -Good > > Unary plus is actually irrelevant: > > $ perl -lwe '$x = +"Good"; print -$x' > -Good I hadn't actually forgotton - I even re-read "Symbolic Unary Operators" in perlop, but I didn't want to wander too far off into strange Perl 5 territory. Miko actually wrote at the end of his mesage: ] -Miko ] uh oh, I just forced myself into numeric context and negated myself $ perl -lwe 'my $x = -Miko; print -$x' +Miko $ perl -lwe 'my $x = +Miko; print -$x' -Miko $ perl -Mstrict -lwe 'my $x = -Miko; print -$x' +Miko $ perl -Mstrict -lwe 'my $x = +Miko; print -$x' Bareword "Miko" not allowed while "strict subs" in use at -e line 1. Execution of -e aborted due to compilation errors. I know why that is, at least technically, but didn't fancy trying to explain why it should be like that from a language design point of view. Although I'm sure someone here could do that ;-) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Perl6 Operator List
On Sat, 26 Oct 2002, Damian Conway wrote: : Larry mused: : : : > Now I'm wondering whether these should be split into: : > : > +&+|+! - bitwise operations on int : > +&= +|= +!= : > : > ~&~|~! - bitwise operations on str : > ~&= ~|= ~!= : : I think this is UME (Unnecessary Multiplication of Entities), especially : given: : : > +$x .| +$y : > ~$x .| ~$y Well, yes, but what does +$x .| ~$y do? I guess in a multimethod world it's too ambiguous to dispatch... We're also missing the actual C operators that are guaranteed to return 0 or 1: $x ?& $y# C's $x && $y $x ?| $y# C's $x || $y $x ?! $y# C's, er, !!$x ^ !!$y : > I think a good case can be made for *not* defining the corresponding : > super assignment operators: &=, |=, and umm...I guess it would have : > to be !=, er... : : I suspect disjunctive superpositions will get a great deal : of use as sets, and so the ability to add an element to an : existing set: : : $set |= $new_element; : : might be appreciated. But it's no big thing. Yes, but we certainly can't have !=. Another argument for not using ! for xor. I guess _ is available as a kind of | laying down. Can't have "x". We could use "o" as short for "one or other". $either = 1 o 2; $set o= 1; $comp = o $mask; if $x oo $y $c = $a ~o $b That's very distinctive. I think I could get to like it. : > I'd still love to the double angles for a qw synonym. : : I was hoping we'd be able to generalize << from the heredoc introducer to : the file slurp operator. But I can certainly see the attraction of: : : use enum <>; : : ;-) Actually, I meant the French double-angle quotes. Larry
Re: Learning curve (was Re: Perl6 Operator List)
On 26 Oct 2002, Simon Cozens wrote: : [EMAIL PROTECTED] (Michael Lazzaro) writes: : > But our version of "understandable" still means a steep, steep learning : > curve. : : It's worse than that; for practitioners of many languages, the learning : curve has a 180 degree turn. : : Quick: what are the bitwise operators in Java, JavaScript, C, C++, C#, : Perl 5, PHP, Ruby, and Perl 6? Which of these languages do we want to : draw programmers from? : : Someone will now argue that bitwise operators aren't used very often anyway. : Great, so we make a change that bites (NPI) people when they least expect : it; that makes it all OK. No, it doesn't make it all OK, but that's why somebody's getting paid to make the hard decisions. It's my job to balance out the short-term pain with the long-term gain. I appreciate that we have a responsibility to current programmers. I also appreciate that we have a responsibility to programmers who haven't even been born yet. Above all, I have an appreciation that what I'm trying to do here is, in fact, completely impossible. That won't stop me from trying. Larry
RE: Perl6 Operator List, Take 2
References: <[EMAIL PROTECTED]>
Questions :
* are stream separators ";" "&" "|" in the "for" loop - operators
in the usual sence ( like "," ) or they are pure grammar ?
* is prototype of the subrotine more regexp then expression ?
to what extent it is a regexp ? where it is stored , can we inspect it
or even change .
* do we have have an axcess to the signature of the
subroutine if we have been passed only its reference .
that is , for exemple , can
process( @x , &step )
guess how many arguments &step expects ?
* how one can write function analogous to "for" loop that will be able to
handle multiple streams ?
* how one can call subroutine "in place"
sub (str $x , int $n ) {
$x ~ ["one, "two", ... , "hundreed"][$n]
} . ("/home/temp/", $f ) ;
or
given ( "/home/temp/", $f )
-> ( str $x , int $n ) {
$x ~ ["one, "two", ... , "hundreed"][$n]
};
it seems that the last does not work because given take only one argument.
thanks ,
arcadi
Re: Perl6 Operator List
Larry Wall wrote: > : > Now I'm wondering whether these should be split into: > : > > : > +&+|+! - bitwise operations on int > : > +&= +|= +!= > : > > : > ~&~|~! - bitwise operations on str > : > ~&= ~|= ~!= Well, wait, these might have some promise, I think. Using the '.' for them is still a little non-intuitive, even though it is very bit-like. (We're going to be using the dot everywhere else to mean 'method', I don't know if it's obvious that the dot will, in this one context, mean something completely different?) And bitwise-string and bitwise-int are pretty different, and those (above) look pretty much like what they are... > Yes, but we certainly can't have !=. Another argument for not using > ! for xor. I guess _ is available as a kind of | laying down. > Can't have "x". We could use "o" as short for "one or other". > $either = 1 o 2; In a fever dream, I was once hoping that we could introduce 'o' or maybe 'c' to mean 'octal', to solve one of the most annoying things computing has inflicted upon me: 123 # 123, decimal 0123# 123, octal. WHAT??? WHY??? '0123' # FINE, so what's this, and why??? and changing that to: 0123# decimal 0b0110 # binary 0o123 # octal 0x123 # hex I know, I know, that's completely not-the-culture. Just always bugs me. Stupid tradition. :-P MikeL
RE: Perl6 Operator List, Take 2
On Sat, 26 Oct 2002, fearcadi wrote:
: * are stream separators ";" "&" "|" in the "for" loop - operators
: in the usual sence ( like "," ) or they are pure grammar ?
If ";", probably operator, though behaving a bit differently on
the left of -> than on the right, since the right is essentially
a signature. Ordinarily a ; in a signature would be taken to
mean optional arguments, but "for" would hide that meaning.
If we used & and | they'd have to be pure grammar, since they're
not really doing superpositions.
: * is prototype of the subrotine more regexp then expression ?
: to what extent it is a regexp ? where it is stored , can we inspect it
: or even change .
I have been resisting the notion that the signature can be generalized
into a regex. I'd rather have it separate, so that parsing is a
separate concern from the list of input arguments. In my tome last
night I was actually putting regex-ese into the name rather than the
signature, like this:
sub term:qa (str $quotestr) { ... }
which would presumably define a qa// term. But maybe that's putting
too much load onto the term: notation. Maybe it should be
sub term:qa (str $quotestr) is parsed /qa/ { ... }
Or maybe it should be something else entirely. In any event, all
the information should be stored somewhere where it can be inspected,
almost certainly in ordinary properties. In fact,
my int sub foo (int $x) { ... }
is really syntactic sugar for something like:
my &foo is retsig (int) is sig (int $x) is body { ... }
which may in turn be syntactic sugar for:
my &foo ::= new Code(retsig => (int),
sig => (int $x),
body => { ... });
: * do we have have an axcess to the signature of the
: subroutine if we have been passed only its reference .
: that is , for exemple , can
:
: process( @x , &step )
:
: guess how many arguments &step expects ?
I don't see why not, if a sub ref is pointing at its descriptor as
it does in Perl 5.
: * how one can write function analogous to "for" loop that will be able to
: handle multiple streams ?
That depends on whether ; is an operator or pure grammar. :-)
In either case, the body of the function is going to get in the
separate streams as an array of lists. The signature will also have
to come in as a sequence-separated list, so that the routine can match
up the streams. I expect that "for" might have an immediate component
(read "macro") that analyzes the number of streams at compile time
so as to call an efficient looping algorithm for the common cases.
: * how one can call subroutine "in place"
: sub (str $x , int $n ) {
:
: $x ~ ["one, "two", ... , "hundreed"][$n]
:
: } . ("/home/temp/", $f ) ;
:
: or
:
: given ( "/home/temp/", $f )
: -> ( str $x , int $n ) {
: $x ~ ["one, "two", ... , "hundreed"][$n]
: };
:
:
: it seems that the last does not work because given take only one argument.
But that argument can certainly be a list, and it seems like it would
not be too terribly difficult to make it do the signature binding
just the same as if they were function arguments.
In fact, I'm thinking about a Haskellish way to take any argument
that's a list reference and map it against a sub-signature.
Something like:
sub foo ([$head, *@tail], *@other) { ... }
foo( [1,2,3], 4,5,6 );
with the result that the parameters are bound like this:
$head := 1
@tail := 2,3
@other := 4,5,6
Or maybe the declaration of a sub-signature just uses parens like the
outer ones:
sub foo (($head, *@tail), *@otherargs) { ... }
That's less distinctive but more consistent. On the other hand,
there are perhaps reasons to distinguish a sub-signature that
parses multiple args from a sub-signature that parses a single
list arg.
In that frame of mind, your latter case might just work right out of the
box. The "given" supplies a scalar context to its left argument, so
the ("/home/tmp/", $f) is taken to mean ["/home/tmp/",$f]. And that
is a valid list to feed to the sub-signature on the right. At worst,
you might have to use [] on the right instead of (). If so, it'd probably
be better to use it on both sides:
given [ "/home/temp/", $f ]
-> [ str $x , int $n ] { ... }
Note that the topic in the given is an array ref in this case, not the
the first element of the list.
Larry
RE: Perl6 Operator List
In-reply-to: <[EMAIL PROTECTED]>
>
> my Pet @list = qm : << name type breed >> {
> fido dog collie
> fluffy cat siamese
> };
>
>That's still a lot easier to type than some of the alternatives I've
>had to do for larger structures.
why ?
my @attrs=qw{ name type breed } ;
my Pet @list = qw {
fido dog collie
fluffy cat siamese
} ~~ sub (@x) { map ->($x,$y,$z){
{ @attrs ^=> ($x,$y,$z) } @x
}
or
my Pet @list = for qw {
fido dog collie
fluffy cat siamese
} -> ($x,$y,$z){
{ @attrs ^=> ($x,$y,$z) }
}
if for works likek map .
arcadi
Re: [OT] Power of Lisp macros?
At 9:54 AM -0700 10/25/02, Larry Wall wrote: Suppose you have a system in which all farm animals are classified into the same category, and distinguished by one letter in their name. All farm animals begin with, say, "snarfu". So we get: ... A similar problem exists with street names. Some housing developments use very similar names for all of their streets, causing quite a bit of confusion for newcomers. On a slightly larger scale, a short stretch of Interstate 280 (in the SF Bay Area) has the following offramps: Farm Hill Page Mill Sand Hill that is, /.a.. .ill/. -r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm- my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: Perl6 Operator List
On Sat, 26 Oct 2002, Michael Lazzaro wrote: : Date: Sat, 26 Oct 2002 10:57:01 -0700 : From: Michael Lazzaro <[EMAIL PROTECTED]> : To: Larry Wall <[EMAIL PROTECTED]> : Cc: Damian Conway <[EMAIL PROTECTED]>, : "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> : Subject: Re: Perl6 Operator List : : Larry Wall wrote: : > : > Now I'm wondering whether these should be split into: : > : > : > : > +&+|+! - bitwise operations on int : > : > +&= +|= +!= : > : > : > : > ~&~|~! - bitwise operations on str : > : > ~&= ~|= ~!= : : Well, wait, these might have some promise, I think. Using the '.' for : them is still a little non-intuitive, even though it is very bit-like. : (We're going to be using the dot everywhere else to mean 'method', I : don't know if it's obvious that the dot will, in this one context, mean : something completely different?) And bitwise-string and bitwise-int are : pretty different, and those (above) look pretty much like what they are... And you get the C || and && for free ?&?|?! - bitwise operations on booleans ?&= ?|= ?!= Yes, it's redundant to say "bitwise" and "boolean" together. :-) But distinguishing int ops from str ops fixes the really nasty rule in Perl 5 that says "If this value (these values) has (have) ever been used in a string context..." Or was it a numeric context? I can't remember. And hey, if I can't remember... : > Yes, but we certainly can't have !=. Another argument for not using : > ! for xor. I guess _ is available as a kind of | laying down. : > Can't have "x". We could use "o" as short for "one or other". : > $either = 1 o 2; : : In a fever dream, I was once hoping that we could introduce 'o' or maybe : 'c' to mean 'octal', to solve one of the most annoying things computing : has inflicted upon me: : : 123 # 123, decimal : 0123# 123, octal. WHAT??? WHY??? : '0123' # FINE, so what's this, and why??? : : and changing that to: : : 0123# decimal : 0b0110 # binary : 0o123 # octal : 0x123 # hex : : I know, I know, that's completely not-the-culture. Just always bugs me. : Stupid tradition. :-P If one were going to generalize that, one would be tempted to go the Ada route of specifying the radix explicitly: 0123# decimal 2:0110 # binary 8:123 # octal 16:123 # hex 256:192.168.1.0 # base 256 or some such. Larry
RE: Perl6 Operator List
In-reply-to: <[EMAIL PROTECTED]>
>
> my Pet @list = qm : << name type breed >> {
> fido dog collie
> fluffy cat siamese
> };
>
>That's still a lot easier to type than some of the alternatives I've
>had to do for larger structures.
on the second thought :
my @attrs= ;
my Pet @list = map {
{ qw{name type breed } ^=> ($^x, $^y, $^z) }
} qw{
fido dog collie
fluffy cat siamese
};
or
my @attrs = qw{ name type breed }
my Pet @list=qw{
fido dog collie
fluffy cat siamese
} ~~ sub (@x) { map { _ => _ } @attrs x Inf ^, @x }
~~ sub (@x) { map { { _ , _ , _ } } @x ;
arcadi
Re: Perl6 Operator List
On Sat, 26 Oct 2002, Damian Conway wrote:
: I suspect disjunctive superpositions will get a great deal
: of use as sets, and so the ability to add an element to an
: existing set:
:
: $set |= $new_element;
:
: might be appreciated. But it's no big thing.
Or maybe it is a big thing. People keep asking why they can't say
$a[1][2] = 2;
$a[1]{a} = "A"; # type error?
Well, maybe they can now:
$union = [1,2,4,8];
$union |= {a => "A", b => "B", c => "C"};
$union[2] # 4
$union{a} # "A"
It's not just a union, of course. You can go on to say:
$union |= {a => "ant", b => "bug", c => "catepilllar"};
$union{a} # "A" | "ant"
That's all assuming that [] and {} (and (), for that matter) actually
select only appropriate refs from the superposition of refs.
Larry
RE: Perl6 Operator List
On Sat, 26 Oct 2002, fearcadi wrote:
: In-reply-to: <[EMAIL PROTECTED]>
:
: >
: > my Pet @list = qm : << name type breed >> {
: > fido dog collie
: > fluffy cat siamese
: > };
: >
: >That's still a lot easier to type than some of the alternatives I've
: >had to do for larger structures.
:
: on the second thought :
:
:
: my @attrs= ;
: my Pet @list = map {
: { qw{name type breed } ^=> ($^x, $^y, $^z) }
: } qw{
: fido dog collie
: fluffy cat siamese
: };
:
: or
:
: my @attrs = qw{ name type breed }
: my Pet @list=qw{
:fido dog collie
:fluffy cat siamese
: } ~~ sub (@x) { map { _ => _ } @attrs x Inf ^, @x }
:~~ sub (@x) { map { { _ , _ , _ } } @x ;
Well, you can do that, but I can guarantee people are going to want
syntactic sugar.
Larry
Re: Perl6 Operator List
On Sat, 26 Oct 2002, Larry Wall wrote:
: $union{a} # "A" | "ant"
Of course, the interesting question at this point is what
$union{a} = "axiomatic";
does if there's more than one hash in the superposition.
Larry
Re: Learning curve (was Re: Perl6 Operator List)
Michael Lazzaro wrote: > Here's my own argument for using "like/unlike", and "none", and a > bunch of other english-sounding things we haven't even talked about > yet. > > ... I don't think we've put much of a dent in the "readability" > complaints ... I think we need to care about these concerns a _lot_ > ... I agree that this is an important concern which should be addressed. > My own solution would be, in part, that we offer english-word aliases > like "like", etc., even if they're only meant as training-wheel > versions of the more linenoisy things, wherever we can. So people can > be trained on the words, and graduate to the "professional" constructs > as they become more comfortable. However I believe that having English aliases would make matters worse. They would make the language bigger. That's more to learn over all. There is already lots to learn in Perl, and I think having unnecessary duplication would make that even more work. Beginners would not need to learn the symbolic versions for writing their own code, but they'd need to be able to read the symbolic versions for reading other people's. And given how many people first encounter Perl by downloading somebody else's script from the web or by being thrown into maintenance of something written by a former employee, being able to read others' code is important. It's also slightly patronising. "We don't think you're good enough to play with the punctuation characters yet, but here's some alphanumerics to use instead." Would people submitting code in public forums get labelled as newbies because they've chosen to use the lettered versions? Would gurus who know the punctuation forms use the English versions so as to make their code more readable for beginners? Would this actually help beginners or merely make the situation worse when they finally do encounter the punctuation forms? Having exact synonyms also violates the principle that similar things should look similar. On encountering something 'new' in a program I would expect it to do something different. If I see C<+&> and already know that C<+> means numify in Perl and that C<&> is bitwise and in C (etc) then I might be able to guess that C<+&> is numeric bitwise and. But if I thought that I already knew that the symbol for that operation was C then I'd be less likely to guess the meaning of C<+&> cos I'd be searching among the space of things I didn't already know how to do. Finally, what happens to C<&&> and C and friends? If they become synonyms we lose a convenient distinction. If they remain as they are we have a language where many ops have synonymous symbolic and English forms for 'ease of learning' but a few instead have precedence differences. If we come up with an English synonym for C<&&> and a symbolic synonym for C I don't think that'd really help. This is only objecting to having English operators as synonyms for symbolic ones. None of the above would apply if where English forms were used they were to be the _only_ forms, with no symbolic equivalents. > My bigger solution would be to reserve a lot more english-sounding > barewords, in all forms, towards the goal of making well-understood > concepts more obvious to newcomers. I think that makes sense where there are appropriate words to use. However many of the concepts we're dealing with don't have obvious everyday-English equivalents. "Numbitand" certainly isn't an English word. Even for concepts such as map and hash I don't think the English word is a great help to many beginners: they know maps as things you look at to get lost when driving, and merely have to remember that Perl uses map mean 'like a loop but giving a list of values'. I wouldn't like to speculate on what they know as hash, but again it's a jargon word with a specific meaning in Perl largely unassociated with anything in real life. We're talking about having lots of operators in Perl 6. There are potentially twenty-four different or operations[*0]. I don't think there are twenty-four different English words which can usefully denote those meanings in a memorable way. At least combining symbols means that patterns can be learnt. That makes me sound against having English operators at all. I'm not. I agree that well-chosen English words will be more readable for beginners and that that is a good thing, even if it means some gurus having to type four letters instead of two symbols[*2]. But I can see it being hard to solve in some places. *0 Logical high precedence, logical low precedence, superpositional, numeric bitwise, string bitwise (that's five), all with exclusive-or variants (ten), plus the or-defined variants at two levels of precedence (twelve) all of which can be hyped[*1] over a list (twenty-four) *1 I'm not sure that "hyped" is the correct verb here for "applied over a list with the hyper operator", but it sounded better than "hypered". *2 Which when you take into account, and the fact that punctuation sy
Re: Perl6 Operator List, Take 2
Damian Conway wrote: > > ~~ !~ - smartmatch and/or perl5 '=~' (?) > > like unlike- (tentative names) > > Do we *really* need the alphabetic synonyms here? > Me no like! I agree with Damian. C wouldn't've been a bad name for the Perl 5 C<=~> operator; it's at least similar to SQL's C. However the smart matching is going to do many things in Perl 6, representing tests such as 'is contained in' or 'contains'. I don't think that there's an English word which is flexible enough to represent all the kinds of matching this will do. As such I think it's less confusing to have a special symbol that we all remember as doing 'magic matching' than it would be to have an English word which sometimes has its ordinary English meaning and sometimes has the meaning of a different English word or phrase. Smylers
Re: Perl6 Operator List
> Date: Sat, 26 Oct 2002 09:16:41 -0700 (PDT) > From: Larry Wall <[EMAIL PROTECTED]> > > We're also missing the actual C operators that are guaranteed to return 0 or 1: > > $x ?& $y # C's $x && $y > $x ?| $y # C's $x || $y > $x ?! $y # C's, er, !!$x ^ !!$y And we need those... why? Wouldn't: ?($x && $y) ... work? > Yes, but we certainly can't have !=. Another argument for not using > ! for xor. I guess _ is available as a kind of | laying down. > Can't have "x". We could use "o" as short for "one or other". > > $either = 1 o 2; > $set o= 1; > $comp = o $mask; > if $x oo $y > $c = $a ~o $b > > That's very distinctive. I think I could get to like it. We also still have binary ? and \, for whatever reason I mentioned that. Luke
Re: Perl6 Operator List
Larry Wall wrote: > I think we also need to fix this: > > print (length $a), "\n"; > > The problem with Perl 5's rule, "If it looks like a function, it *is* > a function", is that the above doesn't actually look like a function > to most people. Yup, definitely. This is one of the things that is most awkward about teaching Perl 5 beginners. It isn't nice to have to explain the intricacies of this right at the beginning of the course, but not doing so leads to people getting caught by it and not realizing why. > I'm thinking we need a rule that says you can't put a space before a > dereferencing (...), I'm concerned that making this sensitive to whitespace doesn't simplify things. > print(length $a), "\n"; > print (length $a), "\n"; Those look to me like they should do the same thing as each other. Distinguishing them sounds scary, much scarier than having C<$a _ 1> being different from C<$a_1>. How much is the 'if it looks like a function it is a function' rule needed at all? What would be the harm in not having any special rule here, so both of the above pass the line-break to C? Somebody needing to ensure that C only got one argument could do: (print length $a), "\n"; That is, parens always go round the outside of the thing they are grouping even when the thing is a function call. That would be counter-intuitive to anybody coming from a background in a language where parens have to be used in all function calls, but: 1 It has the benefit of there being one simple rule to learn, with no caveats about functions (or whitespace). Even when somebody gets it wrong, it's a case of showing how the general rule should be applied in this particular case rather than introducing an exception; that should be easier to learn. 2 There's no need to have any sort of disambiguating character (like the current C<+> or the suggested C<.> (with opposite meanings)). 3 If somebody wants to put parens after all her/his function names they often won't do any harm. I don't think the default situation for somebody who doesn't know the rules is made worse. There are some situations made 'worse', and some, like the above, made 'better'. Smylers
Re: Learning curve (was Re: Perl6 Operator List)
On Sat, Oct 26, 2002 at 09:23:19PM -, Smylers wrote: > Michael Lazzaro wrote: > > > Here's my own argument for using "like/unlike", and "none", and a > > bunch of other english-sounding things we haven't even talked about > > yet. > > > > ... I don't think we've put much of a dent in the "readability" > > complaints ... I think we need to care about these concerns a _lot_ > > ... > > I agree that this is an important concern which should be addressed. > > > My own solution would be, in part, that we offer english-word aliases > > like "like", etc., even if they're only meant as training-wheel > > versions of the more linenoisy things, wherever we can. So people can > > be trained on the words, and graduate to the "professional" constructs > > as they become more comfortable. > > However I believe that having English aliases would make matters worse. I agree, in general. I was planning on writing something about this. Now I don't have to :-) The only thing I would add, is that this is an experiment that has already been tried. Perl 5 has English.pm. Is is used? Not much. Who uses it? Mostly people writing their first programs. Why is this? Well, I suspect that people read though perlvar and notice the references to English.pm and think that if is comes with the core they should probably be using it. After a while they realise that most people don't use it so they still have to learn the punctuation, and anyway they still have to search perlvar every time they need to know what they should check after calling system(), so what's the point? How many people can even remember the English for $_? Or how to spell "The string following whatever was matched by the last successful pattern match"? Anyway, you can draw your own conclusions from the experiment. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Perl6 Operator List, Take 2
Simon Cozens wrote: Ah, I see. So (x & y) is equivalent to all(x,y) ? Yes. C, C, and C are the n-ary prefix versions of binary infix C<|>, C<&>, C respectively. One might imagine others of this ilk too, perhaps: BinaryN-ary +sum *prod ~cat genericreduce Damian
Re: Perl6 Operator List
You know, \ and friends as xor is appealing to me. There's no problem with \\ or \=, so that works. It's got nothing to do with references, but unary | has nothing to do with anything. Plus, it's parallel (er, perpendicular) to // as err, being logical and all. Just to clarify: \ superpositional one \\ logical xor \= superpositional one-assignment Also, a question about superpositions: Is $x = 1 | 2 | 3 equivalent to $x = 1 | 2 $x |= 3 or $x = (1 | 2) | 3 or is there a difference at all? So the latter is either 3 or the superposition 1 | 2. Does $x == 1 still return true? I guess the root of my question is... do superpositions search deep or shallow? Luke
Re: Learning curve (was Re: Perl6 Operator List)
Paul Johnson wrote: > On Sat, Oct 26, 2002 at 09:23:19PM -, Smylers wrote: > > > I believe that having English aliases would make matters worse. > > I agree, in general. I was planning on writing something about this. > Now I don't have to :-) Pleased to be of help! > The only thing I would add, is that this is an experiment that has > already been tried. Perl 5 has English.pm. > > Is is used? Not much. > > Who uses it? Mostly people writing their first programs. Good point. > How many people can even remember the English for $_? Or how to spell > "The string following whatever was matched by the last successful > pattern match"? There is one situation where I use it. That's for C<$UID> and friends. I have never bothered to learn which brackets are which in those four variables, and I need them so infrequently that I think the English names make the code considerably more readable. But this is a particular situation where the Perl names are referring directly to pre-existing real-world concepts that already have specific names. Keeping those names makes sense (when compared with seemingly arbitrary punctuation[*0]). It doesn't follow that it makes sense to try to fit names on to concepts that don't have them. C<$_> is just 'the current thing I'm dealing with right now', and C<~~> could be 'the appropriate kind of match' without having to find single-word English labels. *0 Yes, I'm aware of the mnemonics in perlvar, but I can't recall them fast enough when browsing through code. Smylers
RE: Perl6 Operator List
: my @attrs = qw{ name type breed }
: my Pet @list=qw{
:fido dog collie
:fluffy cat siamese
: } ~~ sub (@x) { map { _ => _ } @attrs x Inf ^, @x }
:~~ sub (@x) { map { { _ , _ , _ } } @x ;
by the way , ~~ seems to work like unix "|" pipe .
in the Apo4 the entry says
@a ~~ sub ( @x ) { ... } > &b(@a)
will it hande that :
@a ~~ map { _ => _ }
~~ map { {_,_,_} }
where the first *unsupplyed* argument to map
is expected to be *list* ?
also , is here the following DWIMmery in place
sub pairs ( $x,$y ){ $x => $y } ;
sub triples ( $x,$y,$z ){ {$x,$y,$z} };
@a ~~ &pairs ~~ &triples ;
?
so that ~~ will wrap "for" loop around "pairs" and "tripples" ,
similar to "-n" perl flag ;
Re: Perl6 Operator List
Luke Palmer wrote: You know, \ and friends as xor is appealing to me. H. I quite like that too. :-) Also, a question about superpositions: Is $x = 1 | 2 | 3 equivalent to $x = 1 | 2 $x |= 3 No. The precedence is wrong. or $x = (1 | 2) | 3 Yes. or is there a difference at all? No (if you mean between those two forms above). Yes (if you mean between those two and C). ;-) So the latter is either 3 or the superposition 1 | 2. Yes. Does $x == 1 still return true? Yes. I guess the root of my question is... do superpositions search deep or shallow? Think if it like this... Suppose: $x1 = any(1,2,3) and $x2 = 1|2|3; $x1 has three superimposed states: C<1>, C<2>, and C<3>. $x2 has two superimposed states: C and C<3> If we write: $x1 == 1 that means: any(1,2,3) == 1 which means: 1==1 || 2==1 || 3==1 which is true. If we write: $x2==1 that means any(any(1,2),3) == 1 which means: any(1,2)==1 || 3==1 which means: 1==1 || 2==1 || 3==1 which is true. So the effect is the same either way. The only time you'd notice any difference between $x1 and $x2 is if you asked for their eigenstates, in which case $x1 would give you three states (C<1>, C<2>, and C<3>) and $x2 would give you two states (C and C<3>). Damian
Re: Perl6 Operator List, Take 2
fearcadi wrote:
* do we have have an axcess to the signature of the
subroutine if we have been passed only its reference .
that is , for exemple , can
process( @x , &step )
guess how many arguments &step expects ?
I'd expect that Code objects would have a C or C method:
&subname.sig()
$subref.sig()
* how one can call subroutine "in place"
sub (str $x , int $n ) {
$x ~ ["one, "two", ... , "hundreed"][$n]
} . ("/home/temp/", $f ) ;
Yes. Or, if you're not gung-ho on explicit typing:
{ $^x ~ ["one, "two", ... , "hundreed"][$^n] }.("/home/temp/",$f)
or
given ( "/home/temp/", $f )
-> ( str $x , int $n ) {
$x ~ ["one, "two", ... , "hundreed"][$n]
};
it seems that the last does not work because given take only one argument.
That's right. But this does:
for "/home/temp/", $f
-> str $x , int $n {
$x ~ ["one, "two", ... , "hundreed"][$n]
}
Damian
Re: Perl6 Operator List
Larry wrote: And you get the C || and && for free Yeah, but it's the same sense of "free" in which spam is "free". You pay for it in other ways. But distinguishing int ops from str ops fixes the really nasty rule in Perl 5 that says "If this value (these values) has (have) ever been used in a string context..." Or was it a numeric context? I can't remember. And hey, if I can't remember... However, I think a better fix is to default the bitwise ops to numeric, unless both args are *currently* strings. And the unary ~ and + makes it easy to be sure when you're not sure: +$x .| +$y # definitely bitwise OR ~$x .| ~$y # definitely charwise OR If one were going to generalize that, one would be tempted to go the Ada route of specifying the radix explicitly: 0123 # decimal 2:0110 # binary 8:123 # octal 16:123 # hex 256:192.168.1.0 # base 256 Amen! Damian
Re: Perl6 Operator List
On 26 Oct 2002, Smylers wrote:
: Larry Wall wrote:
: > I'm thinking we need a rule that says you can't put a space before a
: > dereferencing (...),
:
: I'm concerned that making this sensitive to whitespace doesn't simplify
: things.
:
: > print(length $a), "\n";
: > print (length $a), "\n";
:
: Those look to me like they should do the same thing as each other.
Sorry, they don't look that way to me.
: Distinguishing them sounds scary, much scarier than having C<$a _ 1>
: being different from C<$a_1>.
But we already have exactly the same distinction with
$foo{ $bar }
$foo { $bar }
not to mention
$a ?? $foo::bar
$a ?? $foo :: bar
: How much is the 'if it looks like a function it is a function' rule
: needed at all? What would be the harm in not having any special rule
: here, so both of the above pass the line-break to C?
The harm would be that we'd basically be reinventing Lisp syntax with
precedence in place of some of the parens.
: Somebody
: needing to ensure that C only got one argument could do:
:
: (print length $a), "\n";
:
: That is, parens always go round the outside of the thing they are
: grouping even when the thing is a function call.
You're also bringing that parenthesis all the way out to the front of:
($obj.foo.bar.baz[3]{"finagle"}.each.subobj.print length $a), "\n";
That's not so good. Unless you make method syntax different from functions.
Which is also not so good.
: That would be counter-intuitive to anybody coming from a background in a
: language where parens have to be used in all function calls, but:
:
: 1 It has the benefit of there being one simple rule to learn, with no
: caveats about functions (or whitespace). Even when somebody gets it
: wrong, it's a case of showing how the general rule should be applied
: in this particular case rather than introducing an exception; that
: should be easier to learn.
Lisp has one simple rule to learn too. :-/
And I don't think this is introducing another exception when we're
talking about generalizing it for all brackets, and maybe all operators
that can have both a postfix and some non-postfix meaning.
: 2 There's no need to have any sort of disambiguating character (like
: the current C<+> or the suggested C<.> (with opposite meanings)).
At the cost of requiring *two* separate disambiguating characters
in many cases, one of which is a long way away from the "action".
To put it another way, these kinds of disambiguating characters break
up the left-to-right reading. This is the sort of thing we're trying
to get away from already. Perl 5 had the problem with braces:
Perl 5: @{ foo($x) }[1,2,3]
Perl 6: foo($x)[1,2,3]
: 3 If somebody wants to put parens after all her/his function names
: they often won't do any harm.
Until they write
print rand(3), "\n"
and wonder why they're getting
print rand(3, "\n")
: I don't think the default situation
: for somebody who doesn't know the rules is made worse. There are
: some situations made 'worse', and some, like the above, made
: 'better'.
Well, here I'd trot out Simon's argument that most of the people will
be coming from C-ish background, not Lispish background. Counting
by "situations" doesn't take into account the fact that I'd be lynched
by several million people if I did that.
I do think that "." may be the wrong character to "eat" whitespace though.
$hash .[$key]
$hash _[$key]
Reminds me of the old problem of what to use if we adopted the rule
I keep hankering for that says a final } on a line ends the current
statement. A _ could be made to suppress whitespace interpretation
there too, only on the other end of the bracket:
$x = do { foo(); bar(); baz() }_
+ 2;
(That _ would presumably *not* turn the following operator into a postfix.)
Using _ rather than . would prevent it from being interpreted as a method call.
That might be particularly important with alphanumeric operators.
$x .x # the .x method
$x _x # the x postfix operator
The definition of a factorial could then be
sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1)! }
(assuming decent tail-recursion optimization).
Note that since the syntax is implied by the name, the newly defined
operator can be used within the body. But this would be a syntax
error:
sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1) ! }
which could be fixed with the _:
sub postfix:! (num $x) { $x < 2 ?? $x :: $x * ($x - 1) _! }
Weird, but it's all consistent with the distinction we're already
making on curlies, which gave a great increase in readability.
And it would let someone declare a ++ binary operator if they wanted it.
print $a++ ++ ++$b;
Whatever that means... :-)
Larry
RE: Perl6 Operator List
Larry Wall writes:
> sub term:qa (str $quotestr) is parsed /qa/ { ... }
Michael Lazzaro writes :
> my Pet @list = qm : << name type breed >> {
> fido dog collie
> fluffy cat siamese
> };
doesnt it have to be
my Pet @list = qm << name type breed >> : { ... } ;
?
sub term:qm ( @attrnames : str $quotestr is parsed// ) {
$quotestr ~~ m:w/ [ ]+ / ;
my @thing = $0{word} ;
...
};
is this right way to declare term:qm ?
arcadi .
Re: Perl6 Operator List
[EMAIL PROTECTED] (Larry Wall) writes:
> : Distinguishing them sounds scary, much scarier than having C<$a _ 1>
> : being different from C<$a_1>.
>
> But we already have exactly the same distinction with
>
> $foo{ $bar }
> $foo { $bar }
>
> not to mention
>
> $a ?? $foo::bar
> $a ?? $foo :: bar
And we had none of these distinctions in Perl 5. I hope this scares you
as much as it scares me.
To the innocent bystanders, I hope you're not buying any of this crap
about Perl 6 being more "regular" or removing the "inconsistencies" of
Perl 5. It simply isn't true.
--
The trouble with computers is that they do what you tell them, not what
you want.
-- D. Cohen
Re: Perl6 Operator List
On Sun, 27 Oct 2002, Damian Conway wrote: : Luke Palmer wrote: : : > You know, \ and friends as xor is appealing to me. : : H. I quite like that too. :-) Except what about unary xor, i.e. 1's complement? Besides, Windows programmers would continually be writing $a / $b and wonder why they don't get one($a,$b); : > Also, a question about superpositions: Is : > : > $x = 1 | 2 | 3 : > : > equivalent to : > : > $x = 1 | 2 : > $x |= 3 : : No. The precedence is wrong. How so? : > or : > : > $x = (1 | 2) | 3 : : Yes. It's not clear that that shouldn't do the Right thing just like $a < $b < $c : [Large amounts of how-to-think-of-it snipped...] : So the effect is the same either way. So why not just make it the same? Otherwise you can't really use |= to add to a set like you wanted. All you can do is make a new set that holds the old set plus the new member, which isn't the same thing, since in set theory a set is a thing distinct from its members. : The only time you'd notice any difference between $x1 and $x2 is if you : asked for their eigenstates, in which case $x1 would give you : three states (C<1>, C<2>, and C<3>) and $x2 would give you two states : (C and C<3>). I think we should make people people write any(any(1,2),3) if that's the weird thing they want. I think | and & should automatically reduce as long as you're combining similars. Or at least |= should have the notion of appending to an existing any, just as ~= appends to an existing string. The length of your "how to think of it" is indicative that mere mortals will choose not to think of it at all... Larry
Re: Perl6 Operator List
Larry wrote: : H. I quite like that too. :-) Except what about unary xor, i.e. 1's complement? I was carefully ignoring that. ;-) Besides, Windows programmers would continually be writing $a / $b and wonder why they don't get one($a,$b); : > Also, a question about superpositions: Is : > : > $x = 1 | 2 | 3 : > : > equivalent to : > : > $x = 1 | 2 : > $x |= 3 : : No. The precedence is wrong. How so? The former does the two |'s then a single assignment. The later does one |, and assignment, another |, and then another assignment. The difference might be significant, under overloading. It's not clear that that shouldn't do the Right thing just like $a < $b < $c Well, I'd certainly be in favour of that! So why not just make it the same? Otherwise you can't really use |= to add to a set like you wanted. All you can do is make a new set that holds the old set plus the new member, which isn't the same thing, since in set theory a set is a thing distinct from its members. Agreed. I'd certainly prefer it to DWIM. I think we should make people people write any(any(1,2),3) if that's the weird thing they want. I think | and & should automatically reduce as long as you're combining similars. Agreed. Damian
RE: Perl6 Operator List
On Sun, 27 Oct 2002 [EMAIL PROTECTED] wrote:
: : my @attrs = qw{ name type breed }
: : my Pet @list=qw{
: :fido dog collie
: :fluffy cat siamese
: : } ~~ sub (@x) { map { _ => _ } @attrs x Inf ^, @x }
: :~~ sub (@x) { map { { _ , _ , _ } } @x ;
:
: by the way , ~~ seems to work like unix "|" pipe .
:
: in the Apo4 the entry says
:
: @a ~~ sub ( @x ) { ... } > &b(@a)
:
: will it hande that :
:
: @a ~~ map { _ => _ }
:~~ map { {_,_,_} }
:
: where the first *unsupplyed* argument to map
: is expected to be *list* ?
The purpose of ~~ is first and foremost to return a reasonable boolean
value in boolean context. The question is whether the one ~~ will
notice the other ~~ operator in one of its arguments and thereby
force that argument into boolean context, just as
$x ~~ ?foo($^x)
notices the ? and just calls foo() rather than trying to match the
return value of foo(), as it would if you said:
$x ~~ +foo()
$x ~~ ~foo()
I think it would be cool if there were a way to pull the arguments out
to the front, because then we really could write in Japanese word order:
@args wa $*OUT de print yo!
: also , is here the following DWIMmery in place
:
: sub pairs ( $x,$y ){ $x => $y } ;
: sub triples ( $x,$y,$z ){ {$x,$y,$z} };
: @a ~~ &pairs ~~ &triples ;
:
: ?
:
: so that ~~ will wrap "for" loop around "pairs" and "tripples" ,
: similar to "-n" perl flag ;
This doesn't make sense to me. If you're trying to pass the parsed topic list
to them, they should be returning a boolean value. If you're trying to return
a set of values to be compared against @a, Perl's not going to also pass @a
to your functions.
Larry
Re: Perl6 Operator List
On 27 Oct 2002, Simon Cozens wrote:
: [EMAIL PROTECTED] (Larry Wall) writes:
: > : Distinguishing them sounds scary, much scarier than having C<$a _ 1>
: > : being different from C<$a_1>.
: >
: > But we already have exactly the same distinction with
: >
: > $foo{ $bar }
: > $foo { $bar }
: >
: > not to mention
: >
: > $a ?? $foo::bar
: > $a ?? $foo :: bar
:
: And we had none of these distinctions in Perl 5. I hope this scares you
: as much as it scares me.
Eh? Perl 5 certainly distinguishes these:
$foo::bar
$foo :: bar
It just doesn't give any meaning to the latter.
: To the innocent bystanders,
I'm afraid you're preaching to the null set here. :-)
: I hope you're not buying any of this crap
: about Perl 6 being more "regular" or removing the "inconsistencies" of
: Perl 5. It simply isn't true.
Hey, sounds like it'd make a great column. Go for it. I'll expect
a little more than an argument by assertion, however.
Larry
RE: Perl6 Operator List
> I think it would be cool if there were a way to pull the arguments out
> to the front, because then we really could write in Japanese word order:
>
> @args wa $*OUT de print yo!
>
> : also , is here the following DWIMmery in place
> :
> : sub pairs ( $x,$y ){ $x => $y } ;
> : sub triples ( $x,$y,$z ){ {$x,$y,$z} };
> : @a ~~ &pairs ~~ &triples ;
> :
> : ?
> :
> : so that ~~ will wrap "for" loop around "pairs" and "tripples" ,
> : similar to "-n" perl flag ;
> This doesn't make sense to me. If you're trying to pass the parsed topic list
> to them, they should be returning a boolean value. If you're trying to return
> a set of values to be compared against @a, Perl's not going to also pass @a
> to your functions.
so maybe it will be usefull to have " smart argument binding "
operator . it will not be used a lot so it can have long name.
maybe
~> .
map &triples, map &pairs, @a
map is doing piping right-to-left ;
but operations happens in reverse order to
the order in which we read
it .
"for" doit in 'normal' order but
for @a {
&pairs ;
&triples ;
}
is totally different and
for for @a, &pairs , &triples
looks strange . and we have to adjust "for" count to number of "steps"
..
so maybe
@a ~> &pairs ~> &triples ;
arcadi
Radix (was Re: Perl6 Operator List)
> Larry wrote: > > If one were going to generalize that, one would be tempted to go the Ada > > route of specifying the radix explicitly: > > > > 0123# decimal > > 2:0110 # binary > > 8:123 # octal > > 16:123 # hex > > 256:192.168.1.0 # base 256 Heck that'd be fine with me... then I can easily do stuff in base 36, which I do a lot of. :-/ Still might want a letter shortcut for b/o/h, though. Just as long as 0123 doesn't magically mean octal I'm happy. Stupid, STUPID OCTAL. :-) MikeL
labeled if blocks
Will Perl6 have labeled if blocks? Like this:
BLAH:
if ($foo) {
...
last BLAH if $bar;
...
}
_
Surf the Web without missing calls! Get MSN Broadband.
http://resourcecenter.msn.com/access/plans/freeactivation.asp
RE: Perl6 Operator List
_ as space eating grammar rule . just beautifull! this is in harmony with $x = 123_567 ; and we can use it as explicite space $x =_$a++_+_++$a ; or even as separator in *ugly* looking operators @x ^_~~ s/.../.../ arcadi
Re: Perl6 Operator List
On 10/26/02 7:24 PM, Simon Cozens wrote: > To the innocent bystanders, I hope you're not buying any of this crap > about Perl 6 being more "regular" or removing the "inconsistencies" of > Perl 5. It simply isn't true. I was buying that right up until about a week or two ago when Larry emerged from his cocoon and started pouring scary line noise into this list :-} I've been trying to comfort myself by thinking that these are just the odd corners of the language, and that this stuff will likely only be relevant to people creating their own operators (or overriding existing ones). Larry's just thinking out loud, right? Surely he'll eventually settle down and come up with a sensible solution...right? Right?! Reading the threads from the past few days, I can't help but think of the great "loss of '.' as the string concatenation operator" debates from the past. Some people were in favor of keeping it and requiring whitespace where necessary to eliminate ambiguity, but the overwhelming consensus seemed to be: "No, Perl 6 has to be much more regular than that!" Fast forward to a little bit and we get "_" as the replacement operator, which (surprise) requires whitespace where necessary to eliminate ambiguity. Fast forward to today and we've got, well, this thread. Seems like the ride is getting bumpy... -John
RE: Perl6 Operator List
but what about placeholders ? arcadi .
Re: Perl6 Operator List
On 10/26/02 8:18 PM, Larry Wall wrote: > On 27 Oct 2002, Simon Cozens wrote: > : To the innocent bystanders, > > I'm afraid you're preaching to the null set here. :-) I don't know whether to be flattered that you think I'm not just a bystander, or insulted that you think I'm not innocent ;) -John
Re: Learning curve
Smylers wrote:
> This is only objecting to having English operators as synonyms for
> symbolic ones. None of the above would apply if where English forms
> were used they were to be the _only_ forms, with no symbolic
> equivalents.
Yes, I think we're basically saying the same thing, but in different
ways. I think my broader argument is that, indeed, few operators have
english possibilities, BUT in having all these linenoise operators,
we're using up our karma points. We need to gain them back in other areas.
I'm thinking particularly of verb-things, adjective-things, and
prepositional things, not noun-things like $UID, etc. My particular
examples are indeed the verbs "map" and "grep". What do they do? Well,
mapping and grepping. It's ingrained for most of us, from using them so
often, but a beginning programmer _really_ doesn't know what those words
mean in those contexts. Even though, as pointed out before, "map" is a
real word!
Here's my own train of thought. How would we say ~~, out loud? How do
you pronounce it in conversation, I mean? Probably as "smart match", or
more likely we'd say, for $a ~~ $b, "a matches b". So maybe "matches"
works as an english name. Still a little long, so what about just
"match" or "like"? Heck, I'd even argue that "$a mat $b" works, too.
What does "mat" do? It "mats". If "grep" is a word, "mat" can be a
word. :-) Or "lik". Or "sma". Letters make brain happy. Happy
brain good!
Now, maybe "mat" works, and maybe it doesn't: I don't think we should
force letter-isms where they just don't work. But in any places they
might, I think we owe it to ourselves to try REALLY HARD to make
something work. The whole properties things, for example. We've got
"is", and "is" is going to be a modifier for a
whole-heck-of-a-lot-of-things. And "is" is short, so we like it.
But there are some things that you can think of as "properties" that can
be more rigorously categorized, and can do so with sufficient clarity to
be useful. Instead of
my Dog $dog
is fetched { ... } # callbacks on the var
is stored { ... };
why not make an "on" companion to "is" that implies a property that's an
event/callback/assertion?
my Dog $dog
on fetch { ... }
on store { ... };
It doesn't seem to cost us much, and I'd argue it's cleaner, and
potentially more meaningful to the compiler.
But yes, I certainly agree it sometimes goes the other way, too. We can
argue that one place it english doesn't work is "but", because "but" is
counterintuitive for some situations. So maybe "but" needs a
punctuational counterpart. Maybe, shudder, that's where ':::' gets used.
I'm certainly against mere aliases for the general and/or/xor/math
operators. Just cautioning that we need to look hard through
/usr/dict/words and see where we can get back some karma!
MikeL
Re: Perl6 Operator List
John Siracusa wrote: > Larry's just thinking out loud, right? Yes, and so is everyone else. Most posts here, including Larry's, are stream-of-conciousness. Heck, in one of the last ones I swear there were, what, 6 or 7 possible ways to say the same "binary op" things. 90% of everything proposed is shot down, though sometimes it generates a lot of noise before dying. Even many of the players here move in-and-out of conversation, from lurker to poster to lurker, depending on topic & free time. I bet the operator list changes another 5 times, in huge ways, before being finalized. I posted the latest-full-list so that everyone could see all the implications of what was being discussed in the previous threads. People saw, and issues are a-flyin, and something will come of it. Think positive! MikeL
Re: labeled if blocks
On Sat, 26 Oct 2002, Steve Canfield wrote:
: Will Perl6 have labeled if blocks? Like this:
:
: BLAH:
: if ($foo) {
: ...
: last BLAH if $bar;
: ...
: }
I don't see why we need it offhand. But we might well have something
that returns out of the innermost {...} anyway, so you could use that.
Larry
RE: Perl6 Operator List
Larry Wall:
# Besides, Windows programmers would continually be writing
#
# $a / $b
*rolls eyes*
(Yes, I know that's a joke. (It is, isn't it? :^) ))
--Brent Dax <[EMAIL PROTECTED]>, Windows Perl and Parrot hacker
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
XOR vs. Hyper (was Re: Perl6 Operator List)
FWIW, if people are really eager to keep ^ for xor (I don't think anything's clicking great as a replacement), we could of course switch hyper to ~. That would give us, in part: ? ! + - _ # unary prefixes + - * / % ** x xx# binary +=-= *= /= %= **=x=xx= ~+~- ~* ~/ ~% ~**~x~xx# hyper ~+= ~-=~*=~/=~%=~**= ~x= ~xx= and or xor err# logical ops && || ^^// # logical ops b& b| b^ # binary (placeholders, for now) &|^# binary or super (dunno, for now) all any one none # superpositional (+ sum,prod,cat,reduce) That would put us back to square one with string cat, but it _would_ give people back their C-like xor, which would help the familiarity issue a bit. OR, we could use ~ for string and ~~ for hyper, which I think would be OK except for the presence of an ~~~ operator for hypercat (it does sort of look like a cat going really fast, though, doesn't it?) We could also try for some bracketing constructs around hypers, or a doubled punct, or something. Thought of course about <+>, it looks very hyper-like, but probably still too many issues with the old-style file <$stuff> + - * / % ** x xx# binary +=-= *= /= %= **=x=xx= <+> <-><*><%><**> # hyper <+=> <-=> <*=> <%=> <**=> Dunno, just feels like there should be a solution here, somewhere... @a ~~+ @b # not awful @a <+> @b # sigh, this is pretty nice looking @a h<+> @b @a @<+> @b @a ^+^ @b @a `+ @b @a .+. @b @a =+= @b @a ~+~ @b @a \+\ @b @a [+] @b @a h[+] @b @a @[+] @b @a @+ @b MikeL
Re: labeled if blocks
--
On Sat, 26 Oct 2002 21:02:20
Larry Wall wrote:
>On Sat, 26 Oct 2002, Steve Canfield wrote:
>: Will Perl6 have labeled if blocks? Like this:
>:
>: BLAH:
>: if ($foo) {
>: ...
>: last BLAH if $bar;
>: ...
>: }
>
>I don't see why we need it offhand. But we might well have something
>that returns out of the innermost {...} anyway, so you could use that.
Well, I always thought that labeled blocks in general would give us a
way to label lexical scopes. If so, why shouldn't it apply to if
blocks?
-Erik
>
>Larry
>
>
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
