If I went with get, the opposite would be unget for both historical
and huffmaniacal reasons.
But get has too strong a class accessor connotation in most OO.
unpull? ;-)
If there's a willingness to rename shift/unshift, why not consider
going a bit further (and offend shell heritage) to note that pull/put
aren't really linguistically opposed either (unlike push/pull). Why
not
rename pop to pull, and use something like put/take for shift/unshift?
That goes way
It makes good sense to me -- if we're trying to move a piano from you
to
me then either you can push or your end or I can pull on my end: we're
operating on different ends of it, but the effect in both cases is
moving in one direction.
As a mnemonic for remembering which side push/pull operate
Cunshift's only virtue, IMHO, is that it's clearly the inverse of
Cshift. But I think the spelling and aural relationship between
Cpush, Cpop, Cpull, and Cput is clear enough to negate that.
But then, I'm a little biased.
Except that push and pull are logical opposites linguistically, but
not in
The debugger API PDD that I submitted a couple of days ago suggested that
we incorporate a profiler into the core. What do people think of this
idea?
I think that with a clean API, many third-party profilers could and would
be created. I am skeptical of the value of putting it in the core,
I wonder how long (less than a year?) it will be until people are writing
computer languages that know enough about context to select a parsing that
Makes Sense when faced with an ambiguous construction.
Not long. My Linguana talk/paper @ TPC treats (in part) a natural language
programming
Sure, program XSLT in XML. I guess that makes about as much sense as XSLT
is ever going to. My question is, if you think programming Perl in XML is
such a good idea, why not do it?
program XSLT in XML? What does that mean? Have you used XSLT? Do you
understand what it is and what it
Having it in the core, in C[++], would be that much more efficient,
and that much less of a hack. Maybe the tradeoff is that it
wouldn't work. :-)
Everyone's making these assumptions, WHY WON'T ANYONE LOOK AT
CLASS::OBJECT?!
It might not work, Schwern. And even if it did, it might be
For your collective amuse() abuse() dismiss() I humbly submit:
duran (or derivatives)
Aside from conjuring images of reflex, rio, and maybe Barbarella
for a select few, the word occurs in some interesting contexts. It means
little aside from it being a last name, a city name, and bearing
Logs on archive.develooper.com for p6l and p5p haven't been written to
since 4/27. I assume somebody is already looking at it, or updates are
scheduled for longer periods than before?
durian
n 1: tree of southeastern Asia having edible oval fruit with a
hard spiny rind [syn: {durion}, {durian tree}, {Durio
zibethinus}]
2: huge fruit native to southeastern Asia `smelling like Hell
and tasting like Heaven'; seeds are
The biggest problem I have with sandboxing is that to do it right is
apparently difficult, judging by the number of people that get it wrong. We
need to rope in a security expert, I think, for the design.
I don't suppose we have one in the house somewhere?
Where have you gone, Malcolm
Don't Let Architecture Astronauts Scare You
http://joel.editthispage.com/stories/storyReader$320
This is a really good article. The quotes from MS and Sun whitepapers are
living proof that rarely are superior technical means being espoused.
Superior sales are the more likely culprit,
the idea of a dereference operator dumbfounds lots
of folks. What's an object got to do with a reference, much less a
pointer? A p5 object is very confusing to others for this reason, and so
is the syntax.
So you want a method invocation syntax that doesn't remind people of
references.
If, instead, you wrote:
$me = $name + getpwuid($);
You would get numeric addition. Always. In this way, you maintain a
reliable semantic separation of string concat and numeric addition,
while gaining a syntax that is similar to other HLL's. Having $var
expand $var is the reason this
The only reason you'd have to use the op form of a string concat is when
you have to add stuff in that isn't evaluated inside quotes, like funcs.
That doesn't make sense. Your proposal was to cause quotes to force concat
context, but here you say the op is only useful when evaluating stuff
| Under what I originally posted:
|
|$a += $b;# string
|$a += $b; # numeric
You still haven't given a good explanation of
$a += sub();# is it a string or a number?
The quotes don't work. Anything but the most basic statement introduces
way more ambiguity than we
This one here's been bugging me for a bit. Larry never said that perl 6
would assume its input code was perl 5. Perl 6 will always assume its input
is perl 6. The said (and I'm still trying to dig up the quote) is that
we'll be enabling warnings and strict by default (as opposed to the off
Still, I'll be really, *really* surprised if most perl code require any
rewriting to run under perl 6. TomC's got quite a cache of old perl code,
and I've got some mildly hairy perl 5 code that I want perl 6 to eat
without complaint.
OK. But by the current thread, this ability of perl6 to
There won't be any magic toggles to make typeglobs come back if they go
away, or anything of that sort. Default behaviours like warning and
strictness may vary depending on whether perl thinks it's parsing a module
specifically written for perl 6 or not, but that's a far cry from parsing
It might even mean that we can have a URL literal type,
I trust that you will think long and hard about that.
Agreed. Saying "URL literal type" is rather bold since "URL" is an
open-ended story. It is certainly nice to think of them as opaque
filenames for "opening" them and doing
if (open(BLAH, "mailto:[EMAIL PROTECTED]")) { ...
Ah yes. You did say "scheme", didn't you?
Well then, consider the PR value. ;-)
if (open(BLAH,":URL","mailto:[EMAIL PROTECTED]")) { ...
Now PerlIO/URL.pm has to know the semantics of /^mailto:/.
If it does it can do DNS lookup for MX record for north.pole and
presumably fail and return undef.
Oops sorry that is perl5 ;-)
Which part? "Presumably", "fail",
All I could think was, "good thing the 3rd Camel came out before Larry
used it to classify RFCs." :)
I am glad RFC 141 was rejected, even if Larry claims it was for
entertainment value. For the same reason people feel the need to explain
the use of "apocalypse", the design of Perl 6 should not
And what would be a better way of testing this out than being able to
make perl6 parse and run perl5 code correctly? (and I think that a key component
ways of making this workable would be to promote a descendent of
Parse::RecDescent to be the mechanism that parses perl for *real* and is
In my experience of Japanese (and other languages) it's quite the opposite.
Speakers get lazy. They cut corners. They omit things. They corrupt verb
forms. Latin was pretty regular; languages derived from it aren't.
Simon doesn't know anything about Japanese, though. ;)
The evolution of
I think Simon meant '[EMAIL PROTECTED]', but isn't interested enough to
correct himself. :)
Uh, have you followed this thread? It's nothing but another perlbashing
session by a verbosity monger who can't handle $.
Well, you can bash him back in perl6, or continue the conversation on
advocacy. Up to you.
Excuse me, but why would you send a perlbasher to the perl advocacy
list. I
On Fri, Mar 23, 2001 at 11:34:41PM +0100, Otto Wyss wrote:
- Make readability your main objective. Readability is possibly the
weakest part of Perl.
There's nothing fundamentally about Perl that makes it unreadable. Seriously.
Perl doesn't write unreadable Perl, people do. You can write
Hmm. I just relized what he's talking about. As an example, most nonsimple
statements (IE past-tense, ones with modal and action verbs, etc) end in the
verb. For example, an english-speaker would say:
I must walk the god. (Subject modal-verb action-verb direct-object.)
A german-speaker
The reward? English-speaking children learn what is arguably the most
flexible and expressive spoken language in the world.
Oh good hell.
Yup. Remember, Larry Wall is a linguist by training--he learned in school
about human languages. He applied this knowledge to Perl.
I wish I had
Could someone summarize the arguments for such an operator? Doing so, to
me, seems to subtrack from the scripting domain something which belongs
there. Teaching the transform in classes is a wonderful way to both
illustrate the power of Perl's map, and more importantly, help programmers
this would have to be a proper module and not a builtin op. there is no
reason to make this built in.
This was essentially my point with regards to naming this op
"map_sort_map". Just explaining the function of the op negates its
usefulness *as* an op, because of the complexity of extracting
33 matches
Mail list logo
