Re: pull put (Was: Angle quotes and pointy brackets)
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? ;-)
Re: pull put (Was: Angle quotes and pointy brackets)
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 beyond offending shell heritage. That actively opposes sixty years of computer science terminology setting push and pop in opposition. I'm not objecting to pop, but pull in opposition to push, on the other side of the array.
Re: pull put (Was: Angle quotes and pointy brackets)
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 on, I agree. (A stalled car etc.) It would be nice if the corresponding functions could similarly be opposed without the potential confusion for beginners, but I realize that may not be possible, and your example is at least convincing that it's better than shift/unshift.
Re: pull put (Was: Angle quotes and pointy brackets)
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 standard CS parlance. could be very confusing. There's a possibility of using Cenq and Cdeq for enqueue/dequeue, except that Cdeq == Cpop in standard implementations. So Cenq and Cshift? yeck. 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? Having push and pull operate on opposite ends of an array strikes me as more confusing than even shift. When it comes to adding and removing elements, shouldn't there be semantic opposition for functions that operate on the same end? (I realize that take is already ... taken, for control structures.)
Re: Per-object inheritance in core a red herring?
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 really slow.
Somebody should write an implementation first, and then tackle efficiency.
Something like
sub sub {
my ($self, $method_name, $method ) = @_;
*{ref($self).'::'.$method_name} = $method;
}
for adding object methods would be a good start. I think I'll call it
Class::Object.
Dan
Re: Properties and stricture
I would like to be able to use Perl for serious large-scale industrial-strength object-oriented projects, but the lack of strong compile-time type checking really prevents it, unfortunately. Industrial-strength, as Chip says, is great, but also dangerous for pets and small children.
Re: So, we need a code name...
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 resemblence to some neat stuff. One bummer is the likeness to AMD's Duron. *shrug* Relations are up to you to draw, so read between the lines. Just don't ask why I looked it all up. It is, in fact, a totally unrelated story which has kept me up all night. Connectionist pride. Similar to: 1. Latin dura (Italian, Spanish also): hard, solid, durable. Also Latin durare, last to endure. 2. Dura the circle, where Nebuchadnezzar set up a golden image near Babylon (Daniel 3:1). Still exists, and still bears the ancient name, which is something. The city is Dura in Syria, rebuilt many times over a thousand years, as a military colony by the Seleucids, a caravan city around 100 BC by the Parthians, and a frontier fort in AD 165 by the Romans. Home of the only extant Christian community meeting or assembly house from the 3rd century, earliest example of Christian community religious gathering. 3. Radiodurans, a form of pseudomonas bacterium (pseudomonas are able to use virtually any organic molecule as a source of carbon and of energy). Radiodurans are an extreme environment lifeform, thriving at the cores of swimming-pool nuclear reactors (to the annoyance of plant physicists). This one is long and interesting. 4. The prefix deru-, solid, firm, steadfast. Has variants in Old English, Old Norse, and Greek, Latin, and Sanskrit. Names (Duran): 1. (b. 1350) Jewish philosopher, linguist, and satirist, compelled to Christianity and later resumed Judaic worship. Known for his scholarly writings on Hebrew grammar. 2. (b. 1361) First Spanish Jewish rabbi to be paid a regular salary by the community. Reduced Thirteen Articles of Faith of Moses Maimonides to three essential dogmas. He was a synergist. ;-)
list logs?
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?
Re: So, we need a code name...
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 roasted and eaten like
nuts
I think that's rather descriptive of Perl in general. Its huge, hard
on the outside, soft on the inside, smells really nasty but if you're
brave enough (or dumb enough) to take a bite it tastes wonderful.
I agree. Especially considering the language-independence of the parser
being planned. Besides the meaning, it's a rather cool word all by itself.
Re: So, we need a code name...
You want to name it after a fruit smelling of dead cows and sewer gas? Oy! *I* didn't suggest the Duran name :-) No, that was me. *Your* suggestion was the durian. Can a word association with the band by the same name x 2 really be a bad thing? One hell of a comeback they're had. ;-)
Re: sandboxing
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 Beattie? A nation turns its lonely eyes to you. Oooh-ooh-ooh. Er, a republic.
Re: .NET
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, especially when a solution is proposed as new and innovative, when it usually isn't. Another snippet from the .NET whitepaper: snip Everyone believes the Web will evolve, but for that evolution to be truly empowering for developers, businesses, and consumers, a radical new vision is needed. Microsoft's goal is to provide that vision and the technology to make it a reality. /snip In other words, evolution in and of itself is not empowering. Without the vision[tm], evolution is deempowering.
Re: Curious: - vs .
You're thinking of objects as references and references as akin to pointers, which makes sense because that's how they're implemented in Perl 5. If you think of objects as their own entities, however, or think of references as something other than pointers (in particular, something that doesn't require explicit dereferencing), then using . to access object members is entirely compatible with C. I tried to make this point before, but I don't think people understood what I was getting at. I did. :) Moreover, 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. While I agree with some that we should keep Perl folk happy before making the world happy, this is one syntax quirk which really doesn't help Perl IMO. When method invocation has such a generally-accepted syntax everywhere else, it can only be positive to adopt a similar syntax.
Re: Sane + string concat proposal
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 outside of quotes. Umm.
Re: Sane + string concat proposal
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 is possible. So, what would this do? $user_pass = (getpwuid($))[0] + (getpwuid($))[1]; Your operator is still ambiguous, since you probably want a concat, but have no place for the quotes. The convention needs to consider more than just variables.
Re: Sane + string concat proposal
| 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 should be comfortable with. And the idea that + should be interpreted by the parser as an op, well, doesn't work. At all.
Re: Larry's Apocalypse 1
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 by default now) if and only if perl can tell it's parsing code for a module. (Via the "module" keyword) Actually, the quote in "Apoc1" reads: --- That is, Perl 6 must assume it is being fed Perl 5 code until it knows otherwise. And that implies that we must have some declaration that unambiguously declares the code to be Perl 6. Without throwing more hornets into the nest, I think it's worth considering that by and large, most people using both perl6 and perl5 will opt to differentiate right on the command-line or #!. I know I will. It isn't *that* difficult to keep 2 local interpreters lying around. Or 3; I still have a perl4 somewhere. I understand why lots of people freak when considering that perl6 will be totally different. But I don't. Simple migration is good. Legacy at the cost of innovation is not.
Re: Larry's Apocalypse 1
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 interpret perl5 needs a toggle, be it a package/module declaration, a #! switch, whatever. That is, the syntax will not be compatible. Whether the perl6 interpreter is *able* to 'do' perl5 is not so much the issue as how it will do it. So already you have broken perl5 insomuch as it has to be interpreted *as* perl5. From here on out, it's just a matter of implementation. Do you use a switch, do you use a different interpreter. Does the switch actually just fork another interpreter? I suppose the talk of a ubiquitous "meta-language" which allows you to write perl with whatever syntax you choose would solve this, but I am highly skeptical of anybody's ability to define such a language that would accomodate obfuscated perl5. Imagine how that would look. Yeah, but innovation at the cost of legacy's not a great idea either. Don't forget we have an enourmous legacy base--every single person who programs in perl now. This is probably our last chance for a big language upheaval for quite a while, but that doesn't mean that we're actually going to have that much of one. Well, it is going to be substantial. Again, if we need to differentiate at interpreter startup, regardless of the implementation, it is going to be substantial. Otherwise, perl6 should just be able to know the difference when it encounters small syntactical differences, and we wouldn't be having the conversation.
Re: Larry's Apocalypse 1
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 perl 5 code generally. OK, I follow. So are we resolved on why we need a flag for the interpreter (back to the one liners)?
Re: Larry's Apocalypse 1
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 IO on tehm but one major headache is the extensibility: the scheme part, especially. Check out http://www.w3.org/Addressing/schemes.html for the latest list. Each scheme carries with it own semantics for how the URL should be understood and which methods can be applied on it. So URLs are not literals, they have structure, and only thinking of them as filenames may be too simplistic. But the structure you speak of exists only on the server. A URL as accessor reference doesn't really need to know anything about the opening of that path other than the fact that it is a URL. This renders it pretty useless as a structure to be interpreted *as* a structure as far as the client is concerned. But I agree, if only to not have to configure proxy settings to get 'Configure' to work. :/ So these are actually half-digested-half-baked beans. The order of half-ities shouldn't be given any more thought ... damn, too late.
Re: Larry's Apocalypse 1
if (open(BLAH, "mailto:[EMAIL PROTECTED]")) { ...
Ah yes. You did say "scheme", didn't you?
Well then, consider the PR value. ;-)
Re: Larry's Apocalypse 1
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", "undef" ? ;-)
Re: Larry's Apocalypse 1
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 the basis of micro-perl, etc.) Regardless of the implementation, you are right on. It would be such an enjoyable thing to have a standard "Perl 5.x" lib of meta-syntax definitions that could serve as both parser logic and function mappings. The day you can execute a Perl5 test script successfully within that framework is a cool, cool day.
Re: Larry's Apocalypse 1
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 focus on being
the final "thing", even if everyone believes it will be. This would rob
Jon of future tantrum opportunities.
I was very glad to see Larry address RFC 28 in the way he did; this will
be quoted often in the future, both concerning being "needlessly fearful"
of Perl adopting a different language paradigm, as well as the "essence"
of Perl being context sensitivity ("Perl culture, Perl readability"
threaders take note).
The example suggestion about breaking the @foo -- $foo[] relationship is
a perfect indicator of where he sees this going: breaking some behaviour
to gain consistency in context treatment. I think such "courage" as he
puts it is absolutely worth the benefit. I want to see more paragraphs
like this in future documents; they really give a glimpse into what he
wants to happen.
I agree with what has been said regarding the "package" vs.
"module/class/blah" 5/6 differentiation. Keep it simple. It won't be long
before we (I) scoff at a module starting with "package" the way we (I) do
now with "require cgi_lib.pl;". Kidding.
I think there is much discussion to be had concerning RFC 73, regarding
Larry's suggestion that core functions return objects that are struct
tm's. I'm wondering what Chip thinks about this. Also, I'm wondering if
the intent of the RFC was what Larry describes. References to 48 suggest
list, array, arrayref, hash, and hashref contexts, in addition to scalar
and string. Does Larry feel that all of these are important? I guess we're
not talking about 48, though. :)
Re: Perl culture, perl readabillity
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 languages isn't exactly stop-and-go. All natural languages have evolved from something. Irregularities compound. The exception is word polysemy, which tends to increase with the evolution of the language. Whether ambiguous contexts are irregular is debatable, however.
Re: Perl culture, perl readabillity
Anyway, I'm trying to argue lingustics in a perl ML, with zero training. Is there a linguist in the house? (Hm, didn't Larry go to Japan to learn a language with wierd word-order?) (What's up with Larry, anyway? Any preliminary RFC responces?) Everyone a linguist. :) In any case, I think the summary on this is that Perl undoubtedly reflects English syntaxes in many ways, and not in others. We aren't writing a natural language, anyhow. The fact is that Perl does allow syntactic flexibility absent from nearly all other programming languages. That should be enough for everyone with a programming language. My point has simply been that "readability" for non-English speakers should not be more of a problem with Perl than any other code, and is, in fact, less so. At the start of this thread, I mentioned Damian's Perligata. You begin to see the method behind the madness (sorry Damian). Our conversation isn't unique, or isolated. See Umberto Eco's "The Search for the Perfect Language" for the same conversation, repeated by every thinking person who lived. We aren't as clever as we'd like to think. Well, Perligata is ...
Re: Perl culture, perl readabillity
I think Simon meant '[EMAIL PROTECTED]', but isn't interested enough to correct himself. :)
Re: Perl culture, perl readabillity
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 mean, I know Nat tolerates it, but it's completely inappropriate. Just send him back to comp.lang.python OK, Otto, go back to comp.lang.python. Or, discuss your concerns about Perl on [EMAIL PROTECTED], where a few folks might just help you understand the method behind the madness.
Re: Perl culture, perl readabillity
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 some beautifully
readable programs in Perl. You can write some horrible programs in Perl too.
Try it. Take an algorithm and write it in as many ways as you can. Try and
make it as ugly or as beautiful as possible - the fact is, you *can* choose
how readable you want it to be.b
The side effect of flexible op behaviour and some ambiguity in syntax is
the ability to write how you want to write. The interesting part is that
well-written ("readable") Perl would be considered by a non-programmer to
be much more intelligible than, say, what a programmer would call
"readable" C, since they can actually deduct the function without
understanding the language. ("You mean I can write, 'print values %hash',
and it will work?") You *can* write programs in Perl which are
significantly more readable than their equivalents in other languages,
because of this behaviour.
When programmers say "readable", they usually mean to say "statically
consistent", preferring a language with no contextually-conditional
behaviour. The result is an inability to write code that *is*
unreadable, syntax that is not idiomatic, blah blah blah. The result isn't
Perl, or Perl 6.
As for the English influence, you're welcome to identify ways that the
syntax could be extended or tightened to be less so. That's the intent of
the mailing list. But please, no more Latin ... I like positional
dependency. :)
Re: Perl culture, perl readabillity
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 would say:
I must the god walk. (Subject modal-verb direct-object action-verb.)
(Yes, I am a dislexic, agnostic insomniac.)
"The god I must walk", "walk the god I must", etc. They aren't immediately
familiar, but they are grammatical.
This is exactly analgous to the perl form (english-perl):
sort { f(a) = f(b) } @list; (Action-verb subordanate-verb (adverbal form)
direct-object.) OTOH, for a german-speaker, sort @list {f(a) = f(b)}
would be more natural (Action-verb direct-object subordanate-verb
(infinitive form)). (Note, BTW, that gramaticly, perl statements always
have a implied subject of "Intepreter" [0]. (Also note that in english, the
adverbal form of a verb normaly ends with ly, in german it ends with en, and
in perl is surrounded by curly-braces.))
You're saying that it would be more natural for an English speaker to say,
"Sort numerically this list", as opposed to "sort this list numerically"?
I disagree; the latter is more natural for English speakers. I don't see
this as evidence of "English Perl". You could also analogize your sort
example as:
sort { f(a) = f(b) } @list
"Apply this sort to this list"
The same holds true for at least Spanish and French. I don't know German.
Consider 'print':
print FILEHANDLE data;
This isn't the most intuitive form for English speakers, who would tend to
say:
"Print this data to this filehandle."
Rather than:
"Print to this filehandle this data.
Then again, if you think of objects (in the OO sense) as doing things, then
they normaly are the subject, and _not_ the indirect-object (in the english
sense).
Well, then don't think of them that way. :) Perl objects of the class
variety are direct objects, indirect objects, subjects, and even verbs if
$_[0] is discarded in methods. It's true they are most commonly subjects,
but can be used as most anything. Isn't that great?
Re: Perl culture, perl readabillity
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 learned about human languages in school. That ape stuff got old real quick. On another note, perhaps we should set up something where longer names for some special variables are built in. How's $}PERLVERSION sound? Yeah, that's a good idea. Not. Perl is hard to compare with any other languages except those it borrowed heavily from or those that borrowed heavily from it. I don't think Perl has borrowed much from Pascal (besides maybe the " : " syntax for attributes) so Perl and Pascal are hard to compare. Uh .. So the basic question is, readability or usability? I say usability. I say ":ability".
Re: Schwartzian Transform
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 understand the beauty of compact Perl. I'd hate to see that relegated to the "how-we-used-to-do-it" column in the name of making it easier. IMO the very quest for a name would be reason enough to not do it. "map_sort_map"? That begs the question. And since Randal asks that it not be named after him ... (I heard he filed a trademark on Schwartzian, so that's out. :) On 22 Mar 2001, Randal L. Schwartz wrote: "Brent" == Brent Dax [EMAIL PROTECTED] writes: Brent @s = schwartzian( Please, if we're going to add an operator, let's not call it schwartzian! I have enough trouble already telling people how to spell my name. :) Maybe I should have a kid named "Ian", so I can see on a roster some day: Schwartz,Ian :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Schwartzian Transform
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 the keys in order, and the subsequent comparisons. Imagine the perldoc entry.
