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.
Per Bothner <per@xxxxxxxxxxx> writes: > 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. 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. > > NO, IT IS NOT! YES, IT IS! :) > Lars Thomas Hansen's sample implementation is basically all it > proposes. See: > http://srfi.schemers.org/srfi-17/mail-archive/msg00014.html 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, What? > 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 merit. david rush -- And Visual Basic programmers should be paid minimum wage :) -- Jeffrey Straszheim (on comp.lang.functional)