This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
scgmille@xxxxxxxxxxxxxxxxxx wrote:
> I'm not opposed to merging ! and !! in favor of the programmer
> checking purely-mutable-collection? except on the grounds that it
> increases the opportunity for error.
Yes, that is a reasonable concern. Regardless of your final decision, I
recommend that you either rename *-set! or make it a special case. It
cannot remain the way it is, however, because it's unimplementable in
some Schemes. For example, it would be impossible to use SRFI-44's
vector-set! in a PLT Scheme module.
>> One of the reasons I don't like pure-mutable as implemented is that
>> you've provided pure-mutable versions of the mutators but not the
>> accessors.
> Nothing prohibits them in a future SRFI. But its quite unusual for
> datastructures to require modification on access ....
I agree, which is why I haven't mentioned it so far.
> Dictionaries have conceptual issues precisely because they are a
> mapping where all other collection styles in the SRFI are just
> collections.
Agreed. I keep waffling between two different concepts for the
dictionary: is it a collection of mappings, or is it a bag with an
index?
Some possible solutions:
1. Pick one or the other and run with it.
2. Implement both: "indexed-bag" and "mapping."
3. Remove the dictionary and implement it in a later SRFI.
I'm fine with any of those. If you choose only one interface, I would
prefer the "collection of mappings."
> This, more than any type hierarchy issue, is the reason for dictionary
> weirdness. Can you elaborate on the issues that exist outside of
> dictionaries?
I think the other collections are OK. It's the "more than one kind of
value" aspect of dictionaries that causes the problem. Even that isn't
too bad if you treat them as collections of mappings. In that model, you
can almost always use the bag or sequence interface. I'm still trying to
work it out.
Regarding *-set! as a linear-update function:
>> And just to add insult to injury, he must change his code from impure
>> to pure-functional style, since SRFI-44 does not define vector-set!!.
> Not pure-functional at all, but linear-updating.
There's no difference from the programmer's point of view! Remember,
linear update procedures have the same restrictions as pure-functional
procedures (plus a few more). You must assume that side-effects occur
but you cannot rely on it.
I'm a bit surprised that vector wasn't defined as pure-mutable.
>> These silent changes and similar identifiers will [increase the
>> likelihood of errors and] cause problems in code reviews.
> This is more an issue for programmers than the specification of the
> SRFI.
I can't disagree more strongly. If the specification makes errors likely
and reviews difficult, that's a problem with the spec, not the
programmers. This is such an important issue that language standards
committees include it in their charters! (See C++.)
I didn't analyze the procedures closely the first time around -- I found
a few issues before I ever got that far -- but when I did I noticed
several inconsistencies and error-prone naming conventions. Examples:
vector-set! incompatible with R5RS
mutable vs immutable (seem like opposites, but they're not)
string= vs string=? (names too similar, different semantics)
*-all vs *-any (names similar and counterintuitive)
> I can't speak for everyone here, but I don't think the flaws are as
> grand as you think.
Perhaps not. But I do see a few major issues:
1. Quiet incompatibility with R5RS.
2. Error-prone naming conventions.
3. Problems with the dictionary interface.
If you can resolve all of them and finalize the SRFI, that's great.
> The SRFI is quite usable in its current form, programmer confusion
> notwithstanding.
"Quite usable" and "programmer confusion notwithstanding" don't belong
in the same sentence. Seriously.
> The few exceptions are fixable, and I intend to fix them.
> I welcome your input.
Great!
--
Bradd W. Szonye
http://www.szonye.com/bradd