Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!mitech.COM!gjc
From: gjc@mitech.COM
Newsgroups: comp.lang.scheme
Subject: technical implementation details in language interface
Message-ID: <9008231801.AA27169@schizo>
Date: 23 Aug 90 15:38:38 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: gjc@mitech.com
Organization: The Internet
Lines: 69

First learn computer science and all the theory.
Next develop a programming style. Then forget all
that and just hack.   George Carrette [1990]

So much for clever sayings. We must be all wondering, where is
this Ozan Yigit guy coming from with such flaming attacks on
somebodies freely published lisp implementation, followed up
by telling us how great his new "PSI" thing is going to be.

But there may be some learning going on here...

>|> ... it is extremely important to have a straightforward interface to
>|> code written in C? ...

>What does this have anything to do with a complete/proper implementation
>of the language? 

CALL/CC is the only thing really. The other stuff is lazyness combined
with not wanting to scare some people off with a lots of complexity.

>>In article <9008201428.AA01042@samsung.com> gjc@mitech.com writes:
>>A radically different implementation, completely throwing out
>>the design goal of natural intermixing of lisp and C programming ...

>I do not know what this means. Could you be more specific? What exactly
>is it that a radical implementation [presumably supporting full call/cc
>without assembler support] absolutely *cannot* do that SIOD can? Why is
>this so important?

Maybe the best thing I can say is that once the PSI implementation is done
one may be able, with carefully study perhaps, to see the difference more
clearly.

A portable approach to CALL/CC written in C (or common lisp, or pascal ...)
strongly suggests what is called an EXPLICIT CONTROL interpreter.

On the other hand SIOD is an IMPLICIT CONTROL interpreter.

Gee, thats it. No big deal. But explicit control vs implicit control
does have implications with respect to call sequences such as
FORTRAN->SCHEME->C->SCHEME->C->SCHEME->C...

From a theoretical point of view? Maybe just that the FORTRAN and C compilers
have been written with one way of handling the whole problem of procedure
calls and returns. By using IMPLICIT control in the Scheme interpreter one
allows the C compiler writer to decide *for-us* (implicitely) how procedure
calls are going to be made. But if we use EXPLICIT control then *we-decide*
and therefore we get no benefit from a lot of what the Hardware/Compiler
people who work for the company who sold us the computer have done for us.

This is NOT an argument against CALL/CC in general. Heck, in the near
future with stuff like the Open Software Foundations operating system
being based on Mach, which has all sorts of funny stuff having to do
control constructs, well, CALL/CC type things may be able to be done
in implicit control interpreters.

Actually CALL/CC may be an ideal way of dealing with X-Window application
programming at the XT level, which forces an EXPLICIT control model
because of the need for procedures called by XtAppMainLoop to return
"immediately". An explicit-control scheme interpreter which did
a certain quantum of work (for efficiency purposes) in a procedure
posted via XtAppAddWorkProc would be a workable way of dealing with this.

Compiled scheme code can also use explicit control of course, as long
as there is a driver loop someplace. But the XtAppAddWorkProc idea will
limit the amount of optimizations which are reasonable. (e.g. local labels
procedures turning into machine code with go-to's).

-gjc