High Level vs Low Level

[Laurent Martelli]

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

  Jim> Sorry for the late response -- I was gone all weekend.

  Jim> Laurent Martelli wrote: 

  >> 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> It's not low-level, but Lisp's semantics are.  Lisp doesn't
  Jim> think "I need to dial a phone now" (high level) -- it thinks "I
  Jim> need to call a function now" (low level).

  Jim> There's lots and lots of advantages to having high-level
  Jim> language semantics rather than high-level library semantics,
  Jim> and they're all related to the compiler being able to do more.
  Jim> Optomization, interoperability, and platform-independence come
  Jim> to mind, but my favorite is compile-time error checking.  In my
  Jim> mind, the more errors you catch at compile time, the better,
  Jim> and a high-level language can do that.  Compare the effects of
  Jim> a typo under each approach:

  Jim> Lisp: (dial '555-=1212') -- This is a library call with a
  Jim> string.  Compiles fine, dies at runtime.  BUGGY!

  Jim> DSL: (dial '555-=1212') -- This is a language keyword with
  Jim> compile-time checking.  Results in compile error.  SAFE!

I agree that it's better to catch errors as early as possible. And I
think that lisp machines could detect a lot of errors at "compile"
time, without adding new semantics. I think that it's mainly a
question of pre/post conditions. 

Let consider that `dial' is defined as follow :

(defun dial (number)
  (check (phone-number-p number) "invalid phone number")
  ...
)

(defun check (bool)
  (if (not bool) (raise "invalid phone number)))

And you call (dial '555-=1234') somewhere.

Since the argument you give to `dial' is a constant, it would be
rather easy for the lisp-machine to see that this will always fail
because check will always raise an error. The compiler just need to
know that calling `raise' is wrong. No need that add new semantics. 

Anyway, I believe that compilers/interpreters should be opened so that
new optimizations can be added when you need them. Free Software is
one way to open programs, but it remains very difficult to "hack"
programs because they are not always designed to be easily hacked. The
philosophy is rather "You've got the sources, so shut up and hack". 

-- 
Laurent Martelli
martelli@iie.cnam.fr