Path: utzoo!attcan!uunet!decwrl!ucbvax!bloom-beacon!mitech.COM!gjc
From: gjc@mitech.COM
Newsgroups: comp.lang.scheme
Subject: what makes programming?
Message-ID: <9008201428.AA01042@samsung.com>
Date: 19 Aug 90 01:06:13 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: gjc@mitech.com
Organization: The Internet
Lines: 72

Ted Dunning had better gets his facts straight or else
he will end up looking like the poor fool taken in by "the joke."

Given that the source code to SIOD is so small he must be a very incompetent
programmer to miss so much. (The obvious stuff that is, at this point I
guess we cannot expect you to be able to understand the whole point of
having something like SIOD in the first place. Hobgoblins of little
minds and all that ...)

This will be pretty boring stuff for most people ... (D keys ready).

He says:

>i just grabbed siod again and note on quick examination the following
>missing features:

>   all string functions
Wrong. string-append and read-from-string are in SIOD.C
>and the following errors:
>   consp should be pair?
What do you think this code does in SLIB.C init_subr("pair?",tc_subr_1,consp)?
And then in SIOD.SCM I do this:
(define consp pair?)
Did that fool you? Hard to tell why, because even if you look at the
value of CONSP it prints out as #<SUBR(5) pair?>

So much for the obvious blunders.
>   symbolconc should be more like append-string
Well, symbolconc was useful, an old hack, in the definition of defmacro.
>   delay
>   force
Given that SIOD.SCM has a reasonable implementation of CONS-STREAM, HEAD,
and TAIL you can hardly fault an implementation for not providing the
names "delay" and "force" for you.
>   length
It ain't length that matters, its ability! How many times do you have to
be told this? (Note: this is a joke)
>   memq
Guilty as charged. But just to illustrate the extensibility aspect
of things:
LISP memq(e,list) LISP e,list;
{LISP l;
 for(l=list;CONSP(l);l=CDR(l)) if EQ(e,CAR(l)) return(l);
 return(NIL);}
>   memv
>   member
>   assv
>   assoc
At least this shows you spent some effort in reading the code,
because you didn't include ASSQ in your shit list. But
to tell the truth, I was going to remove ASSQ when it was no longer
needed by EVAL (between version 1.2 and 1.3 the environment was changed
from an alist to a framelist).
>   <= 
Guilty, old maclisp problem I guess, used to say (not (> x y)) instead.

Etc. Etc. 

>  call/cc doesn't allow upward funargs

The only interesting thing in the whole list. This is a real problem
in fact. call/cc was defined in terms of maclisp style *CATCH and
*THROW, which in C are implemented using setjmp and longjmp.
A radically different implementation, completely throwing out
the design goal of natural intermixing of lisp and C programming
(in natural styles) would be required otherwise. (Or much machine
specific assembly language).

Perhap it could be CALL/CC that really differentiates Scheme from
just about every other programming language that exists.

-gjc