gjc@mitech.COM (08/19/90)
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
ted@nmsu.edu (Ted Dunning) (08/21/90)
gjc@mitech.COM seems determined to defend his false advertising of siod as an implementation of scheme. to that end, In article <9008201428.AA01042@samsung.com> gjc@mitech.COM prevaricates: Ted Dunning had better gets his facts straight or else he will end up looking like the poor fool taken in by "the joke." i admit to having spent several hours trying to use siod to run scheme programs once. that seemed a lot like being the butt of a joke. Given that the source code to SIOD is so small he must be a very incompetent programmer to miss so much. naahhh... i only spent 30 minutes on noting the differences, mostly using an emacs macro to search the source. with so many omissions, it can be hard to exactly survey the damage. (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 ...) what _is_ the point in calling siod scheme when it isn't? what _is_ the point in writing it if it can't easily be extended to be scheme? > all string functions Wrong. string-append and read-from-string are in SIOD.C holy cow, this must be what they call support of strings, alright!!! but, of course, string-append doesn't work right and read-from-string isn't in the rev^3 report. what i was primarily referring to when i said string functions were the following functions: string?, make-string, string-length, string-ref, string-set!, string=?, string-ci=?, string<?, string-ci<?, string>?, string-ci>?, string<=?, string-ci<=?, string>=?, string-ci>=?, substring, string->list, list->string, string-copy, symbol->string, string->symbol and string-fill! but i got tired of typing and let it go with a generalizations. while i am in a listing mood, the following character functions were all missing, too: char? char=? char-ci=? char<? char-ci<? char>? char-ci>? char<=? char-ci<=? char>=? char-ci>=? char-alphabetic? char-numeric? char-whitespace? char-upper-case? char-lower-case? char->integer integer->char char-upcase char-downcase as well as the following vector functions: vector? make-vector vector vector-length vector-ref vector-set! vector->list list->vector vector-fill! > consp should be pair? What do you think this code does in SLIB.C init_subr("pair?",tc_subr_1,consp)? you are right. the use of consp (and defun and friends) is only residual lispishness, but not really errors in the schemeishness (or lack of same) of siod. > symbolconc should be more like append-string Well, symbolconc was useful, an old hack, in the definition of defmacro. of course, string handling would be more useful. > 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. given the macro facility you could even implement delay without much effort. > length It ain't length that matters, its ability! How many times do you have to be told this? (Note: this is a joke) joke, right. got it. but that is what i said in the first place, siod is a joke. > call/cc doesn't allow upward funargs Perhap it could be CALL/CC that really differentiates Scheme from just about every other programming language that exists. that includes differentiating scheme from siod. -- Offer void except where prohibited by law.
gls@THINK.COM (Guy Steele) (08/21/90)
Date: Sat, 18 Aug 90 21:06:13 EDT From: gjc@mitech.com ... Perhap it could be CALL/CC that really differentiates Scheme from just about every other programming language that exists. Indeed, although it reminds me of the definition of a human being as a "featherless biped": succinct but not necessarily to the point. --Guy
matthias@titan.rice.edu (Matthias Felleisen) (08/21/90)
To: gls@THINK.COM
Subject: Re: what makes programming?
Newsgroups: comp.lang.scheme
In-Reply-To: <9008202136.AA02170@mozart.think.com>
References: <9008201428.AA01042@samsung.com>
Organization: Rice University, Houston
Cc:
Bcc:
In article <9008202136.AA02170@mozart.think.com> Guy Steele writes
that some definition of Scheme in terms of CALL/CC "reminds [him] of
the definition of a human being as a 'featherless biped': succinct
but not necessarily to the point."
That's true, so let's try something better:
I. Syntax: Scheme's syntax is simple (minus a few glitches, which the
committee will eventually eliminate) and resembles a mathematical
language of algebraic expressions.
II. Type structure: Scheme is dynamically typed.
III. Core:
1. Scheme has first-class procedural values, described by a
Lambda-calculus-like syntax.
2. Scheme has assignments that can affect all (lexical) variables in
an unrestricted manner.
3. Scheme provides access to a first-class procedural abstraction
of the control state of the underlying evaluation machinery.
[4. Scheme implementations provide a modest form of a control delimiter
in the form of a read-eval-print loop. (Private Opinion)]
IV. Primitive Constants and Functions:
1. Scheme provides a fixed number of built-in sets of constants (domains),
symbols (an arbitrary set of elements that are in 1-1 correspondence
with identifiers), boolean values, several forms of numbers, strings,
vectors, and perhaps a few others.
2. Scheme provides a domain predicate for each domain of constants.
It also provides a domain predicate for procedural values (which is
the negation of all other domain predicates because Scheme has a
FIXED number of domains).
3. Scheme provides several ways for constructing values in each
domain, selecting components and destructively altering
components (if there are any).
V. Pragmatics: Scheme comes with a programming philosophy: Use the
least expressive fragment (starting with the functional core
progressing to continuations and side-effects), in which a problem can
be formulated naturally.
--- This is all there is. The rest is noise. -- Also, Standard ML
satisfies all of the above modulo I, II and IV(2) [crucial!], III(4)
[replaceable by reference cells as in Chez Scheme].
The above classification borrows some elements from Landin's [1]
informal attempt at classifying languages and my own first attempt [2] at
formalizing the ideas that were behind Landin's stuff and the
original Scheme design [3].
[1] {Landin, P.J}. The next 700 programming languages. {\it Commun.
ACM \bf9}(3), 1966, 157--166.
[2] {Felleisen, M}. On the expressive power of programming languages.
In {\it Proc. 1990 European Symposium on Programming}. Neil Jones,
Ed. Lecture Notes in Computer Science, 432. 1990, 134--151.
[3] {Steele, G.L., Jr. and G.J. Sussman}. Lambda: The ultimate
imperative. Memo 353, MIT AI Lab, 1976.
-- Matthiaspeter@ficc.ferranti.com (Peter da Silva) (08/22/90)
In article <TED.90Aug20125352@kythera.nmsu.edu> ted@nmsu.edu (Ted Dunning) writes: > what _is_ the point in writing it if it can't easily be extended to be > scheme? The point is to serve as a small extension language for C programs, to keep people from having to re-invent zillions of tiny inadequate macro languages and configuration file formats. For it to be small enough for this, it's a bit much to expect it to include all the functions in scheme. And it's a bit much to expect it to break C calling conventions. Before evaluating any tool, ask yourself what problem it's designed to solve. That hammer you're criticising might be a perfectly good hole-punch. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
colin@array.UUCP (Colin Plumb) (08/23/90)
In article <9008201428.AA01042@samsung.com> gjc@mitech.com writes: > Perhaps it could be CALL/CC that really differentiates Scheme from > just about every other programming language that exists. Possibly. I prefer just being able to get the enclosing continuation, as one language a friend wrote did by making it available in the magic identifier "return". The result looked a lot like C, except in the translations of the call/cc puzzles, which were littered with things like "return return;" Does anyone know why "call/cc" made it into scheme as the preferred way to access continuations? You often have code like: (call/cc (lambda (cc) (...code that uses cc...))) which seems slightly inelegant to me. -- -Colin
alms@cambridge.apple.com (Andrew L. M. Shalit) (08/24/90)
In article <578@array.UUCP> colin@array.UUCP (Colin Plumb) writes:
Does anyone know why "call/cc" made it into scheme as the preferred way
to access continuations? You often have code like:
(call/cc (lambda (cc) (...code that uses cc...)))
which seems slightly inelegant to me.
This means that CALL/CC can be a function. It doesn't have to be
a macro.
cf CALL-WITH-INPUT-FILE and CALL-WITH-OUTPUT-FILE.
For a case where people decided the extra syntax was worthwhile,
see LET, and LET*.
-andrew
--