kdmoen@watcgl.UUCP (10/22/87)
likes@silver.bacs.indiana.edu writes: >If you look at it Common Lisp is just one series of kludges after another >(extra arguments to assoc, packages, no first-class functions, etc...) >On the other hand, Scheme has more of a unified picture of the world >(if you ignore versions with first class environments ala M.I.T.). First class environments are not discussed in any of the MIT tech reports on Scheme that I possess. What are they, how are they used, and why do they compromise Schemes "unified picture of the world"? One other thing: in the R3 Report on Scheme, it says: "Scheme does not have any standard facility for defining macros. "The ability to alter the syntax of the language creates numerous problems. All current implementations of Scheme have macro facilities, ... but it isn't clear at this time which solution is best. <this is followed by a list of problems with macros> Perhaps this was true a year ago, but is it still true? Has anyone done work that "solves" the macro problem? -- Doug Moen University of Waterloo Computer Graphics Lab UUCP: {ihnp4,watmath}!watcgl!kdmoen INTERNET: kdmoen@cgl.waterloo.edu
oz@yetti.UUCP (10/26/87)
In article <2095@watcgl.waterloo.edu> Doug Moen writes: >... >Has anyone done work that "solves" the macro problem? > Yep. It is scheme84's "syntax extension" facility: "Scheme84 allows the user to declare new special forms. Such constructs are syntactic entities that are *expanded* during compilation of code that used them. In other dialects of lisp and other versions of Scheme, similar constructs are called macros" [Scheme84 Ref Man - Rep 153] I think this pattern-based extension facility is so elegant that it makes ordinary lisp macro facilities look like a horrendous (can you say bletcherous?) cludge. example: syntactic extension "and" (declare-syntax and () [(and) true] [(and e) e] [(and e1 e2 ...) (if e1 (and e2 ...) false)]) The ellipsis (...) is a part of the definition, and used to specify arbitrarily long lists. Intrigued ? See: D. Friedman, C. Haynes, E. Kohlbecker and M. Wand, "Scheme84 Interim Reference Manual", Indiana University Computer Science, Tech. Rep. 153, June 1985 E. Kohlbecker, "Using Mkmac", Indiana University Computer Science, Tech. Rep. 157, May 1984 oz -- You see things, and you say "WHY?" Usenet: [decvax|ihnp4]!utzoo!yetti!oz But I dream things that never were; ......!seismo!mnetor!yetti!oz and say "WHY NOT?" Bitnet: oz@[yusol|yulibra|yuyetti] [Back To Methuselah] Bernard Shaw Phonet: [416] 736-5257 x 3976
jh@tut.fi (Juha Hein{nen) (10/29/87)
Also to me the scheme-84 extend-syntax facility is nice and easy to use but why can't the Scheme community agree to standardize it? As we all know many useful extensions to Scheme (scoops, environments, records, etc.) are implemented using syntax extension. Without a standard systax extension facility these extensions can't be easily ported from one implementation to another. -- Juha Heinanen Tampere Univ. of Technology Finland jh@tut.fi (Internet), tut!jh (UUCP)
bds@lzaz.ATT.COM (BRUCE SZABLAK) (10/30/87)
In article <179@yetti.UUCP>, oz@yetti.UUCP writes: > In article <2095@watcgl.waterloo.edu> Doug Moen writes: > >... > >Has anyone done work that "solves" the macro problem? > > Yep. It is scheme84's "syntax extension" facility: Hmmm. The impression that I got from the report was that the concerns were not with the "syntatic sugar", but with debugging, handling redeclaration of macros, and other problems you get when you add an early binding construct in a late binding, incrementally compiled world... I admit that I may have misunderstood their concerns though. (by the way, the macro definition syntax described has been around for some time I believe).