This page is part of the web mail archives of SRFI 17 from before July 7th, 2015. The new archives for SRFI 17 contain all messages, not just those from before July 7th, 2015.
David Rush <kumo@xxxxxxxxxxxxx> 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
per@xxxxxxxxxxx http://www.bothner.com/~per/