Re: pull put (Was: Angle quotes and pointy brackets)

2004-12-06 Thread Dan Brian
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)

2004-12-05 Thread Dan Brian
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 
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)

2004-12-05 Thread Dan Brian
It makes good sense to me -- if we're trying to move a piano from you 
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)

2004-12-04 Thread Dan Brian
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: as long as we are discussing 'nice to have's...

2001-07-21 Thread Dan Brian

 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

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, when a
well-designed API would exist specifically with the end of getting some of
that work out of the porter's pockets, and instead allow the World to
develop their own, much as it currently happens with Java.

Re: reparsing the ambiguous

2001-07-10 Thread Dan Brian

 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 language, taking sense ambiguity into account. Not terribly
sophisticated, and requiring gobs of statistical context data to work. But
it knows whether 'open' directs a file, URL, or network connection. It
wouldn't be (too) difficult to introduce context-dependent treatment of
variables. I doubt anyone is interested in downloading several hundred MB
of disambiguation statistics with a language distribution, however. :-)



2001-07-09 Thread Dan Brian

  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 does? It makes quite a bit of sense for
those performing regular conversions from a single data set. (No, these
questions aren't directed to Adam. :-) As Adam points out, a source filter
that takes XML and puts it through an XSL sheet to output eval-ready Perl
would be very simple.

 What's your question?  XML Editors are not the limiting factor
 preventing XML-based programming languages; that argument doesn't
 stand up in the face of XSLT adoption.  The dubious value of those
 beneifits (and the re-engineering cost) are the true limiting factors.

Correct. The benefit is not as obvious as some seem to think. If the goal
is format consistency, then what is gained by format consistency? It
hardly means that you could translate one language to another, or have
close interrelations between functional elements within your DTDs. If that
were the case, we wouldn't have different programming languages in the
first place.


Re: Per-object inheritance in core a red herring?

2001-06-30 Thread Dan Brian

  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

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 


Re: So, we need a code name...

2001-05-06 Thread Dan Brian

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?

2001-05-06 Thread Dan Brian

Logs on 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...

2001-05-06 Thread Dan Brian

n 1: tree of southeastern Asia having edible oval fruit with a
 hard spiny rind [syn: {durion}, {durian tree}, {Durio
2: huge fruit native to southeastern Asia `smelling like Hell
   and tasting like Heaven'; seeds are roasted and eaten like
 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: sandboxing

2001-05-03 Thread Dan Brian

 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

2001-05-02 Thread Dan Brian

 Don't Let Architecture Astronauts Scare You$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:

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.

In other words, evolution in and of itself is not empowering. Without the
vision[tm], evolution is deempowering. 

Re: Curious: - vs .

2001-04-26 Thread Dan Brian

 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. OK. But why does it have to be the dot? It is already taken.
 Sorry. Use an operator that doesn't exist yet in Perl. For example, old
 style VB used ! to connect objects and their properties:
   $object!method(foo, bar);

It doesn't have to be the dot. But the plain fact is that the dot is
generally recognized in this way; why is making Perl syntax more
recognized a bad thing? If what we're after is making Perl better, then
one of the primary improvements should be making objects more readable for
the multi-language programmer. I'm really not against '-', but then
again, I *like* that
Even so, I recognize that it doesn't make Perl more readable, especially
when glob syntax is used to manipulate the reference table.

A traditionally negating symbol ('!') is the last character I would want
to see. As for VB  ;)

Re: Sane + string concat proposal

2001-04-24 Thread Dan Brian

 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

2001-04-24 Thread Dan Brian

 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

2001-04-24 Thread Dan Brian

 | 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

Re: Larry's Apocalypse 1

2001-04-09 Thread Dan Brian

 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

2001-04-09 Thread Dan Brian

 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

2001-04-09 Thread Dan Brian

 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

2001-04-06 Thread Dan Brian

   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 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

2001-04-06 Thread Dan Brian

 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

2001-04-06 Thread Dan Brian

  if (open(BLAH,":URL","mailto:[EMAIL PROTECTED]")) { ...
 Now PerlIO/ 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

2001-04-05 Thread Dan Brian

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;". 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: Larry's Apocalypse 1

2001-04-05 Thread Dan Brian

 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: Perl culture, perl readabillity

2001-04-03 Thread Dan Brian

 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,

Re: Perl culture, perl readabillity

2001-03-27 Thread Dan Brian

I think Simon meant '[EMAIL PROTECTED]', but isn't interested enough to
correct himself. :)

Re: Perl culture, perl readabillity

2001-03-27 Thread Dan Brian

 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

2001-03-26 Thread Dan Brian

 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

2001-03-26 Thread Dan Brian

 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

  "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

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

2001-03-26 Thread Dan Brian

 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

2001-03-22 Thread Dan Brian

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:
 Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
 See for onsite and open-enrollment Perl training!

Re: Schwartzian Transform

2001-03-22 Thread Dan Brian

 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.