Jared Forsyth
01/31/2023, 4:53 AMKonrad Hinsen
01/31/2023, 6:21 AMJarno Montonen
01/31/2023, 7:44 AMthe 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 Rusher
01/31/2023, 7:55 AMJared Forsyth
01/31/2023, 9:16 PMYou could still end visibly exactly the same function calls binding to different overloads.
So that's already the case with a + b
and c + d
, 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.Jarno Montonen
02/01/2023, 6:19 AMKonrad Hinsen
02/01/2023, 10:25 AMyairchu
02/01/2023, 1:33 PMPrior Art
…
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 Forsyth
02/01/2023, 1:40 PMJarno Montonen
02/01/2023, 2:00 PMJared Forsyth
02/01/2023, 2:24 PM