Since `return-from', used in conjunction with a `block' seems like nothing
more than the lexical version of `throw', why does `return-from' take an
&optional result-form, whereas `throw' requires its second argument
(result-form)? It's a small detail, but I like to understand inconsistencies
in the language, it this is one. I think the 2nd arg in `throw' should be
optional.
dave
David Bakhash <·····@acs.bu.edu> writes:
> Since `return-from', used in conjunction with a `block' seems like nothing
> more than the lexical version of `throw', why does `return-from' take an
> &optional result-form, whereas `throw' requires its second argument
> (result-form)? It's a small detail, but I like to understand inconsistencies
> in the language, it this is one. I think the 2nd arg in `throw' should be
> optional.
History. It's a reasonable request that THROW should do likewise.
But you should understand that THROW and BLOCK were not really originally
understood to be so related and have each followed separate migration paths
over a long period of time in order to get, as they are now, close enough
to similar that you can see this.
It used to be that there was also a set of functions called ERRSET and ERR
which were not substantially more than CATCH and THROW without ERR passing
a value back. It took a while to realize that ERR and THROW were really
redundant and to get them out. We got rid of ERR, which was good because
it was kind of a mess, but we go rid of the 0-arg version of THROW in the
process, which was probably bad.
All other things being equal, I'd advocate fixing this. But the expense
of changing the standard is so high that likely the changes you'll see in
the future will ber layerings, not corrections. Still, we'll see.
That's just a guess on my part, not anyone's policy statement.
* Kent M Pitman <······@world.std.com>
| All other things being equal, I'd advocate fixing this. But the expense
| of changing the standard is so high that likely the changes you'll see in
| the future will ber layerings, not corrections. Still, we'll see.
| That's just a guess on my part, not anyone's policy statement.
hm? how would making an argument optional be expensive? it seems like
it's a trivial thing to do, while, say, adding a required argument would
be expensive. perhaps I'm misled by the work required to make it work
that way in a conforming Common Lisp system:
(shadowing-inport 'cl:throw)
(defmacro throw (tag-form &optional result-form)
`(cl:throw ,tag-form ,result-form))
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
I agree that this is not a big change, because it won't (AFAIK) break old
code, and it won't change the behavior of Lisp, yet it will make it more
consistent. Anyway, if one wanted to "request" such a change, who would
he/she contact? Is there a place that you're supposed to write to people
suggesting these changes, etc?
dave
David Bakhash <·····@acs.bu.edu> writes:
> I agree that this is not a big change, because it won't (AFAIK) break old
> code, and it won't change the behavior of Lisp, yet it will make it more
> consistent. Anyway, if one wanted to "request" such a change, who would
> he/she contact? Is there a place that you're supposed to write to people
> suggesting these changes, etc?
You can pay your $600 in dues and become part of the current NCITS/J13
standardization process for the next revision of the ANSI Common Lisp
standard, if the deadline for membership has not passed yet. You can
contact ···@franz.com for details about joining and find out if it
isn't too late, and you can subscribe to ·····@ai.sri.com, though it
has been pretty quiet as discussion goes on now without public view by
paying members only.
Christopher
* Christopher R Barry wrote:
> You can pay your $600 in dues and become part of the current NCITS/J13
> standardization process for the next revision of the ANSI Common Lisp
> standard, if the deadline for membership has not passed yet. You can
> contact ···@franz.com for details about joining and find out if it
> isn't too late, and you can subscribe to ·····@ai.sri.com, though it
> has been pretty quiet as discussion goes on now without public view by
> paying members only.
That last bit isn't correct: there is no discussion currently going on
that is available to J13 people only (or if there is it is
accidentally only reaching a subset!). There was an (informal)
proposal that something like that should happen but nothing was
actually done.
Another correction: there is no deadline for membership, although it
runs by calendar year so if you join now you are paying $600 for 6
months.
However a large proportion of the J13 members probably read this
newsgroup, so I should think that good ideas that appear here are at
least being noticed.
--tim