That doesn't seem to work with composite types and Nothing. Using a day-old
nightly build:
julia> type MyType; end
julia> example(x::Int, mt::MyType=nothing) = println("in example")
example (generic function with 2 methods)
julia> example(1)
ERROR: no method example(Int64, Nothing)
in example at none:1
julia> example(1, MyType())
in example
Which is why I resorted to the Union() stuff.
On Thursday, May 8, 2014 10:32:10 AM UTC-4, Tim Holy wrote:
>
> I agree that declaring types is an effective way of increasing clarity.
> (Fundamentally I suspect that suggests inadequacies in our documentation.)
> Aside from the more "valid" use in controlling which version of a function
> will run on which types of data.
>
> However, you don't have to leave off type information from optional
> arguments:
>
> function findsmallest(v::Vector, issorted::Bool = false)
> if issorted
> return v[1]
> else
> return minimum(v)
> end
> end
>
> will be callable either as findsmallest(v, false) or findsmallest(v). If
> you do
> supply the extra argument, it must be a Bool. Doesn't that do what you're
> hoping for?
>
>
> You can also supply types to keyword arguments, i.e.,
>
> function findsmallest(v::Vector; issorted::Bool = false)
>
> which will then be callable either as findsmallest(v) or findsmallest(v,
> issorted=true).
>
> --Tim
>
> On Thursday, May 08, 2014 07:00:42 AM Adam Smith wrote:
> > 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
>
