Lambda the Ultimate

It is not generally proper to post call-for-papers on LtU. Exceptions have been made, for broad workshops likely to appeal to many LtU readers. I hope the 2014 ML Family workshop also qualifies.

The ML Family workshop intends to attract the entire family of ML languages, whether related by blood to the original ML or not. Our slogan is ``Higher-order, Typed, Inferred, Strict''. Designers and users of the languages fitting the description have many issues in common, from data representation and garbage collection to fancy type system features. As an example, some form of type classes or implicits has been tried or been looked into in several languages of the broad ML family. We hope the ML Family workshop is a good forum to discuss these issues.

Also new this year is a category of submissions -- informed opinions -- to complement research presentation, experience reports and demos. We specifically invite arguments about language features, be they types, garbage collection, implicits or something else -- but the arguments must good and justified. Significant personal experience does count as justification, as do empirical studies or formal proofs. We would be delighted if language implementors or long-time serious users could tell, with examples from their long experience, what has worked out and what has not in their language.

The deadline for submitting an abstract of the presentation, up to 2 PDF pages, is in a month. Please consider submitting and attending!

With respect to detected contradictions in large information system, according to [Russo, Nuseibeh, and Easterbrook 2000]:

"The choice of an inconsistency handling strategy depends on the context and the impact it has on other aspects of the development process. Resolving the inconsistency may be as simple as adding or deleting information from a software description. However, it often relies on resolving fundamental conflicts, or taking important design decisions. In such cases, immediate resolution is not the best option, and a number of choices are available:

Ignore - it is sometimes the case that the effort of fixing
an inconsistency is too great relative to the (low) risk that the
inconsistency will have any adverse consequences. In such cases,
developers may choose to ignore the existence of the inconsistency in
their descriptions. Good practice dictates that such decisions should be
revisited as a project progresses or as a system evolves.

Defer - this may provide developers with more time to elicit
further information to facilitate resolution or to render the
inconsistency unimportant. In such cases, it is important to flag the
parts of the descriptions that are affected, as development will continue
while the inconsistency is tolerated.

Circumvent - in some cases, what appears to be an
inconsistency according to the consistency rules is not regarded as such
by the software developers. This may be because the rule is wrong, or
because the inconsistency represents an exception to the rule that had
not been captured. In these cases, the inconsistency can be circumvented
by modifying the rule, or by disabling it for a specific context.

Ameliorate - it may be more cost-effective to ‘improve’ a
description containing inconsistencies without necessarily resolving them
all. This may include adding information to the description that
alleviates some adverse effects of an inconsistency and/or resolves other
inconsistencies as a side effect. In such cases, amelioration can be a
useful inconsistency handling strategy in that it moves the development
process in a ‘desirable’ direction in which inconsistencies and their
adverse impact are reduced.