You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So all functions become HOFs that thread pass-though some implementation.
During factoring-out the function application from demand - I noticed - that yes - it simplifies the code, but that HOF legacy gets lost.
Having HOFs for everything is nice to preserve.
Had an epiphany. HOF functions move to the top-level. Class instances specialize HOFs to the HNix implementation.
Proper argument ordering (that currently happens) allows:
So force instead of force: forall . HOF it becomes forceF kleisli. The force becomes force = forceF pure. With that, we would leverage all work & code done and would have simultaneously the HOF abilities and the code elegance and I believe the performance. Because for GHC is easy to understand that class MonadThunk: force = forceF pure is constant and so the function is specialized to the class, giving us free to all this.
The #850 works on it also.
In #776 noted that Value methods are HOFs that can form the class instances.
The text was updated successfully, but these errors were encountered:
Anton-Latukha
changed the title
Please, move HOFs to toplevel, while class instances should be specialized to for what the class instances are for
Please, move HOFs to toplevel, while class instances should be specialized to what the class instances are for
Feb 27, 2021
Anton-Latukha
changed the title
Please, move HOFs to toplevel, while class instances should be specialized to what the class instances are for
Please, move Kleisli HOFs to separate *F type classes, while main class instances should be specialized to what the class instances are for
Feb 28, 2021
The initial HNix code has a fully open structure.
So all functions become HOFs that thread pass-though some implementation.
During factoring-out the function application from
demand
- I noticed - that yes - it simplifies the code, but that HOF legacy gets lost.Having HOFs for everything is nice to preserve.
Had an epiphany. HOF functions move to the top-level. Class instances specialize HOFs to the HNix implementation.
Proper argument ordering (that currently happens) allows:
So
force
instead offorce: forall . HOF
it becomesforceF kleisli
. Theforce
becomesforce = forceF pure
. With that, we would leverage all work & code done and would have simultaneously the HOF abilities and the code elegance and I believe the performance. Because for GHC is easy to understand thatclass MonadThunk: force = forceF pure
is constant and so the function is specialized to the class, giving us free to all this.The #850 works on it also.
In #776 noted that Value methods are HOFs that can form the class instances.
The text was updated successfully, but these errors were encountered: