-
Notifications
You must be signed in to change notification settings - Fork 36
[interpreter] Add event section #151
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
open Types | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Even if its kind of trivial, can you also add an .mli file for this module? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
|
||
type event = {ty : func_type} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, it's a bit odd that this is func_type not event_type. I can see why, but it would break down once an event type has additional attributes. The underlying problem is that there are two notions of event_type: the syntactic one (with a typeidx) and the semantic one (with the function type inline). Depending on context, we want one or the other. This is not a situation we've had before, so I don't have any great suggestion right now. We can resolve this later. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ack. Regarding the syntactic vs semantic There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The difference is the extra indirection. For function types, the type section is just mapping a typeidx to a func type, and the functype itself is a closed type description. Once looked up, we can use that directly. But for event types, the definition itself refers to another typeidx, so isn't self-contained. This becomes clearer if we assume that an event type has additional ingredients, say, a hypothetical event_mode (as per the reserved zero byte). Then for the syntax, we'd need There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree, and for this reason I think types.ml should contain the resolved type.
which makes sense for encoding, decoding and pretty-printing. For type checking, imports/exports and everything else, the resolved type is easier to work with. WDYT about simply reverting back to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, both I'm afraid we can't hack around the two facets, they're inherent. It's relatively localised here, but becomes ubiquitous with concrete reference types. In the function references proposal I currently resolve it by actually distinguishing syntactic and semantic types. They differ by how variables are represented: for syntactic types it's just an index, with semantic types they become a pointer to the actual definition. But I suggest to not worry about it for now. I want to play with streamlining this a bit and can fix it later. This needs a representation that cleanly carries over to the paper spec. |
||
type t = event | ||
|
||
let alloc ty = | ||
{ty} | ||
|
||
let type_of evt = | ||
evt.ty |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
open Types | ||
|
||
type event = {ty : func_type} | ||
type t = event | ||
|
||
val alloc : func_type -> event | ||
val type_of : event -> func_type |
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.
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.
Done