[Tinkering] Object Oriented HTML Templating #5
Conversation
|
given it's always explicitly passed, an evidence/handle of some named effect is essentially an object-reference under disguise? despite resume/ctl ability the methods can have. |
| fun body-begin-scripts(): (() -> <html-tree|e> ()) | ||
| fun body-end-scripts(): (() -> <html-tree|e> ()) | ||
|
|
||
| fun defaultpage(action: ev<html-layout<<pure|e>>> -> <pure|e> a) : <pure|e> a |
There was a problem hiding this comment.
a Koka module ref bug here? it's not pub but can be used from front.kk with simple import.
There was a problem hiding this comment.
Actually no bug here. If you don't specify a module name (module html/layout) at the top of the file, it's not really a separate module, more of just a source file, and everything is defaulted to pub.
There was a problem hiding this comment.
nice to know this trick, can I understand it like when you import a module which w/o its own module declaration, the result is like how #include work in C?
| fun body-begin-scripts() | ||
| super.body-begin-scripts() | ||
| fun body-end-scripts() fn() | ||
| super.body-end-scripts()() |
There was a problem hiding this comment.
the fn() and ()() looks really weird, but might simply bcoz we are demonstrating "settability" for object semantics.
There was a problem hiding this comment.
|
@TimWhiting , I don't know where to look at, but does Koka currently have some syntax support in defining a |
examples/front.kk
Outdated
| fun do(action : () -> e a) : e a | ||
| action() | ||
|
|
||
| value struct cnode |
There was a problem hiding this comment.
Koka warns:
Type cnode requires 40 bytes which is rather large for a value type
does this mean value keyword will force the generated machine code pass that struct values via registers/stack ?
i wonder if string fields would also have its var-len payload packed altogether, i'm thinking about koka-lang/koka#543 , mini-heaps with var-len data seem to work performantly that way too.
There was a problem hiding this comment.
Koka ultimately leaves the registers / stack up to the C compiler. However, it does mean that the string struct will be embedded in the cnode struct instead of having a pointer to that value. However, it doesn't change whether the strings themselves are value / ref objects. Strings are currently represented by a length and then the pointer to the chars (not necessarily allocated next to the length field).
No, but it would be a good issue to raise on Koka's repo. Specifically to another named handler would be good I think. |
examples/front.kk
Outdated
| fun set-body-content(c) | ||
| super.set-body-content(c) | ||
| fun set-page-title(t) | ||
| super.set-page-title(t) |
There was a problem hiding this comment.
With the way you designed this we can probably get rid of the set-* methods. Which would make this somewhat nicer.
|
closing this in preference to #6 |
This is based on #4, one major change is to have OO inheritance happen at user site instead of lib site. But "descendant object" has to recite all "methods" of super class (effect), maybe syntactic sugar can help with it, but I keep thinking other alternatives...