other annotations

[Raimo Niskanen]

On Thu, Jan 28, 2021 at 01:43:00PM +0100, Loïc Hoguin wrote:
> 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.

That is an interesting idea.

{ok, ^Var} = foo(),
{ok, match^Var} = foo(),

More verbose, but not terribly.  Still next to the variable. and no
intermediate variable is needed.  Maybe even clearer.
Opens up for other annotations.

Then ^ would be the annotation binary operator.

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

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB