Re: Traffic lights and language design
[again, apologies if this is a duplicate] * Michael G Schwern <[EMAIL PROTECTED]> [05/04/2001 15:51]: > > Oddly enough, varying the number of traffic lights can effect > efficiency. By over-regulating you can choke off traffic. Constant > fiddling with the setups and timings, trying to control each and every > intersection to maximize throughput leads to gridlock, zero > throughput. The exact opposite of what was intended. > > We are in danger of doing just that. By wanting to correct, > streamline and optimize every bump and snag in Perl we may cross some > imaginary line and have syntactical gridlock where the language design > descends into a morass of continual minor adjustment. By backing off > we can often find a much more sweeping solution than just putting up > lights on every corner. A perfect example is Larry's "module" > solution to the Perl 6 vs Perl 5 interpretation (although it still > needs a few extra lights here and there to make it really work). Actually, I can relate to this, this is the same feeling I got when reading certain parts of Apoc2. First off, I think many of the deeper semantic changes are very much on the right track. Such as the new context rules, and the way that variables are treated as references. So in Perl 6: @foo = (1, 2, 3); print "First one is ", @foo[1], "\n"; @bar = @foo; # reference copy, not list flattening I think this is good. Excellent, actually; there's lots of potential to improve the way arrays/hashes/lists are handled this way. However, I think lots of the proposed syntactic changes to Perl are on the verge of becoming unnecessary. And here I'm NOT talking about .-deref, since some of Larry's comments have convinced me there's some additional semantics to gain from this (.foo like $foo). I'm thinking more along the lines of: @list = < foo $bar %baz blurch($x) >; @list = qw/ foo $bar %baz blurch($x) /; # same as this I can't help but thinking "Why?" The whole q-series of quoting ops are easy to understand and use. Do we really need a "prettier" alternative to them? The same thing for having to do: print <<"EOF"; Hello, $name EOF Again, this seems unnecessary. It seems to impose unneeded burden on the programmer for the most common case. Damian Conway said something a while back to me, and I never realized how important it is to Perl: Just remember that consistency is a hobgoblin, and has little sway in Perl. At the time I gasped - how could we ignore consistency?! - but then I realized that though Perl isn't the most consistent language, it is one that has intelligent defaults which suit programmers well. I worry we're reacting against what other non-Perl-hackers complain about. But often these are the same things that JAPHs love about the language. Anyways, this isn't meant to spawn a religious war, but I do agree changing too much syntax without marked gains is not a good thing. I think we should only mess with stuff that's really truly broken, not just that's suboptimally attractive. -Nate
Re: apo 2
On Fri, May 04, 2001 at 03:00:59PM +0100, Michael G Schwern wrote: > On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote: > > And btw . . . Wouldn't > > > > $thing has property > > > > make more sense than > > > > $thing is property > > "$foo has true" doesn't flow as well as "$foo is true". Dunno quite > what the other expected uses are. Veracity is the ability to be true. Veracity is the property of truthfulness? $thing has veracity. $thing's veracity is true. An object environment I prototyped a few years ago used something similar. There were five levels of objects: Level 0 object: object (the fundamental building block of the universe) Level 1 objects: aspect (a reusable property for templates) is an object template (an intangible, ideal object) is an object Aspects (level 2): clothing (the ability to be worn) is an aspect containable (the ability to be somewhere) is an aspect container (the ability to contain things) is an aspect lidded (the ability to be sealed) is an aspect owner (the ability to own something) is an aspect posession (the ability to be owned) is an aspect session (the ability to service connections) is an aspect shell (the ability to parse commands) is an aspect tcpd (the ability to accept tcp socket connections) is an aspect etc. Templates (level 3): actor (a base class for players) is a template with container, containable, session and shell properties. container (an ideal tangible container) is a template having container properties. lidded container (an ideal sealable container) is a template having container and lidded properties. login daemon (something which answers remote connections and authenticates identities) is a template having tcpd properties. thing (an ideal tangible object) is a template with containable and posession properties. etc. Real tangible objects (level 4): the login server is a login daemon rocco is an actor rocco's backpack is a lidded container schwern is an actor schwern's pants are clothing schwern's fish is a thing etc. Hmm... perhaps I should include magic clothing: a template with clothing, container and lidded properties. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
Property/method naming conventions
I know I'm jumping ahead, but here goes...
Built-in classes in Perl 5 and 6 are uppercase: UNIVERSAL, ARRAY, HASH, etc.
By convention, "user" classes are Title::Cased. Simple guideline: don't use
UPPERCASE class names or risk being squished by a later revision of Perl.
Method names *sort of* follow the same convention in Perl 5: DESTROY, FETCH,
STORE, etc. User-defined methods are usually lowercase(). Simple
guideline: don't use UPPERCASE method names or risk being squished by a
later revision of Perl.
Now Perl 6 has "properties", some of which will be "built-in", from what I
can gather. Apocalypse 2 says:
"Note that when you say $foo.bar, you get $foo's compile-time
property if there is one (which is known at compile time, duh).
Otherwise it's an ordinary method call on the value (which looks
for a run-time property only if a method can't be found, so it
shouldn't impact ordinary method call overhead.)"
Given this, it seems to me (again, possibly jumping the gun) that the entire
lowercase method namespace is "unsafe" since you never know when a new
built-in property will be added to the language.
Say I've got a favorite Perl 6 module that I've been deploying for years,
and the most popular method is foo(). But then Perl 6.0.2 arrives with a
whizzy new built-in "foo" property that I'm just dying to use. Do I have to
force everyone to check this property with $obj.btw{'foo'}, and warn them
sternly that $obj.foo won't do what they expect? (Or should they next
expect that? :) Or do I have to change my favorite module's interface to
accommodate the new property?
And what happens here?
module My::Class;
sub .constant { 0 }
...
$foo = My::Class->new(...);
$foo is constant; # Sets "constant" property, right?
unless($foo.constant) # Calls .constant() *method*, right?
{
# Does it make sense to get here?
}
This problem already exists to some degree in Perl 5. Stuff like isa() and
can() is already squatting in the lowercase "user method" namespace. But I
have a feeling that properties will multiply a lot faster than UNIVERSAL
methods, so the opportunity for conflict seems even greater.
One possible solution it so make all built-in properties UPPERCASE:
# Set built-in property
$obj is CONSTANT;
# Check built-in property
if $obj.CONSTANT { ... }
# Call user-defined method
$obj.constant;
The simple guideline: don't use UPPERCASE property names, or risk being
squished by a later revision of Perl.
I have to admit that UPPERCASE built-in properties strikes me as damn ugly,
but it does avoid namespace conflicts... :-/
IIRC, doing the same thing for built-in/special methods was proposed by one
RFC:
sub IMPORT { ... }
if $obj->ISA(...) { ... }
if $obj->CAN(...) { ... }
Of course, that means you'd also have to do:
@array.LENGTH
$fh.NEXT
and so on. More ugliness. Hrmmm... :-/
Well, I guess this'll all be covered in the Apocalypse that deals with
objects and modules. But the property/method namespace conflict is relevant
to Apocalypse 2, IMO, so I'm looking for some answers about that part...
-John
Re: So, we need a code name...
Stephen P. Potter schrieb am 2001-05-03, 8:46: > Lightning flashed, thunder crashed and "Matt Youell" <[EMAIL PROTECTED]> wh > ispered: > | > What about leaving the flora aund fauna and using a name > | > like they call ships? > | > They always got names of females or towns... > | > > | > I suggest: > | > > | > PISA > | > > | > | Um... that sounds perilously close to "Piece Of". Am I alone on this one? > > That wasn't the first corruption that I thought of, but mine was along > similar lines... Hmm, i see, in Germany we speak german, and here it sounds ok. We have no word like you have it: 'pee'. (That is how 'PI' is spoken here). gph -- =^..^=
Re: Property/method naming conventions
On Sat, May 05, 2001 at 01:10:52PM -0400, John Siracusa wrote:
> This problem already exists to some degree in Perl 5. Stuff like isa() and
> can() is already squatting in the lowercase "user method" namespace. But I
> have a feeling that properties will multiply a lot faster than UNIVERSAL
> methods, so the opportunity for conflict seems even greater.
> One possible solution it so make all built-in properties UPPERCASE:
Good thinking.
This also led me to think about what happens when we introduce new built-ins.
Perl 5 has had a complete built-in freeze for a long long time now because
you can't bring in a new built-in without risking smacking subroutines in
old code.
We can get around that in Perl 6 by reversing the precedence: let user-defined
subroutines and methods take priority over built-ins. This would allow for
easy overloading ("sub open { ... }") and give us forward-compatibility. (If
you want to be sure you're working with built-in open, just use CORE::open)
Maybe something similar for properties.
--
"He was a modest, good-humored boy. It was Oxford that made him insufferable."
Re: Apoc2 - concerns
On Saturday 05 May 2001 19:28, Uri Guttman wrote: > the proposed qh only fails with a key or value of => which is highly > unlikely and can be worked around as a value by inserting another => > > %foo = qh( foo bar => => baz ) > > is: > > %foo = ( foo => 1, bar => '=>', baz => 1 ) Or it could be %foo = ( foo => 1, bar => 1, '=>' => 'baz' ) But I like the concept of a quote hash. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Apoc2 - concerns
On Sat, May 05, 2001 at 08:49:15PM -0400, Bryan C. Warnock wrote:
> %foo = ( foo => 1, bar => 1, '=>' => 'baz' )
> But I like the concept of a quote hash.
Of course, that could be spelt
%foo = <+foo +bar =>("baz")>;
(Just doing my bit for "use strict :<+refs>")
--
The debate rages on: Is Perl Bactrian or Dromedary?
Re: Apoc2 - concerns
On Sat 05 May, John Siracusa wrote: > On 5/5/01 3:28 PM, Larry Wall wrote: > > Well, that's enough brainwracking for the moment. Gloria is making me > > go eat something... > > Bread and water until Apocalypse 33 is done? ;) At one Apocalypse a month, that is a very long time... Would Larry survive for nearly three years on just Bread and water? :-) Richard -- [EMAIL PROTECTED]
Re: Apoc2 - concerns
Nathan Wiger writes:
: You know, I was just thinking about this, and I agree with Dan. Actually,
: there's some big problems in trying to get rid of <> and make Perl do the
: "right thing" in boolean context (like the while loop example). Consider:
:
:$FH = open " a shortcut to the
: proposed new general-purpose-iterator concept? So:
:
:$line = $FOO.next;# yuck, I agree with Dan
:$line = next $FOO;# better...
:$line = <$FOO>; # aaah :-)
:
:print while ($FOO); # infinite, assuming $FOO defined
:print while ($FOO.next); # while reading the file
:print while (<$FOO>); # still my favorite
:
: Otherwise, it seems like there's a lot of Black Magic with calling next()
: automatically, and for something as fundamental as I/O that makes me really
: nervous.
I expect the real choice is between <$FOO and <$FOO>. I can convince
myself pretty easily that a unary < is just another name for "next", or
"more", or something. On the other hand <$FOO> has history. And if
one special-cases <$...>, we could also have as a qw()
replacement. All we'd be doing is taking that syntax away from
globbing, and giving it to qw, more or less. (Less, because I'd like
to mean {foo => 1, bar => 1, baz => $xyz} or some
such, where the 1's are negotiable.)
But maybe I should hold out for «» meaning qw() eventually. If we
continue to require quotes on the string of <<"END", we could even use
<< foo bar baz($xyz) >> as an ASCII workaround, I suppose. That's not
much more readable than qw(), I admit.
That leaves < free to be either a prefix or circumfix operator of
arbitrary complexity.
If < is a unary operator, then one could have an arbitrary expression
returning an iterator:
$line = as funny parens:
$line = ;
On the other hand, I wouldn't want to go so far as to require
<1..10>
merely to make the iterator iterate. Saying
@foo[1..10]
ought to be enough clue. But does that mean that
%foo{$STDIN}
should read one value or all of them? Or some number depending on the number
of values expected in the context? And now we're back to the question
of slice context, really. Obviously, given a list flattener *, we'd
expect
%foo{*$STDIN}
to return all the values. Maybe then
%foo{<$STDIN}
returns exactly one value, and
%foo{$STDIN}
guesses.
Looking at it from the iterator object end, there might really be three
methods:
$STDIN.next # Return one element regardless of context.
$STDIN.more # Return number of element wanted by context.
$STDIN.all # Return all element regardless of context.
Or maybe there's only a "more" method, and you simply have to force the
context if you don't want it to guess. We don't actually have a good
notation for forcing a scalar context yet, let alone a scalar context
wanting a certain number of arguments. Doing violence to our current
notions of what various prefix operators currently mean, we might want:
$$STDIN # Return one element regardless of context.
@$STDIN # Return number of element wanted by context.
*$STDIN # Return all element regardless of context.
or
$STDIN # Return one element regardless of context.
=$STDIN # Return number of element wanted by context.
*$STDIN # Return all element regardless of context.
or
$-STDIN # Return one element regardless of context.
$=STDIN # Return number of element wanted by context.
$*STDIN # Return all element regardless of context.
or
$:$STDIN# Return one element regardless of context.
@:$STDIN# Return number of element wanted by context.
*:$STDIN# Return all element regardless of context.
or
$($STDIN) # Return one element regardless of context.
@($STDIN) # Return number of element wanted by context.
*($STDIN) # Return all element regardless of context.
or
$:$STDIN# Return one element regardless of context.
$STDIN# Return number of element wanted by context.
@:$STDIN# Return all element regardless of context.
or
$<$STDIN# Return one element regardless of context.
<$STDIN# Return number of element wanted by context.
@<$STDIN# Return all element regardless of context.
or some other casting mechanism yet to be devised.
The basic underlying question is, what is the context that should fire
off an iterator? Everyone thinks @foo[1..10] should just do the right
thing, whatever that is. Assuming the following makes an iterator,
and doesn't set $iter to 1 the first time through:
$iter = 1..10;
How many of these work?
while ($x = @foo[$iter]) { ... }
while ($x = <$iter>) { ... }
while ($x = $iter) { ... }
for ($iter) { ... }
I think that iterators must
Re: Apoc2 - concerns
On 5/5/01 3:28 PM, Larry Wall wrote: > I expect the real choice is between <$FOO and <$FOO>. I can convince > myself pretty easily that a unary < is just another name for "next", or > "more", or something. Yeah, but it looks like "previous"! ;) > maybe I should hold out for «» meaning qw() eventually. Ick. > Well, that's enough brainwracking for the moment. Gloria is making me > go eat something... Bread and water until Apocalypse 33 is done? ;) -John
Re: apo 2
Rocco Caputo wrote: > $thing's veracity is true. What about just $thing is; -- John Porter All men are subjects.
Re: apo 2
On Sat, May 05, 2001 at 04:10:47PM -0400, John Porter wrote: > Rocco Caputo wrote: > > $thing's veracity is true. > > What about just > $thing is; Existence is not the same as essence. -- Triage your efforts, y'know? - Thorfinn
Re: Apoc2 - concerns
Ok, this is long, so here goes...
> I expect the real choice is between <$FOO and <$FOO>. I can convince
> myself pretty easily that a unary < is just another name for "next", or
> "more", or something. On the other hand <$FOO> has history. And if
> one special-cases <$...>, we could also have as a qw()
> replacement. All we'd be doing is taking that syntax away from
> globbing, and giving it to qw, more or less. (Less, because I'd like
> to mean {foo => 1, bar => 1, baz => $xyz} or some
> such, where the 1's are negotiable.)
One thing I think we should avoid is as many "special cases" as possible.
This is already why people hate <> currently - because it does both glob()
and readline().
I would say that <> having history is actually a good thing. It's a
foundation, really, since readline() is an iterator of sorts. All we'd be
doing is generalizing the notion. Not only does it apply to files, but it's
a shortcut to more() wherever you feel like using it.
As for <> as a qw() replacement, I think there are really two issues here.
First, you're not really talking about a "replacement", since you're
mentioning different semantics. So qw() will still be widely used. I suggest
that we simply create another q-op to do the qw-ish things you're proposing.
Perhaps qi() for "interpolate" or something else. Plus <> has the terrible
problem that the POD C<> stuff does w/ embedded > chars. The really nice
thing about the q's is you can choose any bracket you want. I think fleshing
out this series of constructs makes the most sense.
> For a circumfix, you could just treat <> as funny parens:
>
> $line = ;
>
> On the other hand, I wouldn't want to go so far as to require
>
> <1..10>
>
> merely to make the iterator iterate. Saying
>
> @foo[1..10]
>
> ought to be enough clue.
Yes, I think that <> could just be shortcut to wherever you wanted more()
called. Just like .. with a different notation:
@foo = <$BAR>;
@foo = @bar[1..10];
@foo[0..4] = <$BAR>;
This is nice because it looks Perlish, but fundamentally it could be reduced
to a single iterator concept.
> But does that mean that
>
> %foo{$STDIN}
>
> should read one value or all of them?
I would say that this should return only one thing - the $STDIN variable. No
automatic iteration should be done. Otherwise you run into problems with how
to pass filehandles around as variables. I think iteration needs to be
explicit.
If you want iteration:
%foo{<$STDIN>}; # poll the iterator
%foo{$STDIN.more};# same thing
The iterator is just a member function, and you have to call it if you want
it.
$FOO = open "); # now filehandle is iterated (lazily)
&do_more_stuff($FOO.more); # same thing
%holding_stuff{$FOO.more}; # same thing, just into a var
close $FOO;
I think these semantics make sense.
> Obviously, given a list flattener *, we'd expect
>
> %foo{*$STDIN}
>
> to return all the values. Maybe then
>
> %foo{<$STDIN}
>
> returns exactly one value, and
>
> %foo{$STDIN}
>
> guesses.
I'd so this differently, as hinted at above:
%foo{<$STDIN>};# return all values
%foo{<$STDIN); # return one value
%foo{$STDIN}; # pass the $STDIN variable
This is assuming that we want < to exist and have a different semantics. But
I'm not sure that's a good idea. For one thing, you'd have to mention it
several times if you want a couple values. I think there's got to be a
better way to request the number of lines based on context.
%foo{<$STDIN>}; # the whole thing
%foo{ (1..2) = <$STDIN> }; # anonymous list request?
%foo{ <$STDIN>[1..2] }; # or notate it as a list?
%foo{ ($STDIN.more)[1..2] }; # same thing
The last one seems to make sense (it's got those (localtime)[2,3] roots),
with the third one as a shortcut.
> Looking at it from the iterator object end, there might really be three
> methods:
>
> $STDIN.next # Return one element regardless of context.
> $STDIN.more # Return number of element wanted by context.
> $STDIN.all # Return all element regardless of context.
>
> Or maybe there's only a "more" method, and you simply have to force the
> context if you don't want it to guess.
I think one method is the way to go. Let the subs and other contexts request
the number of elements to get back using lazy evaluation:
@foo[1..10] = <$STDIN>; # get 10 iterations
$bar = <$STDIN>;# next one
&lazy_sub(<$STDIN>);# lazily
Assuming:
sub lazy_sub ($a, $b, $c, $d) { }
Then the last line above would lazily grab the next four lines.
> We don't actually have a good
> notation for forcing a scalar context yet, let alone a scalar context
> wanting a certain number of arguments.
Personally, I'd look at it differently. I don't think that getting a number
of arguments out of a scalar context makes sense. Rather, I think you need
to call a member function or do whatever to get a list, then lazily evaluate
that.
@
Re: Apoc2 - concerns
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> As for <> as a qw() replacement, I think there are really two NW> issues here. First, you're not really talking about a NW> "replacement", since you're mentioning different semantics. So NW> qw() will still be widely used. I suggest that we simply create NW> another q-op to do the qw-ish things you're proposing. Perhaps NW> qi() for "interpolate" or something else. Plus <> has the terrible NW> problem that the POD C<> stuff does w/ embedded > chars. The NW> really nice thing about the q's is you can choose any bracket you NW> want. I think fleshing out this series of constructs makes the NW> most sense. i think qX is the way to go for extending quotes. it has a long history, there are multiple intuitive uses already and it is extendable. i think waht larry seems to want is qh() for quote hash. here is a possible syntax/semantic for it: %foo = qh( foo bar baz ) is like %foo = ( foo => 1, bar => 1, baz => 1 ) but any single element could be paired with => inside so: %foo = qh( foo bar => 2 baz ) is like %foo = ( foo => 1, bar => 2 , baz => 1 ) other variations could be supported. i am not sure i like: %foo = qh( foo bar(2) baz ) as how would you know if that is 'bar(2)' or bar => 2? the proposed qh only fails with a key or value of => which is highly unlikely and can be worked around as a value by inserting another => %foo = qh( foo bar => => baz ) is: %foo = ( foo => 1, bar => '=>', baz => 1 ) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11 Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
Re: Apoc2 - concerns
At 01:51 AM 5/6/01 +0100, Simon Cozens wrote: >The debate rages on: Is Perl Bactrian or Dromedary? It's a Dromedary, it says so in the Colophon. But maybe the symbol of Perl 6 should be a Bactrian, with the extra hump symbolizing the increased power. You knew this was coming... -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com
