On Fri, 20 Aug 2004, Luke Palmer wrote:
Austin Hastings writes:
Larry Wall wrote:
Hmm. Gotta decided if S$foo.bar() is too ugly to live though...
It is.
Agreed.
Though IMHO Perl has a long history of syntax allowances too ugly to live,
and yet, as long as they are not *enforced*,
On Sat, 14 Aug 2004, Smylers wrote:
could reparse the result. XXX .repr is what Python calls it, I think.
Is there a better name?
Yes; I've no suggestions as to what it might be, but surely there's
_got_ to be a better name than C.repr.
.repr is fine for me. An alternative that springs
On Fri, 20 Aug 2004, Dan Hursh wrote:
Peter Behroozi wrote:
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... }
On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
So all the laziness goes into the array implementation. But you don't
even need to write your iterator fancily. If you just write your scalar
version of postcircumfix:, Perl will do the rest.
So if you use an iterator in list context, Perl will
David Green writes:
On 8/20/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
So all the laziness goes into the array implementation. But you don't
even need to write your iterator fancily. If you just write your scalar
version of postcircumfix:, Perl will do the rest.
So if you use an iterator
Dov Wasserman writes:
Larry Wall [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
next D next N all D all N
== == = =
$iter $iter.pull ?1
On Thu, 2004-08-19 at 12:17 -0400, Matt Diephouse wrote:
At this point, you may as well use C.records (think C$/ -- record
separator):
for $foo.records { ... }
Then it'd be a small step to allow:
for $foo.records :sep, { ... }
--or--
for $foo.records(,) { ...
On 8/19/04, [EMAIL PROTECTED] (Luke Palmer) wrote:
David Green writes:
Hang on -- should we be saying for each $foo or for $foo.each
anyway? We don't say for @foo.each; the iteration is implicit. So
I'm thinking it should be for $foo or while next $foo.
Well, Cfor $foo gives you a
On 8/19/04, [EMAIL PROTECTED] (Larry Wall) wrote:
It's hard to come up with an English word that means next in scalar
context but all in list context.
I never know whether to name my arrays singular or plural, either. =)
But couldn't there be Two Ways To Do It? One singular name and one
David Green writes:
Then I thought that maybe for doesn't need to work lazily (except that
the conveniently just-posted Synopsis 4 confirms that it is supposed to
be lazy). Or maybe for is only as lazy as is reasonable, meaning if
it knows how (e.g. if you're using an array or filehandle,
On Fri, Aug 20, 2004 at 10:49:17AM -0600, Luke Palmer wrote:
:
: method postcircumfix: ($self: *%opt) returns List {
: scalar $self.*%opt, $self.*%opt # [1]
: }
:
: [1] Look, Larry, I had to use Cscalar! Maybe we _do_ need to revive
: $()!
It's not clear to me that $() would
On Fri, Aug 20, 2004 at 12:52:56PM -0700, Larry Wall wrote:
: Unfortunately, the only obvious one, 's', is taken.
I remind myself that 'S' is equally obvious, and not taken. Like _,
it suffers from spacing issues, but could be the ASCII backup for
the § character. (As Y is likely to be the
Peter Behroozi wrote:
I'm not particular to any of the verbs used yet, but maybe that's
because I don't think of the as a general iterator, but more of a
gobbler-type creature (and formerly a globber, too). Could we try:
for $foo.fetch { ... } #or
for $foo.grab { ... } #or
for $foo.eat { ... }
On Fri, 2004-08-20 at 14:26, Austin Hastings wrote:
Dan Hursh wrote:
generalimpose scalarimpose list
-----
D$foo.eat$foo.bite$foo.gobble
N$foo.look$foo.peek$foo.peruse
hmm, I don't like eat
Larry Wall wrote:
On Fri, Aug 20, 2004 at 12:52:56PM -0700, Larry Wall wrote:
: Unfortunately, the only obvious one, 's', is taken.
I remind myself that 'S' is equally obvious, and not taken. Like _,
it suffers from spacing issues, but could be the ASCII backup for
the § character. (As Y is
Chromatic wrote:
On Fri, 2004-08-20 at 14:26, Austin Hastings wrote:
Dan Hursh wrote:
generalimpose scalarimpose list
-----
D$foo.eat$foo.bite$foo.gobble
N$foo.look$foo.peek$foo.peruse
hmm, I don't like eat
chromatic wrote:
On Fri, 2004-08-20 at 14:26, Austin Hastings wrote:
Dan Hursh wrote:
generalimpose scalarimpose list
-----
D$foo.eat$foo.bite$foo.gobble
N$foo.look$foo.peek$foo.peruse
hmm, I don't
Austin Hastings writes:
Larry Wall wrote:
Hmm. Gotta decided if S$foo.bar() is too ugly to live though...
It is.
Agreed.
I still kinda like underscore.
How about scalar? The fact that one person, one time, came up with a
need to invoke it doesn't mean we have to race it up the
On 8/20/04 5:30 PM, Austin Hastings wrote:
How about scalar? The fact that one person, one time, came up with a
need to invoke it doesn't mean we have to race it up the huffman tree.
P6 is winning the DWIM race most of the time contextually. Maybe [#] as
a macro, if you like.
Yeah, that's my
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
On Sat, Aug 14, 2004 at 09:56:34PM +, Smylers wrote:
: I like that exception; it means that if all your array elements end with
: line-breaks, you don't end up with all but the first one being indented
[...]
That's the
On 8/15/04, [EMAIL PROTECTED] (David Wheeler) wrote:
On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
for all $*IN # all() is junction
for each $*IN # each method wants closure if we follow Ruby
for next $*IN # next $foo is a loop exit
Hmm. Maybe the problem is that we shouldn't
On 8/19/04, [EMAIL PROTECTED] (David Green) wrote:
On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
for all $*IN # all() is junction
for each $*IN # each method wants closure if we follow Ruby
for next $*IN # next $foo is a loop exit
[...]
Each and every are the obvious choices,
David Green writes:
On 8/19/04, [EMAIL PROTECTED] (David Green) wrote:
On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
for all $*IN # all() is junction
for each $*IN # each method wants closure if we follow Ruby
for next $*IN # next $foo is a loop exit
[...]
Each and every
On 2004-08-18 at 22:37:31, Larry Wall wrote:
Actually, I've settled on .perl for now, on the assumption there could
also be a .python, a .ruby, a .cobol, a .intercal, etc.
Perhaps there should be a special name visible only at the language
level that automatically translates to
David Green wrote:
...but print next $foo is better than print each $foo. ...
print another $foo
for another $foo {...}
while another $foo {..}
It's 5 characters too many, but it works.
Dan
On Thu, Aug 19, 2004 at 10:38:48AM -0500, Dan Hursh wrote:
David Green wrote:
...but print next $foo is better than print each $foo. ...
print another $foo
for another $foo {...}
while another $foo {..}
It's 5 characters too many, but it works.
print more $foo;
for more $foo {
On Thu, Aug 19, 2004 at 05:08:55AM -0600, Luke Palmer wrote:
: Well, Cfor $foo gives you a one-iteration loop. But perhaps list
: flatten could work on iterators:
:
: for *$foo { ... }
I dislike that purely on visual grounds in the case of
for *$*IN { ... }
But I expect most folks
On Thu, 19 Aug 2004 10:38:48 -0500, Dan Hursh [EMAIL PROTECTED] wrote:
while another $foo {..}
It's 5 characters too many, but it works.
Dan
At this point, you may as well use C.records (think C$/ -- record
separator):
for $foo.records { ... }
Then it'd be a small step to allow:
for
Matt Diephouse writes:
for $foo.records :sep, { ... }
The trouble is that using a for loop builds a list in memory, which
can be troublesome.
I think that in Perl 6 Cfor doesn't build a list in memory, so as to
avoid the troublesome bits.
Smylers
On Thu, Aug 19, 2004 at 10:53:06AM -0500, Jonathan Scott Duff wrote:
: I like each best though. Why exactly can't it work?
It could be made to work. The sources of cognitive interference are:
1. Perl 5's each(%hash) function, which is probably not a problem.
2. Ruby's array.each {|x|
Larry Wall writes:
next D next N all D all N
== == = =
$iter $iter.read ?1 $iter.read ?2
@array @array.shift@array.for
After all, a pull is the other end of a push.
Larry
So do we also get:
%hash.push(key = 'value'); # harder than %hashkey = 'value';
%hash.unshift; # same as %hash.push
%hash.shift; # same as %hash.pull
%hash.pop; # same as %hash.pull
Which then begs if you can do
@array.push(3 = 'value'); #
On Thursday 19 August 2004 02:14 pm, Paul Seamons wrote:
@array.push(3 = 'value'); # index 3 gets 'value'
Hmm. Well that makes it hard to have an array of pairs - so never mind.
Paul Seamons
On Thu, Aug 19, 2004 at 12:31:42PM -0700, Larry Wall wrote:
So let's rewrite the table (assuming that all the hash methods are just
variants of .values), where N and D are non-destructing and destructive:
next D next N all D all N
On Thu, Aug 19, 2004 at 01:54:39PM -0600, Luke Palmer wrote:
: That is very tickley. But there's another kind of dissonance there.
: @array.pull needs to take arguments[1] when called with list pull,
: otherwise it's basically useless.
It's not useless if you just want to interpolate an entire
On Thu, Aug 19, 2004 at 05:26:38PM -0400, John Macdonald wrote:
: In scalar context a non-destructive read of an iterator might
: be called $iter.peek and the next .read will get (and remove)
: the same value that .peek returns. Implementation would be
: fairly simple - the control info for an
On Sat, 14 Aug 2004, Larry Wall wrote:
To get a Perlish representation of any data value, use the C.repr
method. This will put quotes around strings, square brackets around
list values, curlies around hash values, etc., such that standard
Perl could reparse the result. XXX .repr is what
On Wed, Aug 18, 2004 at 10:02:57PM -0600, John Williams wrote:
: On Sat, 14 Aug 2004, Larry Wall wrote:
: To get a Perlish representation of any data value, use the C.repr
: method. This will put quotes around strings, square brackets around
: list values, curlies around hash values, etc.,
On 8/14/04, [EMAIL PROTECTED] (Larry Wall) wrote:
To get a Perlish representation of any data value, use the C.repr
method. This will put quotes around strings, square brackets around
list values, curlies around hash values, etc., such that standard
Perl could reparse the result. XXX .repr is
Larry Wall writes:
: {$foo[$bar]}
: {$foo}[$bar]
:
: That last example seems to violate the previous stipulation about
: not following a closure by dereferencers.
That's the point--it isn't a dereferencer. It's literal brackets.
Ah, yes. Sorry -- my mind was determined to
On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
If one goes with a standard method name, we also want to see what it
looks like as an indirect object:
for more $*IN
for iter $*IN
for every $*IN
for read $*IN
for in $*IN
for shift $*IN
Of these, I like Cevery best.
Like I
=head1 Title
Synopsis 2: Bits and Pieces
=head1 Author
Larry Wall [EMAIL PROTECTED]
=head1 Version
Maintainer: your name here
Date:
Last Modified:
Number: 2
Version: 0
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues.
@@ -165,7 +165,7 @@ =head1 Built-In Data Types
=item *
Built-in object types start with an uppercase letter: Int, Num, Str,
-Bit, Ref, Scalar, Array, Hash, Rule and Code]. Non-object (value) types
+Bit, Ref, Scalar, Array, Hash, Rule and Code. Non-object (value) types
are lowercase: int,
Larry Wall writes:
Synopsis 2: Bits and Pieces
Nice. (Minor pod corrections sent as a diff under separate cover.)
You may interpolate a package name into an identifier using
C::($expr) where you'd ordinarily put the package name. The parens
are required.
XXX Actually, C::{$expr} might
On Sat, Aug 14, 2004 at 09:56:34PM +, Smylers wrote:
: A bare closure also interpolates in double-quotish context. It may
: not be followed by any dereferencers, since you can always put them
: inside the closure. ... The old disambiguation syntax ... is dead.
: Use closure curlies
On Sat, Aug 14, 2004 at 09:56:34PM +, Smylers wrote:
: You may interpolate a package name into an identifier using
: C::($expr) where you'd ordinarily put the package name. The parens
: are required.
:
: XXX Actually, C::{$expr} might be made to work instead, given that
: that's how
46 matches
Mail list logo
