I recently started looking at Lisp/Scheme. Once or twice I came
accross M-Expressions. From what I understood, m-expressions could be
used to define new syntax...first of all is this correct? Basically
I'd like to develop my own language with c/c++ like syntax...but I
would like to use lisp/scheme in the back. Any way, I have found no
tutorial that mentions m-expressions. Is it now obsolete? Any
pointers as to where I can find more information about it? Thanks.
-Falcon
It's possible to define your own syntax with macros. But by the time
you're skilled enough at Lisp to do that, you know why it's not a good
idea.
One person who would disagree with me is the author of Gambit Scheme,
which comes with an infix extension language called "Six," which looks
like C and is translated by the reader into Scheme in a
straightforward, well-documented way - apparently exactly what you're
talking about. I've never heard of this language outside of the Gambit
manual, don't know if anybody uses it, and don't really know what the
rationale for it is, but it's there as an example if you're interested.
falcon wrote:
> I recently started looking at Lisp/Scheme. Once or twice I came
> accross M-Expressions. From what I understood, m-expressions could be
> used to define new syntax...first of all is this correct? Basically
> I'd like to develop my own language with c/c++ like syntax...but I
> would like to use lisp/scheme in the back.
yes, this is a newbie question: you most assuredly do not want to
develop a language with C/C++ syntax, though you will not know that
until you have learned Lisp/Scheme. The syntax is one of the best things
about Lisp, and one of the worst about C/C++.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Although I don't appreciate the syntax completely, I'm starting to see
the elegance. I think I'm well on my way to being convinced of Lisp's
greatness, but the application for which I started looking at LISP will
require average technical people to interact with it. Think of a
database with stored procedure language. I can build my database
management system in a language of my own choice (let's say lisp) but
when I provide a language for the end-user, it needs to be like
C/C++/Java/etc. (just an example).
Now I can parse my language and translate it to Lisp...but if there is
a well thought-out standard way of doing it (I hoped M-Expressions were
it) then it makes it easier for me.
Actually I just thought of a simpler example. What if users of my
applications use something like SQL (many lawyers and MBAs at my
company have learned just enough SQL...so good/bad developers don't
even enter into the picture). Obviously SQL is not what's considered
'lispish.' How hard will it be to parse sql and convert it to some
representation which can interact with the lisp (or scheme) code of the
application?
TXL (http://www.txl.ca/) claims that it took some of its features from
LISP, now as far as I can tell, TXL makes it very simple to parse and
manipulate a grammar...how does LISP compare?
I didn't mention it earlier, thanks for your responses so far!
falcon wrote:
> Although I don't appreciate the syntax completely, I'm starting to see
> the elegance. I think I'm well on my way to being convinced of Lisp's
> greatness, but the application for which I started looking at LISP will
> require average technical people to interact with it. Think of a
> database with stored procedure language. I can build my database
> management system in a language of my own choice (let's say lisp) but
> when I provide a language for the end-user, it needs to be like
> C/C++/Java/etc. (just an example).
>
> Now I can parse my language and translate it to Lisp...but if there is
> a well thought-out standard way of doing it (I hoped M-Expressions were
> it) then it makes it easier for me.
Just make your programming language XML-based. Then you get the power
of S-expressions with the marketability of XML. The same people who
hate reading (or (> x y) (func?)) will be fine with the XML equivalent:
<or>
<greater-than>x y</greater-than>
<func />
</or>
-- MJF
falcon wrote:
> Although I don't appreciate the syntax completely, I'm starting to see
> the elegance. I think I'm well on my way to being convinced of Lisp's
> greatness, but the application for which I started looking at LISP will
> require average technical people to interact with it. Think of a
> database with stored procedure language. I can build my database
> management system in a language of my own choice (let's say lisp) but
> when I provide a language for the end-user, it needs to be like
> C/C++/Java/etc. (just an example).
>
> Now I can parse my language and translate it to Lisp...but if there is
> a well thought-out standard way of doing it (I hoped M-Expressions were
> it) then it makes it easier for me.
You can do a lot of things both with macros and reader macros. There is
no "standard" way of doing these things: Macros and reader macros allow
you to use full Common Lisp for building your macros. Depending on your
concrete requirements, you will probably build your own library to
handle the cases well that you need for your specific purposes. (Read:
Your requirements are too vague to make more specific suggestions.)
For some examples see the following links:
- http://www.cliki.net/infix
-
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/cgol/0.html
...or check out some of the various SQL integrations for Common Lisp.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
falcon wrote:
> Although I don't appreciate the syntax completely, I'm starting to see
> the elegance. I think I'm well on my way to being convinced of Lisp's
> greatness, but the application for which I started looking at LISP will
> require average technical people to interact with it. Think of a
> database with stored procedure language. I can build my database
> management system in a language of my own choice (let's say lisp) but
> when I provide a language for the end-user, it needs to be like
> C/C++/Java/etc. (just an example).
It is not clear from what you write whether "end users must use syntax
X" is a constraint imposed by a boss or client, or simply your best guess.
The system I am developing will require a configuration language, and I
plan for that to be Lisp-y. Others will argue for non-Lisp-y, and I will
say, For now Lisp-y gets us there faster, we can do m-exprs next. Of
course, as with Lisp itself, we will never end up doing m-exprs because
everyone will love Lispy syntax. :)
Don't forget: Lisp is going to go through the roof in the next twelve
months. By the time you are in beta your users will be beating you over
the head for forcing them to use C syntax.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
"falcon" <········@gmail.com> writes:
> Now I can parse my language and translate it to Lisp...but if there is
> a well thought-out standard way of doing it (I hoped M-Expressions were
> it) then it makes it easier for me.
Via Lemonoder:
http://www.jroller.com/page/trasukg/20050419#while_writing_yaql_i_accidentally
You might find it interesting. As I understand Lisp history, the
short version is that the S-expresion syntax was used to work out the
parse trees in lei of developing an M-expression syntax for production
use. The problem was, the S-exp syntax was so nice and also highly
amenable to macros (something no other language has done yet, so far
as I know) that the Lispers came to love it and stuck with it.
I find it an amusing irony that the dreaded parenthesis of Lisp are
the enabler of its awesome power.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
"falcon" <········@gmail.com> writes:
> Now I can parse my language and translate it to Lisp...but if there is
> a well thought-out standard way of doing it (I hoped M-Expressions were
> it) then it makes it easier for me.
M-expressions are a footnote in the history of Lisp.
As with everything in Common Lisp, there's no one single way to parse.
There are multiple techniques, vocal advocates of every one, and
battles between them lasting hundreds of messages on c.l.lisp. I know
at least of the following techniques:
- writing lexers by hand;
- writing lexers by hacking the Lisp reader
(see for example http://ftp.linux.org.uk/pub/lisp/cclan/infix.tar.gz);
- writing lexers using the META technique
(http://home.pipeline.com/~hbaker1/Prag-Parse.html)
- writing lexers using regular expressions (http://weitz.de/cl-ppcre/).
- writing parsers by hand (recursive descent, only suitable for LL(1));
- writing parsers using META (I've never seen an example);
- writing parsers using a LALR(1) parser generator
(I'm partial to http://www.pps.jussieu.fr/~jch/software/cl-yacc/).
And of course there's the solution of using XML and usint a nonvali-
dating XML parser.
Juliusz
"falcon" <········@gmail.com> wrote on 23 Apr 2005 00:3:
> when I provide a language for the end-user, it needs to be like
> C/C++/Java/etc. (just an example).
Do you mean that it needs to be one of the already known official languages
(a _real_ C, C++, or Java)? Or that it only has to look like them?
Is your intent to somehow reimplement Java in Lisp? Or only to put surface
syntax on Lisp, so that it "looks like" Java, but really is exactly Lisp?
Because I can't imagine a real-world requirement that says: "you don't have
to use C/C++/Java, but you MUST use only a language that appears at a glance
to look like one of them." That seems to be what you said, but it doesn't
make any sense that someone would only be concerned with the surface syntax,
yet not concerned at all with how the language really works (the "semantics").
On the other hand, if you have to actually implement one of the real languages,
then starting from scratch and implementing them in Lisp sounds silly too.
Surely you should just use one of the existing official compilers/interpreters.
Other than you just wanting to play around, and see if it would be possible
to use a C-like syntax to program Lisp code, you don't seem to be expressing
a real problem. Even though your posting suggested that you're trying to solve
some real problem.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Kenny Tilton wrote:
>
> falcon wrote:
>
>> I recently started looking at Lisp/Scheme. Once or twice I came
>> accross M-Expressions. From what I understood, m-expressions could be
>> used to define new syntax...first of all is this correct? Basically
>> I'd like to develop my own language with c/c++ like syntax...but I
>> would like to use lisp/scheme in the back.
>
> yes, this is a newbie question: you most assuredly do not want to
> develop a language with C/C++ syntax, though you will not know that
> until you have learned Lisp/Scheme. The syntax is one of the best things
> about Lisp, and one of the worst about C/C++.
Falcon is trying to reinvent Dylan.
IMO, Dylan would have been the logical and worthwhile evolution of
Common Lisp, except the Dylan community decided they couldn't achieve
significant market penetration without aping C syntax. That single
mistake was sufficient to make the language worthless.
"falcon" <········@gmail.com> writes:
> I recently started looking at Lisp/Scheme. Once or twice I came
> accross M-Expressions. From what I understood, m-expressions could be
> used to define new syntax...first of all is this correct? Basically
See section "What's with All the Parentheses?" at the beginning of
this page:
4. Syntax and Semantics
http://www.gigamonkeys.com/book/syntax-and-semantics.html
particularly the quote of John McCarthy, which refers to the
early--i.e. late 1950s and early 1960s--history of Lisp. The page is
part of this book by Peter Seibel:
Practical Common Lisp
http://www.gigamonkeys.com/book/
Highly recommended.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface