Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA 17 Sep 85 15:39:06 EDT Received: from indiana by csnet-relay.csnet id a014789; 17 Sep 85 15:33 EDT Date: Tue, 17 Sep 85 10:19:37 est From: Kent Dybvig To: MIT-MC!JAR%unc.csnet@CSNET-RELAY.ARPA, SCHEME@mit-mc.ARPA Subject: Re: report; scheme in CL; trace Chez Scheme supports two interfaces for tracing. One is available to the user after his program is entered (the normal "trace" interface) and the other must be imbedded in the program ("trace-lambda" or "trace-recur"). "trace" works only as you say, for the outermost invocation of a function created with "defrec", and not at all for let- or letrec-bound lambda expressions. Using "trace-lambda" in place of "lambda" or "trace-recur" in place of "recur" causes the same tracing that "trace" provides. In order to provide the user with a handle on the traced function, the "trace-lambda" syntax requires an identifier to precede the formal parameters. The only disadvantage of "trace-lambda" is that the program must be reentered to be traced. This can have a significant impact on an interactive session unless multiple windows are provided. Kent Dybvig dyb.Indiana@CSnet-Relay  Date: Mon, 16 Sep 85 16:06:36 EDT From: Jonathan A Rees Subject: report; scheme in CL; trace To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].646835.850916.JAR> [Topic #1:] MIT AI memo 848, the Revised Revised Report on Scheme, is back from the printer. The text is exactly the same as what most of you received in the mail about a month ago, but is is now available in quantity, and is has a nice binding with a blue cover. They can be ordered from: Elizabeth Heepe Publications, Room NE43-818 MIT Artifical Intelligence Laboratory 545 Technology Square Cambridge MA 02139 Enclose a check for $6.00 per copy (U.S. funds) payable to the MIT Artificial Intelligence Laboratory. If you are strapped for cash or you need it quickly, I can send you one directly myself, bypassing the publications office. [Topic #2:] I have written, as a quick hack, and with the generous support of DEC, an implementation of the essential subset (and a little more) of RRRSS, in Common Lisp. (RRRSS is my abbreviation for Revised Revised Report on Scheme Scheme.) It works by translating RRRSS into Common Lisp; tail recursion is accomplished by compiling calls in a peculiar way (incompatible with the host Common Lisp's procedure caall, which will not necessarily be tail recursive at the right time). If you are interested in testing it out for me, and sending remarks & bug reports, I'd be grateful. The plan is to eventually make this part of the Common Lisp "Yellow Pages." I'll mail the source code to anyone requesting it. [Topic #3:] I'm curious to know how implementors have dealt with the problem of causing trace (i.e. debugging) packages to interact properly with (DEFINE (FOO ...) ...). I.e. if one says (TRACE FOO) [or (TRACE 'FOO) or whatever your local syntax is], one would like all recursive calls from FOO to itself to be traced. Especially tricky to make this work with native-code compilers. I think this was one reason why in T we made (DEFINE (FOO ...) ...) be the same as (DEFINE FOO (LAMBDA (. ...) ...)), instead of using the MIT and RRRSS semantics, because then TRACE can be implemented at the source code level, as (SET! FOO (MAKE-TRACED-PROCEDURE FOO)), without any need to know the underlying representation. What have other people done? Jonathan  Date: Mon, 12 Aug 85 10:47:18 EDT From: Jonathan A Rees Subject: delay, force, cons-stream To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].609180.850812.JAR> Could someone remind me why DELAY, FORCE, and CONS-STREAM aren't in the RRReport, even non-essentially? This absence seems inconsistent with the presence of SEQUENCE, which exists only because it appears in S&ICP. DELAY, FORCE, and CONS-STREAM also are used in S&ICP. Jonathan  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 9 AUG 85 19:24:22 EDT Date: 9 Aug 1985 19:22 EDT (Fri) Message-ID: From: Bill Rozas To: Jonathan A Rees Cc: SCHEME@MIT-MC.ARPA Subject: Altering quoted structure In-reply-to: Msg of 9 Aug 1985 18:40-EDT from Jonathan A Rees I agree with you even though MIT Scheme does not detect alterations to quoted structure. I think the report should say it is an error to modify them. PS : What do you do about Gcing quoted structure if it is in read-only memory? Is it not garbage-collectable? Is the garbage collector special?  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 9 AUG 85 19:20:04 EDT Date: 9 Aug 1985 19:18 EDT (Fri) Message-ID: From: Bill Rozas To: Jonathan A Rees Cc: SCHEME@MIT-MC.ARPA Subject: (EQV? #\? #\?) ? In-reply-to: Msg of 9 Aug 1985 18:47-EDT from Jonathan A Rees yes!!  Date: Fri, 9 Aug 85 18:51:15 EDT From: Jonathan A Rees Subject: Altering quoted structure, addendum To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].607118.850809.JAR> The example (define vec '#(0 (2 2 2 2) "Anna")) --> vec (vector-set! vec 1 '("Sue" "Sue")) --> unspecified vec --> #(0 ("Sue" "Sue") "Anna") is also at fault, and can be fixed the same way as the other one. Jonathan.  Date: Fri, 9 Aug 85 18:47:31 EDT From: Jonathan A Rees Subject: (EQV? #\? #\?) ? To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].607113.850809.JAR> Could we agree that EQV? should do a CHAR=? comparison on characters? Jonathan?  Date: Fri, 9 Aug 85 18:40:58 EDT From: Jonathan A Rees Subject: Altering quoted structure To: SCHEME@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].607100.850809.JAR> I would like to point out a small problem in an example in section II.4, "Pairs and lists." The following interaction: (define x '(a b c)) --> x (define y x) --> y (set-cdr! x 4) --> unspecified x --> (a . 4) (eq? x y) --> #!true y --> (a . 4) will not necessarily work in implementations (e.g., Yale's) where quoted structure may be stored in read-only memory. I don't think the report says anything about quoted structure being immutable, but I think that it is very important that implementations be allowed to make them be read-only. I recommend that the description of QUOTE (which is perhaps too terse even for my taste) be amended appropriately. The example can easily be fixed: just write (define x (list 'a 'b 'c)) instead of (define x '(a b c)) . While the report can only specify that modifying quoted structure "is an error," I would consider it any implementation which doesn't detect such modifications to be deficient. It isn't done because it's difficult. Jonathan  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 5 AUG 85 21:51:34 EDT Date: Mon, 5 Aug 1985 21:49 EDT Message-ID: From: CPH%MIT-OZ@MIT-MC.ARPA To: Kent Dybvig Cc: Bartley%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA, mw%brandeis.csnet@CSNET-RELAY.ARPA, scheme@MIT-MC.ARPA Subject: identifiers and symbols In-reply-to: Msg of 5 Aug 1985 00:03-EDT from Kent Dybvig Date: Monday, 5 August 1985 00:03-EDT From: Kent Dybvig I think that we should point out that certain objects may be translated into Scheme expressions, with emphasis on translation (that is, say that it may require writing the object to a file and handing the compiler the resulting file). I personally am opposed to any mention of files or compilers in such a manner. These are completely orthogonal to what I consider the essence of the programming language (and programming environment), and serve only the cloud the real issues, not clear them up. Ideally I would like an environment without files, and without any explicit compilation, in which all of that non-essential stuff happens transparently to me. I'm interested in writing and debugging procedures and data structures, not files of characters. If we lose the idea of "program as data" people will wonder what we are still using all these parentheses for. Independent of the "program as data" feature, those parentheses are still an essential aspect of the SIMPLICITY of Scheme (and Lisp) syntax. This is, I think, even more important than the fact that a Scheme program is representable as a data structure. One can, for example, represent a Pascal or C program as a data structure in one of those languages (albeit clumsily), but that does not make the external syntax any simpler. To allow the potential for translation requires that we agree upon a common representation for programs as data. I think that this is completely irrelevant as we have not included the EVAL procedure in the Scheme standard. Nothing else in the standard relates to such a representation in any way.  Received: from csnet-relay by MIT-MC.ARPA 5 Aug 85 21:36:53 EDT Received: from unc by csnet-relay.csnet id ah10818; 5 Aug 85 21:29 EDT Received: from unc (dopey) by thorin (4.12/4.7) id AA15806; Mon, 5 Aug 85 00:03:04 edt Received: by unc (4.12/4.7) id AA25673; Mon, 5 Aug 85 00:03:23 edt Date: Mon, 5 Aug 85 00:03:23 edt From: Kent Dybvig Message-Id: <8508050403.AA25673@unc> To: Bartley%CSL60%ti-csl.csnet@csnet-relay.arpa, mw%brandeis.csnet@csnet-relay.arpa Subject: Re: identifiers and symbols Cc: scheme@mit-mc.ARPA In reading the draft Scheme report, it appears that the possibility is left open for identifiers and symbols to be distinct. For example, the first paragraph in Section II.5 says that symbols are often used to represent identifiers, implying that other alternatives are possible. Is this correct? If so, are identifiers defined as objects (how do they behave)? Does read of "X" return an identifier or a symbol? Alan Snyder I think of an "identifier" as a non-terminal in the grammar, while a "symbol" is a datatype, so identifiers are not objects, and READ of X returns a symbol. The reason identifiers and symbols are distinct is that we don't want to impose the implementation requirement that a Scheme program must be internally represented as an s-expression. In particular, an identifier in a program may be lexically processed by a compiler without passing through READ at all, and therefore need not be represented as a symbol. Having identifiers and symbols obey the same syntax rules is just a way to facilitate the representation of identifiers by symbols, but it doesn't require it. I periodically pick this nit because many non-Schemers confuse "symbols" with "variables." Further distinguishing "symbols" from "identifiers" is meaningful to me, and seems to be implied by Will's wording, but may be more controversial. Does anyone else see things this way, or am I outside the pale (again)? David Bartley ------- _________________________________ Yes, I think you've got it right. Identifiers are part of the external syntax of Scheme programs; symbols are a kind of data manipulated by those programs. Symbols have an external representation as character strings, which typically, though not necessarily, coincides with the external syntax of identifiers. One of the most important differences between Lisp and Scheme is, as you point out, the rigid separation between programs and data, and between syntax and semantics. Most Lisp dialects constrain programs to be maintained as S-expressions; Scheme very carefully does not. For more on this, see the paper by Muchnick and Pleban, A Semantic Comparison of Lisp and Scheme, in the 1980 Lisp Conference. -- Mitch __________________ I think that we should point out that certain objects may be translated into Scheme expressions, with emphasis on translation (that is, say that it may require writing the object to a file and handing the compiler the resulting file). If we loose the idea of "program as data" people will wonder what we are still using all these parentheses for. To allow the potential for translation requires that we agree upon a common representation for programs as data. The natural one is the one that prints the way we expect, with symbols denoting identifiers and special form keywords. The wording might go, "If a Scheme object is to be translated into a Scheme program, identifiers are represented by symbols, special forms are represented by lists, ..." This does require the syntax for identifiers to be a subsyntax (?) of the syntax for symbols. In spite of the conclusions of Muchnick and Pleban, I believe that we should support an object-level representation for Scheme programs. One of the beauties of Scheme is the ability to write macro processors and compilers for Scheme in Scheme (easily), and the lack of this ability is the one thing I dislike most about ML. Kent  Received: from csnet-relay by MIT-MC.ARPA 2 Aug 85 16:39:03 EDT Received: from brandeis by csnet-relay.csnet id aa09446; 2 Aug 85 16:31 EDT Received: by brandeis.ARPA (4.12/4.7) id AA00810; Fri, 2 Aug 85 11:46:14 edt Date: 2 Aug 1985 11:39-EST From: mw%brandeis.csnet@csnet-relay.arpa In-Real-Life: Mitchell Wand,faculty Subject: Re: identifiers and symbols To: David Bartley Cc: scheme@mit-mc.ARPA Message-Id: <491845196/mw@brandeis> In-Reply-To: David Bartley's message of 31 Jul 1985 1808-CDT _________________________________ From BARTLEY%ti-csl.csnet%CSNET-RELAY@MIT-MC.ARPA Thu Aug 1 16:24:38 1985 Date: 31 Jul 1985 1808-CDT From: David Bartley Subject: Re: identifiers and symbols To: CPH%MIT-OZ@MIT-MC, Snyder%hplabs.csnet@CSNET-RELAY Cc: Scheme@MIT-MC, Bartley%CSL60%ti-csl.csnet@CSNET-RELAY Status: O In reading the draft Scheme report, it appears that the possibility is left open for identifiers and symbols to be distinct. For example, the first paragraph in Section II.5 says that symbols are often used to represent identifiers, implying that other alternatives are possible. Is this correct? If so, are identifiers defined as objects (how do they behave)? Does read of "X" return an identifier or a symbol? Alan Snyder I think of an "identifier" as a non-terminal in the grammar, while a "symbol" is a datatype, so identifiers are not objects, and READ of X returns a symbol. The reason identifiers and symbols are distinct is that we don't want to impose the implementation requirement that a Scheme program must be internally represented as an s-expression. In particular, an identifier in a program may be lexically processed by a compiler without passing through READ at all, and therefore need not be represented as a symbol. Having identifiers and symbols obey the same syntax rules is just a way to facilitate the representation of identifiers by symbols, but it doesn't require it. I periodically pick this nit because many non-Schemers confuse "symbols" with "variables." Further distinguishing "symbols" from "identifiers" is meaningful to me, and seems to be implied by Will's wording, but may be more controversial. Does anyone else see things this way, or am I outside the pale (again)? David Bartley ------- _________________________________ Yes, I think you've got it right. Identifiers are part of the external syntax of Scheme programs; symbols are a kind of data manipulated by those programs. Symbols have an external representation as character strings, which typically, though not necessarily, coincides with the external syntax of identifiers. One of the most important differences between Lisp and Scheme is, as you point out, the rigid separation between programs and data, and between syntax and semantics. Most Lisp dialects constrain programs to be maintained as S-expressions; Scheme very carefully does not. For more on this, see the paper by Muchnick and Pleban, A Semantic Comparison of Lisp and Scheme, in the 1980 Lisp Conference. -- Mitch  Received: from csnet-relay by MIT-MC.ARPA 1 Aug 85 12:05:09 EDT Received: from ti-csl by csnet-relay.csnet id ad01020; 1 Aug 85 11:54 EDT Date: 31 Jul 1985 1808-CDT From: David Bartley Subject: Re: identifiers and symbols To: CPH%MIT-OZ@mit-mc.ARPA, Snyder%hplabs.csnet@csnet-relay.arpa cc: Scheme@mit-mc.ARPA, Bartley%CSL60%ti-csl.csnet@csnet-relay.arpa In-Reply-To: Your message of 31-Jul-85 1658-CDT Received: from csl60 by ti-csl; Wed, 31 Jul 85 19:05 CST In reading the draft Scheme report, it appears that the possibility is left open for identifiers and symbols to be distinct. For example, the first paragraph in Section II.5 says that symbols are often used to represent identifiers, implying that other alternatives are possible. Is this correct? If so, are identifiers defined as objects (how do they behave)? Does read of "X" return an identifier or a symbol? Alan Snyder I think of an "identifier" as a non-terminal in the grammar, while a "symbol" is a datatype, so identifiers are not objects, and READ of X returns a symbol. The reason identifiers and symbols are distinct is that we don't want to impose the implementation requirement that a Scheme program must be internally represented as an s-expression. In particular, an identifier in a program may be lexically processed by a compiler without passing through READ at all, and therefore need not be represented as a symbol. Having identifiers and symbols obey the same syntax rules is just a way to facilitate the representation of identifiers by symbols, but it doesn't require it. I periodically pick this nit because many non-Schemers confuse "symbols" with "variables." Further distinguishing "symbols" from "identifiers" is meaningful to me, and seems to be implied by Will's wording, but may be more controversial. Does anyone else see things this way, or am I outside the pale (again)? David Bartley -------  Date: Wed, 31 Jul 85 17:46:03 EDT From: Jonathan A Rees Subject: identifiers and symbols To: Snyder%hplabs.csnet@CSNET-RELAY.ARPA cc: SCHEME@MIT-MC.ARPA, CPH@MIT-OZ Message-ID: <[MIT-MC.ARPA].595673.850731.JAR> Date: Tuesday, 30 July 1985 15:54-EDT From: Snyder%hplabs.csnet at csnet-relay.arpa In reading the draft Scheme report, it appears that the possibility is left open for identifiers and symbols to be distinct. For example, the first paragraph in Section II.5 says that symbols are often used to represent identifiers, implying that other alternatives are possible. Is this correct? If so, are identifiers defined as objects (how do they behave)? Does read of "X" return an identifier or a symbol? I think you're confusing domains which Lisp blurs, but that the report takes care to distinguish. The beginning of section II.1, "special forms," says that identifiers, whose syntax is given previously, have two uses (i.e. occur in the grammar in the rhs of two productions): as 's, where they name variables; and inside of 's, where they notate symbols, a particular kind of value. Identifiers, being syntactic, can no more be user-level objects (i.e. values) than can combinations or special forms. Your typical Lisp manual (including, I hate to say, the T manual) starts out the other way around by saying that data (lists, symbols, numbers) can be notated using character strings of a certain form, and then says that data can be interpreted as being program: a symbol can be a variable name, a list can be a combination, etc. The Scheme report asks you to imagine that the fact that programs and data are notated pretty similarly is coincidental. It never says that a program is "read" from a file using a READ function, and then parsed and interpreted through a separate mechanism. Conceivably some poor soul could translate the grammar from the Scheme report into YACC, and write a Scheme system in C, in which maybe identifiers are represented as arrays of small integers, and symbols and lists never come into existence at all, except when a (QUOTE ...) form is evaluated, STRING->SYMBOL is called, etc. The representation of identifiers, like that of numbers, is completely invisible to the user. READ of "X" presumably invokes that part of the Scheme parser which deals with the nonterminal, and returns the appropriate value, as if you had evaluated (QUOTE X) instead of (READ ...); so the value would be a symbol. I think that the statement in section II.4, "Even Lisp and Scheme programs are lists," while true in spirit, is not accurate. But it's difficult to come up with a concise way to connect the two concepts. You'd have to say something to the effect that any sequence of terminals derivable from the nonterminal could also be derived from the nonterminal (can this be inferred from the report? Can 'foo and `(a ,b) be derived from ?). Sorry to be so pedantic... I hope this clarifies things. Jonathan  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 31 JUL 85 14:57:20 EDT Date: Wed, 31 Jul 1985 14:52 EDT Message-ID: From: CPH%MIT-OZ@MIT-MC.ARPA To: Snyder%hplabs.csnet@CSNET-RELAY.ARPA Cc: Scheme@MIT-MC.ARPA Subject: identifiers and symbols In-reply-to: Msg of 30 Jul 1985 15:54-EDT from Snyder%hplabs.csnet at csnet-relay.arpa Date: Tuesday, 30 July 1985 15:54-EDT From: Snyder%hplabs.csnet at csnet-relay.arpa To: cph at mit-mc.ARPA Re: identifiers and symbols Source-Info: From (or Sender) name not authenticated. In reading the draft Scheme report, it appears that the possibility is left open for identifiers and symbols to be distinct. For example, the first paragraph in Section II.5 says that symbols are often used to represent identifiers, implying that other alternatives are possible. Is this correct? If so, are identifiers defined as objects (how do they behave)? Does read of "X" return an identifier or a symbol? Alan Snyder Technically, these two types might be distinct. Practically speaking, there seems little point in doing so. But there is no reason that the report should contain this unnecessary bias. On the other hand, since it is (perhaps) universally true that they are not distinct, I guess that Will did not think the extra effort of completely separating them was worth it. Trying to decide which gets used where (e.g. in READ) might take some time. And if you just assume that they are the same, then (I think) the rest of the report is pretty consistent. But I'm just guessing. I'll forward this to Scheme@MC, which will get you a much wider range of opinions -- that is the best place to send mail concerning the report, since everyone who helped make it will be available to reply.  Date: Tue, 30 Jul 85 22:59:41 EDT From: George J. Carrette Subject: Ambiguous number syntax To: gls@THINK-AQUINAS.ARPA cc: SCHEME@MIT-MC.ARPA, Bartley%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA, MMeyer%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA, GJS@MIT-OZ In-reply-to: Msg of Mon 29 Jul 85 13:06 EDT from Guy Steele Message-ID: <[MIT-MC.ARPA].594615.850730.GJC> Fortunately there is always #.(J-RANDOM-NUMBER "...random syntax")  Received: from THINK.ARPA by MIT-MC.ARPA 29 Jul 85 13:11:25 EDT Received: by THINK.ARPA with CHAOS; Mon, 29 Jul 85 13:07:02 edt Date: Mon, 29 Jul 85 13:06 EDT From: Guy Steele Subject: Re: Ambiguous number syntax To: GJS%MIT-OZ@MIT-MC.ARPA, Bartley%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA Cc: Scheme@MIT-MC.ARPA, MMeyer%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 27 Jul 85 20:14-EDT from Gerald Jay Sussman Message-Id: <850729130650.4.GLS@POLYCARP.ARPA> Date: Sat 27 Jul 85 20:14:38-EDT From: Gerald Jay Sussman I am doing the last pass now... (1) The RRReport states on page 48 that is denoted by #h or #H, while stating on page 50 that the prefix for hex values is #X. Since Common Lisp uses #X for "hexadecimal rational" values, we prefer to believe that the mention of #H on page 48 is a typographical error. Would anyone like to argue otherwise? That was indeed a typo. I will fix it. (2) Is it possible to write a number in base 16 scientific notation? How is the letter 'e' or 'E' to be interpreted -- as a hex digit or the start of the exponentiation suffix? I don't really have a good idea about that. Perhaps we should defer any decisions until someone wants to do it! (sounds unlikely). I actually hate hex and wish it would go away. ------- I cannot resist passing on one proposal for radix syntax that was considered for Common Lisp (and rejected, so take it with a grain of salt!). First, observe thsat traditional mathematical syntax for a radix is a trailing subscript: 1000 = 512 8 10 Second, observe that many non-LISP languages uses parentheses or brackets for subscripting. Well, we can't use parentheses, so try brackets: (EQUAL? 1000[8] 512[10]) For historical compatibility, we also allow 512. to mean the same as 512[10] . Therefore "." means the same as "[10]". So extend this notion to the floating-point notation: 3.14159265 means the same as 3[10]14159265 and now we have an unambiguous place to put the radix: 3[10]1415926535 approximately equals 3[8]11037552 If you really can't stand that, we could settle for 3.11037552[8], where the "[...]" overrides the decimalness of the ".". This still doesn't solve the problem of whether "E" is a hex digit or an exponent marker. Well, the "E" serves two purposes" as a delimiter between significand and exponent, and as a precision indicator (other choices are "D" and perhaps "S", "F", "L", or whatever). One might wish to measure precision in bits. So gobble down "<...>" for this purpose. Then "E" is just an abbreviation for "<24>" or whatever: Pi is approximately [8]311037552<24>+1 If "E" might be taken as a digit, then one must write "<24>" or "". Pretty horrible, huh? --Guy  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 27 JUL 85 20:15:38 EDT Date: Sat 27 Jul 85 20:14:38-EDT From: Gerald Jay Sussman Subject: Re: Ambiguous number syntax To: Bartley%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA cc: Scheme@MIT-MC.ARPA, MMeyer%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA In-Reply-To: Message from "David Bartley " of Fri 26 Jul 85 11:06:00-EDT I am doing the last pass now... (1) The RRReport states on page 48 that is denoted by #h or #H, while stating on page 50 that the prefix for hex values is #X. Since Common Lisp uses #X for "hexadecimal rational" values, we prefer to believe that the mention of #H on page 48 is a typographical error. Would anyone like to argue otherwise? That was indeed a typo. I will fix it. (2) Is it possible to write a number in base 16 scientific notation? How is the letter 'e' or 'E' to be interpreted -- as a hex digit or the start of the exponentiation suffix? I don't really have a good idea about that. Perhaps we should defer any decisions until someone wants to do it! (sounds unlikely). I actually hate hex and wish it would go away. -------  Received: from csnet-relay by MIT-MC.ARPA 27 Jul 85 01:51:17 EDT Received: from ti-csl by csnet-relay.csnet id ae10910; 27 Jul 85 1:46 EDT Date: 26 Jul 1985 1006-CDT From: David Bartley Subject: Ambiguous number syntax To: Scheme@mit-mc.ARPA cc: Bartley%CSL60%ti-csl.csnet@csnet-relay.arpa, MMeyer%CSL60%ti-csl.csnet@csnet-relay.arpa Received: from csl60 by ti-csl; Fri, 26 Jul 85 18:48 CST (1) The RRReport states on page 48 that is denoted by #h or #H, while stating on page 50 that the prefix for hex values is #X. Since Common Lisp uses #X for "hexadecimal rational" values, we prefer to believe that the mention of #H on page 48 is a typographical error. Would anyone like to argue otherwise? (2) Is it possible to write a number in base 16 scientific notation? How is the letter 'e' or 'E' to be interpreted -- as a hex digit or the start of the exponentiation suffix? David Bartley, Mark Meyer -------  Received: from csnet-relay by MIT-MC.ARPA 26 Jul 85 17:43:23 EDT Received: from ti-csl by csnet-relay.csnet id ah08928; 26 Jul 85 17:36 EDT Date: 25 Jul 1985 1055-CDT From: David Bartley Subject: Re: Scheme Not Tail Recursive!!!???? To: GJS%MIT-OZ@mit-mc.ARPA, willc%tekchips%tektronix.csnet@csnet-relay.arpa cc: oxley%ti-csl.csnet@csnet-relay.arpa, scheme@mit-mc.ARPA, Bartley%CSL60%ti-csl.csnet@csnet-relay.arpa In-Reply-To: Your message of 25-Jul-85 0638-CDT Received: from csl60 by ti-csl; Thu, 25 Jul 85 13:06 CST I agree with Don and Gerry. The standard has to take some notice of the finiteness of machines (why else have INEXACT?). Also, the 1978 revised report specifically states that "Scheme is implemented in such a way that tail-recursions execute without net growth of the interpreter stack." Leaving such a statement out of the revised revised report would seem to imply that the language has changed in that respect. -------  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 25 JUL 85 16:08:23 EDT Date: 25 Jul 1985 15:39 EDT (Thu) Message-ID: From: Bill Rozas Subject: previous message To: scheme@MIT-MC.ARPA I apologize for my previous message, the message does not read as I expected. It was certainly not my intent to to alienate anybody.  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 25 JUL 85 14:09:08 EDT Date: 25 Jul 1985 11:49 EDT (Thu) Message-ID: From: Bill Rozas To: Don Oxley Cc: Scheme@MIT-MC.ARPA, Willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Subject: Scheme Not Tail Recursive!!!???? In-reply-to: Msg of 23 Jul 1985 17:02-EDT from Don Oxley I think we should be fairly harsh about this issue. I don't consider an implementation which is not properly tail recursive an acceptable implementation. Note also that by properly tail recursive I don't mean something which just "optimizes" reduction self-calls, but rather one that keeps a minimum amount of state on any reduction. I don't understand your objections about the extent of fluid variables. I don't think a variable binding is an object, and certainly in the context of the report there is no way of obtaining it or manipulating it as an object (so it would not be first class at least). Not being an object, its extent can be limited. However, the objects being "dynamically bound" must certainly have unlimited extent. This difference is similar to the difference between a macro (whatever that may be), and a macro expander, which is a legitimate object (probably a procedure). Both variable bindings and macros are conceptual entities with no counterpart in the language, the objects bound to and the macro expanders are "real" objects which are subject to the same contraints as all other objects. Note also that even if something has formally unlimited extent, if an implementation can prove that it is no longer accessible it can recalim its storage. This is what gc is based on, but nobody claims that any implementation must wait until an actual system-wide gc to reclaim pieces of storage.  Date: Thu, 25 Jul 85 14:16:00 EDT From: Jonathan A Rees Subject: Are fluids objects? To: OXLEY%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA cc: SCHEME@MIT-MC.ARPA, Willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Message-ID: <[MIT-MC.ARPA].587507.850725.JAR> Date: 23 Jul 1985 1602-CDT From: Don Oxley A much more picky point. On page 7, is the statement that ALL objects have unlimited extent. Since fluid variables have dynamic extent, it seems to me that a picky interpretation could preclude fluid variables in the language (the counter argument of course is that is a sufficient base to implement fluids). Would a bit of clarification be helpful? I'm no semantics wiz, but I think that "object" is used consistently in the Scheme and Lisp literature to mean what corresponds to "expressed value" in denotational semanticses. Perhaps this point should be made somewhere. But I believe that if this point is understood, nothing need be said about fluids, since they are not necessarily objects (expressed values). Anything at all can have dynamic extent if it pleases, as long as it is not an object. On the other hand, I don't think the report should preclude language extensions, and some of these extensions might include various kinds of second-class citizens, including perhaps objects with only dynamic extent. (I don't think I'd do such a thing, but someone else might.) If other people agree with me on this, maybe some clarification of the statement on page 7 is in order. Jonathan  Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 25 JUL 85 06:39:15 EDT Date: Thu 25 Jul 85 06:39:18-EDT From: Gerald Jay Sussman Subject: Re: Scheme Not Tail Recursive!!!???? To: willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA cc: oxley%ti-csl.csnet@CSNET-RELAY.ARPA, scheme@MIT-MC.ARPA In-Reply-To: Message from "Will Clinger " of Wed 24 Jul 85 22:47:15-EDT Unless anyone objects, I will insert a one-liner stating that we expect both tail-recursion and dynamic storage allocation and deallocation are assumed in any legit implementation (consistent with modern hardware implementations) -------  Received: from csnet-relay by MIT-MC.ARPA 24 Jul 85 22:44:31 EDT Received: from tektronix by csnet-relay.csnet id ac20001; 24 Jul 85 21:42 EDT From: Will Clinger To: oxley%ti-csl.csnet@csnet-relay.arpa Cc: scheme@MIT-MC.ARPA Received: from tekchips by tektronix with smtp ; 24 Jul 85 17:47:51 PDT Date: Wednesday, 24 Jul 85 17:33:05 PDT Subject: Re: Scheme Not Tail Recursive!!!???? In-reply-to: Your message of 23 Jul 1985 1602-CDT. Finite Memories Considered Harmful (same song, second verse) Tail recursion is an implementation issue rather than a matter of semantics. Gedanken experiment: the Incredibly Big Machine Corporation decides that it can increase its profits by compiling tail recursion improperly while bundling its machines with a contract that calls for customers to add 10^13 bytes of RAM each month as part of preventive maintenance. Likewise garbage collection is an implementation issue, not a matter of semantics. There's nothing in the Revised Revised Report to mandate a garbage collector. On the other hand: Anything that causes programs to run out of memory is a bug. It may be that the Incredibly Big Machine Corporation is shipping a bug-free product. That cannot be said for any implementation that uses a finite memory. It is philosophically inconsistent to insist upon proper treatment of tail recursion and upon garbage collection while allowing finite memories. Of course, people know to ask about the finite memory bug when they purchase a computer. Indeed, the bug is often advertised. Not so many people know to ask about tail recursion and garbage collectors, so maybe we should be inconsistent. William Clinger  Received: from csnet-relay by MIT-MC.ARPA 24 Jul 85 22:26:05 EDT Received: from ti-csl by csnet-relay.csnet id ac16288; 24 Jul 85 7:55 EDT Date: 23 Jul 1985 1602-CDT From: Don Oxley Subject: Scheme Not Tail Recursive!!!???? To: Willc%tekchips%tektronix.csnet@csnet-relay.arpa cc: Scheme@mit-mc.ARPA Received: from csl60 by ti-csl; Wed, 24 Jul 85 00:53 CST In reading the revised, revised report, I can find no statement - either direct or inferred, that Scheme is required to be properly tail recursive. Did I overlook something? I suggest a requirement to that effect be inserted (as an errata if necessary) on page 8. A much more picky point. On page 7, is the statement that ALL objects have unlimited extent. Since fluid variables have dynamic extent, it seems to me that a picky interpretation could preclude fluid variables in the language (the counter argument of course is that is a sufficient base to implement fluids). Would a bit of clarification be helpful? --Don PS. Sorry for nitpicking AFTER the report is out, but sometimes you have to be writing your own manual to be able to read another carefully. -------  Received: from mitre-bedford by MIT-MC.ARPA 24 Jul 85 19:20:04 EDT Date: 24 Jul 1985 17:35:50-EDT From: linus!ramsdell@Mitre-Bedford Received: by linus.UUCP (4.12/4.7) id AA16213; Wed, 24 Jul 85 08:00:35 edt Date: Wed, 24 Jul 85 08:00:35 edt From: linus!ramsdell (John D. Ramsdell) Message-Id: <8507241200.AA16213@linus.UUCP> To: bccvax!scheme@mit-mc.arpa Received: by linus.UUCP (4.12/4.7) id AA07000; Tue, 23 Jul 85 07:57:28 edt Date: Tue, 23 Jul 85 07:57:28 edt From: ramsdell (John D. Ramsdell) Message-Id: <8507231157.AA07000@linus.UUCP> To: bccvax!scheme@mit-mc.arpa Subject: CSI Lisp Cc: bccvax!meehan@yale In my opinion, CSI Lisp was implemented by knowledgeable people who know very well about tail recursion optimization. They are not the kind of people that would leave it out because its too hard to figure out. In fact, their Apollo implementation reliably does the optimization. They left it out from some implementations because they wanted to port their programs to machines by implementing their lisp on top of existing systems. Since Common Lisp and Lisp-VM are not required to do the opimization, they realized that they would incure much pain and suffering if they spend the effort to get it right in these lisps. Reasonable people doing reasonable things. My only complaint is that reasonable people reading their ad in CACM would conclude that all their implementations are tail recursive. Cognitive Systems should be applauded for porting a dialect of lisp that is much simpler than Common Lisp, yet just as useful. I think it is important to recognise the good with the bad. Comments and questions about CSI Lisp should be directed to Jim Meehan (MEEHAN@YALE). John  Date: Mon, 22 Jul 85 18:23:54 EDT From: George J. Carrette Subject: truth in advertisement To: gls@THINK-AQUINAS.ARPA cc: SCHEME@MIT-MC.ARPA, linus!ramsdell@MITRE-BEDFORD.ARPA In-reply-to: Msg of Mon 22 Jul 85 13:41 EDT from Guy Steele Message-ID: <[MIT-MC.ARPA].584702.850722.GJC> I just saw the price of the thing, $10K for the DEC/VAXLISP version. Now considering the DEC/VAXLISP cost is $12k, charging $10K for a three or four page lisp program that does syntactic translation of Scheme code into Common-Lisp code is a bit absurd. The question is what has been written in "T" that has that kind of economic value? Evidently a few things! Or it could be the case of Unix costing $300 from Berkeley or a Unix emulator under VMS costing you a minimum of $8k.  Received: from THINK.ARPA by MIT-MC.ARPA 22 Jul 85 13:42:58 EDT Received: by THINK.ARPA with CHAOS; Mon, 22 Jul 85 13:39:45 edt Date: Mon, 22 Jul 85 13:41 EDT From: Guy Steele Subject: truth in advertisement To: GJC@MIT-MC.ARPA, SCHEME@MIT-MC.ARPA, linus!ramsdell@MITRE-BEDFORD.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <[MIT-MC.ARPA].582540.850720.GJC> Message-Id: <850722134121.2.GLS@UBALDO.ARPA> Well, if you believe that the company is truly sinister and trying to rip people off with shoddy merchandise, then all the legal apparatus that GJC describes may be brought to bear. But it may be that the lack of tail-recursion is due to incompetence, ignorance, oversight, or maybe even an intentional tradeoff made to gain something else. There is a lot to be said for first writing or calling the company and reporting it as a bug and politely asking how soon it will be fixed. What you do next depends on their reaction. --Guy  Date: Sat, 20 Jul 85 06:51:14 EDT From: George J. Carrette Subject: truth in advertisement To: SCHEME@MIT-MC.ARPA, linus!ramsdell@MITRE-BEDFORD.ARPA In-reply-to: Msg of 19 Jul 1985 20:51:17-EDT Fri 19 Jul 85 09:48:40 edt from linus!ramsdell at Mitre-Bedford, linus!ramsdell (John D. Ramsdell) at Mitre-Bedford Message-ID: <[MIT-MC.ARPA].582540.850720.GJC> I think that just about all one can do is send letters to the editors of the magazines publishing such advertisements. Another thing one can do is write a letter to the company asking "will your product run the enclosed program: X" to which they will probably reply yes (because it will on one implementation). Then you write a letter saying, "great, here is my $$$ please send me a copy." Then when you get the bogus copy that wont run your program you say to them: "Please send my money back." To make it most effective you get 10 or 20 people in on this doing exactly the same thing. The company wont be as willing to give back thousands of dollars. Then when they dont give the money back you go to the Atterny (spell program no help for this word) General's Office and file a complaint (both state and federal). 10 to 20 complaints are enough to get the feds moving on a mail-fraud/wire-fraud investigation. The laws protecting consumers from magazine advertisement mail-order rip-offs are sufficiently strong to cause server problems to a company in arrears. For one thing just the act of filing so many complaints can make it difficult for a small company to raise money from sources that are smart enough to check for such things. And if things get serious enough the post office can cut off their mail (quite a screw eh?), not to mention the criminal penalties that hang over them. On the other hand, given the effort of making an example of a company like this, and given how much work it is to do a reasonable Scheme implementation on top of any halfway decent lisp, maybe it would be better for us to pitch in and come up with and advertise for distribution-at-cost some true Scheme implementation? It would probably be less work (although maybe less fun) than screwing some losing company to the wall. -gjc  Received: from mitre-bedford by MIT-MC.ARPA 19 Jul 85 20:56:49 EDT Date: 19 Jul 1985 20:51:17-EDT From: linus!ramsdell@Mitre-Bedford Received: by linus.UUCP (4.12/4.7) id AA25878; Fri, 19 Jul 85 09:48:40 edt Date: Fri, 19 Jul 85 09:48:40 edt From: linus!ramsdell (John D. Ramsdell) Message-Id: <8507191348.AA25878@linus.UUCP> To: bccvax!scheme@mit-mc.arpa Subject: CSI Lisp is not tail recursive An advertisement for CSI Lisp recently appeared in CACM. The ad states "CSI LISP is a new implementation of T, which is decended from SCHEME". For those who don't know, T is a dialect of SCHEME that is fairly true to SCHEME's basic ideas. For example, T programmers are allowed to assume that evaluation of programs is tail recursive. Looping constructs generated out of tail recursive procedures do not increase the size of the stack. Recent mail to T-DISCUSSION@YALE reveal that CSI Lisp makes no promise to be tail recursive and is not tail recursive on implementations that run on top of Common Lisp and LISP-VM! I believe Cognitive Systems must reveal that CSI Lisp is not tail recursive or it should not associate CSI Lisp with T and SCHEME in its ads. In my opinion, a language should, at the very least, be tail recursive if it is to be associated with SCHEME. John PS Ada's name is protected - can anything be done for SCHEME's name?  Date: Thu, 11 Jul 85 23:17:53 EDT From: George J. Carrette Subject: What cr*p To: mw%brandeis.csnet@CSNET-RELAY.ARPA cc: SCHEME@MIT-MC.ARPA, cth%indiana.csnet@CSNET-RELAY.ARPA, dpf%indiana.csnet@CSNET-RELAY.ARPA, lang-scheme%indiana.csnet@CSNET-RELAY.ARPA In-reply-to: Msg of 9 Jul 1985 22:27-EST from mw%brandeis.csnet at csnet-relay.arpa Message-ID: <[MIT-MC.ARPA].572724.850711.GJC> If you think *thats* bad... a paper on a reference count garbage collection technique in the ISA conference on expert systems and robotics this June. And if you think thats bad you should see the kind of proposals DOD is getting for "supercomputer lispmachines"  Received: from csnet-relay by MIT-MC.ARPA.ARPA; 10 Jul 85 02:26:14 EDT Received: from brandeis by csnet-relay.csnet id a016623; 10 Jul 85 2:18 EDT Received: by brandeis.ARPA (4.12/4.7) id AA08833; Tue, 9 Jul 85 22:33:50 edt Date: 9 Jul 1985 22:27-EST From: mw%brandeis.csnet@csnet-relay.arpa In-Real-Life: Mitchell Wand,faculty Subject: What cr*p To: dpf%indiana.csnet@csnet-relay.arpa, lang-scheme%indiana.csnet@csnet-relay.arpa, cth%indiana.csnet@csnet-relay.arpa, scheme@mit-mc.ARPA Message-Id: <489810451/mw@brandeis> Would you believe that Software: Practice & Experience is about to publish a paper entitled "On the role of t and nil in Lisp", and whose abstract is "It is widely believed that McCarthy's interpreter is a running Lisp program. It is not, because it does not interpret t and nil correctly. We show how to fix this bug." It's only 2-1/2 pages, but MUMBLE!  Received: from csnet-relay by MIT-MC.ARPA.ARPA; 10 Jul 85 00:39:55 EDT Received: from ti-csl by csnet-relay.csnet id aj16083; 10 Jul 85 0:30 EDT Date: 9 Jul 1985 0937-CDT From: Arthur Subject: Scheme Benchmark Programs Sought To: scheme@mit-mc.ARPA cc: scheme.users%CSL60%ti-csl.csnet@csnet-relay.arpa Received: from csl60 by ti-csl; Tue, 9 Jul 85 21:10 CST Hello, Un-Common Lisp Lovers: I am beginning a Scheme performance evaluation project here at TI CSL, an initial task being to build a suite of benchmark programs. Beyond the Gabriel Lisp Benchmark Suite translated to Scheme and examples from A&S, most Scheme programs around these days seem to be "systems" code, e.g., compilers and editors. I am soliciting "applications" code from Scheme users, especially programs that show off **canonical Scheme programming style**. I am not placing any limits a priori on the code size, however, I do request that source provided conforms to the Revised Revised Report. What's in it for you? Well, possible enshrinement of your name and all or part of your favorite program in a "standard" benchmark suite for Scheme. Also, the good feeling that comes with advancing the cause of Lisp-Done-Right, since I hope to show off the performance advantages of the Scheme runtime model. The ultimate suite of programs will be made available over the net to interested parties, of course. Thanks for your cooperation. Regards, Arthur Altman Texas Instruments Computer Science Laboratory (214) 995-0383 CSNET: altman@ti-csl ARPANET: altman%ti-csl@csnet-relay U.S. Postal Service: M.S. 238, P.O. Box 226015, Dallas, Texas, 75266 -------  Received: from SU-SUSHI.ARPA by MIT-MC.ARPA 21 Jun 85 20:22:54 EST Date: Fri 21 Jun 85 17:22:22-PDT From: Andy Freeman Subject: Re: lcm To: willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA cc: scheme@MIT-MC.ARPA In-Reply-To: Message from "Will Clinger " of Fri 21 Jun 85 16:37:59-PDT (lcm) recently came up on the common lisp mailing list and that the decision was that the Common Lisp manual was wrong. I believe Bill Gosper and Alan Bawden were major participants in that discussion. I'd review that before making a decision. -andy -------  Received: from csnet-relay by MIT-MC.ARPA 21 Jun 85 19:31:11 EST Received: from tektronix by csnet-relay.csnet id ac01342; 21 Jun 85 18:43 EDT From: Will Clinger To: scheme@MIT-MC.ARPA Received: from tekchips by tektronix with smtp ; 21 Jun 85 11:30:56 PDT Date: Friday, 21 Jun 85 11:25:37 PDT Subject: lcm A question from John Gateley (gateley%waltz@ti-csl.csnet) and my response: Gateley: Common lisp says (lcm) = infinity, and since they don't have a representation of infinity, lcm is required to have at least one argument. Scheme says (lcm) = 1. Also, common lisp allows lcm to take 0 as an argument, with result 0. Scheme does not allow zero as an argument. Is this what is desired, or should scheme be closer to common lisp. Clinger: The relevant passage in Guy Steele's book is on page 202: "Mathematically, (lcm) should return infinity. Because Common Lisp does not have a representation for infinity, lcm, unlike gcd, always requires at least one argument." Even as a mathematician, I can't agree that (lcm) should return infinity, because the n-ary generalization of an associative binary operator should return an identity for the operator when it is given no arguments. Infinity certainly isn't an identity for lcm. 1 is. I think I inserted the requirement that the arguments to lcm be non-zero. I have no particular quarrel with Common Lisp on this matter, but I didn't want to get bogged down in pathological cases. Since it is inconsistent to allow zero as an argument to gcd but not to lcm, I would like to change the report so that lcm behaves as in Common Lisp when given a zero argument.  Received: from MIT-VAX by MIT-MC via Chaosnet; 25 APR 85 16:08:56 EST Received: by mit-vax.Mit-chaos.Arpa (4.12/4.8) id AA09287; Thu, 25 Apr 85 16:07:44 est Date: Thu, 25 Apr 85 16:07:44 est From: Bert Halstead To: JAR@MIT-MC Subject: Re: number exponent syntax Cc: SCHEME@mc Yeah, I saw the same article, and it was the thought of that that caused me to insert the words "(almost)" in my message. But once we start having impreciseness in our exponent, there is little point to saying anything about the mantissa! I figured this was probably a minefield Scheme could avoid entering. -Bert  Date: Thu, 25 Apr 85 15:42:31 EST From: Jonathan A Rees Subject: number exponent syntax To: rhh@MIT-VAX cc: SCHEME@MIT-MC In-reply-to: Msg of Thu 25 Apr 85 12:01:58 est from Bert Halstead Message-ID: <[MIT-MC].469882.850425.JAR> Date: Thu, 25 Apr 85 12:01:58 est From: Bert Halstead Seems to me that precision and exactness are (almost) completely meaningless in an exponent. One could perhaps make an argument for different radices in the exponent notation, but then one could also make an argument for other things (e.g., scientific notation with a base other than 10). I'd probably just as soon we didn't. I'm not one to talk, since I never use numbers, but I read a CACM article once about a proposed hardware number representation in which one could represent numbers with no significant digits in their EXPONENT. The author claimed that this was useful. So not all of this meaninglessness is to be concluded forgonely. Don't take this as a contrary argument; merely a word of caution. Jonathan  Received: from MIT-VAX by MIT-MC via Chaosnet; 25 APR 85 12:03:03 EST Received: by mit-vax.Mit-chaos.Arpa (4.12/4.8) id AA05298; Thu, 25 Apr 85 12:01:58 est Date: Thu, 25 Apr 85 12:01:58 est From: Bert Halstead To: scheme@mit-mc.ARPA, willc%indiana.csnet@csnet-relay.arpa Subject: number exponent syntax Seems to me that precision and exactness are (almost) completely meaningless in an exponent. One could perhaps make an argument for different radices in the exponent notation, but then one could also make an argument for other things (e.g., scientific notation with a base other than 10). I'd probably just as soon we didn't. -Bert  Received: from csnet-relay by MIT-MC.ARPA; 24 APR 85 18:41:59 EST Received: from indiana by csnet-relay.csnet id ad16863; 24 Apr 85 14:38 EST Date: Wed, 24 Apr 85 12:48:17 est From: Will Clinger Received: by iuvax.UUCP; id AA05047; Wed, 24 Apr 85 12:48:17 est To: scheme@mit-mc.ARPA Subject: two-armed if (oops) Yikes! Thank you John, I meant to say that ONE-ARMED IF would become optional. TWO-ARMED IF will remain essential, of course. There has already been sufficient response to convince me that plus signs should be allowed in exponents. Still at issue is whether exponents can have radix, precision, or exactness specifiers, and indeed whether exponents should be allowed to have arbitrary number syntax. At some point the more general exponent syntax should become extended rather than optional, and all we're trying to do is to determine that point. Peace, William