Re: [julia-users] Re: macros design
Le mercredi 20 avril 2016 à 16:22 +0100, Didier Verna a écrit : > Milan Bouchet-Valat wrote: > > > > > OTOH, short-circuit operators are in limited number (&& and ||). > > Packages authors cannot create new ones without the user knowing > Do you mean it's possible to create new short-circuit operators ? No, precisely that it's not possible, so we don't need a special syntax like @. Regards > > > > 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-group > > eddataframes > Thanks. > > > > > > 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. > Sure. It would have to be built-in. >
Re: [julia-users] Re: macros design
Milan Bouchet-Valat wrote: > OTOH, short-circuit operators are in limited number (&& and ||). > Packages authors cannot create new ones without the user knowing Do you mean it's possible to create new short-circuit operators ? > 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 Thanks. > 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. Sure. It would have to be built-in. -- ELS'16 registration open! http://www.european-lisp-symposium.org Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [julia-users] Re: macros design
Isaiah Norton wrote: > Just to follow up on this a bit: we've continually reworked the > metaprogramming documentation because it can be an especially > difficult concept for people who don't have a compiler background or > Lisp experience. The most common sources of misunderstanding have been > rooted in people not internalizing that macros, from a definition > standpoint, are just functions that return expressions. A lot of > questions on the mailing list treated macros as "spooky magic" (I'll > admit to feeling this way for a long time!). We want to make them less > so. Showing explicit returns, and emphasizing macros as > transformations first, was an attempt to reduce the level of implicit > knowledge required to understand what is happening. Makes sense. Thanks. But now that you've had the opposite reaction, perhaps you could add a note that the return is actually not needed. :-D -- ELS'16 registration open! http://www.european-lisp-symposium.org Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [julia-users] Re: macros design
cormull...@mac.com wrote: > https://github.com/JuliaLang/julia/blob/3c354b4a391307d84915445bdd6fb464371f30fc/doc/at_macro_reasons > Nice, thanks :-) -- ELS'16 registration open! http://www.european-lisp-symposium.org Lisp, Jazz, Aïkido: http://www.didierverna.info
Re: [julia-users] Re: macros design
Le mercredi 20 avril 2016 à 15:34 +0100, Didier Verna a écrit : > Matt Bauman 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
Re: [julia-users] Re: macros design
> > Yup, implicit return works for macros, too. The manual makes it explicit > to emphasize the function-like syntax transformation (as opposed to > CPP-like textual substitution). Just to follow up on this a bit: we've continually reworked the metaprogramming documentation because it can be an especially difficult concept for people who don't have a compiler background or Lisp experience. The most common sources of misunderstanding have been rooted in people not internalizing that macros, from a definition standpoint, are just functions that return expressions. A lot of questions on the mailing list treated macros as "spooky magic" (I'll admit to feeling this way for a long time!). We want to make them less so. Showing explicit returns, and emphasizing macros as transformations first, was an attempt to reduce the level of implicit knowledge required to understand what is happening. On Wed, Apr 20, 2016 at 9:50 AM, Matt Bauman wrote: > On Wednesday, April 20, 2016 at 8:58:35 AM UTC-4, Didier Verna wrote: >> >> >> What's the rationale behind this particular way of invoking macros >> (the @ character) ? > > > It's nice for both humans (it's obvious that there could be some > non-standard evaluation semantics or other such funniness) 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). > > >> And why a single macro concept for two different >> things (with or without arguments) ? >> > > Are you talking about the optional parentheses? That is: `@m(x,y)` vs `@m > x y`? 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. > > On Wednesday, April 20, 2016 at 9:19:03 AM UTC-4, Didier Verna wrote: >> >> Also, I'm wondering about the use of RETURN in all the one-liner >> macro examples from the manual. > > > Yup, implicit return works for macros, too. The manual makes it explicit > to emphasize the function-like syntax transformation (as opposed to > CPP-like textual substitution). >
[julia-users] Re: macros design
On Wednesday, April 20, 2016 at 8:58:35 AM UTC-4, Didier Verna wrote: > > > What's the rationale behind this particular way of invoking macros > (the @ character) ? It's nice for both humans (it's obvious that there could be some non-standard evaluation semantics or other such funniness) 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). > And why a single macro concept for two different > things (with or without arguments) ? > Are you talking about the optional parentheses? That is: `@m(x,y)` vs `@m x y`? 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. On Wednesday, April 20, 2016 at 9:19:03 AM UTC-4, Didier Verna wrote: > > Also, I'm wondering about the use of RETURN in all the one-liner > macro examples from the manual. Yup, implicit return works for macros, too. The manual makes it explicit to emphasize the function-like syntax transformation (as opposed to CPP-like textual substitution).
[julia-users] Re: macros design
https://github.com/JuliaLang/julia/blob/3c354b4a391307d84915445bdd6fb464371f30fc/doc/at_macro_reasons
[julia-users] Re: macros design
I wrote:
> What's the rationale behind this particular way of invoking macros
> (the @ character) ? And why a single macro concept for two different
> things (with or without arguments) ?
Also, I'm wondering about the use of RETURN in all the one-liner
macro examples from the manual. Why not just:
macro sayhello()
:( println("Hello, world!") )
end
--
ELS'16 registration open! http://www.european-lisp-symposium.org
Lisp, Jazz, Aïkido: http://www.didierverna.info
