[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: where is srfi-17 going?
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
NO, IT IS NOT!
Lars Thomas Hansen's sample implementation is basically all it
[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
> 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.
(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.