Home » forums » LtU Forum

Default, implicit, inherited

An important question in programming languages seems to be how to optimize the expression of common cases or how to allow writing programs in you-know-what-I-mean style -- some tools for that are default or implicit parameters, implicit conversions, inheritance. They all can be explained in terms of some kind of merge operation that takes some base information and combines that with user-provided information. All these features make languages more practical and more complex.

Are there any papers or projects that specifically explore defaults, implicits and inheritance as related topics?

By Aivar Annamaa at 2013-11-30 09:21 | LtU Forum | previous forum topic | next forum topic | other blogs | 4310 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The Implicit Calculus, 2012, arxiv

The Implicit Calculus
by Bruno C. d. S. Oliveira, Tom Schrijvers, Wontae Choi, Wonchan Lee, Kwangkeun Yi
2012

Generic programming (GP) is an increasingly important trend in programming languages. Well-known GP mechanisms, such as type classes and the C++0x concepts proposal, usually combine two features: 1) a special type of interfaces; and 2) implicit instantiation of implementations of those interfaces.
Scala implicits are a GP language mechanism, inspired by type classes, that break with the tradition of coupling implicit instantiation with a special type of interface. Instead, implicits provide only implicit instantiation, which is generalized to work for any types. This turns out to be quite powerful and useful to address many limitations that show up in other GP mechanisms.
This paper synthesizes the key ideas of implicits formally in a minimal and general core calculus called the implicit calculus, and it shows how to build source languages supporting implicit instantiation on top of it. A novelty of the calculus is its support for partial resolution and higher-order rules (a feature that has been proposed before, but was never formalized or implemented). Ultimately, the implicit calculus provides a formal model of implicits, which can be used by language designers to study and inform implementations of similar mechanisms in their own languages.

By gasche at Sat, 2013-11-30 14:16 | login or register to post comments

Defaults considered harmful ;-)

Long ago I wished I could design a language with no defaults whatsoever, on the grounds that defaults are an unbounded source of error; the trouble is that one wants to be able to see everything one has to know to understand a piece of source code, and defaults are all about making things not be visible — potentially making unbounded masses of stuff not be visible. The idea fell apart when looked at closely, of course, because without defaults one is more likely to repeat things over and over, with each repition another chance to get them wrong and another place they're hardcoded in making them more difficult to change. But I still wish for some alternative way to the benefits usually associated with defaults, so that defaults could be banished once and for all.

By John Shutt at Sat, 2013-11-30 14:34 | login or register to post comments

…without defaults one is

…without defaults one is more likely to repeat things over and over…

It’s less of a problem when you have an easy way to factor out the application of a default. In Haskell, for instance, you often see both fullyGeneralFoo and theUsualFoo where the latter is defined as fullyGeneralFoo someDefault. Creating definitions is cheap (this = that and an optional signature) and they can be scoped (with where or let–in). Monads with “defaulty” semantics such as Maybe and Either are also pertinent.

By Jon Purdy at Sun, 2013-12-01 10:03 | login or register to post comments

Re: Defaults considered harmful ;-)

I share the feeling. I expect any default to be disappointing. If someone builds a program without finding a specific choice they like, they probably won't be thrilled with the default choice either.

I think implicits are a different story though. To adapt the Python credo: It's nice to have the code write itself, as long as there's one (and preferably only one) obvious way to do it.

With a default, there's more than one reasonable choice. The choice of default is made by a developer (not a consistent algorithm), so even experienced outsiders won't be sure what to expect until they look it up.

[...] the trouble is that one wants to be able to see everything one has to know to understand a piece of source code, and defaults are all about making things not be visible — potentially making unbounded masses of stuff not be visible.

Well, they make more things visible, too. If you write less code overall, you can cram more of your program on one screen.

By Ross Angle at Sun, 2013-12-01 10:14 | login or register to post comments

Implicit Configurations, Soft Constraints

Oleg Kiselyov wrote about Implicit Configurations a while back.

In constraint programming, defaults are often represented as soft or low-weight constraints. Related: soft constraint tutorial, dyna.

There are 'default logics', too. But these have awful reasoning properties. Don't use them.

Many years ago, I wrote a bit about policy injection - which is related to constraint models but separates the weighting heuristic from the code. The benefit is the ability to explore or configure different solutions by tweaking one's preference function. I still use variations of this technique.

By dmbarbour at Sat, 2013-11-30 16:46 | login or register to post comments