I've used such approaches. One configuration I've found useful: * each module provides a set of types * each module requires a set of types * a plugin provides a set of modules * within an application, each type may be provided at most once * additional information - soft constraints, preferences - can be provided * a special set of types declare concurrent, toplevel runtime behaviors
The linker then serves as a constraint solver operating on a set of modules (provided by a set of plugins). The hard constraint that each type is provided at most once helps simplify the constraint efforts. Soft constraints can support policy and preference based selection between different implementations, e.g. for Qt vs. Wx for a UI library. I'm able to leverage Haskell's type inference such that many of the requirements and provided interface may be inferred, which greatly lowers the burden on developers. By use of plugins, I'm able to model live programming and ad-hoc application overrides within this scheme. It's a powerful approach - better than of import-by-name, and still part of my sirea-plugins project design. But, as I mentioned earlier, I'm disappointed by the inconsistency-of-thought, of requiring developers to think in terms of linkers-as-constraint-solvers for an application of another paradigm. Staged computation operating within a uniform toplevel paradigm, OTOH, still enables modeling of constraint solvers at link-time (especially if stateless stable models [1][2] are provided as link-time resources) - but leaves such decisions to the application developers in a more ad-hoc fashion. Regards, Dave [1] http://awelonblue.wordpress.com/2012/09/07/stateless-stable-arts-for-game-development/ [2] http://awelonblue.wordpress.com/2012/03/14/stability-without-state/ On Sat, Apr 20, 2013 at 7:32 AM, John Nilsson <j...@milsson.nu> wrote: > One approach I've been thinking about is to invert the "information > hiding" principle. > > The problem with information hiding is that the interface and properties > exposed by a module is determined by the module: "I am a..." And some line > is drawn between which properties are implementation details, and which are > the contract. > > So I was thinking, what if the roles were swapped. What if modules could > not declare a public contract but instead just had to conform to any type, > interface or property that a client depending on it would care to declare > as a requirement. In effect changing the module description into a > collection of "You are a..." statements. Kind of similar to how a > structural type allow any module conforming to the interface without the > module having to implement a particular nominal type. > > For one, declaring a contract for a dependency is rather easy as it is > based on local reasoning: "What do I do, what do I need?" as compared to > "What do I do, what do others need?" > > Another benefit would be that there is no arbitrary reduction of the > modules full capabilities. For example a Java List only implementing > Iterable couldn't be used by clients requiring an ordered and finite > sequence. > > I would expect this to encourage module writers to declare the smallest > set of properties possible to depend on so that there would be more focus > on "information shielding", what information to expose one self to, rather > than what information not to expose to others. > > > The problem with this approach is that the proof of conformance can't come > from the module, and it's hardly productive to require each client to > provide one. I guess in some sense this is partly solved by a mechanism > such as type classes as done in Scala or Haskell. One problem with this > scheme though is that they do this by means of a static dispatch, making it > impossible to specialize implementations by runtime polymorphism. While I > haven't played with it, I do believe that Clojure has solved it while > preserving runtime polymorphism. > > > BR, > John > > > On Thu, Apr 18, 2013 at 3:13 AM, David Barbour <dmbarb...@gmail.com>wrote: > >> Sounds like you want stone soup >> programming<http://awelonblue.wordpress.com/2012/09/12/stone-soup-programming/>. >> :D >> >> In retrospect, I've been disappointed with most techniques that involve >> providing "information about module capabilities" to some external >> "configurator" (e.g. linkers as constraint solvers). Developers are asked >> to grok at least two very different programming models. Hand annotations or >> hints become common practice because many properties cannot be inferred. >> The resulting system isn't elegantly metacircular, i.e. you need that >> 'configurator' in the loop and the metada with the inputs. >> >> An alternative I've been thinking about recently is to shift the link >> logic to the modules themselves. Instead of being passive bearers of >> information that some external linker glues together, the modules become >> active agents in a link environment that collaboratively construct the >> runtime behavior (which may afterwards be extracted). Developers would have >> some freedom to abstract and separate problem-specific link logic >> (including decision-making) rather than having a one-size-fits-all solution. >> >> Re: In my mind "powerful languages" thus means 98% requirements >> >> To me, "power" means something much more graduated: that I can get as >> much power as I need, that I can do so late in development without >> rewriting everything, that my language will grow with me and my projects. >> >> >> On Wed, Apr 17, 2013 at 2:04 PM, John Nilsson <j...@milsson.nu> wrote: >> >>> Maybe not. If there is enough information about different modules' >>> capabilities, suitability for solving various problems and requirements, >>> such that the required "glue" can be generated or configured automatically >>> at run time. Then what is left is the input to such a generator or >>> configurator. At some level of abstraction the input should transition from >>> being glue and better be described as design. >>> Design could be seen as kind of a gray area if thought of mainly as >>> picking what to glue together as it still involves a significant amount of >>> gluing ;) >>> But even design should be possible to formalize enough to minimize the >>> amount of actual design decisions required to encode in the source and what >>> decisions to leave to algorithms though. So what's left is to encode the >>> requirements as input to the designer. >>> In my mind "powerful languages" thus means 98% requirements, 2% design >>> and 0% glue. >>> BR >>> John >>> Den 17 apr 2013 05:04 skrev "Miles Fidelman" <mfidel...@meetinghouse.net >>> >: >>> >>> So let's ask the obvious question, if we have powerful languages, >>>> and/or powerful libraries, is not an application comprised primarily of >>>> glue code that ties all the "piece parts" together in an >>>> application-specific way? >>>> >>>> David Barbour wrote: >>>> >>>>> >>>>> On Tue, Apr 16, 2013 at 2:25 PM, Steve Wart <st...@wart.ca <mailto: >>>>> st...@wart.ca>> wrote: >>>>> >>>>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >>>>> > In real systems, 90% of code (conservatively) is glue code. >>>>> >>>>> What is the origin of this claim? >>>>> >>>>> >>>>> I claimed it from observation and experience. But I'm sure there are >>>>> other people who have claimed it, too. Do you doubt its veracity? >>>>> >>>>> >>>>> >>>>> On Mon, Apr 15, 2013 at 12:15 PM, David Barbour >>>>> <dmbarb...@gmail.com <mailto:dmbarb...@gmail.com>> wrote: >>>>> >>>>> >>>>> On Mon, Apr 15, 2013 at 11:57 AM, David Barbour >>>>> <dmbarb...@gmail.com <mailto:dmbarb...@gmail.com>> wrote: >>>>> >>>>> >>>>> On Mon, Apr 15, 2013 at 10:40 AM, Loup Vaillant-David >>>>> <l...@loup-vaillant.fr <mailto:l...@loup-vaillant.fr>> wrote: >>>>> >>>>> On Sun, Apr 14, 2013 at 04:17:48PM -0700, David >>>>> Barbour wrote: >>>>> > On Sun, Apr 14, 2013 at 1:44 PM, Gath-Gealaich >>>>> > In real systems, 90% of code (conservatively) is >>>>> glue code. >>>>> >>>>> Does this *have* to be the case? Real systems also >>>>> use C++ (or >>>>> Java). Better languages may require less glue, (even >>>>> if they require >>>>> just as much core logic). >>>>> >>>>> >>>>> Yes. >>>>> >>>>> The prevalence of glue code is a natural consequence of >>>>> combinatorial effects. E.g. there are many ways to >>>>> partition and summarize properties into data-structures. >>>>> Unless we uniformly make the same decisions - and we won't >>>>> (due to context-dependent variations in convenience or >>>>> performance) - then we will eventually have many >>>>> heterogeneous data models. Similarly can be said of event >>>>> models. >>>>> >>>>> We can't avoid this problem. At best, we can delay it a >>>>> little. >>>>> >>>>> >>>>> I should clarify: a potential answer to the glue-code issue is >>>>> to *infer* much more of it, i.e. auto-wiring, constraint >>>>> models, searches. We could automatically build pipelines that >>>>> convert one type to another, given smaller steps (though this >>>>> does risk aggregate lossiness due to intermediate summaries or >>>>> subtle incompatibilities). Machine-learning could be >>>>> leveraged to find correspondences between structures, perhaps >>>>> aiding humans. 90% or more of code will be glue-code, but it >>>>> doesn't all need to be hand-written. I am certainly pursuing >>>>> such techniques in my current language development. >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> fonc mailing list >>>>> fonc@vpri.org <mailto:fonc@vpri.org> >>>>> >>>>> http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> >>>>> >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> fonc mailing list >>>>> fonc@vpri.org <mailto:fonc@vpri.org> >>>>> >>>>> http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> >>>>> >>>>> >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> fonc mailing list >>>>> fonc@vpri.org >>>>> http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> >>>>> >>>> >>>> >>>> -- >>>> In theory, there is no difference between theory and practice. >>>> In practice, there is. .... Yogi Berra >>>> >>>> ______________________________**_________________ >>>> fonc mailing list >>>> fonc@vpri.org >>>> http://vpri.org/mailman/**listinfo/fonc<http://vpri.org/mailman/listinfo/fonc> >>>> >>> >>> _______________________________________________ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >>> >>> >> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
