May aswell define == and hash along with show

[jkroso]

No description provided.

[cstjean]

Why? My reasoning for defining show is that without show,

using QuickTypes
@qtype Foo(x; y=10, _define_show=false)
Foo(3)
> Foo(3, 10)

and typing Foo(3, 10) doesn't work (intentionally) for constructing the type. Foo(3; y=10) works, so that's what we show. It's in line with what Base does.

[jkroso]

Well with immutable types == and hash always end up being defined the same way so it makes sense to just do it for you. For mutable types the default methods for == and hash are already spot on though.

[cstjean]

Sorry, I don't understand. @qimmutable doesn't define ==, so we get the standard immutable equality comparison. Are you saying that you disagree with the way == and hash are defined for immutables in Julia? Could you give some code showing how hash/== should be implemented?

[jkroso]

Yea I mean when users define ==/hash they always do it the same way. So yea I think Julia should actually handle immutable types differently for == and hash.

• how I define == when I do it manually
• with a macro

[cstjean]

Isn't that what Julia does already?

immutable Foo
    x
    y
end

Foo(Foo(2,3), 4) == Foo(Foo(2,3), 4)  # true

What's the difference with your macro?

[jkroso]

That works because it's a bits type. If you throw a string in there it will
return false
On Sun, 6 Nov 2016 at 4:24 PM Cédric St-Jean notifications@github.com
wrote:

Isn't that what Julia does already?

immutable Foo
x
yend
Foo(Foo(2,3), 4) == Foo(Foo(2,3), 4) # true

What's the difference with your macro?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDXtM5NC4LcZIq0z2Mfqdd0RTJCcqLWks5q7UiGgaJpZM4Km5me
.

[cstjean]

Right.

I agree with you that == is poorly-defined, at least at first glance. But QuickTypes' goal is to provide a more convenient syntax for defining types, without changing semantics. I like that its behaviour is "obvious" at the moment, and requires little-to-no explanation.

Both of your issues would be better addressed in Base, especially since 0.6 is going to be released in just two months. Or you could write a BetterTypes package, and start from QuickTypes' macros.

[cstjean]

@jkroso Just stumbled on the relevant Julia issue

[cstjean]

I've changed my mind; it would be a nice contribution to this package, as long as the behaviour is optional. Perhaps

@qstruct Foo(a, b)
@recursive_identity Foo

? It can expand into your defequals and defhash, although we should get rid of the @eval.