Missed one: Semi-unification in one-way constraint solvers. It’s been about 20 years since I last looked deeply into these, so maybe another approach is being used. I might be confusing it with something else, now that I’m doubting my memory…
But yes, conditional code seems to be some of the heaviest boilerplate. Avail still has a few minor issues related to extending types and methods in a modular way, but it’s by far the best I’ve seen (if I do say so myself). As we discussed in our video chat a couple of weeks ago, the remaining problems are related to abstract methods and their relationship to “abstract types”, whatever those are in Avail, ensuring method definitions in one module cannot collide with method definitions in another module (by construction would be nice), and some detail about covering all subcases. Oh, and determining ambiguous lookups statically. > On Feb 26, 2015, at 5:36 PM, Robbert van Dalen <[email protected]> wrote: > > So here is the Expression Problem in a nutshell: > > 1) In any strongly typed OO language (say Java) we can easily extend classes, > but we cannot easily add methods to classes in a modular fashion. > 2) Conversely, in any strongly typed Functional language (say Haskell) we can > easily add new (pattern matching) functions, but we cannot easily extend data > types in a modular fashion. > > There are ways to go around these problems, but these solutions tend to be > not first-class and require additional boilerplate. > > In strongly typed Avail there is no Expression Problem! > Both data (types) and (multi) methods can be modularly and independently > mixed at compile time, and be dynamically added/removed at the runtime. > Cool... > > So why is this important? > > To get rid of if/then/else constructs! > > Because most if/then/else constructs are hardcoded ‘dispatchers/matchers’ on > data shapes, to produce other data shapes. > They are essentially binary decision trees in disguise, that carve up data > into a rigid hierarchal taxonomy. > > So why not let your compiler do the heavy lifting of dealing with (nested) > if/then/else constructs? > Currently, there are four ways alternative ways to express if/then/else: > > 1) via single polymorphic dispatch (OO) > 2) via pattern matching (Functional) > 3) via unification (Prolog: two way pattern matching) > 4) via rule matching (backchaining/forward chaining). > > Yet, all 4 of them cannot fully remove all if/then/else constructs in a > modular way without introducing boilerplate (aka: The Expression Problem). > > Except Avail…. > > The way I see the Avail runtime, is that it behaves like a strongly typed > forward chaining rule engine, via the dispatching of multi methods on data > objects. > > What makes the runtime so flexible is that you can add and remove rules any > time you want. > It allows you to dynamically add if/then/else constructs, optionally via a > strong typing discipline. > > So Avail is the compiler ‘substrate' to potentially eradicate all > if/then/else constructs. > But that’s just my abstract understanding of Avail. > > cheers, > Robbert.
signature.asc
Description: Message signed with OpenPGP using GPGMail
