Le mercredi 20 avril 2016 à 15:34 +0100, Didier Verna a écrit : > Matt Bauman <[email protected]> wrote: > > > > > It's nice for both humans (it's obvious that there could be some > > non-standard evaluation semantics or other such funniness) > Maybe for /some/ humans ;-), but I don't like this. It exposes > implementation details to the programmer. It breaks the functor > syntactic uniformity (consider that a single expression could > otherwise have different semantics in different contexts which gives a > lot of expressiveness) and makes Julia much less convenient for DSLs > design for instance. Also, it's not coherent with the rest of the > language. Short-circuit operators[1] and some built-in constructs also > have non-standard evaluation semantics, but they don't have a funny > calling syntax. The fact that you're calling a macro and not a function is certainly not an implementation detail. The @ is here to warn you that the call might have any kind of side-effects, or at least does not behave like functions.
OTOH, short-circuit operators are in limited number (&& and ||). Packages authors cannot create new ones without the user knowing, so the potential for confusion is much lower. > > and the parser (it knows exactly which symbols it needs to resolve in > > order to expand the macros since nothing else can contain the @ > > character). > Making life easier to the internals should never be a valid argument > to corrupt the externals :-) Besides, I don't see how it would be > difficult to figure out if a symbol refers to a macro, or to a regular > function. In fact, Julia already does something similar, according to > whether a function or a functor is called. Well, I guess that macros > are not first-class enough... > > > > > Are you talking about the optional parentheses? That is: `@m(x,y)` vs > > `@m x y`? > Yes, sorry. > > > > > It's very convenient to have the parentheses-less version for macros > > like @inline and @simd which annotate or transform existing > > structures. And parentheses with comma-separated arguments can be > > nice in cases where the distinction between several arguments might > > get fuzzy otherwise. > OK. Not much convinced here either. Not sure the convenience was worth > the syntactic trouble it causes in the rest of the language > (e.g. deprecating the foo() syntax). > > > One final remark: a corollary of this specific calling syntax is that > eponymous functions and macros may co-exist (they seem to live in > separate namespaces). Anyone ever saw a use for this? Yes. For example, DataFrames.jl and DataFramesMeta.jl provide functions like where(), by() and aggregate() both in function and macro forms. The former takes a function, while the latter offers a convenience syntax which creates a function under the hood. See in particular this section: https://github.com/JuliaStats/DataFramesMeta.jl#operations-on-groupeddataframes > Footnotes: > [1] BTW, is there a functional equivalent to && and friends? I mean, a > logical AND short-circuit function usable in prefix notation? I was > surprised that I can do +(1,2) but not &&(true,false). I don't think that's possible, as the short-circuit behavior of && means it does not evaluate its second operand if the first one is false. So it cannot be a standard function. Regards
