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
Hi -- I'm fascinated by Koka. I love the min-gen principle and how that has played out so far in the composability of the language features.
I've been wondering whether embedding use cases are being considered at all / whether the current implementation is likely to support a good 'embedded' koka story?
In particular I'm wondering whether anyone has thought at all about exposing koka as the query and mutation language interface to a persistence engine. It seems to me that most persistence technologies fundamentally are about finding ways to bring computation 'closer' to data with the application-specific computations constrained in some appropriate ways so as to work well with the persistence engine implementation.
It seems to me like fql could (easily?) be replaced by koka. I'm imagining that building a 'constrained subset' of koka is something that the effects system makes easy potentially? I have this half-baked thought that the whole faunadb api could be rather elegantly exposed as a few koka functions -- where any callbacks that are intended to be passed to the database engine return some 'faunadb specific' effects that constrain the callbacks in the required ways so that they can be shuttled by the engine to the data as needed?
My intuition is that koka might present some quite nice and ergonomic ways to express the kinds of 'i need to pass some constrained computation to some persisted data' operations -- where the constraints and data compose elegantly in ways chosen by the persistence implementation?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi -- I'm fascinated by Koka. I love the min-gen principle and how that has played out so far in the composability of the language features.
I've been wondering whether embedding use cases are being considered at all / whether the current implementation is likely to support a good 'embedded' koka story?
In particular I'm wondering whether anyone has thought at all about exposing koka as the query and mutation language interface to a persistence engine. It seems to me that most persistence technologies fundamentally are about finding ways to bring computation 'closer' to data with the application-specific computations constrained in some appropriate ways so as to work well with the persistence engine implementation.
That's a pretty generic statement but by way of a more concrete example: take faunadb with its somewhat tragic fql syntax https://docs.fauna.com/fauna/current/api/fql/.
It seems to me like fql could (easily?) be replaced by koka. I'm imagining that building a 'constrained subset' of koka is something that the effects system makes easy potentially? I have this half-baked thought that the whole faunadb api could be rather elegantly exposed as a few koka functions -- where any callbacks that are intended to be passed to the database engine return some 'faunadb specific' effects that constrain the callbacks in the required ways so that they can be shuttled by the engine to the data as needed?
My intuition is that koka might present some quite nice and ergonomic ways to express the kinds of 'i need to pass some constrained computation to some persisted data' operations -- where the constraints and data compose elegantly in ways chosen by the persistence implementation?
Is there any juice to my intuition here?
Beta Was this translation helpful? Give feedback.
All reactions