David Rush <xxxxxx@bellsouth.net> 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.

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

NO, IT IS NOT!

Lars Thomas Hansen's sample implementation is basically all it
proposes.  See:
http://srfi.schemers.org/srfi-17/mail-archive/msg00014.html

[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.]

> How does adding *explicit* pointer
> types and the accompanying pointer-aliasing problems interact with the
> compiled Schemes? Or how they interact with the garbage collector?

In my suggestion for how one might add explicit (reified) locations
(again: not part of srfi-17), I did not propose adding "*explicit* pointer
types", at least not anything that would add new pointer-aliasing
or garbage collector problems.

Perhaps I should write up a separate srfi for how Kawa handles
locations to avoid these misunderstandings ...

> I am having a bit of a hard time coming up with a way to express my
> misgivings about this construct. I think it boils down to the fact
> that Scheme *already* has this functionality, *if* you are willing to
> 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.

For example:
        (define (get-XXX) ...)
        (define (set-XXX! new-value) ...)

If you do:
        (set! (setter get-XXX) set-XXX!)
        (define-alias XXX (get-XXX)) ;; Not in srfi-17

you can now do:
        (set! XXX (+ XXX 1))
and it has exactly the effect as:
        (set-XXX! (+ (get-XXX) 1))
but a much more readable syntax.

> 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.
--
	--Per Bothner
xxxxxx@bothner.com   http://www.bothner.com/~per/