This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
Hi Taylor, thanks your for comments! Taylor Campbell <campbell@xxxxxxxxxx> writes: > [...] although the explanation of constructor protocols > is a bit confusing. I agree. Given that it's really not such a complicated thing, I'm somewhat miffed that I haven't been able to do better, even though I certainly tried. Suggestions for improvements would be *very* welcome. > However, that having been said, I still think that this is a great lot > of baggage to impose on Scheme, half the length of R5RS to begin with, > and I'd be very much more comfortable with clearer partitions between > components and what is optional vs required, Yes. The main reason is that, at the time of writing, we lacked the linguistic means to say how it would be split up. I expect we wíll though by the time we put out R6RS (see SRFI 83), so I promise I'll do my best there will be clear partitions. > particularly with respect to reflection and opacity, which is still, > if you'll excuse the pun, not very clear, particularly about exactly > what opacity protects abstractions against. Without opacity and with reflection, a client who gets its hands on a record can get at its fields, thus breaking the abstractions provided by the maker of that record. I agree opacity is a loaded word in this context (and we continue to have discussions about it over in R6RSland), but the SRFI does try to spell out what the specific rationale is. > It would also be comforting to have assurance that SRFI 9 should > still be supported, even if in a separate module, which doesn't > appear to be stated there. I see no reason why it wouldn't be, the same as always. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla