Re: other annotations
Raimo Niskanen <[email protected]>
| Newsgroups | gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected] > > <mailto:[email protected]>>: > > > > 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