I am trying to introduce Lisp to the UQ CS Dept, in which everybody
knows that real men use C++. I will put on a demo of Garnet etc. shortly
but most important decisions are made on first impressions, and the
first impressions are the (())()()s. God said that f(a, b); is easier
to read than (f a b), it requires less characters.
Seriously, (> (+ x 1) (* y 2)) is ugly, and it would be pretty easy
to add a parser to Lisp that could be used instead of the normal Reader.
(At least for demonstration purposes). Such a parser would idealy be
table driven and dynamically extendible -- new macro, new grammar rule.
If anyone has heard of such a thing I would be interested to know.
Thanks,
--
Anthony Berglas
Rm 503, Computer Science, Uni of Qld
Ph 07 365 2812, Australia.
In article ·····@uqcspe.cs.uq.oz.au, ·······@cs.uq.oz.au (Anthony Berglas) writes:
> God said that f(a, b); is easier
> to read than (f a b), it requires less characters.
>
I didn't see a smiley, :-), but let's suppose this was intended to be ironic.
> Seriously, (> (+ x 1) (* y 2)) is ugly, and it would be pretty easy
> to add a parser to Lisp that could be used instead of the normal Reader.
Well, you know what they say about beauty being in the eye of the beholder.
I, for one, much prefer Lisp/Scheme syntax. You can't beat it for elegance, which
is why I find it beautiful. Also, with a good editor (i.e. emacs), selecting
cutting, pasting and formatting s-expressions is so much easier than doing
the same operations on arbitrary blocks and expressions in C.
But these are religious matters, apparently, so I suppose the idea of supporting
alternative surface syntaxes is a good one. Why not make everyone happy?
>
> If anyone has heard of such a thing I would be interested to know.
>
Sorry I can't help you here, but I do know that Apple plans to support an alternative
"algol-like" surface syntax for its new Lisp dialect, Dylan.
---
Thomas F. Gordon
GMD, FIT; Artificial Intelligence Research Division
5205 Sankt Augustin 1 / Germany
email: ·············@gmd.de; phone: (+49 2241) 14-2665
In article <·····@uqcspe.cs.uq.oz.au>, ·······@cs.uq.oz.au (Anthony Berglas) writes:
>
> I am trying to introduce Lisp to the UQ CS Dept, in which everybody
> knows that real men use C++. I will put on a demo of Garnet etc. shortly
> but most important decisions are made on first impressions, and the
> first impressions are the (())()()s. God said that f(a, b); is easier
> to read than (f a b), it requires less characters.
>
> Seriously, (> (+ x 1) (* y 2)) is ugly, and it would be pretty easy
> to add a parser to Lisp that could be used instead of the normal Reader.
> (At least for demonstration purposes). Such a parser would idealy be
> table driven and dynamically extendible -- new macro, new grammar rule.
>
> If anyone has heard of such a thing I would be interested to know.
>
> Thanks,
>
>
> --
> Anthony Berglas
> Rm 503, Computer Science, Uni of Qld
> Ph 07 365 2812, Australia.
>
>
Following exerpts from the GLISP and MLISP manuals. I like Lisp syntax, so I did not use it, but it
sound's promising in your context.
Generalized Lisp
Users Manual
by
David Canfield Smith
Apple Computer
August 1990
Version 1.2
Generalized Lisp (or Glisp for short) is a coordinated set of high level syntaxes for Common Lisp. It is
generalized in the sense that the Lisp programmer has a variety of dialects available, not just Lisp notation.
Initially Generalized Lisp consists of three dialects: Mlisp, Plisp and ordinary Lisp,
together with an extensible framework for adding others. Mlisp (Meta-Lisp) is an Algol-like syntax
for people who dont like writing parentheses. Plisp (Pattern Lisp) is a pattern matching rewrite-rule
language. Plisp is a compiler-compiler; its rules are optimized for writing language translators.
Mlisp and Plisp are documented in separate user manuals.
It is expected that the set of dialects will increase over time as users add new ones.
All dialects may be freely intermixed in a file.The translators for all dialects are written in Plisp,
as is the Glisp translator framework itself.
Support routines for the translators are written in Mlisp and/or Lisp.
All dialects are translated to Common Lisp and execute in the standard Common Lisp environment.
Mlisp
Users Manual
by
David Canfield Smith
Apple Computer
xxx 1990
Version 1.2
Introduction
What is Mlisp?
Mlisp (Meta-Lisp) is an alternative syntax for Common Lisp that reduces its reliance on parentheses.
Mlisp is designed to make Lisp programs easier to read. Mlisp programs are translated into Lisp and
then compiled, executed or printed. Therefore Mlisp has exactly the same capabilities as Common Lisp,
no more and no fewer. Nevertheless, experience has shown that many people can write larger and
more complex programs in Mlisp than in Lisp, since they can better understand the code.
The Mlisp syntax is a derivative of Algol, with begin-end blocks, if-then-else conditionals, etc.
The fundamental rule in Mlisp is that the mathematical notation
function(arg1, arg2, ..., argn)
is translated into the Lisp notation
(function arg1 arg2 ... argn)
For example,
print("abc", stream)
translates to
(print "abc" stream)
Any Lisp s-expression can be produced in this way, even special forms. For example,
cond(=(a, b)(c), t(d))
translates to
(cond ((= a b) c) (t d))
Of course the former is hardly an improvement on the latter, so special syntax has been added for most special forms:
if b then c else d
The idea for Mlisp was first proposed by John McCarthy in his earliest Lisp report in 196?.
In article <·····@uqcspe.cs.uq.oz.au> ·······@cs.uq.oz.au writes:
>
>Seriously, (> (+ x 1) (* y 2)) is ugly, and it would be pretty easy
>to add a parser to Lisp that could be used instead of the normal Reader.
[...]
>If anyone has heard of such a thing I would be interested to know.
Well, the tone of your whole message leads me to believe that your are looking
for a general parser, in which case I know of nothing already available. But on
the offchance that you were just looking for infix-to-prefix translation for
arithmetic operators, both Winston and Horn (_LISP_ 3rd Ed) and the more
advanced text by Norvig (_Paradigms of AI Programming_) give examples of this
with an easy way to extend it.
Also, I personally prefer the prefix notation so that I don't have to remember
precedence and associativity rules. Anecdotes prove little and are biased
by personal tastes, but when I use ML (esp code written by others), I somewhat
miss the consistency and simplicity of the infix notation.
- Marty
(proclaim '(inline skates))
In article <·····@uqcspe.cs.uq.oz.au> ·······@cs.uq.oz.au (Anthony Berglas) writes:
I am trying to introduce Lisp to the UQ CS Dept, in which everybody
knows that real men use C++. I will put on a demo of Garnet etc. shortly
but most important decisions are made on first impressions, and the
first impressions are the (())()()s. God said that f(a, b); is easier
to read than (f a b), it requires less characters.
Interlisp (and it's successor, Medley), have supported this format,
called "apply form". As far as I know no one's ever used it outside of
the exec (interface to the interpreter), as it really messes with your
brain to use it for deeply nested forms (or at least my brain :-).
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
·····@cis.ohio-state.edu
CGOL, a language that looks Algolish but is translated into Lisp
for its semantics, was developed by Vaughn Pratt, some years ago.
It was initially implemented for Maclisp, but was also useful in
Franz Lisp. I have just recently gotten (for a term project) a
translation of CGOL into Common Lisp. The semantics of CL are
in a variety of ways more complicated than Maclisp, and there are
some Maclisp features (e.g. LEXPR, FEXPR, ...) that have disappeared.
If anyone is sufficiently interested in seeing this translation
to try it out (it was developed on Allegro CL), send me a note.
My intention is to post the relevant documents and code at some
ftp site, after I look at it and try it out more, myself.
The extensible "top-down operator precedence" parsing scheme
devised by Pratt is quite useful, and highly extensible. The
Macsyma computer algebra language uses a Pratt-like parser, and
I suspect that several other systems do, as well.
--
Richard J. Fateman
·······@cs.berkeley.edu 510 642-1879
> In article <·····@uqcspe.cs.uq.oz.au> ·······@cs.uq.oz.au (Anthony Berglas) writes:
>
> I am trying to introduce Lisp to the UQ CS Dept, in which everybody
> knows that real men use C++. I will put on a demo of Garnet etc. shortly
> but most important decisions are made on first impressions, and the
> first impressions are the (())()()s. God said that f(a, b); is easier
> to read than (f a b), it requires less characters.
then god has a strange way of counting. f(a, b); is longer than (f a b) AND is a smaller
character set.
i've tried both C++ and Lisp, learning them roughly in parallel, and my humble
opinion is it's a hell of a lot easier to get things done in Lisp.
--
Hume Smith Wenn ich des Tages nicht dreimal
··········@acadiau.ca mein Schaelchen Coffee trinken darf,
······@bnr.ca so werd' ich ju zu meiner Qual
wie ein verdorrtes Ziegenbraetchen.