Re: [r6rs-discuss] R6 counterproposal
R. Kent Dybvig scripsit: Actually, the point is that they permit one to deal sensibly with lexical scoping at the source level. This not only simplifies the coding of many macros but also allows the definition of others that cannot be written with defmacro. For example, one can use syntax-rules and syntax-case to write macros that perform arbitrary code motion (e.g., define-integrable) without breaking lexical scope. I'm no expert on the subject and you are, but I don't see how there can be anything that define-macro cannot do, since it applies a Turing-complete language to arbitrarily large parts of the program. In fact, syntax-case is strictly more expressive than the old-style Lisp macros represented by defmacro. The lisp-transformer on page 54 of the library document shows how syntax-case can be used (trivially) to write old-style Lisp macros. Defmacro itself is easily defined using lisp-transformer. It sounds like they are equivalent in power, then. -- In politics, obedience and support John Cowan [EMAIL PROTECTED] are the same thing. --Hannah Arendthttp://www.ccil.org/~cowan ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
On May 29, 2007, at 3:04 AM, John Cowan wrote: In fact, syntax-case is strictly more expressive than the old- style Lisp macros represented by defmacro. The lisp-transformer on page 54 of the library document shows how syntax-case can be used (trivially) to write old-style Lisp macros. Defmacro itself is easily defined using lisp-transformer. It sounds like they are equivalent in power, then. Give a trivial definition of syntax-case using defmacro and I would grant you that the two are equivalent in expressive power. So far, we know that (1) you can express defmacro using syntax-case and (2) you cannot do the converse. I don't see how that sounds like the two are equivalent in power. Aziz,,, ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
Give a trivial definition of syntax-case using defmacro and I would grant you that the two are equivalent in expressive power. A complicated and tricky definition would be just as good for power. you cannot do the converse. I would like to be shown that. Defmacro and syntax-case macros can both perform arbitrary transformations on the input they are given. One difference is the inputs they are given: defmacro macros are fed raw s-expressions, while syntax-case macros are fed syntax objects that also contain scope information. Another difference is the expander itself. The syntax-case expander (for example) renames identifiers (in effect, at least) in the context of a macro call so that the identifier if introduced into the output of the macro resolves to the binding of if where the macro was defined rather than to the if bound in the context of the macro call. The defmacro expander doesn't do that. The lack of scope information in the input and the lack of support from the expander cannot be corrected by any transformation of the defmacro macro itself; if the information and support aren't provided, they aren't provided. To give defmacro macros equivalent power, one would have to rewrite the defmacro expander or, possibly, all of the core transformers. In the end, one would end up with a hygienic expansion system. Kent ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
R. Kent Dybvig wrote: In fact, syntax-case is strictly more expressive than the old-style Lisp macros represented by defmacro. Surely syntactic closures suitable for implementing syntax-case are a trivial application of fexpr-style macros and first-class environments, wouldn't you agree? -t ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
Thomas Lord wrote: R. Kent Dybvig wrote: In fact, syntax-case is strictly more expressive than the old-style Lisp macros represented by defmacro. Surely syntactic closures suitable for implementing syntax-case are a trivial application of fexpr-style macros and first-class environments, wouldn't you agree? I believe the issue would be passing along syntactic information through non-macro forms. What you would need is something that would be applied to every form. Lynn ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
R. Kent Dybvig wrote: (1) Expressing defmacro alone is not enough. You have to be able to express at least macroexpand as well (and this has a number of consequences which require you to do even more). Agreed, and to simulate full Common Lisp macros one would have to provide some access to the compile-time environment. Individual implementations of syntax-case support these things in various ways, and perhaps r7rs will as well, but we didn't want to bite off too much for r6rs. While syntax-case is a great improvement over syntax-rules, it's hygiene breaking mechanism leaves something to be desired. Unfortunately, the very mechanism that makes referential transparency and hygiene practical, the lazy propagation of scoping information and marks, also makes it difficult to interpret what (datum-syntax template-id datum) does when you get an expression that's been heavily munged already. More direct access to the scoping information and hygiene mechanism might be the solution, but that obviously depends on how that access is designed. Lynn ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
the very mechanism that makes referential transparency and hygiene practical, the lazy propagation of scoping information and marks, also makes it difficult to interpret what (datum-syntax template-id datum) does when you get an expression that's been heavily munged already. Lazy propagation of scoping information and marks has no impact on the behavior of datum-syntax. If the information is propagated eagerly to all identifiers at once it is the same as if it is propagated lazily. Kent ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
R. Kent Dybvig wrote: the very mechanism that makes referential transparency and hygiene practical, the lazy propagation of scoping information and marks, also makes it difficult to interpret what (datum-syntax template-id datum) does when you get an expression that's been heavily munged already. Lazy propagation of scoping information and marks has no impact on the behavior of datum-syntax. If the information is propagated eagerly to all identifiers at once it is the same as if it is propagated lazily. Ok, I've been confused this whole time about what template-identifier means. I always took it to refer to a pattern variable (identifier in the template). In any case, this restriction illustrates what I am discussing. In the lambda calculus, every form has a definite lexical that applies to the whole form. In syntax-case there is no way to bless an object with a scope that would make it fall in the scope of every identifier in the form. You are, of course, right about it not being related to the laziness. In the eager version, everything just got pushed down to the identifiers immediately, if I recall correctly. I associated it with the laziness because that mechanism does give some scoping information to constructed forms. Lynn ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
I'm confused. On comp.lang.scheme you proposed introducing FEXPRs into the language, but you describe them as a call-by-name mechanism. Traditionally, a FEXPR is a first-class macro. When applied, the source code of the arguments is passed in. A call-by-name procedure, on the other hand, would take its arguments as thunks (like Algol 60!). Call-by-need is a variation where the value is memoized if it is ever forced (like Haskell does). So which is it that you are proposing? On 5/28/07, Joe Marshall [EMAIL PROTECTED] wrote: So am I right in assuming that you were thinking of FEXPRs in the general case rather than the way SCM uses the term? On 5/27/07, Thomas Lord [EMAIL PROTECTED] wrote: Thomas Lord wrote: In the *general case* you can't expand fexpr-style macros at run-time however ur... that's until run-time, not at, of course. -t -- ~jrm -- ~jrm ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
Joe Marshall wrote: I'm confused. On comp.lang.scheme you proposed introducing FEXPRs into the language, but you describe them as a call-by-name mechanism. Traditionally, a FEXPR is a first-class macro. When applied, the source code of the arguments is passed in. A call-by-name procedure, on the other hand, would take its arguments as thunks (like Algol 60!). Call-by-need is a variation where the value is memoized if it is ever forced (like Haskell does). So which is it that you are proposing? I confused matters by formulating fexprs two different (dual of one another) ways and also by not clearly distinguishing between Scheme identifiers and meta-syntactic variables in a formula. Nevermind: It's sufficient to think of classic lisp-style fexprs and first-class environments. Any other description is just some dual of that in which those two things can be expressed and those two things are enough to express all other descriptions. -t On 5/28/07, Joe Marshall [EMAIL PROTECTED] wrote: So am I right in assuming that you were thinking of FEXPRs in the general case rather than the way SCM uses the term? On 5/27/07, Thomas Lord [EMAIL PROTECTED] wrote: Thomas Lord wrote: In the *general case* you can't expand fexpr-style macros at run-time however ur... that's until run-time, not at, of course. -t -- ~jrm ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
On 28 May 2007, at 22:01, Thomas Lord wrote: Joe Marshall wrote: So am I right in assuming that you were thinking of FEXPRs in the general case rather than the way SCM uses the term? SCM fexprs can't (in general) be expanded until run-time so I'm not sure what you are asking. Hobbit (the compiler that come's with SCM) compiles only a subset of programs, as far as I recall. Actually, it's useful that SCM's fexprs have this property: it makes it possible to write domain-specific incremental (re-)compilers in Scheme. Fexprs just add a new rule to application: if the first position of an application points to a fexpr, arguments are unevaluated but the result an expression which is itself evaluated. I'd like fexprs in combination with first-class environments which are reified if and only if their lexical scope includes a call (the-environment). Since any call in a lexical scope can be an invocation of an fexpr, and since any fexpr may result in a call to (the-environment), it is statically undecidable whether reification is necessary or not. So in the general case, you will always need to reify them. Static analysis of the involved fexprs doesn't help you in the general case because they are Turing-complete. That's the gist of Mitchell Wand's paper The Theory of Fexprs is Trivial, IIUC. Pascal -- Pascal Costanza, mailto:[EMAIL PROTECTED], http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
| Date: Sat, 26 May 2007 11:58:47 -0700 | From: Joe Marshall [EMAIL PROTECTED] | | On 5/25/07, Thomas Lord [EMAIL PROTECTED] wrote: |There's nothing especially new about the proposals. | | Nope. And that's part of the problem. | | Both FEXPRs and first-class environments make it extremely | difficult to reason about the behavior of a program. With FEXPRs, | you simply cannot tell whether any particular instance of a | function call is going to be a special form or not. It might be | applicative order this time, normal order next time. Every year or | two someone tries to re-introduce fexprs. People point out the | problems and the person ignores them and tries anyway. He comes | back a month or so later and says ``Well, I got them working, but I | can't figure out how to compile...'' SCM has been using FEXPRs without the difficulties you mention since 1992. In interpretation, each FEXPR form is replaced by the code it expands to the first time that form is evaluated. Both the Hobbit (http://swiss.csail.mit.edu/~jaffer/hobbit_toc.html) and Schlep (http://swissnet.ai.mit.edu/~jaffer/Docupage/schlep.html) compilers expand all defmacros before analyzing the code to be compiled using the SLIB function DEFMACRO:EXPAND* `(require 'defmacroexpand)' -- Function: defmacro:expand* e Returns the result of expanding all defmacros in scheme expression E. SLIB also has expander functions for the Macros-That-Work, Syntactic-Closures, and Syntax-Case macro systems. ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
Joe Marshall wrote:
I'm guessing that we aren't quite talking about the same thing. I
couldn't find
any documentation on FEXPRs in SCM, so I'm not quite sure what the
semantics are.
They are called macros, in SCM. A subset of macros are
memoizing macros. These are classic old lisp-style macros
that take implicitly quoted arguments and return a form to
be evaluated. A memoizing macro is only evaluated
once, ever, per call-site (and then is replaced, permanently,
by the code it produces).
SCM doesn't have first-class environments at the user level
but they figure prominently internally. I forget whether
Guile has surfaced environments or not but Systas Scheme
did.
What I am talking about is first-class functions that don't evaluate
their arguments. For example, in this code:
(define foo (flambda (x y) `(list ',x ',(- y 3
(define bar (lambda (f a b) (f (+ b 2) a)))
(bar cons nil 4) = (6)
(bar foo 4 nil)
= ((+ b 2) 1)
foo is our fexpr, and when we pass it into bar, the subform (+ b 2) is
passed rather than the value.
Right. Fexprs.In SCM, that's:
(defmacro (foo x y) `(list ',x ',(- y 3)))
Both the Hobbit (http://swiss.csail.mit.edu/~jaffer/hobbit_toc.html)
and Schlep (http://swissnet.ai.mit.edu/~jaffer/Docupage/schlep.html)
compilers expand all defmacros before analyzing the code to be
compiled using the SLIB function DEFMACRO:EXPAND*
`(require 'defmacroexpand)'
-- Function: defmacro:expand* e
Returns the result of expanding all defmacros in scheme
expression E.
I expect that this is different from what I was talking about because
the form
cannot be expanded before runtime because the procedure isn't applied.
In this paper:
@inproceedings{ bawden00firstclass,
author = Alan Bawden,
title = First-Class Macros have Types,
booktitle = Symposium on Principles of Programming Languages,
pages = 133-141,
year = 2000,
url = citeseer.ist.psu.edu/bawden00firstclass.html }
Bawden points out that if you know a bit about the macros, like what
sections of code they intend to retain as code and what sections they
intend to manipulate as list structure, you can recover the
compilability, but I don't know of a Scheme system that has taken this
approach.
I have to confess that I making assumptions about what Tom Lord
proposes as FEXPRs, so if I have that wrong, I'm obviously arguing a
bogus position.
In the *general case* you can't expand fexpr-style macros at
run-time however if you use them (along with first-class
environments) to implement conventional Scheme macros,
they should be expandable at compile time by constant
folding and similarly simple partial evaluation.
If you make careful use of first-class environments to implement
something like the PLT macro system, should should (using the
same kinds of tricks) be able to get separate compilation.
-t
___
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
Thomas Lord wrote: In the *general case* you can't expand fexpr-style macros at run-time however ur... that's until run-time, not at, of course. -t ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
On 5/25/07, Thomas Lord [EMAIL PROTECTED] wrote: There's nothing especially new about the proposals. Nope. And that's part of the problem. Both FEXPRs and first-class environments make it extremely difficult to reason about the behavior of a program. With FEXPRs, you simply cannot tell whether any particular instance of a function call is going to be a special form or not. It might be applicative order this time, normal order next time. Every year or two someone tries to re-introduce fexprs. People point out the problems and the person ignores them and tries anyway. He comes back a month or so later and says ``Well, I got them working, but I can't figure out how to compile...'' I was much more gung-ho on first-class environments, but Chris Hanson changed my mind. If an environment is first-class, then it becomes impossible to tell where a symbol is bound. It also becomes impossible to compile anything because you are exposing the implementation of closures. The things you can do with first-class environments can be done in other ways more efficiently and more clearly. Finally, prototype-based object systems make good toys, but not good systems. I was a fan of Object-Lisp (Drescher) for a while, but it had some horrendous problems: The primary one is severe brittleness due to the `fragile base class' problem. This isn't an issue when you have a little object system that you have full control over. It is a huge issue when you have many developers manipulating objects and you want to do something like persist the objects. I tried porting Object Lisp to MIT Scheme and using first-class environments to represent the object bindings. It was a disaster (I managed to get the microcode confused enough to crash). After much discussion with Hanson and Rozas I came to the conclusion that this path was seductive, but unpromising. There may not be much in this note that merits reply either. I'm just pointing out that it's been tried before (several times), found wanting (several times), and discarded (several times), for at least the past 20 years and that a lot of *very* smart people have been unable to make much headway. It's possible that these people are wrong, and that you have a breakthrough method, but based on past evidence I wouldn't put the entire Scheme community down this path. -- ~jrm ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
Thomas Lord scripsit: The addition of a few, parsimoniously chosen features eliminates the need for almost everything that is new in the R6 draft. Nearly *ALL* of the new hacks could be done as SRFIs, if only R6 would add these few OPTIONAL features: Indeed, many R5RS features could likewise be removed in this fashion (though I think some of your cures are far worse than the diseases). However, this fails to appreciate the purpose of a _standard_. We standardize in order to improve communication. There is no reason why people can't implement their own version of LIST-LENGTH (e.g.), but it appears in R5RS precisely so that there will not be a variety of inconsistent implementations under an even larger variety of names. There is nothing in any standard that requires an implementer to conform to it, and likewise for a program author, after all. If you want R5RS (or R4RS), you know where to find it. -- In politics, obedience and support John Cowan [EMAIL PROTECTED] are the same thing. --Hannah Arendthttp://www.ccil.org/~cowan ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
On 5/25/07, Jay Sulzberger [EMAIL PROTECTED] wrote: On Fri, 25 May 2007, Thomas Lord [EMAIL PROTECTED] wrote: R6 should be completely different from the current draft, in my opinion. The addition of a few, parsimoniously chosen features eliminates the need for almost everything that is new in the R6 draft. Nearly *ALL* of the new hacks could be done as SRFIs, if only R6 would add these few OPTIONAL features: Yes. Let us keep Scheme Scheme. In which version of the Scheme report did first class environments appear? Fexprs? -- sam th [EMAIL PROTECTED] ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
Robby Findler wrote: On 5/25/07, Thomas Lord [EMAIL PROTECTED] wrote: Had Scheme been liberalized in the direction of FEXPRs and first class environments a few years back, by now, there'd be a lot of interesting RD in on-line incremental compilation of Scheme. That seems extremely unlikely to me. Anything that doesn't at least have some connection to the typed orthodoxy is already essentially impossible to get published these days (a recent submission to ICFP on macros got a 10 out of 10 from one reviewer but was still rejected). My guess is that what you suggest would have likely made Scheme even less relevant to the PL research community than it currently is. If I understand correctly, you are basically explaining why impossible to get published is an increasingly irrelevant metric. Surely, if Scheme had all of those more dynamic, more general features -- any already-published paper could be updated to include just a few words saying We consider a subset of Scheme in which Now, if the publication refereeing process gives different results just because of that, then it is the publication system, not the programming language, that is broken. However, I think that the presence of those more dynamic, more general features would have a beneficial effect in changing the direction of programming language research. Here is some handwaving as to why: Some years back, you recall, Self was pretty hot stuff in PL research. At the periphery of things like self there was even systems-programming relevance of incremental, on-demand compilation in the form of hacks such as the synthesis kernel. That stuff was hard, back then and still, and so investment in those directions dried up pretty much. Following the worse-is-better pattern, the high-level result of having those features -- a prototype-based object system -- got realized again and again and again in Perl, Python, Lua, Ruby, Javascript, and more. We have empirical evidence that programming languages with that kind of object system have very good survival characteristics. And now, in the real world, we're entering a period when commerce is going to drive innovation in the implementation of such systems where Scheme could have been driving that very same research for years, by now. If Scheme had those features, Scheme implementations might easily have wound up as early contenders in the scripting language wars, and/or as Javascript engines. This would have fed back into research opportunities. For example, a look at the literature suggests that one notable Schemer might have left for greener pastures had fexprs been in Scheme for any length of time: http://citeseer.ist.psu.edu/wand98theory.html. (Or maybe he might have just taken up the challenge for the joy of the hunt Mitch?) Interesting. -t Robby ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
On 5/25/07, Thomas Lord [EMAIL PROTECTED] wrote: Robby Findler wrote: On 5/25/07, Thomas Lord [EMAIL PROTECTED] wrote: Had Scheme been liberalized in the direction of FEXPRs and first class environments a few years back, by now, there'd be a lot of interesting RD in on-line incremental compilation of Scheme. That seems extremely unlikely to me. Anything that doesn't at least have some connection to the typed orthodoxy is already essentially impossible to get published these days (a recent submission to ICFP on macros got a 10 out of 10 from one reviewer but was still rejected). My guess is that what you suggest would have likely made Scheme even less relevant to the PL research community than it currently is. If I understand correctly, you are basically explaining why impossible to get published is an increasingly irrelevant metric. :) Robby ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
On 5/25/07, Thomas Lord [EMAIL PROTECTED] wrote: Sam TH wrote: In which version of the Scheme report did first class environments appear? Fexprs? None but you can see the power of (a weaker variation on the proposed) FEXPRs in SCM. And yet, hygenic macro systems such as syntax-case have been widely adopted in the Scheme community. You can get a hint of the potential of environments from MIT Scheme. And yet, much more static module systems such as those of Chez Scheme, PLT Scheme and Scheme 48 have been adopted by the Scheme community. If you expected the R6RS process to result in an entirely new Lisp dialect, which bore little resemblance to the major Scheme systems in use today, then you had wildly unrealistic expectations. Honestly, entering the Scheme scene around R3 or R4 I had the impression that, by the time of something like R6, things would have gone in these fairly obvious directions. Perhaps others felt these directions were less obvious, or even detrimental. I'm really quite struck, by the way, at how Scheme has languished in the real-world HLL wars, losing to such less disciplined efforts like Python, Lua, Ruby, etc all of which seem to have in common (and that has a big impact on the kinds of innovation that drives them) that they have prototype-based object systems. This account of history has the major flaw that none of the languages you list have prototype-based object systems. Also, the major language with such an object system today, Javascript, is adding a class based object system in its next release. As to why Scheme has 'languished', a quite famous essay on the adoption of technology was written a while back, with Scheme as a primary example. I suggest consulting it. That those are pragmatically identifiable as first-class mutable environments in Scheme, and that such a feature can also be arrived at in independent ways, suggests to me it is a very natural direction for the language to take. First class environments are very different from prototype based object systems. For instance, the latter can be easily implemented in Scheme, without disturbing the rest of the language. The former cannot. It's ironic that we've recently seen (on c.l.s.) a long thread debating the exact meanings of terms like JIT compilation, incremental compilation, etc..Had Scheme been liberalized in the direction of FEXPRs and first class environments a few years back, by now, there'd be a lot of interesting RD in on-line incremental compilation of Scheme. If you think the adoption of FEXPRs would have avoided pointless terminology debates on Usenet, I have some high value property you may be interested in. -- sam th [EMAIL PROTECTED] ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
Re: [r6rs-discuss] R6 counterproposal
On Fri, 25 May 2007, Sam TH [EMAIL PROTECTED] wrote: On 5/25/07, Jay Sulzberger [EMAIL PROTECTED] wrote: On Fri, 25 May 2007, Thomas Lord [EMAIL PROTECTED] wrote: R6 should be completely different from the current draft, in my opinion. The addition of a few, parsimoniously chosen features eliminates the need for almost everything that is new in the R6 draft. Nearly *ALL* of the new hacks could be done as SRFIs, if only R6 would add these few OPTIONAL features: Yes. Let us keep Scheme Scheme. In which version of the Scheme report did first class environments appear? Fexprs? -- sam th [EMAIL PROTECTED] I address no specifics. But I believe that R6RS so far is not sufficiently exact, nor sufficiently minimal. I also recognize that I am a spectator, and not a worker. oo--JS. ___ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
