"Kubilay" <···········@gmail.com> writes:
>
> Question 1: How powerful are the macros? Lisp is supposed to be a
> "programmable language" and as far as I know this feature is provided
> by macros, right? It is also said that one can hammer the Lisp so that
> he can reach a "new" language which is tailored to his needs by using
> macros. So, how far can we extend? Should this language's syntax be
> same of Lisp's? Oh no, I really love Lisp's syntax :) But I just want
> to learn. For example, by using macros, can I develop a "new" language
> called "Lisp++" based upon Lisp but also seems like just as C or Ruby?
>
> I mean something like this:
>
> In Lisp: (setf x (+ 4 5))
>
> In Lisp++: x = 4 + 5 ;
Well, there are really two different questions contained in your
question number one.
The first regards macros, which are very powerful in Lisp. They are
clearly Turing complete, since macros are really lisp functions that
take some source code in (as a lisp structure) and emit other source
code. Since it is a lisp function, arbitrary transformations of the
code can be done. AI work on knowledge representation (KR) used macros
to enable the creation of special KR languages which introduced entirely
new forms like
(defconcept ...)
(defrelation ...)
(assert (....))
(retrieve (?x ?y) (and (c ?x) (r ?x ?y) (s ?x 30)))
where there was a tremendous amount of computation behind the expansion
and operation of the individual parts. In addition to the computational
power that is available to the macro writer, you also get the benefit
that the resulting forms integrate seemlessly (in a syntactic sense)
with the existing language. That provides a nice uniformity and is why
the use of such extended problem-specific languages are used
extensively. Unlike, say, adding SQL to a C++ program, where you pretty
much have to stuff the code into a string, rather than just writing it,
a Lisp-like approach to database access would be based on using Lisp
syntax for the database operators (which could be derived from SQL).
The second part of your question and the only part that you illustrate
in your example is purely about syntactic transformation. It misses the
entire point about using the power to really define a NEW language with
higher level constructs rather than to just modify the syntax of the
language while keeping its power constant.
Modifying the syntax away from the Lisp standard is not something that
can be done with macros, because macros only transform code (in the form
of lisp data structures -- specifically lists). They only operate after
the reading has turned character sequences into data structure. You can
modify the reading process, but that would require implementing your own
parser to transform the surface syntax into lisp structures that would
then be manipulated by macros.
This could be done, but it would also mean that any extension you make
to your language (new definition forms, etc.) require two bits of
updating to make happen. A parser extension to handle the new form, and
a code generation extension to give the new form semantics.
The lisp approach doesn't try to introduce different syntactic forms,
but rather has the new language constructs conform to the existing, very
simple syntax. It is the uniformity and simplicity of the syntax that
allows one to not need to change it in order to integrate new features.
Instead, you can concentrate all of your time and energy on implementing
the actual semantics of your language extensions instead of splitting
your effort between the semantics and the surface syntax processing.
--
Thomas A. Russ, USC/Information Sciences Institute
In article <···············@sevak.isi.edu>,
Thomas A. Russ <···@sevak.isi.edu> wrote:
> [S-expression syntax] provides a nice uniformity and is why the use of
> such extended problem-specific languages are used extensively.
> Unlike, say, adding SQL to a C++ program, where you pretty much have
> to stuff the code into a string, rather than just writing it, a
> Lisp-like approach to database access would be based on using Lisp
> syntax for the database operators (which could be derived from SQL).
Sorry for raising this zombie thread, but I felt the need to mention the
/other/ way to put SQL into your C/C++ program: Embedded SQL!
http://www-db.stanford.edu/~ullman/fcdb/oracle/or-proc.html
Look upon its distustingness and dispair! (or laugh...)
-bcd
--
*** Brian Downing <bdowning at lavos dot net>