Re: [svn:perl6-synopsis] r14407 - doc/trunk/design/syn
On 5/29/07, Larry Wall wrote:
Note that any is considered a singular noun in English,
I started to say, Except when it means 'all', but when used that
way, it still would mean all in the singular sense. But it gives
me an excuse to point out that any can be ambiguous in English;
it's not hard to see which meaning is intended in a given context,
but there's still a temptation to translate an English any into a
Perl any when it really means all.
#If my score equals anyone else's, there's a tie
if $my_score==any(@other_scores) { say I tied with .score2name($my_score) }
#If my score is higher than anyone else's, I win!
if $my_score any(@other_scores) { say Oops, this doesn't DWIM! }
Not a big deal in one way, but it's the kind of error that's easy to
overlook even when you're staring right at it. Which is why when I'm
writing SQL, I prefer to use SOME instead of ANY. If it were spelled
some in Perl, I figure all the extra typing would be worth it to
avoid an occasional error.
In any case, the Huffman coding is probably right because you want
to declare Any parameters more often than you want to talk about any
possible kind of Object, I suspect.
Are Objects really Everything? What about native types like int --
or (thanks to autoboxing) should I really be thinking of them as
Objects with built-in optimiser hints? Not that I have a good
example of why you'd want to specify a native-only type; I'm only
asking out of pedantic curiosity.
-David
[svn:perl6-synopsis] r14410 - doc/trunk/design/syn
Author: larry
Date: Thu May 31 16:53:58 2007
New Revision: 14410
Modified:
doc/trunk/design/syn/S05.pod
Log:
bogus ; termination noticed by pmichaud++
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podThu May 31 16:53:58 2007
@@ -804,7 +804,7 @@
match. The symbol is specified as part of the long name. It may also
be matched within the rule using C sym , like this:
-proto token sigil;
+proto token sigil { }
multi token sigil:sym$ { sym }
multi token sigil:sym@ { sym }
multi token sigil:sym@@ { sym }
Re: [svn:perl6-synopsis] r14407 - doc/trunk/design/syn
At 5:36 PM -0600 5/31/07, David Green wrote: On 5/29/07, Larry Wall wrote: In any case, the Huffman coding is probably right because you want to declare Any parameters more often than you want to talk about any possible kind of Object, I suspect. Are Objects really Everything? What about native types like int -- or (thanks to autoboxing) should I really be thinking of them as Objects with built-in optimiser hints? Not that I have a good example of why you'd want to specify a native-only type; I'm only asking out of pedantic curiosity. If that's true, then it would probably reinforce my argument for renaming Object to Universal. I said before that it is better for type names, or at least the most important or root part of the name of a type, should describe what it represents rather than how it is implemented; Object smacks more of an implementation detail. If it is true that int et al (ignoring autoboxing) is not conceived of as an object by users, that reinforces the idea that Universal sounds more like everything than Object does. -- Darren Duncan
propose renaming Hash to Dict
I decided to bring out this Hash-Dict topic in a different thread
from the thread on Synopsis r14407 about Object-Universal since I
consider them separate though tangential matters that should be
argued on their individual merits.
In the interest of that Perl data types are better off being named
primarily after their meaning rather than their implementation,
probably the current worst offender is Hash.
Barring some better name, I highly recommend/propose renaming Hash to Dict.
The term Dict (as a short form of dictionary) is well understood by
general people and is the term used for associative arrays in some
other languages, so it is easy to learn, and easy to explain to
people in Learning Perl.
The term Dict is easier for new people to Perl, either new
programmers or visitors from other languages, to learn than Hash is.
It allows more self-documenting code where one is used. And writing
Learning Perl should be easier.
For Perl 5 people, it should be very easy to adapt, or for the most
part they may not notice any difference save for documentation
references.
You also have equal huffmanization since the terms Hash and Dict are
both of the same length, and they are also equally easy to type.
And aside from the 4 letter word, all the other details associated
with hashes, eg the % sigil and {} constructor, and parts named
keys,values,pairs,kv et al can/should remain the same as they are.
In fact, since many users of Perl don't refer to the data type by the
name Hash but rather just by % or {}, the change may not take from
their useability at all or they may not even notice that a change
occurred at all, so easy to adapt.
Of course, if that change is made, KeyHash should be renamed to
KeyDict, and so forth.
After this change, the term Hash is then freed up to be used more
specifically to describe an implementation detail of something and/or
hashing functions et al.
I think this change would be a good thing.
Feedback is appreciated, either pro or con.
-- Darren Duncan
Re: propose renaming Hash to Dict
Dictionaries are usually alphabetically ordered. Hashes are not. -- korajn salutojn, juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: propose renaming Hash to Dict
On 5/31/07, Darren Duncan [EMAIL PROTECTED] wrote:
Barring some better name, I highly recommend/propose renaming Hash to Dict.
And lets rename Perl to Python. This is just change for the sake of change.
snip
The term Dict (as a short form of dictionary) is well understood by
general people and is the term used for associative arrays in some
other languages, so it is easy to learn, and easy to explain to
people in Learning Perl.
snip
Dict also makes it sound like you are talking about pornography. Of
course, hash makes it sound like you are talking about getting high.
snip
The term Dict is easier for new people to Perl, either new
programmers or visitors from other languages, to learn than Hash is.
It allows more self-documenting code where one is used. And writing
Learning Perl should be easier.
snip
Please provide the peer-reviewed study that proves this as it goes
against my experience.
snip
For Perl 5 people, it should be very easy to adapt, or for the most
part they may not notice any difference save for documentation
references.
snip
The Perl 5 people are already annoyed that . is changing to ~, sigils
are becoming invariant, etc. Why not change the name of one of the
data structures too? If we give them too many things to complain
about they won't be able to decide where to start!
snip
You also have equal huffmanization since the terms Hash and Dict are
both of the same length, and they are also equally easy to type.
snip
They may be the same number of characters, but I can type hash without
leaving the home row on QWERTY keyboards, I don't know about Dvorak.
snip
And aside from the 4 letter word, all the other details associated
with hashes, eg the % sigil and {} constructor, and parts named
keys,values,pairs,kv et al can/should remain the same as they are.
snip
Right, because dictionaries have keys and values not terms and
definitions. Of course, it all makes sense now.
snip
In fact, since many users of Perl don't refer to the data type by the
name Hash but rather just by % or {}, the change may not take from
their useability at all or they may not even notice that a change
occurred at all, so easy to adapt.
snip
Except of course those poor schmucks who foolishly wrote code like
if (ref $arg eq 'HASH') { ... }
Re: propose renaming Hash to Dict
big snip I thought one of the things that Larry didn't want to do when moving towards the next big version of Perl was to change the nature of the language such that it wasn't Perl any more. I feel that renaming a Hash to Dict would be one of those changes. Personally, I don't find it difficult to discuss Perl hashes and a computer science hash algorithm with people. One of the things I like about Perl is that it doesn't presume that its coders are linguistically impaired. A Perl program's audience - imho - should be the programmers. That it can run efficiently and well on a computer, again imho, is a side effect. DSL
Re: propose renaming Hash to Dict
On Thu, May 31, 2007 at 05:10:57PM -0700, Darren Duncan wrote: : I decided to bring out this Hash-Dict topic in a different thread : from the thread on Synopsis r14407 about Object-Universal since I : consider them separate though tangential matters that should be : argued on their individual merits. : : In the interest of that Perl data types are better off being named : primarily after their meaning rather than their implementation, : probably the current worst offender is Hash. Nope. Hash is mostly about meaning, and very little about implementation. Please don't assume that I name things according to Standard Names in Computer Science. I name things in English. Hash is just something that is disordered, which describes the associative array interface rather nicely, distinguishing it from the ordered Array interface. The fact that it *might* be implemented using a hash algorithm is merely a nice association with some mnemonic value for CSish folks. Likewise, if I say Object I'm referring not to a CS object so much as an English object, which is just something that is fairly discrete and can be handled and treated as a single thing, even if it happens to contain multiple things. About the only nod to CS here is that you can call the .HOW method on any Object. Anything beyond that is the fault of the metamodel. In general I'm much more interested in the natural linguistic feel of Perl than in matching up with any particular standard CS terms. That's why you have given and when, not switch and case. That's why you say next and last, not continue and break. That's why we have state rather than static, my rather than var or decl, contend rather than atomic, maybe rather than orElse, has rather than attr, role rather than interface, and so on. Of course, it's possible to pick words that have too much overloading in the CS literature, but I don't think either Hash or Object really fall into that category, in the case of Hash because hash algorithms are a fairly minor thing, and in the case of Object because people are already used to all different kinds of Object systems, some class-based, some prototype-based, so generalizing to a kind of object that gives you both is not really a problem. And as I said before, part of the reason for using Object is political, because it means we're Really Doing Real OO™. And maybe part of the reason for *not* using Universal is also political, insofar as Perl 5's UNIVERSAL has been sorely abused in various ways, and I don't want people to have that mental association. (Kinda like the fact that Captures resemble anonymous typeglobs but we're *not* going to call them that...) Larry
[svn:perl6-synopsis] r14411 - doc/trunk/design/syn
Author: larry
Date: Thu May 31 22:43:55 2007
New Revision: 14411
Modified:
doc/trunk/design/syn/S12.pod
Log:
There is no longer any run-time dwimmery in indirect dispatch.
Now use $obj.$foo exclusively for symbolic method indirection
$obj.$var and [EMAIL PROTECTED] forms now allow *only* hard refs to Code
objects.
Prefix ops written as postfix no longer use quote form, but $obj.prefix:+
$obj.:+ is allowed as a shorthand for $obj.prefix:+
Clarified that all anonymous Code objects are closures, not methods.
WALK pseudo-class is dead. Now just use .WALK method to return candidates.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podThu May 31 22:43:55 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 27 Oct 2004
- Last Modified: 29 May 2007
+ Last Modified: 31 May 2007
Number: 12
- Version: 53
+ Version: 54
=head1 Overview
@@ -218,15 +218,30 @@
.doit(1,2,3)
-It can use a simple scalar variable for the method name:
+There are several forms of indirection for the method name. You can
+replace the identifier with a quoted string, and it will be evaluated
+as a quote and then the result of that is used as the method name.
-$obj.$methodname(1,2,3)
+$obj.$methodname(1,2,3) # use contents of $methodname as method name
+$obj.'$methodname'(1,2,3) # no interpolation; call method with $ in name!
-The variable may contain either the name of a method or a closure
-object. In the latter case the closure is called with the object
-as its first argument, so that a closure may be used to abstract a
+For situations where you already have a method located, you
+can use a simple scalar variable in place of method name:
+
+$methodobj = $foo ?? bar !! baz;
+$obj.$methodobj(1,2,3)
+
+or more succinctly but less readably:
+
+$obj.$($foo ?? bar !! baz)(1,2,3)
+
+The variable must contain a Code object, that is, a closure of some
+sort. Regardless of whether the closure was defined as a method or
+a sub or a block, the closure is called as a method, with the object
+as its first argument, and the rest of the arguments second, third,
+and so on. For instance, such a closure may be used to abstract a
navigational path through a data structure without specifying the
-root of the path till later.
+root of the path till later:
$locator = - $root, $x, $y { $root.foo[$x]bar{$y}[3] }
$obj.$locator(42,baz) # $objfoo[42]barbaz[3]
@@ -234,30 +249,61 @@
$locator = { .here }
$obj.$locator# $objhere
-The method name may also be quoted with either single or double quotes:
-
-$obj.$methodname(1,2,3) # same as previous
-$obj.'$methodname'(1,2,3) # call method with $ in name!
+As a convenient form of documentation, such a closure may also be written
+in the form of an anonymous method:
-The latter is especially useful for postfix forms that might be confusing
-to the lexer or to the human reader:
-
-$filename.'+' # same as +$filename.
-.'+' # same as +$_
-
-And in fact, if there is a choice between a unary prefix and a postfix
-operator, the quoted forms will choose the prefix operator. See S03.
-Likewise, presuming that C$op does not name an ordinary method on
-C$left, this calls any arbitrary infix operator:
+$locator = method ($root: $x, $y) { $root.foo[$x]bar{$y}[3] }
+$obj.$locator(42,baz) # $objfoo[42]barbaz[3]
-$left.$op($right)
+$locator = method { self.here }
+$obj.$locator# $objhere
-Of course you can force that with:
+Note however that, like any anonymous closure, an anonymous method
+can only be dispatched to directly, like a sub. You may, of course,
+bind an anonymous method to the name of a method in a class's public
+interface, in which case it is no longer anonymous, and may be
+dispatched to normally via the class. (And in fact, when the normal
+method dispatcher is calling individual candidates in its candidate
+list, it calls each candidate as a sub, not as a method, or you'd
+end up with recursive dispatchers.) But fundamentally, there's
+no such thing as a method closure. The Cmethod declarator on an
+anonymous method has the primary effect of making the declaration
+of the invocant optional. (It also makes it an official CRoutine
+that can be returned from, just as if you'd used Csub to declare it.)
+
+Instead of a scalar variable, an array variable may also be used:
+
+[EMAIL PROTECTED](1,2,3)
+
+As with the scalar variant, each array element must be a Code object,
+but the list is treated as a list of candidates to call.
+
+Another form of indirection relies on the fact that operators are named
+using a variant on hash subscript notation, which gives you these forms:
+
+$x.infix:{$op}($y)
+$x.prefix:{$op}
+$x.postfix:{$op}
+
+Generally you see
Re: propose renaming Hash to Dict
At 9:17 PM -0700 5/31/07, Larry Wall wrote: Nope. Hash is mostly about meaning, and very little about implementation. snip And as I said before, part of the reason for using Object is political, snip Okay, thanks for addressing these 2 naming concerns I talked about; I'll drop the associated matter now. -- Darren Duncan
