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
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
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
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
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,
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
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
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
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
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 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
| 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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
