Philosophical musings: interpreting models

[btanksley@hifn.com]

> From: Laurent Martelli [mailto:martelli@iie.cnam.fr]
> Subject: Re: Philosophical musings: interpreting models

> >>>>> "Jim" == Jim Little <jiml@inconnect.com> writes:

>   Jim> Laurent Martelli wrote:
>   >>  >>>>> "Jim" == Jim Little <jiml@inconnect.com> writes:

>   Jim> LISP's semantics are very clean, but they're also very
>   Jim> low-level.
>   >>  ??? To me the semantics of Lisp can be summed up as "call
>   >> functions with parameters which are objects, and do something
>   >> wity the result which is also an object. Plus the fact that you
>   >> can bind a symbol to an object". I think this is very high level
>   >> because it does not mention memory, CPU, storage, IO ...

>   Jim> I agree that it's better than hardware-level semantics, but I
>   Jim> still think Lisp's semantics are very low-level.  They don't
>   Jim> relate to real world actions, only mathematical ones.  Here's
>   Jim> what I see as high level semantics:

>   Jim> . Dial a phone number . Print a document . Display a picture
>   Jim> . Calculate income tax etc

> I'm sorry to insist :-) but the examples that you give can be
> expressed very simply with the semantic of lisp :

>         (dial phone-number)
>         (print document a-printer)
>         (display picture display-device) 
>         ;; note : it's the same as print actually
>         (calculate-income-tax salary)

> If a user wants to dial a phone number, he'll invoque the "dial"
> service and give it the number he wants to dial as a parameter. What's
> so low level in this ?

I don't understand Jim's insistence.  Jim, why is Lisp low-level?

>   Jim> Even if LISP were compiled, it couldn't understand that it's
>   Jim> allowed to compile the program "DISPLAY 'Hello world'" into a
>   Jim> windowed application AS WELL AS a console application.  A
>   Jim> very-high-level language's compiler would have that knowledge.
>   >>  What prevents you from writing such a display function which is
>   >> able to choose how to display depending on the device it can use
>   >> ? Why should the compiler have to do this when this can be done
>   >> at the "user-level" ?

>   Jim> Well, in addition to leading to large and difficult to
>   Jim> understand code, that approach isn't very flexible.  Languages
>   Jim> specify certain semantics and then the compiler has total
>   Jim> flexibility in how those semantics are implemented.  Different
>   Jim> compilers can implement the same semantics in totally different
>   Jim> ways, and compete based on the strength of those
>   Jim> implementations.  If you code the choice directly into your
>   Jim> function, there's no outside involvement and no way for two
>   Jim> different approaches to the same feature to compete.

> Well you can code two alternatives in the function, and choose with a
> simple if. And the compiler ought to be able to optimize the if.

Lisp is free to do this as well -- simply have the compiler implement
DISPLAY as a library function, which is defined to have the semantics you're
asking for.  It seems almost incredibly obvious.

Also, with Lisp's CLOS, which includes multiple dispatch, you can even have
the same function do appropriate things depending on which objects are its
parameters.

> Laurent Martelli

-Billy