> sane indentation by making it part of the language, Perl is a
> language that enforces a dialect of hungarian notation by making
> its variable decorations an intrinsic part of the language.
But $, @, and % indicate data organization, not type...
> What if, instead of cramming everything into
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote:
> > Perl is a highly dynamic language
>
> An object with exactly one and only one method doesn't sound that
> dynamic to me.
Three methods, surely: next, last, redo.
--
Piers Cawley
www.ite
> push chairs, map {woodworking} treestumps;
>
or even
push chairs, map BLOCK(woodworking) treestumps;
Hungarian notation is any of a variety of standards for organizing
a computer program by selecting a schema for naming your variables
so that their type is readily available to someone familiar with
the notation.
Just as Python is a language that enforces the common practice of
sane indentatio
> Doubtless Damian could come up with a way to view them as hashes...
Well, of course.
An iterator is neither pure state nor pure behaviour. It's an
inextricable commingling of the two. In other words: an object.
So they are *most naturally* viewed as hashes:
package Iterator;
Larry Wall wrote:
>
> all arrays are iterators of some sort
BZZT! HSSS! CLANG! DANGER, WILL ROBINSON! DANGER, WILL ROBINSON
David L. Nicol writes:
: Larry Wall wrote:
:
: > Syntactically speaking it's too ambiguous to have both a unary < and a
: > bracketing <>.
:
: Cool. Do we get a > operator to use as an l-value, instead of print?
:
: >$log = join localtime, 'difficult cramigudgeo';
I don't think so.
: >
At 10:23 PM 5/8/2001 +0100, Simon Cozens wrote:
>On Tue, May 08, 2001 at 05:08:58PM -0400, Dan Sugalski wrote:
> >@foo = ({scalar each %some_tied_hash});
> >
> > with the function being called only when you access a particular element?
>
>I'm still confused. Firstly, this doesn't involve first
David L. Nicol wrote:
> That also wraps up the "for should have an explicit
> iterator access method" thread handily! Just label your loop and
> there you are!
Well, right. Every loop would have a control object,
whether it's nonymous or a-.
--
John Porter
Nathan Wiger wrote:
> Perhaps qi() for "interpolate" or something else.
coming to Perl from Scheme I recall some distress that
I had to create
($j=$i) =~ s/(\$\S+)/$1/ge;
instead of what I wanted to do
$j=qqq/$i/;
so my nomination is for tokens matching /qq*/ to behave like
s
Larry Wall wrote:
>
> The ~~ is a cute hack though.
Credit is due to Steve Lane <[EMAIL PROTECTED]> who posted it to funwithperl.
...
> I'm sorry, my eyes go crossed when I look at that, and the two \Q's
> merge into one, which confuses me, in a stereoscopic sort of way.
I was wrong about \Q\
On Tue, May 08, 2001 at 05:08:58PM -0400, Dan Sugalski wrote:
>@foo = ({scalar each %some_tied_hash});
>
> with the function being called only when you access a particular element?
I'm still confused. Firstly, this doesn't involve first-order blocks, which
was kinda what the entire question
On Tue, May 08, 2001 at 05:11:52PM -0400, John Porter wrote:
> > Can you give me an example ...
>
> Rather than head off down this time-wasting tangent yet again,
That smacks of avoiding the question.
Again, do you have a useful example?
--
You will never find a more wretched hive of scum and
Nathan Wiger wrote:
>
> Truthfully, I've always liked the <>'s (and personally don't think we need a
> qw alternative), so I'd rather we stay with:
>
>$a = <$b>; # same as next $b or $b.next
we could generalize the other direction and have angles be a standard
shortcut for the "next" met
I know it is an annoying and bad habit but I'm still young enough so
at first glance I think I know it all.
> [billions and billions of]
> SYN_A # Return one element regardless of context.
> SYN_B # Return number of element wanted by context.
> SYN_C # Re
John Porter wrote:
>
> > [EMAIL PROTECTED] writes:
> > :
> > : why should a reader expect that a declarative description
> > : of &foo would be followed by the body of &foo?
>
> Isn't the functional definition of a sub
> just another one of its attributes, anyway?
I'm a little bit disappointed
Johan Vromans wrote:
>
> [Quoting Michael G Schwern, on May 6 2001, 22:58, in "Re: Apo2: \Q ambigui"]
> > Hmmm, maybe you can point out the "compose" key on my keyboard, I
> > can't find it. ;)
>
> Pick whatever you find convenient. I use the right control key.
> From my .Xmodmap:
>
> ! Compo
Jonathan Scott Duff wrote:
> (*%a, %b) = (%c,%d);# %a slurps, %b gets nothing
> (%a, *%b) = (%c,%d);# %a = %c, %b gets the rest
>
> I'm sure your imaginations can twiddle the cardinality knob
> appropriate for generalization :-)
>
> -Scott
so if you don't know exactly
Nathan Wiger wrote:
>
> I think Uri's qh() suggestion is the cleanest:
me too
> And it would make hash declarations cleaner:
>
>%hash = qh(
> foo
> bar
> jim => 'bob'
> var
>);
>
> Plus maybe even a pragma to set the default value:
>
> use def
John Porter wrote:
>
> Pardon me if someone has already suggested this, but...
> Couldn't labels really be (aliases to) iterator objects?
> So that
> next FOO
> really *does* mean
> FOO.next
>
Marvelous! That also wraps up the "for should have an explicit
iterator access method
Larry Wall wrote:
> Syntactically speaking it's too ambiguous to have both a unary < and a
> bracketing <>.
Cool. Do we get a > operator to use as an l-value, instead of print?
>$log = join localtime, 'difficult cramigudgeo';
> It's possible we're thinking of iterators wrong here. P
Larry Wall wrote:
> there seems to be a shortage of three-humped camels.
At last! the unencumbered image for the mascot! Could
O'Reilly really claim a three-humped camel was an image of
a camel, with a straight face?
Simon Cozens wrote:
>
> On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote:
> > Perl is a highly dynamic language
>
> An object with exactly one and only one method doesn't sound that
> dynamic to me.
nonsense! It's got accessor methods too, for everyone who
wanted to magicalize "$i
Simon Cozens wrote:
> Can you give me an example that is i) useful
> and ii) reasonably obvious to the untrained eye? If not, I humbly suggest it
> has little business being in the "blue-collar language" we call Perl.
Rather than head off down this time-wasting tangent yet again,
I refer readers
At 09:42 PM 5/8/2001 +0100, Simon Cozens wrote:
>On Tue, May 08, 2001 at 12:58:24PM -0700, Larry Wall wrote:
> > Perhaps Perl 6 will have ordinary blocks that can function as continuations
> > to the surrounding list context.
>
>OK, now you've broken my brain. Can you give me an example that is i)
On Tue, May 08, 2001 at 12:58:24PM -0700, Larry Wall wrote:
> Perhaps Perl 6 will have ordinary blocks that can function as continuations
> to the surrounding list context.
OK, now you've broken my brain. Can you give me an example that is i) useful
and ii) reasonably obvious to the untrained ey
Nathan Wiger wrote:
> So < could mean "more" and > could mean "less".
That would sure confuse the math subcommunity! ;-)
> "more" and "less" could be inverses, "more" reading from the current
> position forward and "less" from the current position backwards. This
> notion could be generalize
* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 10:11]:
>
> Nathan Wiger writes:
> : First off, before I forget to mention it, nice job on Apoc2 Larry! You are
> : the man. I know alot of us on p6l can seem like harsh critics at times, but
> : it's only because we love Perl so much. ;-)
>
> We'll ha
At 01:19 PM 5/8/2001 -0700, Nathan Wiger wrote:
>* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 09:36]:
> >
> > Taking history into account is good, though I'd argue that now is the
> > proper time to change history, if we're going to change. Perl would
> > never have been accepted in the first pla
* Larry Wall <[EMAIL PROTECTED]> [05/08/2001 09:36]:
>
> Taking history into account is good, though I'd argue that now is the
> proper time to change history, if we're going to change. Perl would
> never have been accepted in the first place had it been too different
> from what came before, but
At 12:58 PM 5/8/2001 -0700, Larry Wall wrote:
>Simon Cozens writes:
>: On Tue, May 08, 2001 at 03:00:51PM -0400, John Porter wrote:
>: > Bit of a digression; but, the dynamicity of a language is in
>: > no way implicated by the number of methods in one build-in
>: > class. (Besides, this class wi
> Well clearly "on" is the opposite of "no". Yes?
maybe, as in:
my cat maybe Dog;
for some form of relaxed typing constraint.
Larry Wall wrote:
> We're not so far off of a yield-like
> method on continuations here...
> ... ordinary blocks that can function as continuations
> to the surrounding list context.
Ah! Now we're talking!
--
John Porter
Me wrote:
> And, despite perl5's use of no as the opposite
> of use, and given that there may be no use in
> perl6 (;>), and thus perhaps no no, (on and off?),
> then maybe no could be used as not yes?
Well clearly "on" is the opposite of "no". Yes?
--
John Porter
> If you're trying to confuse me, I can assure you it's unnecessary.
;-)
Hey, I try.
--me
(Under cover Ruby/Python agent and
promotor of RFCs 380 thru 1,000,000)
Simon Cozens writes:
: On Tue, May 08, 2001 at 03:00:51PM -0400, John Porter wrote:
: > Bit of a digression; but, the dynamicity of a language is in
: > no way implicated by the number of methods in one build-in
: > class. (Besides, this class will have at least three.)
:
: Ooh, at least three.
Me writes:
: > So bool would perhaps be a synthetic property that has opposite
: polarity
: > from bit? I can see that, sort of. It's something like electrons
: being
: > negative, thank you Mr. Franklin.
:
: s/bit/yes/
:
: yes?
:
: And, despite perl5's use of no as the opposite
: of use, and
> So bool would perhaps be a synthetic property that has opposite
polarity
> from bit? I can see that, sort of. It's something like electrons
being
> negative, thank you Mr. Franklin.
s/bit/yes/
yes?
And, despite perl5's use of no as the opposite
of use, and given that there may be no use in
[Tom's away at the moment, I'm filling in until he gets back.]
--
Asynchronous inputs are at the root of our race problems.
-- D. Winker and F. Prosser
On Tue, May 08, 2001 at 03:00:51PM -0400, John Porter wrote:
> Bit of a digression; but, the dynamicity of a language is in
> no way implicated by the number of methods in one build-in
> class. (Besides, this class will have at least three.)
Ooh, at least three. Again, why special-case a class t
On Tue, May 08, 2001 at 02:59:09PM -0400, John Porter wrote:
> It's also supposed to have an implementation.
I think those of us who are actually likely to write a single line of code or
more should be concerned with that, thank you.
--
[It is] best to confuse only one issue at a time.
Simon Cozens wrote:
> An object with exactly one and only one method doesn't sound that
> dynamic to me.
Bit of a digression; but, the dynamicity of a language is in
no way implicated by the number of methods in one build-in
class. (Besides, this class will have at least three.)
--
John Porter
Simon Cozens wrote:
> Then I call Occam's Razor. Perl is supposed to be easy, no?
It's also supposed to have an implementation.
And to have a consistency level somewhat greater than zero.
Also, consider the implications for user-defined control
constructs.
--
John Porter
On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote:
> Perl is a highly dynamic language
An object with exactly one and only one method doesn't sound that
dynamic to me.
--
Can you sum up plan 9 in layman's terms?
It does everything Unix does only less reliably - kt
Simon Cozens wrote:
> Indeed. And I suspect that the first Perl 6 programmers are Perl 5
> programmers, who know damned well what "next FOO" means.
Would it really cause you that much consternation
to find, after you've been programming in Perl6
for some months or years, that "next FOO" is
actua
Simon Cozens writes:
: 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.
Right, that's been an impedimen
Simon Cozens writes:
: On Tue, May 08, 2001 at 02:47:19PM -0400, John Porter wrote:
: > Not that there are any such people. Yet.
:
: Indeed. And I suspect that the first Perl 6 programmers are Perl 5
: programmers, who know damned well what "next FOO" means.
Well, it's certainly the case that "
On Tue, May 08, 2001 at 02:34:25PM -0400, John Porter wrote:
> Nothing changes at the syntactic level.
Then I call Occam's Razor. Perl is supposed to be easy, no?
--
And it should be the law: If you use the word `paradigm' without knowing
what the dictionary says it means, you go to jail. No e
On Tue, May 08, 2001 at 02:47:19PM -0400, John Porter wrote:
> Not that there are any such people. Yet.
Indeed. And I suspect that the first Perl 6 programmers are Perl 5
programmers, who know damned well what "next FOO" means.
--
"Dogs believe they are human. Cats believe they are God."
From: "Larry Wall" <[EMAIL PROTECTED]>
To: "Eric Roode" <[EMAIL PROTECTED]>
Sent: Tuesday, May 08, 2001 11:03 AM
Subject: Re: Apoc2 - concerns
> Eric Roode writes:
> : And, while I'm on my soapbox here, I don't get how <...> is a vast
> : improvement over qw<...>. :-)
> Please pardon my hyperb
Simon Cozens wrote:
> John Porter wrote:
> > C looks like a method call
>
> It doesn't,
Oh, but it does, to the perl6 programmer who's used to
thinking
$source.next
(or its "indirect object" alternative,
next $source
) iterates the iterator in $source.
Not that there are any s
I like the lisp-associative-array alternating keys,values nature
of the perl5 %hash=@array semantics, and the way it can be used to
set defaults in hashref argument lists. The replacement must
provide an equivalent but less hacky replacement.
--
David Nicol 816.235.11
On Tue, May 08, 2001 at 02:34:25PM -0400, John Porter wrote:
> the guy who wants to know why C looks like
> a method call
It doesn't, any more than "next FOO" looks like a method call
in Perl 5 right now.
--
> I'm a person, not a piece of property.
Happily, I'm both!
- Lionel and Stephen Ha
Simon Cozens wrote:
> I'm sure a "pure virtual base template class" sounds reasonable
> to a C++ programmer, but that doesn't mean it's the clearest thing
> in the world. :)
Nothing changes at the syntactic level.
FOO: while ( $cond ) {
# FOO is now (an alias to) a loop control o
At 10:32 AM 5/8/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: At 09:32 AM 5/8/2001 -0700, Larry Wall wrote:
>: >Perl 6 might not put all the elements of @b on the stack as a temporary
>: >list. Rather, it might just put \@b marked as expandable. (It might
>: >also have to put some kind
At 10:57 AM 5/8/2001 -0700, Peter Scott wrote:
>At 10:32 AM 5/8/01 -0700, Larry Wall wrote:
>>: One of the places I hope to gain some speed is in eliminating flattening
>>: and reconstitution of aggregate variables as much as possible. I'm hoping
>>: to exploit this really heavily to save both the
On Tue, May 08, 2001 at 01:59:47PM -0400, John Porter wrote:
> > > a syntactic loop control iterator object
>
> Why? It sounds reasonable to me
I'm sure a "pure virtual base template class" sounds reasonable
to a C++ programmer, but that doesn't mean it's the clearest thing
in the world. :)
--
John Porter writes:
: Peter Scott wrote:
: > Even if it has a
: > fixed-length prototype, is Perl smart enough to know that it can't be
: > called as an object method, bypassing prototype checking?
:
: Maybe p6 won't have that loophole.
It won't, if the type of the object can be determined at
Simon Cozens writes:
: On Tue, May 08, 2001 at 01:32:24PM -0400, John Porter wrote:
: > a syntactic loop control iterator object
:
: I surely hope you're joking.
It could certainly be argued that anything you can put a label on is an
object by some definition or other. And certainly it turns in
Peter Scott wrote:
> Even if it has a
> fixed-length prototype, is Perl smart enough to know that it can't be
> called as an object method, bypassing prototype checking?
Maybe p6 won't have that loophole.
--
John Porter
Simon Cozens wrote:
> John Porter wrote:
> > a syntactic loop control iterator object
>
> I surely hope you're joking.
Why? It sounds reasonable to me (if not necessarily
desirable). Perl is a highly dynamic language, I
think it could support this.
--
John Porter
At 10:32 AM 5/8/01 -0700, Larry Wall wrote:
>: One of the places I hope to gain some speed is in eliminating flattening
>: and reconstitution of aggregate variables as much as possible. I'm hoping
>: to exploit this really heavily to save both the memory for the flattened
>: lists and the time it
On Tue, May 08, 2001 at 01:32:24PM -0400, John Porter wrote:
> a syntactic loop control iterator object
I surely hope you're joking.
--
I respect faith, but doubt is what gives you an education.
-- Wilson Mizner
Dan Sugalski writes:
: At 09:32 AM 5/8/2001 -0700, Larry Wall wrote:
: >Perl 6 might not put all the elements of @b on the stack as a temporary
: >list. Rather, it might just put \@b marked as expandable. (It might
: >also have to put some kind of copy-on-write lock on @b to keep it from
: >chan
Larry Wall wrote:
> Ordinary "next" methods don't do a goto.
Well, of course, the "next" method of a syntactic
loop control iterator object would not be ordinary. :-)
--
John Porter
: > >is => typing, inheritance, etc.
: > >has => composition, aggregation, etc.
: >
: > True, but those are basic OO concepts, which don't neatly apply to
: > property-lists (a very old Lisp concept that Perl6 is adopting).
Well, you can think of it like that, but I'm actually trying for some
On Tue, May 08, 2001 at 09:44:57AM -0700, Larry Wall wrote:
> there seems to be a shortage of three-humped camels.
No wonder we're short, they're rather careless with them...
The Three-humped Camel:
An advertisement once appeared in a Welsh local paper which
read: 'Last - one three-humped camel.
At 09:32 AM 5/8/2001 -0700, Larry Wall wrote:
>Perl 6 might not put all the elements of @b on the stack as a temporary
>list. Rather, it might just put \@b marked as expandable. (It might
>also have to put some kind of copy-on-write lock on @b to keep it from
>changing out from under, depending
I see nothing about namespacing, e.g. Perl_
Alan Burlison
Nathan Wiger writes:
: First off, before I forget to mention it, nice job on Apoc2 Larry! You are
: the man. I know alot of us on p6l can seem like harsh critics at times, but
: it's only because we love Perl so much. ;-)
We'll have to do something about that. :-)
: Anyways, in addition to the
Peter Scott writes:
: 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 k
Lipscomb, Al writes:
: --_=_NextPart_001_01C0D71B.8F67C8EA
: Content-Type: text/plain;
: charset="iso-8859-1"
:
:
: >
: > $$STDIN # Return one element regardless of context.
: > @$STDIN # Return number of element wanted by context.
: > *$STDIN # Ret
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Please pardon my hyperbole. I don't loathe qw() so badly that I
LW> want to get rid of it. I merely want to put it in the same status
LW> as the other general quote operators that also have a non-general
LW> pair of standard quote
Nathan Wiger writes:
: 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 readl
John Porter writes:
: Pardon me if someone has already suggested this, but...
: Couldn't labels really be (aliases to) iterator objects?
: So that
: next FOO
: really *does* mean
: FOO.next
Ordinary "next" methods don't do a goto.
Larry
Eric Roode writes:
: >And the fact is, I've always loathed qw(), despite the fact that I
: >invented it myself. :-)
: > -- Larry Wall in <[EMAIL PROTECTED]>
:
:
: Well, one person's ugly is another person's joy forever.
:
: Regardless of the aesthetics of q//, qq//, qw//, et al, (a
In a fit of insanity, at 10:14 EDT Tue May 8, I wrote:
>
>9 times out of 100, qw saves a large number of keystrokes. (The
>other 1% of the time, ...
I hope it's obvious that I meant "99 times out of 100"
--
Eric J. Roode
Dan Sugalski writes:
: We'd want an alternative opcode running loop for all this, and it could
: easily enough check times, as could special opcodes. Long-running codes
: could also check at reasonable breakpoints. (Still in trouble with C
: extensions, but that's pretty much a guarantee)
It's
Here's something I promised ages ago, but life got in the way:
first draft of the PDD on all things related to coding: comments,
code structure, naming conventions etc etc. Not as exciting as a Schwartzian
Transform perhaps, but still needs discussion.
I have included comments on bits I'm not sur
At 16:17 May 7, Simon Cozens wrote:
>On Mon, May 07, 2001 at 01:14:12PM -0700, Nathan Wiger wrote:
>> I think Uri's qh() suggestion is the cleanest:
>
>Interesting train of thought, since one of the ideas was that qw() is
>ugly and has to go. (Larry's been saying this for nearly two years now,
>it
80 matches
Mail list logo
