Re: Lisp at sexp's length

From: Marcin 'Qrczak' Kowalczyk (qrczak_at_knm.org.pl)
Date: 12/15/03 

Date: Mon, 15 Dec 2003 07:48:59 +0100

On Sun, 14 Dec 2003 21:18:20 -0500, Rahul Jain wrote:

>> Because it's parsed into an abstract syntax tree before macroexpansion.
>
> And that tree looks nothing like the code.

A tree doesn't look. It exists in memory, it's derived from the stream of
tokens or characters but it's not *the* stream. The same is true in Lisp.
There are lexical rules and grammar rules which transform the stream to
the tree.

>> I don't say that the syntax would look exactly like this, for example
>> it could be <<$x + $y>>, but I do say that a non-Lispy syntax would use
>> parens for grouping and something else for lists (square brackets probably).
>
> Whatever you do, it'll look nothing like the code you're trying to
> generate, as far as I can see.

How does the tree node for addition look like then, if not "something +
something"? In the similar way to parentheses used to build a list node
which means application (or grouping of macro arguments, or a list
constant when quoted), here + is used to build an addition node which
means addition (or building an addition expression when quoted).

The only significant difference is that there is a dozen of kinds of nodes
rather than a few, and that data which represents code is used only for
code (and not also for lists and symbols).

>> There are no two different syntaxes. You use exactly the same syntax in
>> code quotations and in the main program.
>
> The "same" syntax which has 1+2+3 look like a stream of 5 tokens or a
> 3-element list with the 3rd element as another 3-element list?

If it's just a stream of 5 tokens, then (foo bar) is just a stream of 4
tokens.

When it's parsed, it's a tree. If unquoted, it means addition; if quoted,
it means to construct a syntax object which means addition.

In Lisp when it's parsed, it's a list (or tree of lists in general).
If unquoted, it means application; if quoted, it means to construct
a list which can mean application (or other things if used in other
contexts).

>> Do you mean, why to use a different syntax for code and for lists of
>> symbols? Because code is not a list of symbols. Hygiene alone requires
>> that.
>
> So lisp code is somehow "unhygenic"? Does it give you a disease when you
> touch it? Or just a speech impediment? :)

I meant hygienic macros.

> Why... would you like to put commas in your symbols?

I meant expanding to quasiquotations and splicing expressions into it.
In Lisp I must disambiguate using ,', versus , so it's not always just
"replace the parts which change with ,expression", one must be careful
to nesting of quasiquotations. The same is true in my syntax, I would
only let $foo expand to the value of foo and let $$foo expand to $foo.

> And the point remains that no one has come up with a syntax where you
> really can do that other than sexprs.

I did, but it's not finished yet. Wait a couple of weeks / months.

> And I mean 'looks like' from the data structure point of view as well,
> for when you want to build more complex macros.

You must know functions for manipulating lists, and you can often use
quasiquotations to build lists.

In my syntax you must know functions for manipulating syntax objects,
but you generally use code quotations to build and decompose syntax
objects.

>> Actually I would write these macros as functions, assuming my language has
>> a more friendly syntax for anonymous functions than #'(lambda () ...).
>
> Like Smalltalk? The results are nastily slow from what I've heard, even
> from ostensibly modern smalltalkers.

In Smalltalk they can't be inlined because of dynamic dispatch, but in a
language similar to Lisp a global higher-order function can be inlined.

> How would you write compiler-macros?

Sorry, I don't know what they are.

> Because that's the whole point. We like to extend the language. We like
> to create control structures that make sense in the domain we are
> programming in.

I like to have a language which I don't need to constantly extend for such
simple things as passing a piece of code to a function. Macros are fine
for more complex cases. 

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Relevant Pages

  • Re: Lisp at sexps length
    ... > Because it's parsed into an abstract syntax tree before macroexpansion. ... And that tree looks nothing like the code. ... > parens for grouping and something else for lists. ... If that's the case, then not having to quote keywords, NIL, and T when ...
    (comp.lang.lisp)
  • Re: [LogoForum] Re: Berkeley Logo (UCBLogo) 5.5 released (freeware)
    ... In honor of the addition of mouse support to UCBLogo, we have three game ... though they postdate Computer Science Logo Style: ... For ordinary lists we use the following constructor and selectors: ... The tricky one is STREAM, which takes two inputs: ...
    (comp.lang.logo)
  • Re: Cons cell archaic!?
    ... How would the implementation of a Lisp without a using cons look like? ... the irregularity in its often cited regular syntax. ... Lisp at core is based on functional programing on lists. ...
    (comp.lang.lisp)
  • Re: Cons cell archaic!?
    ... fundamental problems of lisp. ... lists and arbitrary binary trees, and it can be used to emulate ... One is the irregularity in its often cited regular syntax. ...
    (comp.lang.lisp)
  • Re: help with array syntax for a loop
    ... That syntax looks fine. ... We want to calculate forces from those particles on other ... in the tree is immaterial. ... All attempts at forall ended up with the vector index i being explicit ...
    (comp.lang.fortran)