Giters

thautwarm / MLStyle.jl

Julia functional programming infrastructures and metaprogramming facilities

Home Page:https://thautwarm.github.io/MLStyle.jl/latest/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Split out match interface

Roger-luo opened this issue · comments

commented

I think we should consider a split match interface so that in the future we can eventually bootstrap the match macro, currently, this is also preventing me from removing MLStyle dependency at runtime, this is basically exporting an interface package with generic functions like pattern_uncall that can be overloaded in another package, etc.

then a utility package needs to be split out to provide things like MLStyle.AbstractPatterns.NoncachablePre etc.

Also I'm not sure why MLStyle takes quite a long time to load for a not-so-large codebase, perhaps we should re-implement the ADT in AbstractPatterns with the type-stable ADT provided by Expronicon.

commented

Actually, the compiler was made in the days I didn't fully aware of Julia latency issues, leading to very frequent (and redundant) runtime compilation.

MLStyle.jl heavily uses high order functions and the so-called tagless final patterns. Such way of abstraction in Julia causes extensive compilation due to the lack of typed functions (like those of FunctionWrappers.jl).

we should re-implement the ADT in AbstractPatterns

I agree things can be improved a lot with type stable ADTs. Also, the pattern compilation engine (i,e, AbstractPatterns) can be redesigned to avoid tagless final patterns. Tagless final is theoretically identical to ADT approach if polymorphic functions and data types used in the engine will not get extended.

I prefer the following roadmap instead of splitting out a utility package:

  1. Implement runtime-free codegen for MLStyle
  2. Redesign the pattern compilation based with type stable code
  3. Implement the pattern compilation with the runtime-free MLStyle code.
commented

It has been quite a long time since the introduction of MLStyle.jl. During years, some features are used but some are not, which suggests that the new pattern compiler does not need to be as powerful as the current one. It can be fairly simple, with support of only the "practical" functionalities.

I have some young PL friends and I'll try to hire some of them for MLStyle v0.5.

commented

It would be nice to have a package with @match & @active but without so much other stuff. I do find it hard to keep track of the large API surface with @λ, @switch, @otherwise, etc.