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]> 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.
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: 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
> 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
> 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: 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: 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
> > > 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
> 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: 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
> 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
> | 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: 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: Curious: -> vs .
> >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
an-object-is-a-reference-which-means-I-can-poke-and-prod-it-and-embed-it-etc.
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: .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: 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: 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: 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: pull & put (Was: Angle quotes and pointy brackets)
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. could be very confusing. There's a possibility of using C and C for enqueue/dequeue, except that C == C in standard implementations. So C and C? 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: 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)
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: 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: 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: http://www.ora.com/news/vhll_1299.html
> > 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. Dan
Re: reparsing the ambiguous
> 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. :-) Dan
Re: as long as we are discussing 'nice to have's...
> 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, 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.
