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 *
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
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
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
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.fe
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'
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
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 l
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 i
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 likel
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'
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 { ... } #or
for $foo.grab { ... } #or
for
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, 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 ASCII
On Thu, Aug 19, 2004 at 08:12:37PM -0500, Peter Behroozi wrote:
: And to replace $/ we could have something like:
:
: for $foo.fetch :upto(",") { ... } #or
: for $foo.fetch :until(",") { ... }
I suppose in <>-ese, that could be one of:
for $foo.< :upto(",") > { ... } #or
for $foo.< :unti
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 C! Maybe we _do_ need to revive
: $()!
It's not clear to me that $() would h
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 fil
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 on
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, C gives you
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.r
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
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [H]ow about a table that looks like this:
>
> next D next N all D all N
> == == = =
> $iter $iter.pull ?1
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 ite
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 ar
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 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
> After all, a pull is the other end of a push.
>
> Larry
So do we also get:
%hash.push(key => 'value'); # harder than %hash<> = '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')
Larry Wall writes:
> next D next N all D all N
> == == = =
> $iter $iter.read ?1 $iter.read ?2
> @array @array.shift@array.for @array
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|
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 C doesn't build a list in memory, so as to
avoid the troublesome bits.
Smylers
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 allo
On Thu, Aug 19, 2004 at 05:08:55AM -0600, Luke Palmer wrote:
: Well, C 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 will end up
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
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 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 .language_I_wa
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
> [..
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 obv
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 shoul
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/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 .rep
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 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 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 C best.
Like I say, all
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 determin
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
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 in
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
@@ -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, num
=head1 Title
Synopsis 2: Bits and Pieces
=head1 Author
Larry Wall <[EMAIL PROTECTED]>
=head1 Version
Maintainer:
Date:
Last Modified:
Number: 2
Version: 0
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopse
49 matches
Mail list logo
