That makes sense. The other (primary) reason I want this is still valid: assisting multiple dispatch (and clarity for other developers) by having the correct types on optional arguments. Since there are no objects for encapsulation of related behaviors, the only good way to explore an API (other than just reading its source) is to use Julia's reflection utilities like names() and methods(). I want to be able to use brief function names like "add!()" on my types, but if every optional argument requires leaving off the type information, there will quickly be ambiguity/collisions with the definitions in different places. Since each one is really intended for a specific type, having that in the function signature would improve clarity quite a bit. That's why I spent a bit of time trying to construct the @optional macro.
On Thursday, May 8, 2014 9:18:01 AM UTC-4, Tim Holy wrote: > > I'm not sure I understand. Except for one particular situation (tuple > arguments), declaring the type of inputs has no impact on performance. The > JIT > will compile a separate version of the function for each different set of > input > types. See the "performance tips" section of the manual. > > --Tim > > On Thursday, May 08, 2014 01:34:12 AM Adam Smith wrote: > > Actually performance is one of the reasons I wanted to do it this way, > > rather than leaving off type info and just dealing with Anys, which is > > slower (and makes multiple dispatch very messy). I will read through > > Julia's parser a bit more and then file an issue. > > > a d a m > > > > On May 8, 2014, at 1:25 AM, "Kevin Squire" > > <[email protected]<javascript:>> > wrote: > > > > > > > Hi Adam, > > > > > > While working with optional and union types won't be as performant as > > > regular types, this seems like it would be useful. Why don't you file > an > > > issue? It might not be easy or feasible to do what you want, but it's > > > good to bring it to the attention of the main devs. > > > > Cheers, > > > > > > > > > Kevin > > > > > > > > > > > > > > >> On Wed, May 7, 2014 at 5:15 PM, Adam Smith > > >> <[email protected] <javascript:>> wrote: > Did you make any progress on > > >> this? I tried to do the exact same thing as you, got the exact same > > >> error, googled, and found this post. It seems that Julia parses > default > > >> values for arguments separately from the name/type of the arguments. > > >> This was the macro I attempted: > > >> macro optional(name, ptype) > > >> > > >> esc(:($name::Union(Nothing, $ptype) = nothing)) > > >> > > >> end > > >> > > >> With the desired usage being: > > >> function do_stuff(x::Int, y::String, @optional(z, Float)) > > >> > > >> # do stuff > > >> > > >> end > > >> > > >> What I _really_ want (but I knew wouldn't be possible) would be: > > >> function do_stuff(x::Int, y::String, z::@optional(Float)) > > >> > > >> # do stuff > > >> > > >> end > > >> > > >> The Julia documentation at > > >> > http://julia.readthedocs.org/en/latest/manual/metaprogramming/#hygiene > > >> makes the exaggerated claim "An expression wrapped in this manner is > > >> left alone by the macro expander and simply pasted into the output > > >> verbatim." > > > >> The documentation is clearly oversimplifying a bit, otherwise my > macro > > >> should work. > > > >> > > >> > > >> > > >>> On Friday, February 21, 2014 3:36:07 PM UTC-5, Joosep Pata wrote: > > >>> Hi, > > >>> > > >>> I’m trying to write a macro that would generate functions with > optional > > >>> arguments. However, I can’t figure out why the following code > behaves > > >>> as it does. I’d appreciate if someone told me what I’m doing wrong. > > > >>> ~~~ > > >>> #1) def. value in quote, works > > >>> ex = :(x) > > >>> q = quote > > >>> > > >>> function f1($ex=1) > > >>> > > >>> x > > >>> > > >>> end > > >>> > > >>> end > > >>> macroexpand(q)|>println > > >>> eval(q) > > >>> f1()|>println > > >>> > > >>> > > >>> #2) def. value in expression, does not work > > >>> ex = :(x=1) > > >>> q = quote > > >>> > > >>> function f2($ex) > > >>> > > >>> x > > >>> > > >>> end > > >>> > > >>> end > > >>> println("does not work") > > >>> macroexpand(q)|>println > > >>> eval(q) > > >>> f2()|>println > > >>> ~~~ > > >>> > > >>> 1) does not allow me to conveniently construct a list of arguments > with > > >>> values, whereas > 2) gives me > > >>> > > >>> > ERROR: syntax: "x=1" is not a valid function argument name > > >>> > > >>> > > >>> The macroexpand of either expression looks identical, except for > spaces > > >>> around the “=“ sign for 2), which should not make a syntactical > > >>> difference. > > > >>> cheers, Joosep > > > > > > > >
