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

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Friday September 21, 2007
02:44 PM

Syntactic Complexity and Implementation Time

[ #34516 ]

The complexity of a language’s syntax does matter. As Eric Raymond once wrote, “Robustness is the child of transparency and simplicity”. Do you for example think it’s a coincidence that Perl 6 is still not ready for production after six years of development?

jpersson commenting on a critique of JRuby versus CPython

Common Lisp barely has syntax. Where are all the reliable F/OSS cross-platform CL implementations then? (Hint: volunteer effort is cheap, not necessarily fast.)

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.
    But people hate the notation. Otherwise, it would be the one, true language. Which, it may yet be.
    • Do you think the ease of implementation depends on how much people like the notation more than the simplicity of the syntax? That's an intriguing thought.

      • He may not, but I do.

        The more people like the notation, the more people will be attracted to assisting with the implementation, which should greatly improve the ease of implementation (from the perspective of a project manager at least)...

        The definition of "ease" is highly subjection and subject to misuse though.

        "How long/easy is a piece of string"
  • 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

    • 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