gjc@mitech.COM (08/23/90)
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
peter@ficc.ferranti.com (Peter da Silva) (08/24/90)
In article <9008231801.AA27169@schizo> gjc@mitech.com writes: > 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` peter@ferranti.com
pcg@cs.aber.ac.uk (Piercarlo Grandi) (08/28/90)
On 24 Aug 90 11:36:04 GMT, peter@ficc.ferranti.com (Peter da Silva) said:
peter> In article <9008231801.AA27169@schizo> gjc@mitech.com writes:
[ ... 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.
--
Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukpeter@ficc.ferranti.com (Peter da Silva) (08/30/90)
(Why the "Allelulia"? I've been raving about making threads and coroutines standard for ever). In article <PCG.90Aug28162440@athene.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > ... 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` peter@ferranti.com
thompson@CEBAF4.CEBAF.GOV (Al Thompson) (08/30/90)
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?