gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to")


From: Tom Lord
Subject: Re: [Gnu-arch-users] arch roadmap 1 (and "what's tom up to")
Date: Tue, 29 Jun 2004 11:02:58 -0700 (PDT)


       William Dode:

       Could you explain briefly why the others langages doesn't fit ?
       specialy lua wich is an embeddable langage. Maybe the answer
       will be in 3) ?

Lua is awefully close and is an inspriation for Furth. (http://www.lua.org/)

Shriram Krishnamurthi in a talk called "The Swine Before Perl" laid
out a list of 5 "gems" -- great ideas in language design, found in
Scheme, commendable to designers of new little languages.

His slides are at http://ll1.ai.mit.edu/shriram-talk.pdf but I'll
reproduce his list of gems here (with his categories):


    ~ closures                  |
    ~ continuations             | The Crown Jewels

    ~ That stupid parenthetical |
      syntax                    | The
    ~ macros                    | Lesser
    ~ tail calls                | Gems


Lua has closures and tail calls.

Lua lacks continuations and while it appears that they would be easy
to add to the language definition, it also appears that they would
be nearly impossible to add to the implementation in a way that is
both efficient and compatible.

Lua lacks macros and has a "mainstream syntax".  These go together and
are symptoms of a larger problem which is that Lua thinks source code
and data are different things, source to be processed by a compiler,
data to be processed by a running program.  

A lisp-like syntax (even an RPN one like Furth) and lisp-like core
types (lists, symbols, etc) arise in part from a deep commitment to
keep code and data the same: to encourage powerful macro systems
(little compilers); to encourage other forms of automated program
transformation.

You could (conceptually):

        1. start with Lua
        2. modify the VM to support fast continuations
           (probably breaking existing extensions)
        3. toss out the syntax and most of the compiler,
           use lisp-ish s-expressions for everything

and then you'd wind up pretty close to Furth.

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]