Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Common Lisp barely has syntax. Where are all the reliable F/OSS cross-platform CL implementations then?

    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

    • Languages with simpler syntax are easier to implement, easier to re-implement, and easier to build to a robust state.

      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

      • 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

        • Common Lisp has plenty of syntax. It's just that its syntax is quite regular and appears simple on the surface.

          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 eval and cond are spec

          • 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 the nature of the parser. Common Lisp also supports both dynamic and lexical binding (depending on the context and usage), which means that a local macro can override a previous definition of a macro of the same name in some situations.

            Common Lisp also supports optional static type declarations, which, strictly speaking, a parser could ignore, but realistically speaking, the parser should understand to some degree. If nothing else, the presence of optional constructs like these only serves to complicate the parser.

            Common Lisp also supports a rich set of data structures, like vectors, bit vectors and hashes:

            ;; Vectors
            * (vector 1 2 3)

            #(1 2 3)
            * #(4 5 6)

            #(4 5 6)

            ;; Bit Vectors
            * #*1101

            #*1101

            Note that the reader syntax #(1 2 3) creates a vector and #*1101 creates a bit vector, both specific data structures that generally use an optimized representation and not stored as a simple set of atoms and cons cells. Note that these values are not atoms, strings or cons cells, and the reader is required to recognize #(...) as a vector and #*... as a bit string. I don't remember off the top of my head what other reader syntaxes a Common Lisp reader must support, but I seem to remember that the reader is required to allow hooks to recognize new user-defined constructs. So a reader isn't required to understand a construct like #regex{...}, but IIRC, it is required to allow you to plug in code to recognize that construct. Which, again, complicates the requirements of a Common Lisp parser.

            Hash tables fall into a similar category, but you could argue that functions like (make-hash-table) doesn't require special knowledge in the parser, but you could also argue that an expression like (setf (gethash c 'color) red), can impact the parser, because setf requires a lookup to find the "setf function [cmu.edu]" to invoke to perform the update. A friendly Lisp parser would tell you when you're trying to invoke setf on a value known not to have a corresponding setf-function.

            I'll grant you that forms like make-hash-table setf-functions don't necessarily require support from the parser, but reader syntax like #(1 2 3) and #*1101 do, and macros certainly do.

            I think you can provide everything you need if only eval and cond are special forms, but I haven't tried to write a Lisp without eval as a special form. That makes for a reasonably simple parser.

            See, this proves my point. You're conflating "Lisp" with "Common Lisp", and casting aspersions on Common Lisp for not being more like McCarthy's one page of code.

            A simple Lisp, like Scheme, has a very small number of special forms. Scheme uses 13 [federated.com]: if, cond, case, and, or, let, letrec, let*, quote, quasiquote and lambda. If your Scheme supports macros, there's also define-syntax, which supports the creation of more special forms. Many of those aren't strictly necessary, and could be reduced to about 4 or 5 if memory serves (lambda, cond, quote and let, but don't hold me to that list), and still be a substantially similar language.

            As proof that Common Lisp is not a simple lisp, consider the 24 [cmu.edu] special forms that a Common Lisp implementation supports at a minimum. This ignores macros, additional reader syntax for things like vectors, and issues like support for setf-functions, among other things.

            One of the nice things about Lisp, though, is that really heinous forms like loop don't need parser support. They complicate the language from a user's perspective, but not the perspective of the programmer writing the parser (just the perspective of the programmer writing the standard library functions). You're talking about the Lisp parser, so I won't go down that path. :-)

            parsing Lisp code is almost trivial.

            True, for certain definitions of "Lisp", that generally exclude Common Lisp. :-)