On Thu, Jul 4, 2019 at 1:42 PM Phil Hofer <firstname.lastname@example.org> wrote:
But the difference between GCC and this SRFI is that there is
a pretty clear definition of what behavior is _expected_ to be
Gcc was a bad choice, because of the ambiguity about the behavior
of the program itself vs. what it produces. Replace it with ls or cat
or the kernel. My trust in these programs is purely social.
Conversely, this SRFI, by your own admission, has "no guarantees."
Consequently, an implementation that is no safer than 'eval' is
today is perfectly conformant.
No, because this is a proposal for specific libraries. The claim is that if you
pass one of them to the `eval` procedure of a non-extreme
implementation of R7RS-small Scheme, you are better off than if you use
the interaction-environment, (scheme base), or the emulated R5RS
environment. I stand by that claim despite all doom-crying.
I concede that define-syntax and friends need to come out, and they will
in the next draft. I'm removing syntax-rules as well, though it is probably safe.
Safety features are supposed to provide guarantees.
This one does not, which is why I don't use "safe(ty)" or "guarantee".
But the relevant criterion of a SRFI is utility, not safety.
In any case, I appreciate the scrutiny, and I would ask everyone to carry on
John Cowan http://vrici.lojban.org/~cowan email@example.com
You annoy me, Rattray! You disgust me! You irritate me unspeakably!
Thank Heaven, I am a man of equable temper, or I should scarcely be able
to contain myself before your mocking visage. --Stalky imitating Macrea