On May 20, 2014, at 3:30 PM, Robbert van Dalen wrote: > On 20 May 2014, at 08:26, Mark van Gulik <[email protected]> wrote: >> On May 19, 2014, at 3:33 PM, Robbert van Dalen wrote: >>> is there an easy way to mimic scala’s implicits? >> [...] >> Technically that's sufficient to allow us to write: >> Print: “∑<1,2,3>”; >> Print: ∑<"a","b","c”>; > > i understand the multi-method approach, but that’s different from the single > abstract implementation that sums a tuple with a monoid. > your example has two concrete implementations.
Yeah, I agree it's not quite the same thing. Perhaps a more idiomatically appropriate translation of the feature would be to provide a trivial adapter layer. That can be done by introducing a "_→monoid" method, then providing overrides for integer and string. Then when you really want a tuple of monoids you can convert a tuple of integers or a tuple of strings via another method "_→monoids", and define “∑_” once, on <monoid|>. The "_→monoid" methods would produce a monoid object that stores the unit in some field and stores the appropriate addition function in another field. The "_→monoids" method can be defined for the signature [tuple]→<monoid|>, using a semantic restriction to statically ensure there's a suitable implementation of "_→monoid" to invoke on each element of the tuple (and that the same method can be invoked for each element of the tuple). This technique is due to Todd, and he wrote up a brilliant paper about it in 2012. It uses Avail's reflection facilities – at compile time! Weird, huh? >> In general it should be fairly simple to build an X --> Y adapter, but Avail >> currently has no way to invoke the conversion operation to implicitly get >> from an X to a Y. The best idea so far is to allow the "_" method for type >> conversion (its merits and pitfalls are frequently investigated in my old >> Avail notebooks). This is currently forbidden, I'm fairly certain. But if >> we open up that capability we should be able to specify any implicit >> conversion paths that we want. In a normal language technology, at some >> level of implementation we would have to synthesize actual helper objects of >> type Y, either to invoke the original X methods with reflection or to hold >> generated code that delegated to the X method. We would also not be able to >> use the resulting Y in place of X because of unwanted identity. Avail is >> still stuck in that regard, since the availability of implicit conversions >> would introduce multiple interpretations of the vast majority of >> expressions. Even something as innocuous as Print: “x”; would be ambiguous, >> because it would be unclear whether we should use x directly or convert x >> from an X to a Y (or myriad other implicit conversions). > > ok, you make implicit typing sound like a tar pit: it probably is! > >> I'm really not impressed by any of these possibilities. They all have the >> potential to make Avail a very messy, special-case, black-magic-filled >> language. So what aspect of Scala's implicits did you have in mind, just in >> case I didn't understand them or I didn't cover it? > > in scala, i use implicit typing to effectively reduce boilerplate and other > redundant code. > and i agree with you that it is messy, black-magic even. > but if i have to choose between boilerplate or magic, i choose magic. I'm fine what that, as long as there's an explicit invocation of the magic, like "<1,2,3>→monoids". Boilerplate is (usually) bad because it's bulky and hides the intent of the code in repetitive drivel. I don't think there's anything overly messy about Print: “∑<1,2,3>→monoids”. Or maybe even folding the type-safe conversion to a tuple of monoids into the "∑_" operation itself. > of course, a lot of boilerplate can also be reduced with macros - which is > another source of magic! We'll get there this summer. I'm still stuck finding the right motivation to produce the file output abstraction. I have a lot of ideas about how to do I/O that I've accumulated over the years (I wrote a commercial high performance object database – in Smalltalk!), and I'd like to make sure that the most profitable ideas fit together snugly. And then I can resuscitate macros. And then probably rip apart the L2 translator once again, this time with the goal of rewriting the naive L1→L2 translation into SSA form, which should enable vastly more powerful transformations. Now there's some magic!
signature.asc
Description: Message signed with OpenPGP using GPGMail
