technical implementation details in language interface 
Author Message
 technical implementation details in language interface

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...

Quote:
>|> ... 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.

Quote:

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



Mon, 08 Feb 1993 23:38:38 GMT  
 technical implementation details in language interface

Quote:

> 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.

Ack. So the solution to programming in X is to install a mid-70s-Forth style
non-pre-emptive O/S in every application. Why not go all the way and implement
threads? (Personally, I'd like to see threads become a relatively common
part of C runtimes. The mechanism required to implement threads should also
open the door to CALL/CC and all sorts of other interesting constructs.

(I would guess off the top of my head that doing threads on top of call/cc
 would be a snap)
--
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`



Tue, 09 Feb 1993 19:36:04 GMT  
 technical implementation details in language interface
George, thnx for your response to my questions. They were not meant
as "flaming attacks" at all, but if they were received as such, my
apologies. Your freely published SIOD *is* appreciated, and has made
scheme converts out of people who would not otherwise be interested.

Now, for specifics:

                                                 [marked with "|"]

|                                             ...followed up
| by telling us how great his new "PSI" thing is going to be.

Somebody asked, and I gave what I thought to be a reasonable summary of
its characteristics. I did not attach any value judgement nor comparisons
to that summary. Since it is not made public as yet, further discussion
is not fruitful.

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

I would not be in this profession if I didn't learn something
every day.

| ... once the PSI implementation is done ...

PSI provably existed for at least nine months now. It is my second
working scheme interpreter (first being an explicit control interpreter
straigth out of SICP), and my third attempt.

| 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.

I take this to be the crux of your argument, and I believe it is a
reasonable answer to my questions. Thanks.

oz
---

Next develop a style. Then forget all that      uucp: utzoo/utai!yunexus!oz
and just play.          Charlie Parker [?]      York U. CCS: (416) 736 5257



Thu, 11 Feb 1993 02:45:52 GMT  
 technical implementation details in language interface


[ ... something about XtAppMainLoop and XtAppAddWorkProc and solving the
callback problem in X by a call/cc style of doing things ... ]

peter> Ack. So the solution to programming in X is to install a
peter> mid-70s-Forth style non-pre-emptive O/S in every application. Why
peter> not go all the way and implement threads?

Alleluiah!

peter> (Personally, I'd like to see threads become a relatively common
peter> part of C runtimes. The mechanism required to implement threads
peter> should also open the door to CALL/CC and all sorts of other
peter> interesting constructs.

Actually, it is exactly the viceversa, because...

peter> (I would guess off the top of my head that doing threads on top
peter> of call/cc would be a snap)

... is the *only* way. To have threads, you *must* have continuations.
Look at it this way: a control switch is just saving the current
continuation and continuing to another one. The same is a wait on a
semaphore; you attach the current continuation to the semaphore queue,
and continue to a new one detached from the cpu queue. Processes never
"sleep" on a semaphore or "wait" to be run; you only have continuations,
some of which may be assigned to a CPU and thus making progress in real
time, and some not.  That's all; just continuation passing.
--

Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg



Sat, 13 Feb 1993 23:24:40 GMT  
 technical implementation details in language interface
(Why the "Allelulia"? I've been raving about making threads and coroutines
standard for ever).

Quote:

> ... is the *only* way. To have threads, you *must* have continuations.

On reflection it appears they're almost equivalent concepts, at least
for user level threads implemented via coroutines. Threads with O/S support
have a bit more baggage attached, particularly if they're preemptive.
--
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`



Mon, 15 Feb 1993 07:37:44 GMT  
 technical implementation details in language interface

Information for an ignorant Scheme Groupie please!

I'm a third year undergrad com sci major with little
experience with threads (I studied them briefly when
working with Mach). Can anyone give me a Thread and
Coroutine Primer?



Mon, 15 Feb 1993 22:57:19 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. You need detailed technical information on x86 processors?

2. OOP Implementation Details

3. Parse and some minor implementation details

4. Informations about implementation details

5. PEP 258: DPS Generic Implementation Details

6. yield: implementation details and other technica

7. Implementation details

8. Py: Technical Journal of the Python Language

9. Wanted: Technical term for a programming language concept

10. SUMMARY - Wanted: Technical term for a programming language concept

11. Wanted: Technical term for a programming language concept

 

 
Powered by phpBB® Forum Software