other annotations

[Loïc Hoguin]

On 28/01/2021 13:11, Richard Carlsson wrote:
> Den tors 28 jan. 2021 kl 11:23 skrev Loïc Hoguin <essen@REDACTED 
> <mailto:essen@REDACTED>>:
> 
>     By the way, if annotations are going to be a thing, it might be a good
>     idea to make them more general so we can annotate other things, such as
>     "pure function" / "side effect function" or "local send" / "remote
>     send". I would personally love to easily identify message sends to
>     remote nodes.
> 
> 
> These are also interesting things - maybe not inline but perhaps as 
> keywords on function definitions; we had some ideas about marking 
> functions as pure (for guards) back in the HiPE project, for example. 
> Like any kind of strict typing, you then get into the question about 
> such functions in other modules: If they can only be used locally, the 
> feature is perhaps too limited to be worth it. To put them in other 
> modules, you'd probably need to do name mangling like e.g. when linking 
> C++, to ensure both caller and callee are following the conventions, and 
> that might get too messy. I don't know anyone who has prototyped that, 
> though, so it's not clear how it would look and feel.

Considering the small number of already bound variables used in a match, 
it might be more appropriate to make this a keyword as well. Or have a 
longer form, for example "^match Var". Then you can have "^pure 
function() -> todo.", "^remote Pid ! Msg" and so on. With the annotation 
being added as metadata and usable by the compiler, parse transforms or 
other tools (allowing custom annotations the compiler doesn't otherwise 
understand).

Other options could be "match^Var", "pure^function()" "remote^Pid ! 
...", or "match::Var", ":match: Var"...

The added advantage is that you're explicitly writing that this is a 
match rather than relying on people's understanding of what ^ means.

-- 
Loïc Hoguin
https://ninenines.eu