Strange thing about define-syntax II
Ji-Yong D. Chung
preceding email-questions about define syntax.
Basic question here is: why does define-syntax
behave differently in the two examples below
(using Petite Chez Scheme):
============================
Setup code. Just type in:
(define-syntax blah
(syntax-rules (a)
((blah x a)
(define x 1000))
((blah x y)
(define x y))
(1) Then, If I type
> (expand '(lambda ()
(blah a a)
a)))
I get
> (lambda (#:a) (letrec ([#:a 1000]) #:a))
(#a: refers to renamed local variable a).
(2) On the other hand, if I type
> (expand '(lambda (a) ;; a is a formal parameter
(blah a a)
a)))
I get
> (lambda (#:a) (letrec ([#:a #:a]) #:a))
=================================
Why the difference?
Jordan Johnson
> Basic question here is: why does define-syntax
>behave differently in the two examples below
>(using Petite Chez Scheme):
>
> (syntax-rules (a)
> ((blah x a)
> (define x 1000))
> ((blah x y)
>
>
>(1) Then, If I type
>
>> (expand '(lambda () (blah a a) a))
>
>
>> (lambda (#:a) (letrec ([#:a 1000]) #:a))
(I assume you're really getting (lambda () (letrec ...));
that's what I get.)
>(2) On the other hand, if I type
>
>> (expand '(lambda (a) ;; a is a formal parameter
> (blah a a)
> a)))
>
> I get
>
>> (lambda (#:a) (letrec ([#:a #:a]) #:a))
From R5RS sec. 4.3.2.:
Identifiers that appear in <literals> are interpreted as
literal identifiers to be matched against corresponding
subforms of the input. A subform in the input matches a literal
identifier if and only if it is an identifier and either both
its occurrence in the macro expression and its occurrence in
the macro definition have the same lexical binding, or the two
identifiers are equal and both have no lexical binding.
<literals> refers to the parenthesized list following "syntax-rules", the one
containing the a symbol. Following the paragraph I quoted, there's a
demonstration similar to yours but using the existing macro for cond.
best,
jmj
--
( jordan m johnson : jorjohns @ indiana.edu : (just some guy) )
( If I were a bug, I would want to be a true Renaissance bug. )
Ji-Yong D. Chung
I know that my question seems like
the example covered in R5RS, but I
was thinking of something else.(or I am
failing to understand you). So, if you can
just bear with me a bit, let me explain.
Say you have:
(lambda ()
(blah a a)
a)
For (blah a a) to expand correctly, in
accordance with my original rule,
(define-syntax blah
(syntax-rules (a)
((blah x a)
(define x 1000))
((blah x y)
(define x y))))
one has to know whether the second occurrence
of variable a within (blah a a) is a literal or a local
variable. If it is a local variable, it should expand
in accordance with the second rule, because local
variable a would have a different syntactic binding
than literal a.
The problem is that you cannot know before the
expansion of (blah a a), whether variable a is a
literal or a local variable.(blah a a) may expand
into a local definition of variable a, in which case
variable a will turn out to be local to the body of
lambda.
In my examples, the variable a turns out to be
local, and not literal a.
Therefore, the macro rule is incorrectly
applied in expanding
(lambda () (blah a a) a)
==================================
Basically my question is:
(1) how can a macro-expander know whether a
variable is local or not (so that it can correctly pattern
match), when it is the expanded form itself that
determines the syntax type?
or more generally
(2) How can a macro correctly expand an expression,
when its output depends on knowing, a priori, what
the output is?
My (probably misguided) view at this point is --
R5RS hygienic macro specification has a bug.
It should reserve a number of keywords, two of which
should be define and define-syntax.
Jordan Johnson
>
> (1) how can a macro-expander know whether a
>variable is local or not (so that it can correctly pattern
>match), when it is the expanded form itself that
>determines the syntax type?
This answer might be too simple for your purposes (as
I haven't implemented a macro system myself), but I believe
the general idea is to pass an environment along in the
expander, and/or add contextual data to the identifiers and
other forms as you process them.
>(2) How can a macro correctly expand an expression,
>when its output depends on knowing, a priori, what
>the output is?
As far as I can tell, that shouldn't be necessary, since
even this literals issue can be resolved based on
information in the unexpanded program tree.
Ji-Yong D. Chung
Some final thoughts -- before I republish this thread (God
forbid, right? :)
>This answer might be too simple for your purposes (as
>I haven't implemented a macro system myself), but I believe
>the general idea is to pass an environment along in the
>expander, and/or add contextual data to the identifiers and
>other forms as you process them.
In my expander, I am passing in the syntactic environment.
So, does Bigloo's version (which is Clinger's version, perhaps
outdated).
>>[I asked] (2) How can a macro correctly expand an expression,
>>when its output depends on knowing, a priori, what
>>the output is?
>As far as I can tell, that shouldn't be necessary, since
>even this literals issue can be resolved based on
>information in the unexpanded program tree.
Of course, that begs the question -- how?
Consider a standard algorithm for
expanding the following (again, I could
be mistaken on understanding of this matter, so
please correct me):
(lambda ()
(blah x y)
(blah_2 y x))
x)
as in my very first example.
The expander does not know, at the time it begins
to expand its bodies, what the true identities of its variables
are. So, the best it can do is, first extend its
syntactic environment by using its own parameter list.
If it knew there were more internal definitions, it would
extend its syntactic environment using the names
of those definitions. The extension is done so that
it can perform renaming, using the
extended environment.
Following that, it expands the first expression.
If it turns out to be a definition, it must augment its
syntactic environment again, before expanding the
second element of the body.
By the time the second expression has been expanded,
we have the following.
(define blah
(lambda ()
(define x __)
(define y x)
The second "define" is correctly expanded,
because we know that variable x is local (variable
x will have been renamed within the second
define as well).
The first definition has a slot open,
to indicate that that variable has not been
renamed, because syntactic environment that it needs
for the substitution is not complete.
To complete the expansion, we need to
augment the syntactic environment once more
(with the name of the second definition)
and then perform renaming substitutions to the
very FIRST body element. So, you see, the
algorithm has to backtrack, in effect expanding
"twice."
My problem here is that if the initial expansion of,
let us say, blah, is incorrect, then, what do we do?
I suppose we can try starting over -- but
(1) first, reexpanding is pretty expensive
AND (2) there will be scenarios in which there
is no converging expansions pattern.
(i.e., the last expansion always causes the first
expansion to be redone).
I am having difficult time understanding
this issue -- there must be something I am missing --
otherwise I am trapped by my stupid logic.
Al Petrofsky
about internal definitions and the matching of literals in
syntax-rules. R5rs section 5.3 allows us to avoid a similar set of
problems by placing restrictions on the shadowing of syntactic
keywords:
Although macros may expand into definitions and syntax definitions in
any context that permits them, it is an error for a definition or
syntax definition to shadow a syntactic keyword whose meaning is
needed to determine whether some form in the group of forms that
contains the shadowing definition is in fact a definition, or, for
internal definitions, is needed to determine the boundary between the
group and the expressions that follow the group.
But that sentence does not save us from the thorny examples below
because they do not involve the shadowing of any keywords. I think
the root of the problem lies in this paragraph from r5rs section
4.3.2:
Identifiers that appear in <literals> are interpreted as literal
identifiers to be matched against corresponding subforms of the input.
A subform in the input matches a literal identifier if and only if it
is an identifier and either both its occurrence in the macro
expression and its occurrence in the macro definition have the same
lexical binding, or the two identifiers are equal and both have no
lexical binding.
The problem is that it is unclear what exactly the lexical environment
of "the macro expression" includes when the macro use is not an
expression, but an internal definition. Consider the expression:
(lambda ()
(define a <exp1>)
(define b <exp2>)
<exp3>)
It is clear that the lexical environment of <exp1> includes bindings
for a and b, and any uses of syntax-rules macros within <exp1> will do
literals matching accordingly. But what is included in the lexical
environment of the (define a <exp1>) form? In the absence of macros
that's not a meaningful question, but consider the following
expression, in which (foo) is a macro use that expands to a
definition:
(lambda ()
(define a <exp1>)
(foo)
(define b <exp2>)
<exp3>)
What is the lexical environment of the macro use (foo)? Does it
include the bindings for a and b? Let's discuss three possible
answers:
1: It includes the bindings for a and b
2: It includes neither binding.
3: It includes the binding for a, but not b.
Let's restate those possible rules:
1: The lexical environment of an internal definition includes
bindings for all the variables internally defined in the body.
2: The lexical environment of an internal definition does not include
bindings for the variables internally defined in the body.
1: The lexical environment of an internal definition includes
bindings for the variables internally defined in the body
before the internal defintion in question.
The third rule is the least appealing, but it leads to the fewest
paradoxes.
Rule one would mean that the environment of the use of the macro foo
would include bindings for a and b, and, somehow, for the variable
into whose definition it will expand. This just doesn't seem
feasible.
Rule two leads to ambiguities like the following expression:
(let-syntax
((foo (syntax-rules (a)
((_ x a) (define x 1))
((_ x y) x))))
(let ((b 2))
(define a 0)
(foo b a)
b))
Does this evaluate to 1 or 2? If (foo b a) is expanded as an internal
definition, then its lexical environment does not include a binding
for a, so it matches the first rule, thereby producing:
(let ((b 2))
(define a 0)
(define b 1)
b)
=> 1
But if (foo b a) is expanded as the first expression of the body, then
its lexical environment includes the binding for a, so it does not
match the first rule, and we get:
(let ((b 2))
(define a 0)
b
b)
=> 2
Either expansion is entirely self-consistent.
Rule 3, though ugly, avoids these ambiguities (and the above example
evaluates to 2.)
Looking at Clinger's "Macros that Work" implementation (as it appears
in slib s7c), one can see that it follows rule 2. However, it has a
bug because it does not do the extra bit of backtracking that rule 2
requires:
(macwork:expand '(let-syntax ((foo (syntax-rules (a)
((_ a) 1)
((_ x) 2))))
(let ()
(define a 0)
(foo a))))
=> (let ()
(letrec ((a|3 0))
1))
In this example, (foo a) is clearly an expression, not a definition,
so its lexical environment includes the binding created by the
internal definition for a, and so it does not match the first rule,
and so the correct expansion is 2. The reason macwork gets it wrong
is that it first expands (foo a) as if it were a definition, with no
binding for a, and then when it sees that the result is not a
definition, it fails to realize that this means it must redo the
expansion (this time *with* the binding for a).
====
The most reasonable solution to the problem that I can see is to
somehow augment the restriction in r5rs 4.3.2 in a minimal way such
that it will forbid these ambiguous cases.
-al
David Rush
explanation when it deserves a scalpel, so please bear with me.
Al Petrofsky <Almol...@Petrofsky.Berkeley.CA.US> writes:
> "Ji-Yong D. Chung" <virtua...@erols.com> asks difficult questions
> about internal definitions and the matching of literals in
> syntax-rules. R5rs section 5.3 allows us to avoid a similar set of
> problems by placing restrictions on the shadowing of syntactic
> keywords:
>
> Although macros may expand into definitions and syntax definitions in
> any context that permits them, it is an error for a definition or
> syntax definition to shadow a syntactic keyword whose meaning is
^^^^^^^^^^^^^^^^^ -- This is the
problem isn't it? A syntactic keyword must be in the head position of
a datum; the ambiguities that are causing the trouble here are from
identifiers that are not in head position. If this were changed
to disallow shadowing of any identifiers "needed to determine..."
> needed to determine whether some form in the group of forms that
> contains the shadowing definition is in fact a definition, or, for
> internal definitions, is needed to determine the boundary between the
> group and the expressions that follow the group.
then the conflicts with 4.3.2 would not arise. Or am I missing the
point completely?
david rush
--
In a tight spot, you trust your ship or your rifle to get you through,
so you refer to her affectionately and with respect. Your computer? It
would just as soon reboot YOU if it could. Nasty, unreliable,
ungrateful wretches, they are. -- Mike Jackmin (on sci.crypt)
Ji-Yong D. Chung
> Al Petrofsky <Almol...@Petrofsky.Berkeley.CA.US> writes:
> > "Ji-Yong D. Chung" <virtua...@erols.com> asks difficult questions
> > about internal definitions and the matching of literals in
> > syntax-rules. R5rs section 5.3 allows us to avoid a similar set of
> > problems by placing restrictions on the shadowing of syntactic
> > keywords:
> >
> > Although macros may expand into definitions and syntax definitions
in
> > any context that permits them, it is an error for a definition or
> > syntax definition to shadow a syntactic keyword whose meaning is
> ^^^^^^^^^^^^^^^^^ -- This is the
> problem isn't it? A syntactic keyword must be in the head position of
> a datum; the ambiguities that are causing the trouble here are from
> identifiers that are not in head position. If this were changed
> to disallow shadowing of any identifiers "needed to determine..."
>
> > needed to determine whether some form in the group of forms that
> > contains the shadowing definition is in fact a definition, or, for
> > internal definitions, is needed to determine the boundary between
the
> > group and the expressions that follow the group.
>
> then the conflicts with 4.3.2 would not arise. Or am I missing the
> point completely?
No, actually, I think your solution is feasible -- provided that you
can get the Scheme community to sign on it. One problem I see is that
an unwitting programmer who thinks she can do anything in Scheme can write a
few (ab)usive macros with paradoxes mentioned before, and
accidentally shoot her own gucci bags. But then, we can say she deserves
it because she was not careful about redefining the keywords.
(Its their problem not ours approach).
My original approach was not similar to using an "ax" but to using a
bulldozer, that of reserving *really* few keywords -- but Scheme community
would probably shoot that down like messenger pigeons.
Ji-Yong D. Chung
> The most reasonable solution to the problem that I can see is to
> somehow augment the restriction in r5rs 4.3.2 in a minimal way such
> that it will forbid these ambiguous cases.
I'd assume that you are also implicitly proposing,
among the 3 rules you have stated, the second
rule to use.
As for augmenting the restriction in r5rs 4.3.2,
how about simply using the very first patern
that matches?
This solution is rather crude and has no reason or
rhyme behind it, of course, and I am not sure the cure is
any better than the disease. For me, an "implementor",
I'd prefer that over uncertainty in implementation.
BTW, how do we convey this type of information/
proposal to people in charge of r5rs/r6rs, so that at
least they have a chance to shoot it down?
David Rush
> BTW, how do we convey this type of information/
> proposal to people in charge of r5rs/r6rs, so that at
> least they have a chance to shoot it down?
Posting right here is about as close as you can get, short of directly
emailing the people listed as authors on the actual report. Certainly
Will Clinger posts here from time to time. Other folk (editors/authors
Rees, Pitman, Dybvig; other luminaries like Shriram, the mighty
Matthiases, Felleisen & Blume. Olin Shivers &cet) that have had
input to the various RnRSs appear periodically, as well.
However, AFAICT, the RnRS-authors list is dead, and new standards
development is happening only in the SRFI world, not in the core
language. It's too bad really because there are some things that can
only be fixed in the core. I'd suggest that you implement your fix to
the macro specification, document it apropriately, and move on. The
Scheme `standard' has always lagged the implementations, anyway.
david rush
--
From the start...the flute has been associated with pure (some might
say impure) energy. Its sound releases something naturally untamed, as
if a squirrel were let loose in a church." --Seamus Heaney
Jeffrey Siegal
> However, AFAICT, the RnRS-authors list is dead, and new standards
> development is happening only in the SRFI world, not in the core
> language. It's too bad really because there are some things that can
> only be fixed in the core.
How about somebody revive the list and restart work on the core
language? This is 2001, after all, and anybody including my grandmother
can easily create a mailing list.
If not all of the RnRS authors want to participate, that's
unfortunately, but perhaps at least a few would, and some new
contributors would take up the slack.
Ji-Yong D. Chung
"Jeffrey Siegal" <j...@quiotix.com> wrote in message
news:3B003455...@quiotix.com...
> David Rush wrote:
> > However, AFAICT, the RnRS-authors list is dead, and new standards
> > development is happening only in the SRFI world, not in the core
> > language. It's too bad really because there are some things that can
> > only be fixed in the core.
>
> How about somebody revive the list and restart work on the core
> language? This is 2001, after all, and anybody including my grandmother
> can easily create a mailing list.
(1) Who would qualify to lead that work (other than the original
authors)?
I cannot imagine that there would be many who know the stuff inside out.
(2) Also, is there enough material to justify revising R5RS? Are there
significant number of problems with Scheme to justify producing R6RS?
If the problem with hygienic macro covered in this discussion thread
is just one of few known problems with the language, then, it probably
does not justify the revision.
(Perhaps, first, there has to be a survey of known problems with
Scheme core language)
I would guess that the amount work required for revising R5RS
should not be too bad, because, after all, it is based
on R5RS, right?. :)
Jeffrey Siegal
> (1) Who would qualify to lead that work (other than the original
> authors)?
> I cannot imagine that there would be many who know the stuff inside out.
As long as there is Scheme work continuing, which there is, there are
people qualified to at least participate. The question of leadership
would need to be addressed after there was at least some part of a group
established (or reestablished). A look at the discussion lists for the
various SRFI's will reveal quite a few expert Scheme linguists and
implementors.
> (2) Also, is there enough material to justify revising R5RS? Are there
> significant number of problems with Scheme to justify producing R6RS?
> If the problem with hygienic macro covered in this discussion thread
> is just one of few known problems with the language, then, it probably
> does not justify the revision.
I remember quite a few issues discussed here over the past few years.
Some of these could, no doubt, the addressed via the SRFI process
(though, as discussed here recently, the SRFI process is really not
intended to guide the progress of the core language) but some are
defitely core issues. Perhaps someone with a better memory (or more
time to dig through the archives) could try to put together a list of
these issues.
> I would guess that the amount work required for revising R5RS
> should not be too bad, because, after all, it is based
> on R5RS, right?. :)
That's the idea.
Alpacas Petrofsky
> I feel like I'm taking an axe to your carefully-constructed
> explanation when it deserves a scalpel, so please bear with me.
>
> Al Petrofsky <Almol...@Petrofsky.Berkeley.CA.US> writes:
> > "Ji-Yong D. Chung" <virtua...@erols.com> asks difficult questions
> > about internal definitions and the matching of literals in
> > syntax-rules. R5rs section 5.3 allows us to avoid a similar set of
> > problems by placing restrictions on the shadowing of syntactic
> > keywords:
> >
> > Although macros may expand into definitions and syntax definitions in
> > any context that permits them, it is an error for a definition or
> > syntax definition to shadow a syntactic keyword whose meaning is
> ^^^^^^^^^^^^^^^^^ -- This is the
> problem isn't it? A syntactic keyword must be in the head position of
> a datum; the ambiguities that are causing the trouble here are from
> identifiers that are not in head position. If this were changed
> to disallow shadowing of any identifiers "needed to determine..."
>
> > needed to determine whether some form in the group of forms that
> > contains the shadowing definition is in fact a definition, or, for
> > internal definitions, is needed to determine the boundary between the
> > group and the expressions that follow the group.
>
> then the conflicts with 4.3.2 would not arise. Or am I missing the
> point completely?
That wouldn't quite do it, because there's still ambiguity about how
to expand macros in the definitions section of a body even when the
location of the definitions/expressions boundary is clear, e.g.:
(let-syntax
((foo (syntax-rules (a)
((_ x a) (define x 1))
((_ x y) (define x 2)))))
(define a 0)
(foo b a)
b)
This evaluates to 1 or 2 unless you add something to 4.3.2 clarifying
whether the internal definition of a is visible at the time of the
expansion of (foo b a). Alternatively, we can call this example an
error by broadening 5.3. I prefer the latter solution. I'm not sure
how best to express it, though. Perhaps appending something like
"... or is needed to determine the expansion of a macro into one of
the definitions in the group". But that monster sentence is already
harder to parse than a Clinton deposition, so a more substantial
overhaul is probably appropriate.
-al
David Rush
>
> > > However, AFAICT, the RnRS-authors list is dead, and new standards
> > > development is happening only in the SRFI world, not in the core
> > > language. It's too bad really because there are some things that can
> > > only be fixed in the core.
> >
> > How about somebody revive the list and restart work on the core
> > language? This is 2001, after all, and anybody including my grandmother
> > can easily create a mailing list.
Indeed. However, there is one other (historically) important ingredient: an
implementation testbed. Again, AFAICT, most of R5RS was implemented
before it was standardized (at least by Scheme48 or so it would
appear). Most of the changes I've heard about have been driven more by
users than implementors. There's nothing wrong with this, in fact it
shows that the language is *much* more lively than a purely
academic/pedagogic tool; but all the standardization in the world is
irrelevant if no one implements the standard.
> (1) Who would qualify to lead that work (other than the original
> authors)? I cannot imagine that there would be many who know the
> stuff inside out.
There are tons of people who could coordinate the effort. I would
personally nominate Shriram Krishnamurthi for his combination of
advocacy, academic and practical experience with PLT, but there are
plenty of others.
> (2) Also, is there enough material to justify revising R5RS? Are
> there significant number of problems with Scheme to justify
> producing R6RS?
That's a matter of taste, but IMHO, yes. Please realize that I think
that Scheme was well-served by the ongoing revision process leading up
to R5RS, and I don't see a need for there to be huge defects to make
it worth opening the R6RS can of worms. But perhaps that's the
difference between a user and an implementor: it's always easy to make
suggestions when you don't have to implement them.
> If the problem with hygienic macro covered in this discussion thread
> is just one of few known problems with the language, then, it probably
> does not justify the revision.
A few others that have been discussed (or whined about) (or I've
complained to my shower about) recently (although there is
little consensus about what to do about them):
* cleaning up the dynamic-wind mess
* fixing the I/O model (arguably SRFI-able)
* extensions to the value lattice
* user-defined types (not another object system!)
* access to machine resources (machine integers, OS memory
structures...This may be partly or wholly SRFI-able)
* Bringing back R4RS low-level macros (although I've not read
the archives on why they were pitched)
* formal recognition of the SRFI process and mandatory support
for *at least* SRFI-0 (SRFI-7 would also be good)
* internal `define' and the PLT `locals' construct
* let/cc vs. call/cc
> (Perhaps, first, there has to be a survey of known problems with
> Scheme core language)
Certainly something more rigorous than my preceding "whinge-list"
should be done.
> I would guess that the amount work required for revising R5RS
> should not be too bad, because, after all, it is based
> on R5RS, right?. :)
Revising the document isn't the hard part. Getting enough support from
implementors is the key.
david rush
--
Next to the right of liberty, the right of property is the most
important individual right ... and ... has contributed more to the
growth of civilization than any other institution established by the
human race.
-- Popular Government (William Howard Taft)
Ji-Yong D. Chung
David Rush wrote in message ...
>---------------------------------------------------------------------------
>I feel like I'm taking an axe to your carefully-constructed
>explanation when it deserves a scalpel, so please bear with me.
>
>Al Petrofsky <Almol...@Petrofsky.Berkeley.CA.US> writes:
>> "Ji-Yong D. Chung" <virtua...@erols.com> asks difficult questions
>> about internal definitions and the matching of literals in
>> syntax-rules. R5rs section 5.3 allows us to avoid a similar set of
>> problems by placing restrictions on the shadowing of syntactic
>> keywords:
>>
>> Although macros may expand into definitions and syntax definitions in
>> any context that permits them, it is an error for a definition or
>> syntax definition to shadow a syntactic keyword whose meaning is
> ^^^^^^^^^^^^^^^^^ -- This is the
>problem isn't it? A syntactic keyword must be in the head position of
>a datum; the ambiguities that are causing the trouble here are from
>identifiers that are not in head position. If this were changed
>to disallow shadowing of any identifiers "needed to determine..."
>
>> needed to determine whether some form in the group of forms that
>> contains the shadowing definition is in fact a definition, or, for
>> internal definitions, is needed to determine the boundary between the
>> group and the expressions that follow the group.
>
>then the conflicts with 4.3.2 would not arise. Or am I missing the
>point completely?
>-------------------------------------------------------------------------
I sent in a bug report to Kent Dybvig for Petite Chez Scheme,
and he seems to feel that R5RS covers the ground. In any case,
Petrofsky, Rush, and Dybvig (at least superficially) seems to agree
that the relevant section in R5RS is 5.3.
The following is an excerpt from his email -- I don't think his email
is personal in nature, so I am posting parts of
that. The example to which he is referring, in the passage below,
is the same example I used earlier in my postings
with (define mamamia (lambda () (blah z z) z).
Regarding that example, Kent Dybvig says:
"In Chez Scheme, the expander processes the forms in a body
from left to right, stopping with each form once it determines that
it is a variable definition or a nondefinition and fully expanding
macro definitions. Once the entire set of definitions is
determined, it processes the right-hand side of each variable definition
and the remaining forms in the body. So in your example, it hasn't seen
the definition for z by the time it expands the macro that looks for z,
hence it does not recognize z as locally defined.
These sorts of problems are the motivation behind the R5RS restriction
that an internal definition cannot affect the expansion of an internal
definition in the same sequence of definitions. Chez Scheme extends
the R5RS by defining expansion as happening in the manner
described above."
==========================================
I would guess he is referring to the following sentence
fragment in R5RS section 5.3, which says
"... it is an error for a definition or syntax definition to
shadow a syntactic keyword whose meaning is needed to
determine whether some form in the groups that contains the
shadowing definition is in fact a definition, ..."
Matthias Radestock
David Rush wrote:
> A few others that have been discussed (or whined about) (or I've
> complained to my shower about) recently (although there is
> little consensus about what to do about them):
>
> * cleaning up the dynamic-wind mess
> * fixing the I/O model (arguably SRFI-able)
> * extensions to the value lattice
> * user-defined types (not another object system!)
> * access to machine resources (machine integers, OS memory
> structures...This may be partly or wholly SRFI-able)
> * Bringing back R4RS low-level macros (although I've not read
> the archives on why they were pitched)
> * formal recognition of the SRFI process and mandatory support
> for *at least* SRFI-0 (SRFI-7 would also be good)
> * internal `define' and the PLT `locals' construct
> * let/cc vs. call/cc
>
Al Petrofsky, in a different thread, has just reminded me of two other
issues that I'd like to see on the list for R6RS:
* ellipsis quotation, i.e. (... ...)
* fix bug in r5rs sample implementation of letrec
Also, if one really wants to open a can of worms, one could attempt to
standardize a module/package system.
IMHO it is absolutely *essential* that the Scheme standardization
process gets revived. R5RS is an excellent piece of work. However, there
are genuine bugs and ommissions that people have discovered in it. It
would be wrong to let that knowledge be "lost" in newsgroups and mailing
lists.
I suppose it is not strictly necessary to go to all the way to R6RS in
order to address bugs/ommissions. A list of errata would probably do and
R6RS could be reserved for genuine extensions (rather than bug fixes /
clarifications). We'd still need a process for dealing with such erratas
though.
Matthias
Jeffrey Siegal
> > * fixing the I/O model (arguably SRFI-able)
> > * extensions to the value lattice
> > * user-defined types (not another object system!)
> > * access to machine resources (machine integers, OS memory
> > structures...This may be partly or wholly SRFI-able)
> > * Bringing back R4RS low-level macros (although I've not read
> > the archives on why they were pitched)
> > * formal recognition of the SRFI process and mandatory support
> > for *at least* SRFI-0 (SRFI-7 would also be good)
> > * internal `define' and the PLT `locals' construct
> > * let/cc vs. call/cc
> >
>
> Al Petrofsky, in a different thread, has just reminded me of two other
> issues that I'd like to see on the list for R6RS:
>
> * ellipsis quotation, i.e. (... ...)
> * fix bug in r5rs sample implementation of letrec
>
> Also, if one really wants to open a can of worms, one could attempt to
> standardize a module/package system.
I'd add:
. Some way of deliberately defining non-hygenic macros
. Clarify some issues with exactness
and, for an even bigger can (barrel) of worms:
. OOP
David Rush
Sliced and diced for (I hope) clarity...
Jeffrey Siegal <j...@quiotix.com> writes:
> > YAM (Yet Another Matthias ;) wrote:
> > > David Rush wrote:
> > > * cleaning up the dynamic-wind mess
> > > * fixing the I/O model (arguably SRFI-able)
> > > * extensions to the value lattice
> > > * user-defined types (not another object system!)
> > > * access to machine resources (machine integers, OS memory
> > > structures...This may be partly or wholly SRFI-able)
> > > * Bringing back R4RS low-level macros (although I've not read
> > > the archives on why they were pitched)
> > > * formal recognition of the SRFI process and mandatory support
> > > for *at least* SRFI-0 (SRFI-7 would also be good)
> > > * internal `define' and the PLT `locals' construct
> > > * let/cc vs. call/cc
> > * ellipsis quotation, i.e. (... ...)
> > * fix bug in r5rs sample implementation of letrec
Good, good.
> I'd add:
> . Some way of deliberately defining non-hygenic macros
This is why I mentioned brining back the R4RS low-level system. It
*was* non-hygienic, but it exposes enough syntactic information to
implement hygienic macros if you wish. It seems very much in line with
the Scheme philosophy...
> . Clarify some issues with exactness
What issues?
> > Also, if one really wants to open a can of worms, one could attempt to
> > standardize a module/package system.
> and, for an even bigger can (barrel) of worms:
> . OOP
I personally believe that these are *really* SRFI issues. There are no
clearly right answers, and the problem space is large enough for
multiple useful solutions to coexist.
david rush
--
Christianity has not been tried and found wanting; it has been found
difficult and not tried.
-- G.K. Chesterton
Biep @ http://www.biep.org/
> and, for an even bigger can (barrel) of worms: OOP
There are so many design decisions here without a way to decide on the
"correct" one, that I think this should be a library issue.
The most the standard might do is reify environments, which would allow a
simple yet powerful OO package to be written in some 20 lines. But I think
even that will not be feasible, despite the advantage that it would clean
up the 'eval' thing, because of efficiency issues with any model that is
rich enough to be theoretically acceptable - so those two parties will take
opposite sides here.
Unless somebody finds a clean and efficiently implementable way to reify
environments. For that, reified mutable locations would be helpful - the
third can of worms! :-)
--
Biep
Reply via http://www.biep.org
ste...@pcrm.win.tue.nl
>Jeffrey Siegal <j...@quiotix.com> writes:
>> > YAM (Yet Another Matthias ;) wrote:
>> > > David Rush wrote:
>> > > * cleaning up the dynamic-wind mess
>> > > * fixing the I/O model (arguably SRFI-able)
>> > > * extensions to the value lattice
>> > > * user-defined types (not another object system!)
>> > > * access to machine resources (machine integers, OS memory
>> > > structures...This may be partly or wholly SRFI-able)
>> > > * Bringing back R4RS low-level macros (although I've not read
>> > > the archives on why they were pitched)
>> > > * formal recognition of the SRFI process and mandatory support
>> > > for *at least* SRFI-0 (SRFI-7 would also be good)
>> > > * internal `define' and the PLT `locals' construct
>> > > * let/cc vs. call/cc
>> > * ellipsis quotation, i.e. (... ...)
>> > * fix bug in r5rs sample implementation of letrec
>
>> . Some way of deliberately defining non-hygenic macros
Some more additions:
* More error checking required for procedures.
* Way to catch failure of primitive functions, such as e.g.
division by zero, so that I don't have to check this myself
every time I do a (/ a b), so as to prevent my interactive
calculator from dying whenever the luser enters 1/0.
(However, returing NaN works for me.)
* Standard module system? Nah, not going to happen.
I am all for a low-level macro system (e.g. a system that allows
arbitrary Scheme code to be executed during macro expansion time),
*provided* that it works OK with all other scheme procedures,
in particular call/cc. That is, it must be possible to reify
a continuation during compile time (really macro expansion time),
and then jump to this continuation at run time. This could
lead to interesting ways to implement (eval ...).
OK, that's a ;-), but it gives an idea what a can of worms is
opened with low-level macro's.
Stephan Houben
--
ir. Stephan H.M.J. Houben
tel. +31-40-2474358 / +31-40-2743497
e-mail: step...@win.tue.nl
Ronald Schröder
<matt...@lshift.net> wrote:
>IMHO it is absolutely *essential* that the Scheme standardization
>process gets revived. R5RS is an excellent piece of work. However, there
>are genuine bugs and ommissions that people have discovered in it. It
>would be wrong to let that knowledge be "lost" in newsgroups and mailing
>lists.
Agreed.
I would like to add that besides renewed language standardization it
would be a good thing to have a write once, run anywhere reference
implementation with an extensive user library.
I do not have any strong feelings about Java but there are some really
good ideas in it, e.g. standardized portable GUI libraries, that are
sorely missed in Scheme.
>A list of errata would probably do and R6RS could be reserved for
>genuine extensions (rather than bug fixes / clarifications). We'd still
>need a process for dealing with such erratas though.
I would suggest dealing with this through schemers.org, in the same
way we deal with SRFIs.
Ronald Schröder
http://www.dreamwater.org/tech/rschroder/
mailto:rsch...@usa.net
mailto:r.sch...@rws.dnb.minvenw.nl
Antti Huima
> A few others that have been discussed (or whined about) (or I've
> complained to my shower about) recently (although there is
> little consensus about what to do about them):
>
> * cleaning up the dynamic-wind mess
Can you clarify what is the mess? In my view dynamic-wind is a great
invention and its functionality absolutely necessary.
--
Antti Huima
Richard Cobbe
> David Rush wrote:
>
> > A few others that have been discussed (or whined about) (or I've
> > complained to my shower about) recently (although there is
> > little consensus about what to do about them):
> >
> > * cleaning up the dynamic-wind mess
I get the feeling that this issue has been discussed to death in recent
months, but I managed to miss most of the discussion.
Rather than restart the whole mess, is there a description of the issues
involved that I could go look at?
Richard
Matthias Blume
Except it is broken wrt. call/cc. In particular, currently we have no
way to reify a continuation, we can only reify a _winding_ continuation.
That is in many cases not at all what one would want.
See the recent discussion on this, or, alternatively, the discussion that
happened several years ago on the same topic. See my proposal for a
call/wc (call-with-winding-continuation) which would leave call/cc what
it used to be. Incidentally, call/wc can be implemented in terms of (the
original) call/cc but not vice versa. Currently we only have call/wc (under
the misleading name call/cc), so we are badly stuck.
Matthias
Juho Östman
>> I'd add:
>> . Some way of deliberately defining non-hygenic macros
>
>This is why I mentioned brining back the R4RS low-level system. It
>*was* non-hygienic, but it exposes enough syntactic information to
>implement hygienic macros if you wish. It seems very much in line with
>the Scheme philosophy...
>
Is there something terribly wrong with syntax-case macro system? It
should allow writing deliberately non-hygienic macros using full
Scheme language and still preserve automatic hygiene.
Syntax-case papers:
http://citeseer.nj.nec.com/dybvig92writing.html
http://citeseer.nj.nec.com/88826.html
Matthias Radestock
"Ronald Schröder" wrote:
>
> >A list of errata would probably do and R6RS could be reserved for
> >genuine extensions (rather than bug fixes / clarifications). We'd still
> >need a process for dealing with such erratas though.
>
> I would suggest dealing with this through schemers.org, in the same
> way we deal with SRFIs.
>
Seems like a reasonable idea. We still need people involved though.
Could the process (which still has to be defined, btw) be run by the
same group that runs the SRFI process ? Ideally it would include some of
the authors/editors of RnRS, since the original authors should really
have some involvement when it comes to issueing errata regarding their
work ;)
Matthias
PS: I'd like to encourage posters to this thread to stay focussed on
discussing the *process* of standardization rather than particular
features of a future R6RS.
Ben Goetter
> Wow, my list hasn't been flamed yet!
Okay, I'll oblige you! Sort of.
A mechanism for exploring extensions to the language akready exists:
SRFI. Until at least one SRFI exists for each item on y'all's lists,
there is no point to this call to revise the existing mutiply revised
standard.
So, if implementation M has a nonstandard feature F that you'd like to
see standard, write it up in a SRFI. If no implementation has this
feature, design and implement it yourself, or lobby the caretakers of
your favorite implementation to do so; then give the feature its head for
a year, to see if it works as you intended.
I suppose that one could make a case for R6RS fixing the two bugs
identified in the spec, and sanctioning the SRFI process. Otherwise,
however, the cry for R6RS is far premature.
Antti Huima
> Antti Huima wrote:
> >
> > David Rush <ku...@bellsouth.net> writes:
> >
> > > * cleaning up the dynamic-wind mess
> >
> > Can you clarify what is the mess? In my view dynamic-wind is a great
> > invention and its functionality absolutely necessary.
>
> See the recent discussion on this, or, alternatively, the discussion that
> happened several years ago on the same topic. See my proposal for a
> call/wc (call-with-winding-continuation) which would leave call/cc what
> it used to be. Incidentally, call/wc can be implemented in terms of (the
> original) call/cc but not vice versa. Currently we only have call/wc (under
> the misleading name call/cc), so we are badly stuck.
Thanks, I read the archives. Summarizing my readings,
* You proposed that call/cc would create a non-winding continuation
and call/wc a winding one.
- Jump to a non-winding continuation would not cause dynamic-wind
frames to be executed, but restore the correct frames list
nevertheless.
- Jump to a winding continuation would run the after- and
before-thunks but work otherwise similarly to a non-winding
continuation.
* One practical motivation is to be able to implement multitasking
by explicitly managing the continuations of the concurrent tasks.
At context switch you do not want to perform potential
dynamic-wind cleanup actions, such as closing and re-opening file
descriptors, say.
* You had the view (sorry if I'm wrong) that a thread and a
continuation could be identical concepts as a thread can be
identified with the linear sequence of continuations it invokes,
and a continuation corresponds to the upcoming linear sequence of
continuations, i.e. the rest of the computation.
What is your view, how does this related to the `dynamic environment'
that is implicitly present in R*RS and that contains for example the
current default output port, and in practical implementations also
lots of other things such as exception handlers.
Now R*RS does not specify how the dynamic environment should actually
respond to non-local exits. Namely, `with-input-from-file' and
`with-output-to-file' which change the dynamic environment have
unspecified behaviour w.r.t. such exits. I think it is common sense
that usually dynamic environments should be restored at jumps to
continuations. In the case of exception handlers this is especially
clear.
In a single-threaded R5RS Scheme we could implement dynamic
environment that would behave in this way generally like:
;; default-output-port not in R5RS
(define *current-output-port* (default-output-port))
(define display
(case-lambda
((datum) (display datum *current-output-port*))
((datum port) ...)))
(define (with-input-from-port port thunk) ;; not R5RS form
(let ((old *current-output-port*))
(dynamic-wind
(lambda () (set! *current-output-port* port))
thunk
(lambda () (set! *current-output-port* old)))))
;; SRFI-23 style exceptions, I presume
(define *exception-handler* (lambda args (error 'no-handler)))
(define (raise exception) (*exception-handler* exception))
(define (with-exception-handler handler thunk) ;; not R5RS form
(let ((old *exception-handler*))
(dynamic-wind
(lambda () (set! *exception-handler* handler))
thunk
(lambda () (set! *exception-handler* old)))))
Now, IF the dynamic environment would work like this, then
implementing multitasking code by explicitly managing non-winding
continuations would not work as the dynamic environments would not be
restored correctly.
Therefore you would need to manage the dynamic environment manually
when doing `context switches', because you couldn't rely on
`dynamic-wind' restoring the correct dynamic environment. But after
that a `thread' is no longer equivalent to a continuation, because a
`thread' is now a continuation + dynamic environment, and the latter
is not a part of the former.
What is your opinion on this issue? Is the idea of dynamic-wind
protected dynamic environment flawed? Can you give some comments?
I want to stress that I ask this because of practical interest: I have
implemented a full-blown Scheme system that has native thread support
and where a thread is not equivalent to a continuation. My call/cc is
a winding one but because jumps to continuations captured by another
thread happen practically never I haven't run into problems. I would
appreciate any insights.
--
Antti Huima
Rob Warnock
+---------------
| Now R*RS does not specify how the dynamic environment should actually
| respond to non-local exits. Namely, `with-input-from-file' and
| `with-output-to-file' which change the dynamic environment have
| unspecified behaviour w.r.t. such exits. I think it is common sense
| that usually dynamic environments should be restored at jumps to
| continuations. In the case of exception handlers this is especially clear.
In the case of file I/O it's not at *all* "clear"!! For instance,
what happens (or "should" happen) if a continuation captured inside
a "with-output-to-file" is (re)invoked after the "with-output-to-file"
terminates normally... thus *closing* the file?!?!?
The Common Lisp standard on the other hand is quite explicit:
[The] "with-open-file" [macro] evaluates the forms as an
implicit progn with stream bound to the value returned by open.
When control leaves the body, either normally or abnormally
(such as by use of "throw"), the file is automatically closed.
If a new output file is being written, and control leaves
abnormally, the file is aborted and the file system is left,
so far as possible, as if the file had never been opened.
This may not be what you *want*, but at least it's defined (and the
sane thing to do in most situations).
To tie this to the "call/cc vs call/wc" issue, if a multi-threading
system tries to use "call/wc" (or a call/wc-in-disguise *named* "call/cc),
disaster is likely if a thread switch occurs while the currently-active
thread is inside a "with-output-to-file"...
Even more perverse examples are easy to imagine.
-Rob
-----
Rob Warnock, 31-2-510 rp...@sgi.com
SGI Network Engineering <URL:http://reality.sgi.com/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
Riku Saikkonen
>* Way to catch failure of primitive functions, such as e.g.
> division by zero, so that I don't have to check this myself
> every time I do a (/ a b), so as to prevent my interactive
> calculator from dying whenever the luser enters 1/0.
> (However, returing NaN works for me.)
It's not pretty, but this should work (in standard R5RS Scheme):
;; Execute and return the value of (thunk), except that if it results
;; in an error, call and return the value of (handler) instead.
(define (catch-errors handler thunk)
(call-with-current-continuation
(lambda (return)
(let ((result #f))
(dynamic-wind
(lambda () 'nothing)
(lambda () ; call the thunk and save the result
(set! result (list (thunk))))
(lambda ()
(if (not result) ; check for an error
(set! result (list (handler))))
(return (car result))))))))
Use it like this:
(define (display-error)
(display "error")
(newline)
'an-error) ; returned from catch-errors
> (catch-errors display-error
(lambda () (+ 1 2)))
3
> (map (lambda (x)
(catch-errors display-error
(lambda () (/ 1 x))))
'(3 2 1 0 -1 -2 -3))
/: division by zero
error
(1/3 1/2 1 an-error -1 -1/2 -1/3)
(Apparently MzScheme considers the exception handler to be inside the
"dynamic context" of dynamic-wind, so the "/: division by zero" is
displayed before (handler) is called.)
--
-=- Rjs -=- r...@lloke.dna.fi
Matthias Radestock
Ben Goetter wrote:
>
> I suppose that one could make a case for R6RS fixing the two bugs
> identified in the spec, and sanctioning the SRFI process. Otherwise,
> however, the cry for R6RS is far premature.
>
There are three classes of standardization work:
1) bug fixes, clarifications, typo corrections to R5RS
I suspect that there are more than just two of these, but even if there
aren't we still need a process to deal with this type of standardization
of things that are "obviously broken" in R5RS. I suggest an "errata"
process that amends R5RS without changing the body of the existing text
or increasing the revision number. When R6RS finally comes along, the
errata would get incorporated into the main text.
2) refinements / additions / changes to core R5RS syntax and/or
semantics
The macro expansion problem that started this thread and the changes to
call/cc / introduction of call/wc fall into this category. They
fundamentally affect R5RS syntax/semantics and are therefore, IMHO, way
beyond the scope of the SRFI process. *If* there is consensus on these
issues (reaching this consensus would somehow have to be part of the
process), they could either became errata (see above) or be simply
recordedfor inclusion in a future R6RS.
3) new features
Many of the items on David Rush's list fall into this category. The
features are, broadly, "compatible" with R5RS, i.e. they are *additions*
rather than changes. The SRFI process works well for these and if
consensus is reached on some of these new features they too should be
recorded/nominated for inclusion in a future R6RS.
So we need a new process to take care of 1), a new process to take care
of 2) and an extension of the SRFI process to take care of the second
part of 3) (the "record/nominate for inclusion in R6RS" bit).
Matthias
ste...@pcrm.win.tue.nl
<hu...@localhost.localdomain> wrote:
>What is your view, how does this related to the `dynamic
>environment'
>that is implicitly present in R*RS and that contains for example the
>current default output port, and in practical implementations also
>lots of other things such as exception handlers.
I'm not Matthias, but in my view, this "dynamic environment" is
best understood as additional data slots in a continuation.
That is, whenever a continuation is created, things like
te default output port, error handlers, the winding context,
and possibly user defined dynamic variables, are conceptually
saved in the continuation. Thus, whenever such a continuation
is invoked, all this is restored.
Note that the ability to create dynamic variables that are
saved in the continuation is sufficient to correctly implement
call/wc and dynamic-wind on top of a true call/cc.
In fact, in a perfect world I would like to see *only*
call/cc and dynamic variables in the standard. call/wc and
dynamic-wind could then be demoted to libraries.
>Now R*RS does not specify how the dynamic environment should actually
>respond to non-local exits. Namely, `with-input-from-file' and
>`with-output-to-file' which change the dynamic environment have
>unspecified behaviour w.r.t. such exits. I think it is common sense
>that usually dynamic environments should be restored at jumps to
>continuations. In the case of exception handlers this is especially
>clear.
Exactly, and this is what I would propose.
Stephan
David Rush
> On 16 May 2001 10:19:52 +0100, David Rush <ku...@bellsouth.net> wrote:
> >> I'd add:
> >> . Some way of deliberately defining non-hygenic macros
> >
> >This is why I mentioned brining back the R4RS low-level system. It
> >*was* non-hygienic, but it exposes enough syntactic information to
> >implement hygienic macros if you wish. It seems very much in line with
> >the Scheme philosophy...
> >
> Is there something terribly wrong with syntax-case macro system?
Not at all, and personally I rather like it, but the R4RS system has
already been reviewed and released once, so it would seem politically
more expedient to revert it. That's all.
david rush
--
Java and C++ make you think that the new ideas are like the old ones.
Java is the most distressing thing to hit computing since MS-DOS.
-- Alan Kay
Rob Warnock
+---------------| > division by zero...
|
| It's not pretty, but this should work (in standard R5RS Scheme):
Nope, sorry! As has been noted several times before, R5RS specifically
does *NOT* promise this will work!!
6.4 Control features
...
(dynamic-wind before thunk after)
...
The effect of using a captured continuation to enter or exit the
dynamic extent of a call to "before" or "after" is undefined.
Plus, there is no guarantee anywhere in R5RS that "signalling an error"
interacts in any way with dynamic-wind!! At most an implementation is
required to "detect and report" certain errors, but it's not required to
do this by calling a continuation captured with call/cc in the top-level
REPL (albeit that's one "obvious" implementation), and thus it's not
required to execute any "after" thunks in any active dynamic-winds.
This means that R5RS call/cc + dynamic-wind are inadequate to implement
a portable exception-handling system. (...unless you add non-standard
extensions, as MzScheme & others have done.)
Michael Sperber [Mr. Preprocessor]
David> jos...@myrealbox.com (Juho Östman) writes:
>> On 16 May 2001 10:19:52 +0100, David Rush <ku...@bellsouth.net> wrote:
>> >> I'd add:
>> >> . Some way of deliberately defining non-hygenic macros
>> >
>> >This is why I mentioned brining back the R4RS low-level system. It
>> >*was* non-hygienic, but it exposes enough syntactic information to
>> >implement hygienic macros if you wish. It seems very much in line with
>> >the Scheme philosophy...
>> >
>> Is there something terribly wrong with syntax-case macro system?
David> Not at all, and personally I rather like it, but the R4RS system has
David> already been reviewed and released once, so it would seem politically
David> more expedient to revert it. That's all.
But its authors hate it now. SYNTAX-CASE is the official successor,
more or less.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Matthias Blume
Should be the same thing. They ought to be restored by call/cc (and, of
course, call/wc) escapes. In fact, my VSCM implementation did this.
You get it for free if you view the "dynamic environment" as an extra
implicit argument to every function call.
> Now R*RS does not specify how the dynamic environment should actually
> respond to non-local exits. Namely, `with-input-from-file' and
> `with-output-to-file' which change the dynamic environment have
> unspecified behaviour w.r.t. such exits. I think it is common sense
> that usually dynamic environments should be restored at jumps to
> continuations. In the case of exception handlers this is especially
> clear.
I agree 100%. (And, btw, R*RS ought to document this very clearly.)
That's why one should not implement it that way.
> Therefore you would need to manage the dynamic environment manually
> when doing `context switches', because you couldn't rely on
> `dynamic-wind' restoring the correct dynamic environment.
Personally I don't want to rely on dynamic-wind for _anything_. My
call/wc was proposed because others insisted on having it. I have
very little use for it.
(Not to mention that the proposed implementation above can make
context switches arbitrarily slow if there are many exception handlers
between two contexts. The straightforward solution where call/cc takes
care of all these "dynamic" things in one fell swoop is constant-time
per context switch.)
> But after
> that a `thread' is no longer equivalent to a continuation, because a
> `thread' is now a continuation + dynamic environment, and the latter
> is not a part of the former.
It is -- if you adopt the "dynamic environment is an implicit argument" point
of view.
Matthias
Matthias Blume
>
> On Wed, 16 May 2001 21:24:26 GMT, Antti Huima
> <hu...@localhost.localdomain> wrote:
> >What is your view, how does this related to the `dynamic
> >environment'
> >that is implicitly present in R*RS and that contains for example the
> >current default output port, and in practical implementations also
> >lots of other things such as exception handlers.
>
> I'm not Matthias, but in my view, this "dynamic environment" is
> best understood as additional data slots in a continuation.
Hmm, if it's not you, then it must be me... :-)
> That is, whenever a continuation is created, things like
> te default output port, error handlers, the winding context,
> and possibly user defined dynamic variables, are conceptually
> saved in the continuation. Thus, whenever such a continuation
> is invoked, all this is restored.
As I have already explained in another reply in this same thread, this
is exactly my view.
> In fact, in a perfect world I would like to see *only*
> call/cc and dynamic variables in the standard. call/wc and
> dynamic-wind could then be demoted to libraries.
Hmm, I would not necessarily agree with this. Call/wc could (and should?)
be implemented using "winder-passing-style" (in a CPS-based compiler),
and that would mean that the compiler has--and will--handle it directly.
The library implementation on top of call/cc is a bit ugly because it
needs to
-- use global variables (yuck!)
-- redefine call/cc
Matthias
(One of the many)
Ronald Schröder
wrote:
>Is there something terribly wrong with syntax-case macro system?
It isn't as powerful as you may think. Take a look at
define-abbreviation in Quinnec's book!
David Rush
> Quoth David Rush:
> > Wow, my list hasn't been flamed yet!
> Okay, I'll oblige you! Sort of.
Thank you sir! May I have another!
> A mechanism for exploring extensions to the language akready exists:
> SRFI. Until at least one SRFI exists for each item on y'all's lists,
> there is no point to this call to revise the existing mutiply revised
> standard.
Somehow, I find it hard to imagine how to write a SRFI that would
address the issues w/dynamic-wind. ditto for user-defined types and
ways to catch errors signalled according to R5RS rules[1].
Is it apropriate to address this level of issue (signficant changes to
R5RS semantics) in a SRFI?
> So, if implementation M has a nonstandard feature F that you'd like to
> see standard, write it up in a SRFI.
The catch-22 here is that the best people to write it up are the
implementors. The withdrawals of SRFI-12 and SRFI-20 might indicate
that they are too busy to tend the SRFI garden.
> If no implementation has this feature, design and implement it
> yourself
This cuts to the heart of my problem with the current processes. My
wish list is *user* driven, not implementor-driven. Scheme culture is
heavily implementor-oriented. But now we have Shriram essentially
lobbying people to quit rolling their own and contribute to existing
impls. But things like fixing I/O or dynamic-wind[2] involve significant
changes to an implementation. So how does a mere mortal make his
needs/desires for improvements in the language known? Or get them
addressed?
> I suppose that one could make a case for R6RS fixing the two bugs
> identified in the spec, and sanctioning the SRFI process. Otherwise,
> however, the cry for R6RS is far premature.
I consider R6RS extremely unlikely to ever happen. Many factors of
Scheme culture weigh against it. I figure that if I start crying for
it now, it might actually happen sometime in the next 5 years.
Perhaps I am too pessimistic, but the fact there is no ongoing
discussion and the fact that every time the issue is raised that it
gets slapped down doesn't give me much hope.
david rush
[1] In fact, the withdrawal of SRFI-12 due to the authors lack of
participation (and the finalization of SRFI-17) may point to the
need for a system with a bit more inertia than SRFI in order to
make the good things happen.
[2] Or getting labelled as non-compliant ;) which doesn't help build a
user base necessary to evaluating the viability of changes.
david rush
--
In a tight spot, you trust your ship or your rifle to get you through,
so you refer to her affectionately and with respect. Your computer? It
would just as soon reboot YOU if it could. Nasty, unreliable,
ungrateful wretches, they are. -- Mike Jackmin (on sci.crypt)
Shriram Krishnamurthi
> This cuts to the heart of my problem with the current processes. My
> wish list is *user* driven, not implementor-driven. Scheme culture is
> heavily implementor-oriented. But now we have Shriram essentially
> lobbying people to quit rolling their own and contribute to existing
> impls.
... a position I continue to stand by.
> But things like fixing I/O or dynamic-wind[2] involve significant
> changes to an implementation. So how does a mere mortal make his
> needs/desires for improvements in the language known? Or get them
> addressed?
What's wrong with the SRFI process? (Confession: I haven't read most
of this thread, partly because I've been out of town.) An RFI,
request for implementation, can get needs/desires known. It of course
doesn't get them addressed, but "mere mortals" should not expect to
see their every need addressed -- the best way to ensure that is to
roll up their sleeves and hack on an existing implementation.
Shriram
Ben Goetter
> Thank you sir! May I have another!
"We now consecrate the bond of obedience. Assume the position."
> Is it apropriate to address this level of issue (signficant changes to
> R5RS semantics) in a SRFI?
Why not? It's a mechanism that we have today to debate, explore, and
experiment with implementation differences.
Think of it as a distributed and partitioned R(+1 n)RS meeting.
> Scheme culture is heavily implementor-oriented.
The culture of every computer language is heavily implementor-oriented.
In the SRFI process, we have an excellent way to get ideas into the
community of implementors at large.
Until concrete and tested proposals exist for each element on y'all's
lists, a call to standardize their solution is inappropriate. You can't
standardize until you have something on which to standardize!
> So how does a mere mortal make his
> needs/desires for improvements in the language known?
Establish a relationship with your favorite implementation.
I'm sure that you could write a fine all-dancing-all-singing I/O SRFI.
You could even do it without intimate access to the most-secret-parts of
an implementation: look at the work that Oleg has done with Gambit. Take
the Olin approach: exhaustively research, synthesize, publish - voila,
you're a hero. If the SRFI process or the prospect of flamage by les
grandes fromages daunts you, then publish your design here (To:
comp.lang.scheme Subject: Lambda, the ultimate Ponzi scheme). That'd at
least make it more likely that somebody else would write the SRFI.
In conclusion, I commend to your attention Will Clinger's final
contribution to rrrs-authors, closing a thread appropriately titled "R6RS
- What is the Point?":
http://www-swiss.ai.mit.edu/ftpdir/scheme-mail/HTML/rrrs-
1998/msg00149.html
Pretty much sums it up for me.
Ben
Jordan Johnson
>>Is there something terribly wrong with syntax-case macro system?
>
>It isn't as powerful as you may think. Take a look at
>define-abbreviation in Quinnec's book!
Would you (or anybody else) mind elaborating on this for those of us without
easy access to that book?
Thanks,
jmj
--
( jordan m johnson : jorjohns @ indiana.edu : (just some guy) )
( If I were a bug, I would want to be a true Renaissance bug. )
Riku Saikkonen
>Riku Saikkonen <r...@lloke.dna.fi> wrote:
>| ste...@pcrm.win.tue.nl () writes:
>| >* Way to catch failure of primitive functions, such as e.g.
>does *NOT* promise this will work!!
Oops... Yes, you're right, of course. I guess I didn't actually read
the R5RS definition of a dynamic extent until now... I think I
understood dynamic extent in terms of changing a stack pointer (or
more generally, moving around in a context graph, as described in the
book _Essentials of Programming Languages_), and I implicitly assumed
that errors would do the same thing as continuation invocation (and
thought that calling continuations from after thunks would be
specified to do something sane). Thanks for enlightening me. :)
Ronald Schröder
wrote:
>Ronald Schröder <rsch...@usa.net> wrote:
>>>Is there something terribly wrong with syntax-case macro system?
>>
>>It isn't as powerful as you may think. Take a look at
>>define-abbreviation in Quinnec's book!
>
>Would you (or anybody else) mind elaborating on this for those of us without
>easy access to that book?
>
I'm afraid I can't give you all the details here. But for starters,
there is an excerpt from the macro chapter of the book at
http://youpou.lip6.fr/queinnec/WWW/chap9.html.
If you are in any way interested in studying Scheme interpreters or
compilers you definitely should try to lay your hands on the book!
The book covers most currently known constructs from most currently
available Lisp dialects, interpretation, compilation, reflection,
macros, etc.
Erratum: the writer's name is Queinnec, not Quinnec.
David Rush
> > R5RS semantics) in a SRFI?
> Think of it as a distributed and partitioned R(+1 n)RS meeting.
The "distributed, partitioned" part, while instituted to break the
gridlock in rrrs-authors, has the problem of lacking momentum, which I
think was shown by the withdrawal of SRFIs 12 and 20 *and* the
approval of SRFI-13 through the heroic efforts of Olin Shivers.
> > Scheme culture is heavily implementor-oriented.
>
> The culture of every computer language is heavily implementor-oriented.
Perl? C? C++? Python? I don't think so.
> Until concrete and tested proposals exist for each element on y'all's
> lists, a call to standardize their solution is inappropriate. You can't
> standardize until you have something on which to standardize!
Fair enough. However, given the uncertainty of Deja's existence (now
back on line thanks to Google, but there's a lesson to be learned
here), there are discussions relevant to the standard taking place
here, in cls, which should be more formally preserved. While a
separate issue from the desirability of R6RS or SRFIs, it would be
nice to see it addressed through sschemers.org.
> > So how does a mere mortal make his
> > needs/desires for improvements in the language known?
>
> Establish a relationship with your favorite implementation.
>
> I'm sure that you could write a fine all-dancing-all-singing I/O SRFI.
> You could even do it without intimate access to the most-secret-parts of
> an implementation: look at the work that Oleg has done with Gambit. Take
> the Olin approach: exhaustively research, synthesize, publish - voila,
> you're a hero. If the SRFI process or the prospect of flamage by les
> grandes fromages daunts you, then publish your design here (To:
> comp.lang.scheme Subject: Lambda, the ultimate Ponzi scheme). That'd at
> least make it more likely that somebody else would write the SRFI.
My day job is C++, and I have gotten so bogged down with it that my
Scheme projects have been starved for cycles for the last four
months. Until I can get someone to pay me for the work, I am just not
going to be abvle to achieve the kind of things Olin accomplished in
Scsh (a tremendous work!) or that Oleg achieves for the US Gov. Yes,
I *am* whining, but I adopted VSCM partly to have an experimental
platform, and I haven't even had the time to grok the code.
Until I free up enough cycles to contribute materially, I am still
searching for ways to contribute to the improvement of the language.
> In conclusion, I commend to your attention Will Clinger's final
> contribution to rrrs-authors, closing a thread appropriately titled "R6RS
> - What is the Point?":
>
> http://www-swiss.ai.mit.edu/ftpdir/scheme-mail/HTML/rrrs-1998/msg00149.html
And now I see why SRFI-17 is considered a "success" for the
process. But something still needs to be done so that things like
SRFIs 12 & 20 don't die on the vine.
Clinger: And maybe the successor to the R5RS should be two documents:
Clinger:
Clinger: Revised^6 Report on the Algorithmic Language Scheme
Clinger: Revised^6 Report on the Traditional Library of Scheme
Clinger:
Clinger: where the second document contains the library syntax and library
Clinger: procedures of the R5RS.
Clinger:
Clinger: I'm not saying this process is ideal. I'm saying it's a way to make
Clinger: progress even if the authors can't reach unanimous agreement on what
Clinger: they want.
> Pretty much sums it up for me.
Me too.
david rush
--
And Visual Basic programmers should be paid minimum wage :)
-- Jeffrey Straszheim (on comp.lang.functional)
Jordan Johnson
>I'm afraid I can't give you all the details here. But for starters,
>there is an excerpt from the macro chapter of the book at
>http://youpou.lip6.fr/queinnec/WWW/chap9.html.
Thanks for the pointer. I'll see if I can turn up a copy of the book.