Re: Relative merits of Lisp-1 vs. Lisp-2?

"levy" <levente.meszaros@xxxxxxxxx> writes:

Kent M Pitman wrote:

But I think the answer is that none of this obviates the importance of
language syntax and semantics unless you think that by adding these
other layers no one will ever look back at the low-level again.

I believe syntax becomes a matter of taste (preferences, policy), but
clearly semantics will not.

But semantics is really an aesthetic in many ways, too, unless it's an
unpredictable semantics. There are things with hugely unaesthetic semantics
for direct programming (TeX and Java fill that bill for me) yet they make
great assembly languages (i.e., targets of back-end code for a higher level
language) because they are highly predictable for their respective tasks.

Also, to the specific point at hand, if you know a particular feature is
weak or even just not what you want, you can program around it.

There are not too few names in a Lisp1. There is an infinity of
names, just as in Lisp2. With appropriate name mangling (which is how
compilers often can choose to implement namespacing anyway this
anyway), you can project two namespaces onto one. With appropriate
idiomatic uses in the compiler, the issue of ((foo...) ...) never comes
up because you can just write (funcall (funcall ...) ...) and paper it
over at the level above. Syntax, you might say, but at some level what
isn't? At some level, there's just a Turing Machine + syntax.
You can "work around" a lack of let bindings by clever renaming, which is
sort of what the lambda calculus does when it does beta reduction.
You can work around a lack of certain kinds of data structures by reshaping
other data flow paths to contain more data (the would-be contents of a
struct) or indexes of data stored elsewhere (as call-by-reference was emulated
in both my Fortran->Lisp translator for Macsyma and I believe also the
one Symbolics had as a product).

In the end, the only "semantics" is that of the machine and the rest is
just data. And even the machine can be emulated, so that "semantics" can
be handwaved away, too, layer after layer.

I used to think semantics and syntax were different, but at some point
I realized it was just a matter of semantics... or is it syntax?

As for the lower layers, one can always look at the assembly code by
switching to a different projection which may not even get materialized
until the code is actually run. Clearly there can be another projection
that shows stuff in the current syntax for backward compatibility.

Also one can look at compilation at any level as a projection and any
intermediate result can be shown to the user. If programs are stored in
structured form then it becomes easier to annotate information for
lower levels which can be hidden from various other views.

I've answered this somewhat above. I agree with pieces of this but
have a different take on some of it, and it's hard to tease it out in the
time I had this morning.

I think the text file approach is very limited, there is one widely
used projection (almost identity transformation) and it's extremly
difficult to create new transformations and annotate information.

On this, I agree the text file is very limited. And I agree it's useful
to have other approaches. But I don't agree that any given other approach
gives fundamentally more power. What I think is the ability to choose
is what gives the power.

I've sometimes said that the key to intelligence is not the choice of
representation but the ability to choose representation dynamically in an
appropriate way.

On another day, we can talk about whether there's any difference between
dynamic and static. (The argument may go something like the above for syntax
and semantics.)

.

Relevant Pages

  • Re: man page syntax for +script
    ... The man pages for [bind] and [comm hook] both describe how you can either replace the current script or append to it, but they give slightly different syntaxes. ... But the syntax for makes it appear that the + and the script are separate arguments, and that caused me some confusion. ... you have a distorted view of what is syntax and what is semantics in Tcl. ...
    (comp.lang.tcl)
  • Re: man page syntax for +script
    ... The man pages for and both describe how you can either replace the current script or append to it, but they give slightly different syntaxes. ... But the syntax for makes it appear that the + and the script are separate arguments, and that caused me some confusion. ... The plus is a semantic definition that these two unrelated commands put on their last argument, expr has a very different semantic definition of "+". ... you have a distorted view of what is syntax and what is semantics in Tcl. ...
    (comp.lang.tcl)
  • Re: Relative merits of Lisp-1 vs. Lisp-2?
    ... language syntax and semantics unless you think that by adding these ... clearly semantics will not. ... As for the lower layers, one can always look at the assembly code by ... Clearly there can be another projection ...
    (comp.lang.lisp)
  • Re: MV Keys
    ... In *practise*, you may not need to worry ... Through creative use of syntax, ... I don't envision a separate language; ... even within the given semantics. ...
    (comp.databases.theory)
  • Re: they mention various metaphors and ramble about various concerns (Re: Kuratowski Ordered Pair)
    ... it means to call x the semantics for syntax y? ... (kind of like your archaic understanding of syntax-semantics ... and i did not see much of substance in response ...
    (sci.math)