[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jun 18 21:48:49 1994 
Subject:Pop forms and syntax extension in Prolog and Dylan 
From:Luc Beaudoin 
Volume-ID:940618.01 

Found this in comp.lang.dylan. Copying it here case anyone is interested.

(BTW, it's a shame that Apple and others will make millions implementing
Dylan on PCs, while Poplog Pop-11 isn't available on standard Windows
PCs and Macs (without UNIX). More on that later. Sounds to me like folks
at Integral Solutions aren't thinking BIG. I once heard the argument that
there really isn't a big demand for a dynamic OOP system on PCs, but
the great interest in Dylan seems to contradict that.)

------------------COPIED NEWS POSTING FOLLOWS-----
Article: 2180 in comp.lang.dylan
Newsgroups: comp.lang.dylan
Lines: 42
References: Scott McKay's message of Thu, 9 Jun 94 07:52:31 EDT         <22309.9406091607@subnode.aiai.ed.ac.uk> <LOU.94Jun10121529@atanasoff.rutgers.edu>
Date: 15 Jun 1994 17:57:39 +1000
Organization: Comp Sci, RMIT, Melbourne, Australia
Subject: Re: Apple's Dylan environment and Lisp-like syntax
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)

lou@cs.rutgers.edu (Lou Steinberg) writes:
>Another model for extensible syntax is Prolog - one can define new
>operators by specifying the token that represents the operator, and
>its precedence.  As far as I know Prolog typically does not provide a
>general source-to-source translation facility invoked by such new
>operators, but one could certainly imagine such a thing.

(Edinburgh) Prolog does let you give words operator properties, but
that *only* affects the equivalent of "READ", not a code walker.
Operators in Prolog are *data*.  For example,
        X is (Y+1)/Z
and     is(X, /(+(Y,1),Z)
are read as exactly the same data structures (this one happens to have
an interpretation as code, but it need not be so interpreted).

The *real* way to extend Prolog "syntax" is via the general source-to-
source translation facility:  term_expansion/2.  Edinburgh-compatible
Prologs have a read-compile loop that looks something like
        loop
            read a term
            feed it to expand_term
            exit loop if the result is 'end_of_file'
            otherwise compile (or assert, or whatever) the result
        end loop
where expand_term is a built-in operation that first calls a
user-defined "hook" term_expansion/2 to rewrite the entire top-level
form.  Think of it as macro-expand, where the code-walking is not
automatic, so if you want subforms expanded you have to program the
code-walker yourself (using the 'predicate_property' meta-data--if you
are lucky enough to have it--to tell you which arguments of what forms
are code).

Note that this user-defined source transformation hook applies _after_
operator parsing, so it cannot tell the difference between forms that
used operators and forms that didn't.

Someone should bring up the Pop "forms" facility.  That provided macros
in a high level Algol-syntax Lisp-data language that were quite easy to
use.  Someone should also mention CGOL.
--
30 million of Australia's 140 million sheep
suffer from some form of baldness.  -- Weekly Times.
--
--
Luc Beaudoin                          |  School of Computer Science
E-mail: L.P.Beaudoin@cs.bham.ac.uk    |  University of Birmingham
beaudoin@mach00.scs.carleton.ca       |  Birmingham B15 2TT, UK