in reply to RFC: Almost a Book

This is definitely an interesting project, as writing an interpreter teaches you a lot about how languages work. However, it seems almost like it's going in the wrong direction. Scheme is a pile of planks and nails, and to get any use of it you have to pound them into a language. Perl, on the other hand, is all sorts of nifty wooden doohickeys designed for common tasks. So your book is doing something like showing how to make boards out of furniture.

It would probably be more useful to write an interpreter or translator that started with all of the built-ins that Perl already has, and added something more. Two examples that come to mind are MJD's Linogram for line drawings, and PDL's PDL::PP, for fast matrix operations. Learning how to extend Perl into other domains and integrate these extensions into the language would both supply interpreter-fu and be extremely useful.

But anyways, I'm just sittin' in the peanut gallery, so who am I to say?

Replies are listed 'Best First'.
Re^2: RFC: Almost a Book
by billh (Pilgrim) on Apr 19, 2006 at 16:36 UTC
    I think you're misunderstanding the primary motivation, which is not to produce something which is useful but something which is comprehensible, in as small a piece of code as possible. I'm perfectly happy with your assertion that scheme is not the most practical of languages for doing real work, but the real attraction of Scheme is that it is internally a thing of great beauty, like a piece of clockwork, and something that with a little effort can be grasped in its entirity.

    A second reason for chosing Scheme was that the proposed "Part II" of the book, on parsing, would make a very clear distinction between the various external syntaxes of languages and a far more conservative core of internal forms, and would point out that in the case of scheme there is little or no difference between the external and the internal form (which is why it's so easy to parse).

    Choosing Perl as the Implementation language was a no-brainer for me because I use it all day every day in any case; and the "Part III" on compilation could justifiably target Parrot, which would be an additional selling point.

[reply]
      Okay, but my take is that there are already a number of well-done "write your own mini-Scheme" books out there (e.g. SICP, Lisp in Small Pieces), and countless homebrew minischeme projects on SourceForge, etc. With a built-in "read" and list-manipulating functions, it's at least as easy to parse and interpret Scheme in Scheme itself as to do it in Perl. Why recapitulate these books in Perl?

      If part 2 supplied an interesting non-scheme-like language with a translation down to part 1's scheme-like one, the book might stand out more. I dunno. I'm not really the target audience for this, so maybe I don't have a good feel for what would be interesting.

[reply]
        > there are already a number of well-done "write your own mini-Scheme" books out there

        Point taken, but a Perl implementation has an advantage over C for understanding an implementation because it's much higher level, and over Scheme because there's no incestuous metacircular evaluation to confuse things.

        Secondly, yes, you hit the nail on the head about syntax because the Parsing section would use the existing evaluator as a target with new, alternative and interesting syntax, certainly better than those "Pratt parsers" that I've seen. Syntax aesthetics is often ignored in hard CS texts.

        Finally the third section on compilation would generate Parrot, making the use of Perl in the other sections doubly relevant, but I said that already.

[reply]
      Oh, and another reason for choosing perl, of course, Is precisely because it has all of those wonderful dohickeys that let me get on with the job in hand and don't get in the way of the explaination.
[reply]

In Section Meditations