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
> 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
> 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 ca
> 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-speake
> 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
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
> 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 th
> 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 la
> 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
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 fo
> > > 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
> 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"
> 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
> 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
> 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 parsin
> 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
ou
> 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 r
> | 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
> 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
>
> >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
>
> "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, esp
> 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, Malco
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 beari
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 r
> > 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. ;
> 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.
> > 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
> 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 wha
> 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,
C's only virtue, IMHO, is that it's clearly the inverse of
C. But I think the spelling and aural relationship between
C, C, C, and C 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. coul
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 beyo
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,
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?" ;-)
37 matches
Mail list logo
