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.
Andrew Wilcox <awilcox@xxxxxxxxxxxxxxxxx> writes: >> Should the operations for access and mutation be augmented >> by functional update? > > I think functional programming will become increasing important (see e.g. > A Fundamental Turn Toward Concurrency in Software > http://www.gotw.ca/publications/concurrency-ddj.htm). > We (the SRFI authors, that is) have come down on the side that we'd like to have functional update, but that there are currently too many design issues to put them in just yet. We're confident they can be eventually added to the current mechanism cleanly, however. (An internal interim revision actually had them, but we took them out again.) The next SRFI revision (out soon) will have a more elaborate issue writeup on the subject. In a nutshell: - Functional update has interaction with record extension, especially when used in inheritance-like settings. Specifically, if a child type can add a functional updater, that means that the parent's fields can be copied without the parent knowing. So we'd probably need a mechanism to control the ability of extension types to copy records. - If new records are initialized via an INIT! clause, shouldn't functional updaters also feature an initializer? Should it be the same? (Incompatible with the current spec.) ... >> If any of these are added, what should the syntax in the syntactic >> layers look like? > > I don't understand enough about the capabilities of macros to know > what is possible. For example, could we have a syntax such as: > > (update <record name> record-expr (<field name> expr) ...) This would be a highly uncontrolled form of functional update. If anything, the functional updaters should be specified as part of the DEFINE-TYPE form, the same way accessors and mutators are. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla