tony@rlgvax.UUCP (Tony Stuart) (04/16/88)
In article <2400014@otter.hple.hp.com>, esh@otter.hple.hp.com (Sean Hayes) writes: > The closing of blocks of code with a delimiter is a must. The only viable alternative is > Landins "offside rule", which forces the correct indentation. I don't know if this has been > tried in an imperative language. In Max, an extensible programming language, functions are used to define new flow-of-control constructs. The argument list to the function constitutes a block. The block may be delimited by three different sets of symbols to support different degrees of block closure. Simple block closure uses parentheses to delimit the argument list or block. They pair just as they do in conventional programming languages such as C. An if-then-else construct could be written as: if (boolean-expression then ( true-function-list ) else ( false-function-list ) ) A disadvantage to this type of closure in a language such as Max is that it becomes difficult for the interpreter (or programmer) to accurately identify the location of a missing parenthesis. To accomodate this problem, Max provides "single named block closure" which uses braces to delimit the argument list. The right brace is followed by the function name that precedes the corresponding left brace. The above example can be rewritten as: if {boolean-expression then ( true-function-list ) else ( false-function-list ) } if In this example, the "if" block uses single named block closure and the "then" and "else" blocks use simple block closure. The type of closure used is entirely up to the programmer. The Max interpreter can detect block structure errors (i.e. missing parentheses) within named blocks delimited by braces. There is a tradeoff between the improved ability to detect errors using single named block closure and the readability of simple block closure. Max also provides a shortcut to writing all of the right parentheses or right braces. It is called "multiple named block closure" and is specified using brackets: function-name [ function-list ] function-name A right-bracket, function-name sequence pairs with the most recent function-name, left-bracket sequence of the same name and closes all intervening blocks. An example of this is: if [boolean-expression then ( true-function-list ] if The "then" block is closed by the multiple named block closure of the "if" block. Max provides a preprocessor to hide these details from the programmer and make the source more readable. A set of preprocessor replacements such as: $replace ("If" "if [") $replace ("EndIf" "] if") $replace ("Then" "then (") Allows one to write the more elegant: If boolean-expression Then true-function-list EndIf -- Anthony F. Stuart, {uunet|sundc)!rlgvax!tony CCI, 11490 Commerce Park Drive, Reston, VA 22091
firth@sei.cmu.edu (Robert Firth) (04/18/88)
It seems clearly desirable that every control construct be able to contain multiple statements, embedded within clear starting and ending delimiters. The Algol-68 style used the opening delimited written in reverse (if...fi, case...esac, comment..tnemmoc [joke]). The motivation was decent, but the implementation, to put it mildly, was vile. Ada is a little better, with if ... end if, case ... end case, and so on. Unfortunately, it is not consistent. Moreover, because the closing delimiter is two tokens, there is more chance of human error and of bogus syntactic error recovery error. CPL I think came closest to getting it right: every opening delimiter can be given a mnemonic name, called a "tag", and the corresponsing closing delimiter must repeat the tag. For instance: IF p = NIL DO $(NullCase ... ... $)NullCase The one mistake, I think, was to allow one tagged end delimiter to close many open constructs: IF p = NIL THEN $(NullCase IF freespaceptr = NIL THEN $(NewBlock ... ... $)NullCase This is a concession to laziness that loses far more than it gains. Note that this still has the Algol-60 style: the control structure really governs only one statement, so you have to add a pair of delimiters after it. This is probably an obsolete notion. A feasible design might be a combination of CPL tags and Modula syntax, for instance: NullCase: IF p = NIL THEN ... ... END NullCase though I'm unhappy with that layout.
gaynor@porthos.rutgers.edu (Silver) (04/19/88)
firth@sei.cmu.edu (Robert Firth) writes: > It seems clearly desirable that every control construct be able to > contain multiple statements, embedded within clear starting and > ending delimiters. I find these delimiters an annoying eyesore at best. I usually write algorithms without them, using indentation show heirarchy. I only include them in fulfillment of a target language's definition. In fact, there are languages whose heirarchical structure is determined solely by indentation (the only one that comes to mind is josh@rutgers.edu's CAML, still under development). Regards, [Ag]
wsmith@uiucdcsm.cs.uiuc.edu (04/19/88)
firth@sei.cmu.edu (Robert Firth) writes: > It seems clearly desirable that every control construct be able to > contain multiple statements, embedded within clear starting and > ending delimiters. I obviously missed something in this discussion. What is wrong with single character delimiters for a compound statement such as { and } as C uses? They do not clutter up the program and distract the reader of the program from seeing the also important data flow of the program. With a reasonable text editor based language oriented editor, the editor can reliably format the indentation of the program automatically and help a programmer visualize the control structure without imposing awkward command languages in the editor. The editor could also show the programmer where the matching } to any { is. The language oriented editor could also do this with case-esac or case-end case, but clutter should be considered when designing a language. The problem with the idea mentioned in other postings about using indentation to represent the control structure is that it does not have a clean formalism to describe the parser. Many languages that are in use can be described with LR derived parsing specifications and thus the syntax of the language can be dealt with formally. I don't think that using whitespace as part of the syntax of the language will be easy to parse. Problems include: handling of multi line expressions and defining default tab stops. It is important that a language be described in a formalism that can be understood and reasoned about. The lexical specifications may be described with regular expressions (regardless of how the expressions are implemented). Context free grammars can be used to specify the syntax. If the language has constructs that are impossible to fit an a context free framework, parsing becomes more difficult, prototyping the language becomes more difficult and implementing the language correctly becomes more difficult. I think the jury is still out on the best way to specify formally semantic information about a program. Bill Smith ihnp4!uiucdcs!wsmith wsmith@a.cs.uiuc.edu
cik@l.cc.purdue.edu (Herman Rubin) (04/20/88)
In article <Apr.18.19.01.07.1988.13299@porthos.rutgers.edu>, gaynor@porthos.rutgers.edu (Silver) writes: > firth@sei.cmu.edu (Robert Firth) writes: > > It seems clearly desirable that every control construct be able to > > contain multiple statements, embedded within clear starting and > > ending delimiters. > > I find these delimiters an annoying eyesore at best. I usually write > algorithms without them, using indentation show heirarchy. I only > include them in fulfillment of a target language's definition. In > fact, there are languages whose heirarchical structure is determined > solely by indentation (the only one that comes to mind is > josh@rutgers.edu's CAML, still under development). > > Regards, > [Ag] I find both of these methods at times easy to follow, and at times hard to follow. There is also the problem of a multiple break. If we use indentation, there is the problem of following the indentation 20 or 50 or 100 lines; in addition, this greatly limits the number of hierarchical levels. Admittedly 10 levels are already difficult to read, but with indentation lines also get shorter. One may also want to use some form of indentation within blocks to inprove readability. The problem with if...fi, case...esac, do...od etc. is that there may be several pending; which is now ended? I hereby make a proposal which I believe may treat the problem in a better manner. First, I am willing to have unlabelled blocks with appropriate delimiters such as the above pairs and also with {...}. (It is my under- standing that if the latter is used that the reversed name does not have to be used also.) I suggest that labelled blocks also be allowed, with possible notations as LABEL{ ... }LABEL if(....) LABEL:: end LABEL; Also if a break is desired which goes back several levels, this could be indicated as break LABEL and another useful "gadget" might be endall LABEL which would close all blocks since LABEL was invoked. This is a suggestion for the introduction of labelled blocks. In no way do I claim that this is necessarily the best way to do it, nor do I believe that I have found all of the uses for labelled blocks. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet
jefu@pawl14.pawl.rpi.edu (Jeffrey Putnam) (04/20/88)
All this discussion about which delimiters we should be using seems
to me rather off the mark. (I personally see nothing wrong with either
the C block "{...}" or the Algol 68 "if ... fi" etc.) I think that
what is really needed is better editors and appropriate software to
handle transformations. That is, if I write with "{...}" in a syntax
smart editor, there is no reason why it could not be transformed to
"begin...end" or any other pair demanded by the formal language description.
Indeed, two people working on the same program might see it in quite
different ways.
In a nice bitmap oriented editor, blocks might be indicated by
drawing lines around the block, drawing a vertical line in front of it,
or even by changing color or font (:-). I think we are forgetting
- or not yet realizing - that the kinds of things demanded by a language
definition is not necessarily what is presented to the programmer.
Time and space do not permit me to describe what i would like to see
in my fantasy editor, but suffice it to say that i dont think delimiters
would ever appear (unless requested).
jeff putnam
jefu@pawl.rpi.edu -or- jeff_putnam%rpitsmts@itsgw.rpi.edu
"People would rather believe a simple lie than the complex truth."mac3n@babbage.acc.virginia.edu (Alex Colvin) (04/20/88)
An other way to do this block overture/closure is to use the production
stmt -> stmt ; stmt
or its nearest equivalent in your favorite notation.
This just gives ";" a high precedence.
Then blocks have to be explicitly cut off, e.g.
if A then if B then S1; S2
= if A then (if B then S1; S2)
/= if A then (if B then S1); S2
Or you could require all syntax to be fully bracketed, as is LISP.lord+@andrew.cmu.edu (Tom Lord) (04/21/88)
Gee, Joe. I guess a little childesh flaming goes a long way. Are we done with this issue yet? -Tom
jesup@pawl13.pawl.rpi.edu (Randell E. Jesup) (04/21/88)
In article <732@imagine.PAWL.RPI.EDU> jefu@pawl14.pawl.rpi.edu (Jeffrey Putnam) writes: >In a nice bitmap oriented editor, blocks might be indicated by >drawing lines around the block, drawing a vertical line in front of it, >or even by changing color or font (:-). Don't joke: the first version of C I used (for the C-64, no less!) had an editor that allowed giving any of 15 colors to any line (against a black background). It really makes the structure of a routine jump out at you. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
esh@otter.hple.hp.com (Sean Hayes) (04/21/88)
>The problem with the idea mentioned in other postings about using indentation >to represent the control structure is that it does not have a clean formalism >to describe the parser. Many languages that are in use can be described with >LR derived parsing specifications and thus the syntax of the language can >be dealt with formally. I don't think that using whitespace as part of the >syntax of the language will be easy to parse. Problems include: handling >of multi line expressions and defining default tab stops. Although it is exteremely convenient to be able to specify a language formally, Surely context free grammars aren't the last word in formal description methods. I think tools like yacc and lex may have done a great deal to inhibit language development. They certainly shouldn't (in my lowly opinion) be used as an excuse to remove language features on the 'hard to parse' argument. On the other hand, whats hard for a parser is often hard for a programmer too. _________________________________________________________________________ |Sean Hayes, Hewlett Packard Laboratories, Bristol, England| |net: esh@hplb.uucp esh%shayes@hplabs.HP.COM ..!mcvax!ukc!hplb!esh|
bhs@mitre-bedford.ARPA (Beverly H. Sobelman) (04/21/88)
In article <732@imagine.PAWL.RPI.EDU> jefu@pawl14.pawl.rpi.edu (Jeffrey Putnam) writes: >In a nice bitmap oriented editor, blocks might be indicated by >drawing lines around the block, drawing a vertical line in front of it, >or even by changing color or font (:-). I think we are forgetting >- or not yet realizing - that the kinds of things demanded by a language >definition is not necessarily what is presented to the programmer. If memory serves correctly, the Builder language developed at Cortex (Waltham, MA) has an associated editing capability that indicates a block via vertical lines down the left side of the display; e.g., when you start an "if" construct, you automatically get the "end" construct (don't remember the exact syntax), with a thin line at the left running between the two, and all code for the body is inserted into that region at appropriate levels of indentation. Makes for a visually appealing and informative display. >Time and space do not permit me to describe what i would like to see >in my fantasy editor, but suffice it to say that i dont think delimiters >would ever appear (unless requested). > As I said above, I think Builder requires delimiters, but the editor ensures proper closure of all blocks. Bev Sobelman MITRE Corp. bhs@mitre-bedford.arpa (617) 271-754
karl@haddock.ISC.COM (Karl Heuer) (04/22/88)
In article <5200003@uiucdcsm> wsmith@uiucdcsm.cs.uiuc.edu writes: >The problem with the idea mentioned in other postings about using indentation >to represent the control structure is that it does not have a clean formalism >to describe the parser. It could be described in terms of a first pass that converts leading whitespace into the appropriate number of begin/end tokens. (C already needs such a description, because the syntax of "#" lines is so different from the rest of the language.) >Problems include: handling of multi line expressions and defining default >tab stops. One possible solution: multi-line expressions are only valid in the presence of a continuation indicator (backslash-newline in C); `tab' is an undefined (or implementation-defined) character in a source file. (Alternately, it could be illegal to mix blanks and tabs in such a way as to make the result dependent on the tab-stop settings.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
les@chinet.UUCP (Leslie Mikesell) (04/22/88)
In article <5100@aw.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (Robert Firth) writes: >A feasible design might be a combination of CPL tags and Modula syntax, >for instance: > How about taking the normal c {} and appending a label, perhaps attached with a character that would otherwise be illegal, then requiring the matching label at the closure. A pre-processor could easily strip the labels off for the pure at heart. This would be ugly, but it would make it possible for the dumbest of editors to find matching block delimiters and it would help do away with most c compilers' notion that "there aren't any wrong c programs" (just because it wasn't what you intended it to be...). Les Mikesell
gast@lanai.cs.ucla.edu (David Gast) (04/23/88)
In article <2400015@otter.hple.hp.com> esh@otter.hple.hp.com (Sean Hayes) writes: > >>The problem with the idea mentioned in other postings about using indentation >>to represent the control structure is that it does not have a clean formalism >>to describe the parser. Many languages that are in use can be described with >>LR derived parsing specifications and thus the syntax of the language can >>be dealt with formally. I don't think that using whitespace as part of the >>syntax of the language will be easy to parse. Problems include: handling >>of multi line expressions and defining default tab stops. > >Although it is exteremely convenient to be able to specify a language formally, >Surely context free grammars aren't the last word in formal description methods. 1) Declaration before use cannot be represented by context free grammars, but many languages reguire declaration before use. The same could be done with indentation. 2) There are other grammar formalisms besides CFGs. For example, vW or two level grammars. While the typical reader may not want to read a vW grammar, the language could be defined with a vW grammar so that compiler writers could check their compilers. The user could be told about indentation. It might also be possible, to use the Grammar Rule Notation, a la Prolog to describe the indentation levels. I do not know (because I have not really considered it). The GNR is more powerful than a CFG. An extra argument to the grammar rules could indicate the level of indentation. David Gast gast@cs.ucla.edu {ucbvax,rutgers}!ucla-cs!gast
daveb@geac.UUCP (David Collier-Brown) (04/23/88)
In article <757@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >I find both of these methods at times easy to follow, and at times hard to >follow. There is also the problem of a multiple break. >[...] > break LABEL > endall LABEL Well, both have been tried, with mixed results. One could label begin-end blocks in PL/1, and add either the block label of the name of the control structure between the "end" and its ";". At least two compilers used this to double-check block nesting and produce warning messages. Similarly, some PL/1 variants (and my memory is fuzzy here...) allowed a leave <label> statement which exited a named block. This may have been part of the ANSI standard, but that was too long ago. Labelled blocks and "endall" existed in BCPL, but were very little-used. It was not obvious whether it was because it was non-traditional or buggy, but is usually remembered in terms of the claim that it lead to making block-balancing errors. -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
henry@utzoo.uucp (Henry Spencer) (04/24/88)
> ... If we use indentation, > there is the problem of following the indentation 20 or 50 or 100 lines; in > addition, this greatly limits the number of hierarchical levels... At risk of starting another flame war, if this is a problem, the function in question is too complex and should be split up into more manageable pieces. If efficiency demands avoiding function calls, the integration of the pieces into a single function should be done mechanically, either by the compiler or by a special-purpose source-transformation tool, so the programmer can continue to deal with the cleanly-partitioned version. -- "Noalias must go. This is | Henry Spencer @ U of Toronto Zoology non-negotiable." --DMR | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
wes@obie.UUCP (Barnacle Wes) (04/25/88)
In article <3564@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: > In article <5200003@uiucdcsm> wsmith@uiucdcsm.cs.uiuc.edu writes: > >Problems include: handling of multi line expressions and defining default > >tab stops. > > One possible solution: multi-line expressions are only valid in the presence > of a continuation indicator (backslash-newline in C); `tab' is an undefined > (or implementation-defined) character in a source file. The implementation-defined `tab' would probably work well. You would need tools to manipulate (edit & print) source files, but most programmers expect these tools now anyhow. On many systems, tab size is not tied to character-cell size anyhow, especially on bit-mapped screens using proportional fonts. If you use a Swiss or Times font on the screen, "4 character" tabs have no meaning. You would instead insert `indent' characters, and tell the editor or source printer to indent .5" for each indent. -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!uplherc! / \/ \/\/ \ - Contend in Vain." - sp7040!obie! / U i n T e c h \ - Schiller - wes
elg@killer.UUCP (Eric Green) (04/25/88)
In article <11532@shemp.CS.UCLA.EDU> gast@lanai.UUCP (David Gast) writes: >In article <2400015@otter.hple.hp.com> esh@otter.hple.hp.com (Sean Hayes) writes: >> >>>The problem with the idea mentioned in other postings about using indentation >>>to represent the control structure is that it does not have a clean formalism >>>to describe the parser. So move it to the lexer. E.g. have your lexer generate a "begin" or "end" block open/close based upon changes in indentation. Sheesh. The parser doesn't have to do EVERYTHING, you know.... if the lexer can strip out whitespace and comments, much simplifying the parser, then it can certainly handle a simple thing like converting whitespaces into opening/closing symbols. Although I do admit that it would not be easily formalized as regular expressions -- the question of whether this particular whitespace is an open, close, or null, depends upon the state of the last whitespace. Big deal. Single line in Lex, to match the whitespaces at the start of the line (including none), count them, compare them to last count, and return result accordingly. Most lexers are hand-built anyhow, so it doesn't really matter. Except as a matter of principle to purists everwhere, who shudder at actions that they cannot easily model with their current formalisms. >>>syntax of the language will be easy to parse. Problems include: handling >>>of multi line expressions and defining default tab stops. I have used a language that uses indentation as its block denotation (Promal). It gets ugly, folks. That, instead of the formalism objections, should be what scratches the idea entirely. The enforced indentation style of Promal, for example, makes procedure headers blend in with the declaration of local variables -- a real nightmare for someone perusing a printout, especially since comments are expected to start in the current column, too (meaning you have to set up a line of dashes before a comment, in order to pick the comment out of the surrounding program text). Not to mention that I might want to indent some things differently from others, to make them stand out, and other things of that sort -- which would be impossible even with a better indention scheme. Then continuations... would need a special "trailer" character (maybe "\"?) to indicate that this is not EOL (= end-of-statement in this sort of language), then the lexer would have to shift gears and NOT count spaces at the beginning of the next line. Again, a pain, both for implementer, and for the poor programmer. But still quite possible. If it was worthwhile. Which it isn't. Free-form languages simply offer too many advantages to go back to fixed-format languages (COBOL!!! GARGH!). And, since the parser is handling BEGIN/END pairs instead of indentation, we have a dichotomy between what is seen, and what is parsed. Might as well just handle BEGIN/END pairs in the first place. Ah well. Sorry to burst the bubble of all you poor earnest academicians trying to cope with indentation in grammars. But, generally, questions of white space etc. should be handled by the lexer, possibly generating symbols to feed to the parser -- and possibly not. A lexical issue, not a parsing issue. Now, devising a suitable formalism to handle lexical issues like THAT may involve quite a bit of work. But all us poor grunts out here will let the brains handle that, and relax with the knowledge that it can all be handled with a few lines of LEX or a couple of subroutines in "C". -- Eric Lee Green elg@usl.CSNET Snail Mail P.O. Box 92191 ihnp4!killer!elg Lafayette, LA 70509 "Is a dream a lie that don't come true, or is it something worse?"
esh@otter.hple.hp.com (Sean Hayes) (04/25/88)
> There are other grammar formalisms besides CFGs. For example, vW > or two level grammars. While the typical reader may not want to > read a vW grammar, the language could be defined with a vW grammar > so that compiler writers could check their compilers. The user > could be told about indentation. > --- David Gast Oh those lovely vW grammars! One of the best courses I did at Uni. was reading and writing vW grammars. But, are there any automatic tools to test/maintain/verify such beasts, for they are less than intuitive. More importantly perhaps, are there any tools to automatically generate parsers? On a more practical subject. I think that something like the Cornell Program Synthesiser system (an attribute grammar parser generator), would be entirely up to the task of enforcing indentation etc. In fact I may even try it! _________________________________________________________________________ |Sean Hayes, Hewlett Packard Laboratories, Bristol, England| |net: esh@hplb.uucp esh%shayes@hplabs.HP.COM ..!mcvax!ukc!hplb!esh|
ken@aiva.ed.ac.uk (Ken Johnson) (04/25/88)
jefu@pawl14.pawl.rpi.edu (Jeffrey Putnam) writes: >In a nice bitmap oriented editor, blocks might be indicated by >drawing lines around the block,... The MIT Media Lab developed a language called `Boxer' which does precisely this. The basic unit is the proceudre, analogous with a Lisp function. The procedure is represented by a box. To loop, etc, you enclose the box inside the box that represents the procedure you are writing. The editor does not have to be bitmap-orienbted, though it probably is. You do not need any function that is not available through Termcap. -- ------------------------------------------------------------------------------ From Ken Johnson, AI Applications Institute, The University, EDINBURGH Phone 031-225 4464 ext 212 Email k.johnson@ed.ac.uk
wsmith@uiucdcsm.cs.uiuc.edu (04/27/88)
An attribute grammar does not help the parsing problem. At attribute grammar takes a parse tree specified in a grammar G and decorates it with information that may be calculated automatically from the structure and terminals used in the parse tree. Somehow the parse tree must be created first. The Cornell Synthesiser generator avoids the problem of parsing except for regions such as expressions that are too difficult to enter except through parsing. By building a program generatively (by resolving one rule at a time), one need not have an unambiguous concrete syntax. Thus, CPS could easily handle the indenting problem, but it creates a whole additional set of issues in the process. With a text file, the compiler must recognize the text of the program and match it with rules commonly specified as two parts: a lexical analyzer and a parser. With the Cornell Program Synthesizer, the semantics routines do not need to do any recognition because the text is already matched with the rules ahead of time. A compiler could use attribute grammars to do type checking and code generation just as easily as the CPS. They are really two different issues: How will the programming environment decide what a programmer meant (by parsing the or by having the program entered as templates)? and how the environment will get meaning from the structure (by using attribute grammars or some other ad hoc scheme)? Bill Smith wsmith@a.cs.uiuc.edu ihnp4!uiucdcs!wsmith
iwm@amvax3.ic.ac.uk (Ian Moor) (04/27/88)
Posting-Front-End: GNU Emacs 18.45.10 of Tue Jan 12 1988 on amvax3 (berkeley-unix) BLISS-11 has MODULE ... ELUDOM ! I kind of like the sound. Seriously, I think languages do need disjoint closing delimiters, Modula-2 with only one `end' is not an improvement on Pascal.
ralphw@C7.IUS.CS.CMU.EDU (Ralph Hyre) (04/27/88)
In article <369@aiva.ed.ac.uk> ken@uk.ac.ed.aiva (Ken Johnson,E32 SB x212E) writes: >jefu@pawl14.pawl.rpi.edu (Jeffrey Putnam) writes: >>In a nice bitmap oriented editor, blocks might be indicated by >>drawing lines around the block,... > >The MIT Media Lab developed a language called `Boxer' ... Sorry, this isn't quite true. It was developed at the MIT Laboratory for Computer Science, Hal Abelson (of SIOCP (Scheme) fame) and Andi DiSessa (I probably mangled the spelling, sorry Andi) were the developers. I believe Andi's now at Berkeley. Boxer borrows a lot of language concepts from LOGO, but the designers though a lot about Scheme as well, as might be expected. The implementors thought about putting up a Boxer front-end to ZetaLisp, since Symbolics machines were what it was developed on. So Boxer is a programming environment as well as a language, and it is possible to think about decoupling the environment stuff from the language, although it would greatly clutter up the syntax. Disclaimer: I hung out with the Boxer group from 1982-83, so I was there, seeing it happen.