Skip to content

Macro to display model struct the way Flux does #2044

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ericphanson opened this issue Aug 22, 2022 · 2 comments · Fixed by #1932
Closed

Macro to display model struct the way Flux does #2044

ericphanson opened this issue Aug 22, 2022 · 2 comments · Fixed by #1932

Comments

@ericphanson
Copy link
Contributor

ericphanson commented Aug 22, 2022

Semi-related to #2043 😄. Custom model structs use

@functor MyModel

to define Functors.children etc. It would be nice if there was also

@define_layer_show MyModel

to generate a method for Base.show, like

using Flux
function Base.show(io::IO, m::MIME"text/plain", x::MyModel)
    if get(io, :typeinfo, nothing) === nothing  # e.g. top level in REPL
      Flux._big_show(io, x)
    elseif !get(io, :compact, false)  # e.g. printed inside a Vector, but not a Matrix
      Flux._layer_show(io, x)
    else
      show(io, x)
    end
  end
end

Alternatives:

  • I guess this could also be built into @functor but I suspect it might be better to keep it separate/ opt-in so you can define your own show method if you want. Also, adding it to @functor would also presumably be breaking since folks may have custom show methods already and that would generate method overwrite warnings and possibly break precompilation.
  • This could be done with an abstact type, but I think it's nice if folks are free to have their model partipicate in their own type hierarchy. But an abstract type seems OK too.
@mcabbott
Copy link
Member

I had a go in #1932 .

But right now I think a supertype like #2028 might be cleaner than having an ever-expanding the zoo of things you ought to invoke for good behaviour. Do you know of examples in the wild where the type hierarchy would clash?

@ericphanson
Copy link
Contributor Author

Do you know of examples in the wild where the type hierarchy would clash?

No, I don't.

But right now I think a supertype like #2028 might be cleaner than having an ever-expanding the zoo of things you ought to invoke for good behaviour.

Yeah, that makes sense. I actually do like the idea of a supertype to opt into nice fallbacks for common features; I think it's most problematic when it's a required part of the interface and you can't use Flux otherwise (rather than opting into some features). There's also always the wrapper thing of

struct MyModel{M<:FluxSuperType} <: MyCustomSuperType
    flux_model::M
end

folks can use if they need to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants