Struggling with quasiquote in MAL

[none albert]

I'm busy with mal
https://github.com/kanaka/mal
a dialect of lisp similar to lisp.

Most types of objects evaluate to herself. number strings.
quotation is necessary for lisp insists that the first item
of a list is a function. All exceptions must be quoted.

Suppose we adapt the rule, that we leave lists alone unless the
first item is a function or a symbol that points to a function.

The expansion of quasiquote / splice-unquote / unquote
suddenly becomes easy in this context.
Switch to an environment where only quasiquote / splice-unquote / unquote
are known. Evaluate. Then continue with the real evaluate.

(quasiquote 1 "A" ( 1 2 3) unquote(a) b ) is to expand to
(cons 1 (cons "A" (cons (1 2 3) (cons (eval a) ( cons b () ) )..)
as a first step, contrary to a tricky choice of possibilities.

There is a hidden quotation in cons.
I find that disenginuous.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

[Kaz Kylheku]

On 2023-08-04, albert@cherry.(none) (albert) <albert@cherry> wrote:
> I'm busy with mal
> https://github.com/kanaka/mal
> a dialect of lisp similar to lisp.
>
> Most types of objects evaluate to herself. number strings.
> quotation is necessary for lisp insists that the first item
> of a list is a function. All exceptions must be quoted.
>
> Suppose we adapt the rule, that we leave lists alone unless the
> first item is a function or a symbol that points to a function.

PicoLisp does this, if I recall correctly. For instance, because
in (1 2 3) 1 is not a function, (1 2 3) evaluates to itself.

If you're implementing Mal, this is decide for you, I think.

> The expansion of quasiquote / splice-unquote / unquote
> suddenly becomes easy in this context.
> Switch to an environment where only quasiquote / splice-unquote / unquote
> are known. Evaluate. Then continue with the real evaluate.
>
> (quasiquote 1 "A" ( 1 2 3) unquote(a) b ) is to expand to
> (cons 1 (cons "A" (cons (1 2 3) (cons (eval a) ( cons b () ) )..)
> as a first step, contrary to a tricky choice of possibilities.

The unquoting splice still needs to be handled. To achieve
that you can give the operators this semantics

(quasiquote a b c) -> (append a b c)

(unquote x) -> (list x)

(splice x) -> x

However, we need all other arguments which are not unquotes
or splices to be turned into lists somehow:


`(1 "A" (1 2 3) ,a ,@b)

(quasiquote a "A" (1 2 3) (unquote a) (splice b))

(append (list a) (list "A") (list (1 2 3)) (list a) b)

I don't see how you can easily escape from quasiquote having to analyze
the interior according to its own rules, rather than just setting up
some environment.

One possibility might be:

(quasiquote a b c) -> (funny-list a b c)

Where funny-list lists all items except for specially
annotates ones. The special annotation is produced by splice.
We have:

(unquote x) -> x

(splice x) -> (cons 'sys:splice x)

When funny-append sees an object like (sys:splice . whatever)
it will spread whatever into a list, and add the items
individually.


The only problem with this is that we are relying on this
specific funny-list run-time support function which has
to do a run-time check.

If the Lisp dialect has to handle dotted quotes and unquotes,
that is an issue also.

> (quasiquote 1 "A" ( 1 2 3) unquote(a) b ) is to expand to

Then your expression reduces to

(append 1 "A" (1 2 3) a

>
> There is a hidden quotation in cons.
> I find that disenginuous.

No there isn't, except for the one you have introduced here
whereby (1 2 3), which is (1 . (2 . (3 . nil))) in CL-like
dialects, is self-evaluating. You put the hidden quotation
into (1 . <whatever>) based on the rule that 1 is not
a function.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazi...@mstdn.ca