Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!nmsu!opus!ted From: ted@nmsu.edu (Ted Dunning) Newsgroups: comp.lang.scheme Subject: Re: what makes programming? Message-ID: Date: 20 Aug 90 18:53:52 GMT References: <9008201428.AA01042@samsung.com> Sender: news@NMSU.Edu Organization: NMSU Computer Science Lines: 97 In-reply-to: gjc@mitech.COM's message of 19 Aug 90 01:06:13 GMT 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>=?, 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-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.