Email list hosting service & mailing list manager

Miscellaneous comments John Cowan (16 Aug 2015 01:05 UTC)
Re: Miscellaneous comments taylanbayirli@xxxxxx (16 Aug 2015 13:21 UTC)
Re: Miscellaneous comments John Cowan (16 Aug 2015 14:04 UTC)
Re: Miscellaneous comments taylanbayirli@xxxxxx (16 Aug 2015 16:29 UTC)
Re: Miscellaneous comments taylanbayirli@xxxxxx (16 Aug 2015 19:50 UTC)
Re: Miscellaneous comments taylanbayirli@xxxxxx (17 Aug 2015 08:21 UTC)

Re: Miscellaneous comments John Cowan 16 Aug 2015 14:04 UTC

Taylan Ulrich Bayırlı/Kammer scripsit:

> I don't think dropping the ! is a good idea, since it dispatches to a
> variety of *-set! procedures and is clearly mutative.

Mmmm, point.

> While there's kind of a conceptual inconsistency between the two- and
> three-argument uses of set!, I think this is unlikely to lead to
> confusion in practice.

Probably not, but it still bothers me, and I still think a different
name would be better, though I can't think of one offhand.

> The SRFI doesn't really use any form of inspection into record types.
> It just piggybacks `define-record-type' to take note of the newly
> defined data type, and create tables mapping symbols to the data type's
> accessors and modifiers.

But that's a choice made by the sample implementation.  It should be
possible to support this SRFI on top of record inspection, and the whole
point of opaque records is that they are uninspectable, so they should
be exempt from the requirement to support this SRFI.  For example,
ports might be implemented as opaque records, but users shouldn't be
able to use this SRFI to see into the implementation details of ports.

> I would rather reserve that feature for types which may have fields that
> "exist" but hold no value.  (In this sense, hashtables have infinitely
> many fields; you get the idea.)  It's natural for those types, whereas
> using (ref #(0 1 2) 3 'default) as a shorthand for a bounds-check and
> fallback value is a rather obscure abbreviation, and for record types
> it's even more strange.  Those are more likely to be programmer errors
> than anything else, I imagine.

Fair enough.

> For now, I don't see it as a show-stopper to support 3-argument set!,
> however with Mark Weaver's input on IRC I began pondering on making the
> whole design closer to (or at least incorporating the one of) Gauche's
> ref* AKA ~ operator.  That, plus I just realized I could support pairs
> distinctly from lists by testing the field argument with `procedure?'
> (meaning it can't be a list index, and is likely to be car/cdr), so your
> example would more idiomatically become
>
> (set! (~ foo car bar) quux),

I like that.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
But that, he realized, was a foolish thought; as no one knew better than
he that the Wall had no other side.
        --Arthur C. Clarke, "The Wall of Darkness"