Re: Apoc2 - STDIN concerns
On Fri, May 04, 2001 at 07:56:39PM -0700, Larry Wall wrote: Nathan Wiger writes: : : This one. I see a filehandle in *boolean* context meaning read to $_, : : just like the current while (FOO) magic we all know and occasionally : : love. I'd expect $FOO.readln (or something less Pascalish) to do an : : explicit readline to a variable other than $_ : : It would be $FOO.next, but yes, that's the basic idea. It's possible : that iterator variables should be more syntactically distinquished than : that. One could, I suppose, make up something about $FOO or $FOO : meaning the same thing thing as $FOO.next, for people who are homesick : for the angles, but I haven't thought that out, and don't even dare to : mention it here for fear someone will take it as a promise. Er, oops... : : So, just to clarify, the thought is: : :print while ($FOO);# like Perl 5 FOO :$var = $FOO.next; # like Perl 5 $var = FOO; : : I assume that this is indicative of a more general iterator syntax, and : subject to indirect objects? : :$FH = open $file or die Can't open $file: $!; :$line = next $FH; : : If so, I can live with that. Yes, that's the reason it's Cnext, and not something more specific like Creadline, which isn't even true in Perl 5 when $/ is mungled. We do have to worry about the Cnext loop control function though. I don't know. If it had to be written as $FH.next then there should be no ambiguity. Graham.
Re: Apoc2 - STDIN concerns
On Sat, May 05, 2001 at 02:46:46AM +0100, Michael G Schwern wrote:
On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
I'm wondering what this will do?
$thingy = $STDIN;
This seems to have two possibilities:
1. Make a copy of $STDIN
2. Read a line from $STDIN
While perhaps inconsistent, I'd really rather it did #2. Here's the
basic argument... compare how often you dup a filehandle with how
often you read from one. Duping is swamped by several orders of
magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
$STDIN.next should still work normally.
How would you pass a handle to a subroutine, or store it inside
a hash or array ?
sub my_read {
my $fh = shift; # whoops
}
I don't think it should do a dup(), but we do need to pass file handles around
Graham.
Re: Apoc2 - STDIN concerns
:$FH = open $file or die Can't open $file: $!; :$line = next $FH; : : If so, I can live with that. Yes, that's the reason it's Cnext, and not something more specific like Creadline, which isn't even true in Perl 5 when $/ is mungled. I dunno. Color me unconvinced--I do use the enough in non-while context (and in non-implied while context) to make the whole idea of next feel rather... nasty. And $FOO.next? Yuck. 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 /etc/motd; die No good unless ($FH);# ??? What does that do? Per the proposal, $FH in a boolean context is supposed to call its next() method to get the next line. So, does that fail because the handle wasn't opened (and hence $FH was never defined) or because /etc/motd is zero-length? And having to write $line = next $FH is already getting cumbersome, to be honest. I say we should combine the two concepts. Why not make 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. -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
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 - STDIN 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 /etc/motd;
:die No good unless ($FH);# ???
You're right, that's a severe problem.
: What does that do? Per the proposal, $FH in a boolean context is supposed to
: call its next() method to get the next line. So, does that fail because the
: handle wasn't opened (and hence $FH was never defined) or because /etc/motd
: is zero-length?
:
: And having to write $line = next $FH is already getting cumbersome, to be
: honest.
True 'nuff.
: I say we should combine the two concepts. Why not make 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 foo bar baz 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
foo bar baz($xyz) 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 = somefunc();
For a circumfix, you could just treat as funny parens:
$line = somefunc();
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#
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 - STDIN 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 foo bar baz 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
foo bar baz($xyz) 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 = somefunc();
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 bar;
do_stuff($FOO);# filehandle passed, not contents
do_more_stuff($FOO); # 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
Re: Apoc2 - STDIN 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 - STDIN 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]
