Philosophical musings: interpreting models

[Laurent Martelli]

>>>>> "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 ?

  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.

-- 
Laurent Martelli
martelli@iie.cnam.fr