Email list hosting service & mailing list manager

Re: where is srfi-17 going? David Rush (05 Feb 2000 00:29 UTC)
Re: where is srfi-17 going? Per Bothner (05 Feb 2000 01:05 UTC)
Re: where is srfi-17 going? David Rush (05 Feb 2000 01:48 UTC)
Re: where is srfi-17 going? Lars Thomas Hansen (05 Feb 2000 02:57 UTC)
Re: where is srfi-17 going? David Rush (05 Feb 2000 02:05 UTC)
Re: where is srfi-17 going? sperber@xxxxxx (18 Feb 2000 14:45 UTC)
Re: where is srfi-17 going? sperber@xxxxxx (07 Feb 2000 08:56 UTC)

Re: where is srfi-17 going? David Rush 05 Feb 2000 01:46 UTC

Per Bothner <> writes:
> David Rush <> writes:
> > DB> I'm much more in favor of reifying locations ...
> > This is a very interesting idea, and as Per has said that it was his
> > original intent
> To repeat once more:  srfi-17 is *not* about reifying locations, and
> it was never my intent to propose that.  What I did was show how
> srfi-17 is *compatible* with reifying locations and works well
> with a Scheme dialect that has reified locations - but does not require it.

No, SRFI-17 is not directly about reifying locations, but it strongly
implies that reification of locations is a Good Thing (tm). I
apologize for my inaccuracy here. However, I think, after reading the
entire message archive, that this is at the *heart* of people's issues
with this proposal, although I have formulated it differently. Shriram,
Mike, And Matthias have all brought up the fundamental difference
between SET! and SET-CAR!, and you have said that they're wrong
because SET! is simply the mutation of an implicit data
structure, the environment, aka the store, etc. Taking that approach
implies that bound names *are* equivalent to first-class `locations'
(or refs or whatever you want to call them).

> > However, Per's analogy with the C `&' operator makes very clear how
> > big this issue is. SRFI-17 is tinkering with fundamental language
> > semantics.

YES, IT IS! :)

> Lars Thomas Hansen's sample implementation is basically all it
> proposes.  See:

I have already looked at it, and it's ugly. It in fact implements what
I found most objectionable about SRFI-17 in the first place. With
SRFI-17 (as it stands) we suddenly get a whole new heap of stuff
magically bound to language *values* and not names. (Yes, there are
flaws in that statement for the pedantic of heart to exploit). This
feels much more like MACLISP or elisp than Scheme. (defun puts a
lambda value on the 'expr property of the atom...)

> [Editors: I propose this sample implementation be merged into the
> draft.  I can make a diff, but I trust you can Do The Right Thing
> without it.]

This certainly should be done.

> > accept opaque types as a fundamental fact of life. In my *engineering*
> > experience, I have found opaque types to be a universally good
> > idea. This is so much the case that even when I am programming in
> > straight C, I still use abstract setters in preference to direct
> > mutation of structs; it is *much* easier to ensure data structure
> > integrity with opaque types.
> On the other hand, with Kawa's define-alias compiled with generalized
> set! you can ensure data structure integrity with opaque types,
> while still using the convenient and natural variable/set! syntax.

But we don't have Kawa's DEFINE-ALIAS in this SRFI, now do we? As it
stands, SRFI-17 opens a wide door for bad data-structure manipulation
techniques. On that basis, I still don't like it.

> > Having reified locations
> > (and thus the ability to access hardware-level addresses)
> The latter is completely independent to the latter,


> except that
> first-class locations would allow some prettier syntax for
> accessing hardware-level addresses, if you had some primitives
> for getting/setting the addresses.

Yep. I only brought that up as part of my motivation for not rejecting
this proposal out of hand. As it stands, I *still* don't really like
it. In it's implication of first-class locations, I think it has some

david rush
And Visual Basic programmers should be paid minimum wage :)
	-- Jeffrey Straszheim (on comp.lang.functional)