Lisp syntax, what about resynchronization? 
Author Message
 Lisp syntax, what about resynchronization?

I agree with most of the comments on this thread about Lisp syntax.
But it occurs to me that one advantage that heterogeneous Algol-type
syntaxes have over Lisp is that when they get lost, they can detect
being lost and resynchronize (And thus produce more errors, but that's
helpful for debugging).  In Lisp, one misplaced parenthesis can easily
put you into "Where the hell is this problem coming from?" mode.

It also occured (*) to me that this could be remedied pretty easily
wrt Lisp syntax.  You'd just need a resynchronization token or tokens,
to mean a) "push" the current depth + 1, b) "restore" the current
depth without popping, and c) "pop" the current depth off.  These
positions would be read as if they contained however many left or rite
parentheses would be needed to reach the level being restored to.

I don't know whether it would be possible to do that with a reader

as tokens, it could look something like this (grabbing the first elisp
defun I saw, kill-all-abbrevs from abbrev.el):

(defun kill-all-abbrevs ()
  "Undefine all defined abbrevs."
  (interactive)

    let
    ((tables abbrev-table-name-list


      while tables

      (clear-abbrev-table (symbol-value (car tables

      (setq tables (cdr tables


(*) Actually, way back when someone here was saying that XML was "Lisp
with brackets" (which I don't entirely buy, but Lisp syntax for
markup... yum).  Where resynchronization in a programming language
just lets you debug more easily, in a markup language it can make all
the difference between a document that will render and one that won't.

--
Tom Breton, http://www.*-*-*.com/ ~tob
Ugh-free Spelling (no "gh") http://www.*-*-*.com/ ~tob/ugh-free.html



Sat, 24 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?
[Oops.  Accidentally replied to this in e-mail.  Copying it here to
 the group, though in the process I have "revised and extended" my remarks.]

Quote:

> I agree with most of the comments on this thread about Lisp syntax.
> But it occurs to me that one advantage that heterogeneous Algol-type
> syntaxes have over Lisp is that when they get lost, they can detect
> being lost and resynchronize (And thus produce more errors, but that's
> helpful for debugging).  In Lisp, one misplaced parenthesis can easily
> put you into "Where the hell is this problem coming from?" mode.

As I recall, and I might be wrong because I didn't myself use it--I
just heard about it, the LMITI (LMI/MIT/TI) branch of the Lisp Machine
had some mode (I think invented/installed by Richard Stallman) that
watched out for misbalanced parens by looking for open parens that were
to the left of a containing paren.  That seems to me almost entirely
adequate to the task.  I don't recall anyone making much noise about
it though I think I may have seen it do its thing once and thought it
was kinda cool at first blush.  It may be that in practice it was too
simplistic and it got in the way.  

I've seen other compilers that keep track of the last place an open
paren in column 0 happened, so that when a compiler error happened,
especially a reader error, they could offer heuristic advice about
the paren balancing beyond what the mere count of parens would give.

Note also that Lisp used to (in Interlisp) have super-parens so you
could use [foo (bar baz)] to make sure you had firewalls for bracketing.
These were heavily (ab)used, with people writing [foo (bar baz],
though it drove many (including Emacs) nuts.  The Maclisp community
(later Common Lisp) made a pretty conscious decision not to do it this way.

I do agree that it's a good property of a language that it should be
"sparse" so that errors are easily detected from non-errors.  But
you can't have everything, and I think the benefit that comes for having
infix comes at a sizable disadvantage.  Even LOOP, which is majorly
infix, is a routine source of indentation woes, and is much harder
to edit using normal motion commands.



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

| I agree with most of the comments on this thread about Lisp syntax.
| But it occurs to me that one advantage that heterogeneous Algol-type
| syntaxes have over Lisp is that when they get lost, they can detect
| being lost and resynchronize (And thus produce more errors, but that's
| helpful for debugging).  In Lisp, one misplaced parenthesis can easily
| put you into "Where the hell is this problem coming from?" mode.

  that's why we have editors instead of compilers help us find problems.
  one very easy way to spot parenthesis errors is to let Emacs indent the
  whole top-level form.  if something moves, undo the indentation, and fix
  whatever you fairly immediately see caused the problem.  repeat until
  nothing moves.

| (*) Actually, way back when someone here was saying that XML was "Lisp
| with brackets" (which I don't entirely buy, but Lisp syntax for
| markup... yum).  Where resynchronization in a programming language
| just lets you debug more easily, in a markup language it can make all
| the difference between a document that will render and one that won't.

  having been one of the leading SGML experts in the world before I finally
  came to conclude it was a fundamentally braindamaged approach (but a good
  solution once you had taken the wrong approach and stuck with it -- like
  so many serious design errors in programming, or, indeed, politics, where
  it is always harder to get back on track than to continue forward and to
  knock down ever more hindrances -- it's like driving a tank: if you drift
  off the road, any telephone poles you might knock down are only proof
  positive of your mighty tank's ability to get where you want to go, and
  the important psyhological "corrector" that hindrances should have been
  is purposefully ignored because you are too powerful), I could go into a
  long an arduous debate over exactly how little resynchronization ability
  SGML's "labeled parentheses" gives you, and how immensely hard it is to
  backtrack the SGML parsing process.  it's a pity that XML is actually a
  little _worse_ in this regard.

  one of the reasons I got into SGML was that it had beautiful, explicit
  markers of the beginning and end of the syntactic structure.  this I
  sensed was great because I had had a lot of Lisp exposure before SGML.
  however, Lisp's elegance loses all its beauty if you adorn parentheses
  with labels, because you actually _lose_ synchronization ability when you
  have to deal with conflated errors: <BAR>...<BAZ>...</BAR> may close BAZ
  and BAR at the same time in the complex game of omitted end tags in SGML,
  but in the fully explicit case, it may be a typo for </BAZ>, or may be a
  missing </BAZ>.  any attempt to resynchronize will get it right half the
  time, which causes subsequent errors to crop up, and then you'd have to
  go back and try the other possibility, but that means reshuffling your
  entire tree structure.  the same is true of empty elements that are
  mistaken for containers.  perhaps <BAZ> should have been <BAZ/>?  that
  means you get it right only a _third_ of the time in XML where you don't
  even have the DTD to help you decide anything, anymore.  'tis wondrous!

  this is the same problem as the stupid IF THEN ELSE problem created by
  people without functioning brains.  that is, is IF THEN IF THEN ELSE a
  two-branch inner or outer IF?  there's simply no way to tell, so it was
  decided it should be inner, which means the program compiles wrong if the
  compiler's idea is different form the programmer's idea.  in Lisp, a
  missing parenthesis would be found when indenting the code.

  Lisp's simple, unlabeled, explicit-structure-marking syntax solves all of
  these problems.  your silly introduction of syntactic noise is another
  example of how a powerful tool can be used to knock down telephone poles
  instead of taking a hint that you should get back on track.  imagine
  giving the programmer the duty of filling in noise like that!  it's the
  mistakes of SGML all over again: _adding_ stuff to make it simpler.

  I hate it when history repeats itself and nodoby learned anything last
  time, either: those who do not know Lisp are doomed to reimplement it.

#:Erik



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

Quote:

> I've seen other compilers that keep track of the last place an open
> paren in column 0 happened, so that when a compiler error happened,
> especially a reader error, they could offer heuristic advice about
> the paren balancing beyond what the mere count of parens would give.

That's certainly an approach.  It needs to detect an error first, tho.

Quote:
> Note also that Lisp used to (in Interlisp) have super-parens so you
> could use [foo (bar baz)] to make sure you had firewalls for bracketing.
> These were heavily (ab)used, with people writing [foo (bar baz],
> though it drove many (including Emacs) nuts.  The Maclisp community
> (later Common Lisp) made a pretty conscious decision not to do it
> this way.

I'm sure abuse would be a problem with my proposal too, for
essentially the same reason.

Quote:
> I do agree that it's a good property of a language that it should be
> "sparse" so that errors are easily detected from non-errors.  But
> you can't have everything, and I think the benefit that comes for having
> infix comes at a sizable disadvantage.  Even LOOP, which is majorly
> infix, is a routine source of indentation woes, and is much harder
> to edit using normal motion commands.

I'm not sure how infix notation got into this.  If what I talked about
translates to infix notation, I don't see it.  

I agree that LOOP's nonconformity is regrettable.  I tend to disfavor
loop for that reason.

--
Tom Breton, http://world.std.com/~tob
Ugh-free Spelling (no "gh") http://world.std.com/~tob/ugh-free.html



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

Quote:


> | I agree with most of the comments on this thread about Lisp syntax.
> | But it occurs to me that one advantage that heterogeneous Algol-type
> | syntaxes have over Lisp is that when they get lost, they can detect
> | being lost and resynchronize (And thus produce more errors, but that's
> | helpful for debugging).  In Lisp, one misplaced parenthesis can easily
> | put you into "Where the hell is this problem coming from?" mode.

>   that's why we have editors instead of compilers help us find problems.
>   one very easy way to spot parenthesis errors is to let Emacs indent the
>   whole top-level form.  if something moves, undo the indentation, and fix
>   whatever you fairly immediately see caused the problem.  repeat until
>   nothing moves.

Which really doesn't address the problem, sorry.  I've assumed from
the start that we were dealing with code that was automatically
indented.  Inspecting the indentation does not neccessarily reveal
errors.  Unless you are focussing on which level you intend an
expression to be in, one level looks very like another.

Quote:
>   Lisp's simple, unlabeled, explicit-structure-marking syntax solves all of
>   these problems.  

No, and I explained why.

Quote:
>   your silly introduction of syntactic noise is another
>   example of how a powerful tool can be used to knock down telephone poles
>   instead of taking a hint that you should get back on track.  imagine
>   giving the programmer the duty of filling in noise like that!  

I think you did not understand what was proposed if you say that.

--
Tom Breton, http://world.std.com/~tob
Ugh-free Spelling (no "gh") http://world.std.com/~tob/ugh-free.html



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

Quote:

> (defun kill-all-abbrevs ()
>   "Undefine all defined abbrevs."
>   (interactive)

>     let
>     ((tables abbrev-table-name-list


>       while tables

>       (clear-abbrev-table (symbol-value (car tables

>       (setq tables (cdr tables



looks like some snails got confused and wandered into the source.

thi



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

scrawled in the dust by Tom Breton in a flowery script, reading:  

Quote:
> (And thus produce more errors, but that's helpful for debugging).

I've usually found that just one error is enough, usually the first one.
There was a time when C compilers would tell me the real error in the
second error message, but that tended to be because of type inference and
the absence of a declaration.

Using languages with reflection, I find that the first error is the only
one I can safely trust, and this is the only one that I get. Every time I
think about recovery, it's a can of worms. So why bother? I just correct
the source code, and try again. It only takes a second or two.

BTW, I also think of XML as you do. XML->documents as Lisp->code. ;)
I'm currently playing with a little tool for turning XML into Lisp code
that, say, builds a tree of CLOS objects. The code could do anything, but
I love the idea of using CLOS to process the tree. Lisp is good at this!
--
Remove insect from address to email me | You can never browse enough
"Ahh, aren't they cute" -- Anne Diamond describing drowning dolphins



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

Quote:

> But it occurs to me that one advantage that heterogeneous Algol-type
> syntaxes have over Lisp is that when they get lost, they can detect
> being lost and resynchronize (And thus produce more errors, but that's
> helpful for debugging).  In Lisp, one misplaced parenthesis can easily
> put you into "Where the hell is this problem coming from?" mode.

Yeah, right. Like when you miss a semicolon or stuff like
that in C(++).

"Where the hell" is actually worse in C(++) as I still
haven't crossed a compiler with the single brain cell
needed to tell me in exactly which file in an #include chain a problem
is actually happening!

Regards,



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

Quote:

>   having been one of the leading SGML experts in the world before I finally
>   came to conclude it was a fundamentally braindamaged approach (but a good

And I know you don't like{*filter*}(and obviously Knuth belongs to the pathetic
`reinvent school', but what choice do I have?).
What can we use then? Any `TexROLLisp' to offer? [It's a real question]

Regards,



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

Quote:

> Which really doesn't address the problem, sorry.  I've assumed from
> the start that we were dealing with code that was automatically
> indented.  Inspecting the indentation does not neccessarily reveal

For my--toy, presently--programs I evaluate every form just after editing
(writing or modifying) it. This provides an early occasion for testing, and
it reduces the chances that unbalanced parentheses remain undetected.

Question for experienced programmers: does this approach scale well to
large systems?

Paolo
--



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

| Which really doesn't address the problem, sorry.

  it seems you're reading awfully fast, but slow down so you get the issues
  that are attempted communicated, OK?

| I've assumed from the start that we were dealing with code that was
| automatically indented.

  but at which level?  there are two major schools, here:  one, which SGML
  adherents tend to belong to, says that at no point in time shall the
  syntactic wellformedness of the total system be in jeopardy, which means
  you cannot at any time perform a task in two steps that causes the whole
  document (SGML) or form (Lisp) between these two steps to break the rules
  of syntax.  this school favors structure editors and completely automatic
  indentation and also storing the document or code in a non-text form when
  they think they can get away with it.  the core principle of this school
  is that structure is "a priori".  the other major school, which you will
  find intrinsic to the Emacs philosophy, is that writing highly structured
  material is a cooperation between user and editing software.  at no point
  in time can there be a guarantee that the structure is complete, but you
  can check for it, and you can cause it to become complete once you detect
  where it is not.  the core principle of this scool is that structure is
  "a posteriori".  I generally tend to be an a posteriori kind of guy, and
  I think a priori kinds of guys pretend to know the unknowable, and since
  you don't listen very well, but assume you already know what I said
  before you actually read it, that rhymes well with the a priori school.

  I assume here that since you drag in the compiler, which is THE WRONG
  PLACE to do this kind of checking and recovery and resynchronization, the
  reasons for which I explained and you did not understand, you want some
  form of cooperation between editor and the human, instead.  that
  cooperation is at its best when it is completed before the compilation
  starts.  less syntactic mess means better cooperation between user and
  editor (Lisp).  more syntactic mess means the compiler is the only tool
  that could ever figure it out (C++).

| Inspecting the indentation does not neccessarily reveal errors.

  I didn't say "inspect", Tom.  what I said was, _when_ you are editing,
  and you are inserting and deleting parenthesis, you will naturally have
  expectations as to what the indentation will be.  that is, if we're still
  assuming that programmers are humans.  you give me the impression that
  you argue in a world where they are not, which rhymes well with my own
  great vision of the future, where computers program people, but this is
  still some ways off, and until then, we have to deal with people typing
  and seeing what they do.  so instead of your silly interpretation of
  inspecting the indentation, I _actually_ said we should watch the
  _changes_ that Emacs makes to the indentation when we reindent code that
  has been changed.  you have obviously never done this, so let me explain
  what it means: suppose you add a binding to a LET form, but you forget to
  close the outermost parenthesis in what you added.  reindent.  watch how
  completely unrelated lines suddenly move.  this is such a fantastically
  simple task most people have to be shown it to understand that it is NOT
  a question of inspecting a _static_ indentation, but of watching Emacs
  make _unexpected_ changes to indentation.  the rule of thumb is: if
  something you don't expect to move, moves, you've made a mistake, and
  undo the indentation immediately, and go fix it.

  however, the interesting point here is that your suggestion does not
  reveal errors in a slightly different, but in principle identical, way to
  what you argue against in my counter-suggestion: the reason is computers
  _still_ don't know the _intention_ of the human programmer, because what
  we look at is a failure to communicate the intent properly in syntax.  in
  the case of SGML (or XML, if you want), that flaw is at the core of the
  braindamaged design: you cannot communicate or even think of structure in
  SGML without knowing it a priori _and_ with full knowledge of the intent
  of the users of that structure.  if you try to do otherwise, you will
  fight structure (or make users fight it), and resort to a posteriori
  means of re-establishing the syntactic structure, when the intent is
  gone.  which is what this silly "resynchronization" proposal is all about.

| Unless you are focussing on which level you intend an expression to be
| in, one level looks very like another.

  no wonder you're seriously confused about this issue to begin with.

| > Lisp's simple, unlabeled, explicit-structure-marking syntax solves all
| > of these problems.
|
| No, and I explained why.

  I see.  no, you did not explain why, Tom.  you cannot _both_ accuse me of
  not getting your point _and_ tell me you already explained what I bring
  up, which must of necessity be something other than your issues.  this
  only means you are not listening to anyone but yourself.

| I think you did not understand what was proposed if you say that.

  sometimes, one person's brilliant idea is a brilliant person's laugh.

  and in this case, my reason for leaving SGML behind was that the kind of
  silly thing you proposed for Lisp was proposed for SGML about once a
  month by various people who thought they had grokked SGML, but hadn't.
  it finally dawned on me that the complexity of the syntax made this
  almost _necessary_ for SGML, so it had to come up, and one of the least
  productive solutions, XML, won the day.  I was there, at the conference
  table where the first thoughts that became XML surfaced.  a few months
  earlier, I had proposed the need for a special marker for empty elements
  -- and then retracted that proposal because it led to new problems -- but
  guess what survived in XML!  and now we have the same stupid issues that
  caused people to think long and hard and come up with XML come to Lisp
  because John McCarthy made the acute observation that XML is basically
  parentheses with labels on them, but some people didn't get the meaning
  of that: drop the stupid labels in XML.  it was _not_ an invitation to
  add labels or (syntactic) markers to Lisp.

  however, I don't expect anyone to understand this unless they actually
  understand SGML, and very few people do, least of all the people who
  think it's great, so I just wanted to put it in writing in case someone
  gets the message.

  structure only appears a priori evident to people who didn't build it.

#:Erik



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

| And I know you don't like{*filter*}(and obviously Knuth belongs to the pathetic
| `reinvent school', but what choice do I have?).
| What can we use then? Any `TexROLLisp' to offer? [It's a real question]

  the realness of the question is evident, but I don't have time to answer
  this fully, now.  it's fairly involved, which is also why I haven't
  gotten around to write something about what attracted me to SGML and what
  made me leave except in commentaries on comp.lang.lisp and comp.text.sgml.

  what do I use myself?  somebody else.   a consistent, simple style in
  plain text makes it possible for skilled typographers to make printed
  text look very nice.  authors generally think they know too much about
  typography, or if they have the wherewithal to realize they don't, go to
  extraordinary lengths to make life for typographers needlessly hard.
  working _inside_ the publishing business also tells you which problems
  SGML were hoped to solve and their magnitude, but also their reason: most
  authors don't know jack about the _logistics_ of writing books, much less
  publishing them.  most authors write books like mad generals conduct
  wars: without concern for how their troops shall get fuel and food and
  ammo.  but if you can't think in terms of logistics, at least have enough
  respect for those who do that you help them by staying out of their way.
  I found it wise to get out of the way, not only because it's a horribly
  _practical_ industry: they just do _whatever_ it takes to get a book out
  (SGML was like asking miners to use{*filter*}gloves so they wouldn't leave
  finger prints on the ore), but also because SGML couldn't help anybody at
  the level they actually needed help.  SGML is a giant conflation of what
  was once a noble division of labor, much worse than the incredibly stupid
  stuff Microsoft thinks is publishing, because Microsoft thinks WYSIWYG is
  going to make skilled typographers happy (hint: they aren't), but SGML
  makes authors _aware_ of the structure that had hitherto been implicit,
  and few authors, except highly skilled technical writers, have any idea
  what their structure communicates until a _long_ way into writing it (if
  we're lucky), or them (if we aren't).

  if you want to consider my web pages in terms of their design, take a
  look at this excellent explanation of what I didn't know I was doing
  before visiting them:

    http://www.*-*-*.com/

  I have been on both ends of the publishing business: I have published
  many articles in magazines and newspapers -- never have the editors been
  happier than when receiving plain text -- and I have helped write the
  software to make a giant web of mad user input into books -- it is not a
  pretty sight.  so I decided to make my plain text a pretty sight and let
  somebody else make my plain text into pretty formatted page layout.

  hope this is a start at an answer, at least.

#:Erik



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?


Quote:

>> I've seen other compilers that keep track of the last place an open
>> paren in column 0 happened, so that when a compiler error happened,
>> especially a reader error, they could offer heuristic advice about
>> the paren balancing beyond what the mere count of parens would give.

>That's certainly an approach.  It needs to detect an error first, tho.

Usually it does.  If you have an extra or missing parenthesis somewhere in
your file, you'll either get an EOF in the middle of an object or a close
parenthesis at top-level.  You would have had to have made an even number
of complementary parenthesization mistakes to avoid them being detected.

Kent mentioned an editor mode that noticed an open parenthesis too far to
the left.  I don't recall this specifically, but I think I remember that
ZMACS Lisp mode recognized open parens at the left margin specially in a
number of ways.  So if you had code like:

(defXXX ...
  ... <not enough close parens>)

(defYYY ...
  ... <too many close parens>)

I think the M-x Find Unbalanced Parenthesis command could tell that each of
the definitions had unbalanced parens, even though they balanced each other
out.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

Quote:

> > I do agree that it's a good property of a language that it should be
> > "sparse" so that errors are easily detected from non-errors.  But
> > you can't have everything, and I think the benefit that comes for having
> > infix comes at a sizable disadvantage.  Even LOOP, which is majorly
> > infix, is a routine source of indentation woes, and is much harder
> > to edit using normal motion commands.

> I'm not sure how infix notation got into this.  If what I talked about
> translates to infix notation, I don't see it.  

infix implies redundancy.  for example, in lisp one writes:

 (if x y z)

one doesn't need "then" to know that y is a then clause because it's
"obvious" that the test is a complete expression and the expression is
therefore concise at the expense of being parse-wise fragile.  A single
character out of place can upset your ability to give good context.
Consider instead:

 if x then y else z

This is a much less fragile thing. A typo like:

 if xy then else z

can give you a bunch of really good information about the nature of
your problem that

 (if xy z)

cannot.  The reason is that the "then" and the "else" are textually heavily
redundant and add a great deal of additional "information" to the form
that can be used to grab some foothold in the presence of errors.  Even
if you misspell a guideword, you have the fact working for you that you
expected a guide word.  So in

 if x ten y else z

it's fairly easy to tell that "ten" is a mis-spelled guide word becuase you
found an "else" before seeing a "then" and you had an unrecognized token
that was very much like a "then" in between.  There is no equivalent of
this kind of extra contextual information in lisp.

So my comment was not about infix per se, but the redundancy of expression
common in infix languages which are typically absent in lisp, which
largely uses positional information instead of keyword information to
delineate program structure.  



Sun, 25 Nov 2001 03:00:00 GMT  
 Lisp syntax, what about resynchronization?

Quote:

> > But it occurs to me that one advantage that heterogeneous Algol-type
> > syntaxes have over Lisp is that when they get lost, they can detect
> > being lost and resynchronize (And thus produce more errors, but that's
> > helpful for debugging).  In Lisp, one misplaced parenthesis can easily
> > put you into "Where the hell is this problem coming from?" mode.

> Yeah, right. Like when you miss a semicolon or stuff like
> that in C(++).

C++, for all its lack of virtue, IME detects syntactic errors more
easily.  The semi-colon errors you mentioned are notoriously very easy
to find.

--
Tom Breton, http://world.std.com/~tob
Ugh-free Spelling (no "gh") http://world.std.com/~tob/ugh-free.html



Sun, 25 Nov 2001 03:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Lisp syntax : Lisp objects :: Scheme syntax : characters

2. New to Lisp question: advantages of Lisp syntax?

3. Implementing letrec-syntax using only let-syntax and syntax-rules

4. Lisp syntax for ocaml?

5. Lisp syntax for Haskell?

6. "Lisp" syntax differences

7. Apple's Dylan environment and Lisp-like syntax

8. LISP syntax?

9. Infix/Prefix and Lisp Syntax

10. Mathematics, syntax and the LISP SPIRIT

11. Mathematics, syntax and the LISP SPIRIT.

12. Lisp syntax and code as data (was: Re: scheme)

 

 
Powered by phpBB® Forum Software