4 ms·

The drawback is that building an AST now requires a symbol table and resolving imports, possibly performing type inference and whatnot. It constitutes a higher

by layer8 8mo ago

The drawback is that building an AST now requires a symbol table and resolving imports, possibly performing type inference and whatnot. It constitutes a higher barrier for various types of tooling. You really want your programming language to avoid becoming context-sensitive in that way. It’s similar for the human reader: The examples are only intelligible to the reader incidentally, due to the names used and some natural-text conventions. In the general case, you have a seemingly random token sequence where you have no idea what binds to what, without looking up the type definitions or having an IDE present the expression in some structured way again. Furthermore, in typical code you don’t have the case of constant values so often. You’ll rather have things like: nextYear thisMonth.previous() lastDayOf(thisMonth.previous()) Double.parse(speedInput) m/s startPos to (startPos + length - 1) Schedule contacts.select(contactId) inputForm.getDateTime()

owlstuffing 8mo ago
> The drawback is that building an AST now requires a symbol table Well, yes and no. During AST building a binding expression resolves as an untyped polyadic expression. Only later during the compiler's type attribution phase does a binding expression's structure resolve based on the operand types. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#operator-precedence https://github.com/manifold-systems/manifold/tree/master/man... > in typical code you don’t have the case of constant values so often. Agreed. It's not really useful with inlined expressions: Schedule contacts.select(contactId) inputForm.getDateTime() but if you write it like: var plumber = contacts.select(contactId) var date = inputForm.getDateTime() var building = findLocation(warehouse) Schedule plumber on date at building But, honestly, I can't say I personally use it that way ;) Initially, I wrote it as a science extension to Java: https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-science https://github.com/manifold-systems/manifold/tree/master/man...

by layer8 8mo ago

owlstuffing 8mo ago

> The drawback is that building an AST now requires a symbol table Well, yes and no. During AST building a binding expression resolves as an untyped polyadic expression. Only later during the compiler's type attribution phase does a binding expression's structure resolve based on the operand types. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext#operator-precedence https://github.com/manifold-systems/manifold/tree/master/man... > in typical code you don’t have the case of constant values so often. Agreed. It's not really useful with inlined expressions: Schedule contacts.select(contactId) inputForm.getDateTime() but if you write it like: var plumber = contacts.select(contactId) var date = inputForm.getDateTime() var building = findLocation(warehouse) Schedule plumber on date at building But, honestly, I can't say I personally use it that way ;) Initially, I wrote it as a science extension to Java: https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-science https://github.com/manifold-systems/manifold/tree/master/man...