Jared Forsyth01/31/2023, 4:53 AM
Konrad Hinsen01/31/2023, 6:21 AM
Jarno Montonen01/31/2023, 7:44 AM
the compiler is involved in the entire process of development, responding to programmer feedback, and giving context-aware feedback in return. In this model, the source code is enriched with the compiler's inferences along the way, which the programmer can inspect & correct (but can also be elided from display for a more compact presentation).About this:
When typing an identifier in Jerd, if you select something from autocomplete, the ID of that term is stuck onto the identifier node, and then the compilation pass doesn't need to do any name resolution -- it knows exactly what is being referenced. And, if you later change the name of a variable, none of the references are broken.How do you plan on handling the case where a new higher precedence function overload is added after a id+arguments code has been 'bound' to an overload that should now be preceded by the new overload for the given id+arguments? So you could end up in a situation in which exactly the same function call expressions bind to different overload depending on which overloads existed at the time of writing (binding) of the call. I guess you could just run the overload resolution again for all the calls, but what if the result for a call depends on a (now hidden) user defined type annotation. You could still end visibly exactly the same function calls binding to different overloads. How would possible implicit casts/conversions fit in?
Jack Rusher01/31/2023, 7:55 AM
Jared Forsyth01/31/2023, 9:16 PM
So that's already the case with
You could still end visibly exactly the same function calls binding to different overloads.
a + b
, if a & b are ints, but c & d are strings, right? Now I actually solve this by coloring all identifiers according to the hash of the definition, so the two function calls would very likely have different colors, allowing you to immediately recognize them as distinct. @Jack Rusher thanks for the link! fascinating read.
c + d
Jarno Montonen02/01/2023, 6:19 AM
Konrad Hinsen02/01/2023, 10:25 AM
yairchu02/01/2023, 1:33 PM
I don’t know if they [Lamdu] store the inferred types in the syntax tree, or if they re-compute them on every edit.Lamdu does a combination: • For every definition (global variable/function) it stores the types of every definition that it used, so that if that definition changes its old type is still used for inference until a manual (and informative!) “update type” action • Inside the definition it does re-infer it on every edit, and an edit that would had resulted in an error in a normal language gets inserted as wrapped in a “fragment” (aka “non-empty hole” which was our old term and was also adopted by Hazel) And btw, Lamdu also has the option to mark the new usage with fragment as the correct one and push the error to other parts of the code. It’s all explained/demonstrated in more detail here:
Jared Forsyth02/01/2023, 1:40 PM
Jarno Montonen02/01/2023, 2:00 PM
Jared Forsyth02/01/2023, 2:24 PM