-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Layout try 2b #6
Conversation
By the way, here is an extended example of OO koka that I created awhile back:
As you'll note it supports mixed lists of different values having the same interface, which is non-typical for a functional language like Koka. Of course you can think of it as simply a record of closures, which all have access to refs for the object's state, and a ref to it's super classes state. So it definitely could be done in other functional languages, but the syntax feels pretty nice to me. You'll notice One limitation of this approach is the fact that the methods available cannot change (the effect has to be something that all 'extended' classes inherit). I guess we could create a subclass effect declaration with more definitions, but then you cannot mix them in a list. However, by exposing the extendable type info, we can create methods that use the evidence to get the internal data, match a specific variant, and get the appropriate bits of state depending on the type. With an accompanying |
@complyue I've added you as a contributor to this repository. As there are 0-2 users and this is somewhat of an experimental package anyways, feel free to experiment / merge and iterate on designs here. We don't have to commit to a certain API quite yet, and feel free to make breaking changes if you feel it improves the overall API. If you want feedback or help on tricky typing issues, feel free to open PRs still and I'll review them. I'd love to get to the point where we also have APIs to update an actual DOM using Koka's JS backend. (This should be in a clearly differentiated module though, so we can use the core modules on other Koka backends for server-side programming). |
I'd been longing for open sum type several times in working with Haskell, so nice to hear that Koka has it! from the animal example, I roughly feel that "name effect" maps to |
@TimWhiting , thanks for inviting me to this repo, I really have pleasure to learn Koka this way (asking your kind help whenever needed ;-), and certainly will try contribute as best here. wrt exploring templating designs, may I suggest you commit the effect-polymorphic, component/build parts to |
Done. Also I simplified the naming a bit to try to match the current API design. BTW, In Koka I prefer to use shorter names like |
I see :) loving the new concise names 👍 and Koka is really lovable in its local namespace design 👍 👍 I realized Koka just supports function/operator overloading via that local namespacing, brilliant idea 👍 had been longing for it when with Haskell several times |
val title = "The Front Page" | ||
|
||
with super <- default() | ||
with page <- named handler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how realistic it is, to add syntactic sugar to Koka, for surface syntax to omit methods simply delegating to super
, in defining page
here?
i.e. is it simple or complex in drafting a PR to add this?
update: might need https://en.wikipedia.org/wiki/C3_linearization with multiple inheritance in mind, also that'll need a way to store and investigate an ev<>
's supers (i.e. mro), apparently more complex.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah there are a lot of considerations here, ordering of superclasses / mixins, allowing multiple different effects to have the same operation names etc. To fully support OO would be quite a change to possibly the type system as well, and not just a simple desugaring. In general I try to keep the number of operation clauses small, and then any time I think I need a new operation, see if I can make the current operations more general and provide functions that call those general clauses and do something more specific. The current design actually could be simplified a lot by creating a struct to hold the individual components and just making the effect have an operation for getting and setting that struct held in a state variable.
examples/front.kk
Outdated
fun main() | ||
val page = do | ||
with val cnodes-info = [ | ||
Cnode("dev", "192.168.11.50", 8, 16, 30), | ||
Cnode("dev", "192.168.11.51", 8, 18, 30), | ||
Cnode("gpu01", "192.168.11.20", 8, 65, 128), | ||
Cnode("gpu02", "192.168.11.21", 8, 90, 128), | ||
] | ||
frontpage() | ||
println(page.show) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TimWhiting , do you think this a sufficiently motivating example for do
to go into std/core
?
I'd quite like it in reminiscent of Haskell.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I don't really see the need, at least in this example, because you can omit the do
and just keep the indentation and Koka evaluates this as a value (it's not a function really, just a sequence of expressions / statements and the last one is the definition's value).
Koka supports this kind of nested defintion scope.
That being said, do
is kind of nice coming from Haskell. From other languages, it might require a bit more explaination, but it is also mostly self-explanatory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
besides the indentation, I mean to limit some effects/vars within a nested scope, of shorter lifetime, what's the idiomatic Koka way to do that? by far I can only think of do
fitting this...
update: ah, i see, val =
can just accept indented rhs, nice already 👍
@TimWhiting what's the syntax to add more data constructors to an open type? i'm tinkering with this:
|
|
Rather strange error:
|
Instead of this:
Try:
Koka doesn't really support multiple letters in type variables. You can use a single letter followed by a number. To restrict the type variable to a specific type you'd have to have some form of subtyping which Koka does not. |
pity to hear 😞 how does |
I've created some documentation for some lesser known / used Koka features here in a community repo: It's not quite polished enough to include in the Koka book I think, but it answers maybe some of your questions about abstract / extend type, under the type-definitions section. |
update: with the fix from your previous suggestion, full code https://gist.github.com/complyue/245b7b95edc298128fbab26597b08de1 another typing error - seems I've still got the wrong intuition about composing effects:
help pls! why this doesn't work? |
Because Change the type to reflect what I said:
This is most commonly the best solution - make sure that your function inputs have the same effect type as the returned effect type - as long as no handlers are installed. or,
Also a fine solution, a bit more runtime overhead for explicitly masking the effect, and restricts inference of the action to ensure the console effect is not used in the action (if it is used in the action it would cause a duplicate console effect, and require duplicate console handlers - which for the console effect in particular might not be an issue). This is why the first solution is typically the right choice, unless you are purposefully dealing with multiple different instances of handlers for the same effect. or, when debugging:
|
so update: i'm sketching for the case where update2: so |
I agree that we need to make it easier to type annotate, it is not very ergonomic currently, and encourage uses of creating aliases for groups of effects, which are occasionally hard to name. The only way to actually dismiss effects is to handle them. Otherwise you are claiming a function is a total function with respect to that effect without it actually being so. In particular Koka needs to know about handlers to appropriately compile and optimize calls to effect operation. Otherwise the optimizer might improperly index into the internal vector of handlers it keeps. In other words if This doesn't prevent you from creating another handler for the file effect such as Despite the security implications, I do recognize that there are legitimate reasons to dismiss some builtin effects. (Haskell provides I would not use mask for this case. It doesn't make sense to me, but maybe it is what you are looking for. There is also no "forbidding" of effects in a polymorphic variable - that is not polymorphism, it is subtyping. There are other languages with algebraic effects with different type systems that allow negative effects, but also are more limited in other ways. While I do think that Koka, or some derivative of it will need or should add subtyping at some point, there is still a lot to explore with what we can do without subtyping. Koka has so many features that have not been experimented with much in practice, and I think we need to figure out the limitations, to figure out what is actually needed and what just needs new or different programming patterns that haven't been explored before or as much. Implicits, algebraic effects, named effects, static overloading, already lead into an area not explored very much at all. Additionally Daan envisions Koka as a sort of For more advanced type systems with subtyping, or larger changes, I think he'd rather someone create their own language that compiles to Koka. Not saying that Koka will never get subtyping - it is quite general, but that it probably will not be a priority, because it doesn't quite fit minimal as far as implementation / type system complexity, especially when Koka's type system is already getting a bit complex. |
thanks for the informative reply! i get more fresh new insights from your words, and realized that i do find implicits in Koka as nice as type classes in Haskell, in adding tho it may need easy ways to extend the surface syntax of Koka to further smooth lib/end programmer experience. and toward this direction, are there plans for Koka to digest IRs/ASTs translated by some mechanism on the fly, like "Template Haskell" from GHC? i'm a fun of DSL, Koka is already great at this, by custom infix operator and overloading support, it'll be even greater if fostering advanced type-level / compile-time programming. |
Yes, it definitely marks the upper bound. I am also very interested in DSLs or a form of meta-programming / flexible front-end for Koka. Yes, I agree that Koka is already great at this with infix operators, overloading, and as exemplified by this package indentation and trailing lambdas. I think it is important to explore what kinds of DSLs we can make with the current features. However, every time I have to write my own show / (==) functions, I feel kind of sad inside - especially if they are the straightforward default implementations. I do have a PR to automatically generate those koka-lang/koka#426, but due to recursive types and divergence the types aren't quite what Daan wants. I think I can fix that a bit, but he has other things he'd like to focus on first. For more discussion about metaprogramming see this issue: koka-lang/koka#536 |
As far as this PR goes, how do you feel about the changes, and should we actually have the default expected |
yeah, Koka has its very inner beauty in minimalism as well as being very fundamental, i don't expect it very smooth wrt programmer experience from the early days (i.e. now), but i believe it'll get polished over time, and let's do that :D
if u mean the
my opinion is that we can defer adding the
i'd love to work with u for that via later/other PRs, and contribute as best as i can, is that okay? and I just created #7 , pls have a look, and see if that worth more effort to try? i think i need your help to progress on that direction. |
Yeah, that is great! |
Same as #5, but with changes to return component instead of a function like #3