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.

Syntactic Complexity and Implementation Time 8 Comments More | Login | Reply /

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

    The point here is that Lisp barely has any syntax. Common Lisp is a Lisp, but that doesn't mean that the 'barely any syntax' attribute necessarily applies to it. Common Lisp takes Lisp, and adds a lot of features, many of which layer on top of the trivial surface syntax. So, while it appears that Common Lisp programs are nothing more than well-crafted trees of cons cells, they are in fact much more syntactically rich. Consider what happens when you add vectors, hashes, macros, MOP, generic functions, and format strings. The only thing the surface syntax simplifies is the Common Lisp reader function, not the entirety of the implementation.

    Nevertheless, you asked for a list of cross platform common lisp implementations, and wikipedia lists a few [wikipedia.org]. Specifically, I draw your attention to SBCL, CMUCL, CLisp, GCL, ECL, OpenMCL, and Armed Bear Common Lisp. The number of open source implementations of Common Lisp is actually larger than the list of commercial implementations. We can quibble about their robustness, cross-platform-ness or whatnot, but the fact is that there are multiple open source, cross platform, somewhat interchangeable implementations to choose from.

    Again, Common Lisp's simple surface syntax simply obscures the issue. No implementation of Common Lisp is ideal, which is why there are multiple implementations and no single canonical implementation. As I said, Common Lisp appears to have a simple syntax, but it doesn't, so it really shouldn't be under discussion anyway.

    A better example for your critique would be Scheme, since there are multiple open source, robust, and cross platform [wikipedia.org] implementations of Scheme. Interestingly, nearly all Scheme implementations are open source. Most are conformant to some community standard or another, usually R5RS, but also R4RS for some of the older projects.

    Add all this up, and jpersson's comment does in fact hold up, even if it isn't supported by esr's snarky remark. Languages with simpler syntax are easier to implement, easier to re-implement, and easier to build to a robust state. This helps explain why there are multiple implementations of Common Lisp, Scheme, Tcl, Ruby, Python, Make, various XML parsers, XSLT, C and so on, many of which are robust enough for real world use. This also helps explain why there is effectively only one implementation of languages like Perl, TeX, and perhaps Ada -- these languages are so quirky that it's hard enough to build one complete, robust, open source implementation that no one really wants to build another. (Even pumpkings assert that Only Perl Can Parse Perl, with all seriousness.)

    If Perl6 were less syntactically rich, there would be more implementations of it. Decades of industry experience back up this assertion, snarky quotes and false analogies aside. But that's Larry's decision to make, and he's comfortable with syntactic richness, and all of the tradeoffs it brings. And that should be enough for us.

    • Consider what happens when you add vectors, hashes, macros, MOP, generic functions, and format strings. The only thing the surface syntax simplifies is the Common Lisp reader function, not the entirety of the implementation.

      I think that was exactly chromatic’s point: whether or not the surface syntax is complex is not what makes the entirety of the implementation big and complex. Unlike the Schemes you mention, Perl 6 puts the entirety of the implementation (or nearly) under the syntax umbrella. T

      • The fact that only perl can parse Perl is not because Perl’s syntax is so quirky that implementing a parser would be painfully difficult. It’s because you cannot parse Perl without executing it.

        So only perl can execute Perl, then? Why is that?

        • That is because the language is big and quirky in all sorts of ways, obvious and obscure alike – much more so than just the surface syntax itself.

          But we were talking about surface syntax, so that is beside the point.

    • 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

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.