NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
False Analogy Alert! (Score:2)
chromatic, I understand your frustration with jpersson's comparison, but that does not make your false analogy correct.
If we start with the premise that "sharp objects are cheap and easy to fabricate", it's a huge leap to ask "where are all of the disposable samurai swords [wikipedia.org]?" In fact, there are very many "disposable sharp objects", but we call them "razor blades", "box cutters" and "toothpicks".
Th
Re: (Score:1)
Aristotle expanded on what I meant, but I still want to push the point of CL. What does it take to write a CL reasonably competitive with SBCL? You have to compete with its performance (which likely means targeting architectures directly), or portability, or library support, or getting at least one of those an order of magnitude righter than SBCL. None of those have anything to do with
Re: (Score:2)
What does it take to write a CL reasonably competitive with SBCL?
A whole heck of a lot. First, you need to be compliant with CLTL2 [cmu.edu], which clocks in at over 1,000 pages. Then, if you want to make an ANSI Common Lisp implementation, there's additional work to implement the diffs [tech.coop] between the two specs.
By comparison, the original Lisp specification was 2 pages, the original Scheme specification wasn't much bigger. R4RS and R5RS both clock in at about 50 pages.
All of this gets back to the original point of contention:
Common Lisp barely has syntax.
That assertion is simply untrue. Common Lisp h
Re:False Analogy Alert! (Score:1)
Perhaps we mean different things by syntax. The way I understood the original comment, syntax means "Things you need to write a parser for." For CL, that's basically identifying applications, atoms, conses, and symbols, while providing access to the parser for macros and allowing (optionally) a couple of special forms (I think you can provide everything you need if only
evalandcondare special forms, but I haven't tried to write a Lisp withoutevalas a special form). That makes for a reasonably simple parser. The code can get more complex if you rewrite the AST into a different execution form (or compile it instead of interpreting it), but parsing Lisp code is almost trivial.If you mean something different by "syntax", then I see where we're talking past each other.
Reply to This
Parent
Re: (Score:2)
Perhaps we mean different things by syntax. The way I understood the original comment, syntax means "Things you need to write a parser for."
No, we mean the same thing. Lisp is all cons cells and lambdas. It's a small language, which is why it can be defined in one page of code [technologyreview.com]. (I said "two pages of code" before, because Technology Review originally published an annotated version as a centerfold spread).
Common Lisp is not that language.
Common Lisp, for one example, supports macros. Macros are read by the reader function (the parser), and change its behavior. Common Lisp also supports modules, which can export macros, and also change