On Wed, Apr 22, 2015 at 9:25 AM, Maik Schünemann
wrote:
> Andy Fingerhut writes:
>
> > As a silly example, if one gets to define their own equals for lists,
> > and you decide to define lists as equal if they contain the same
> > number of items, e.g. the list (1 2 3) is equal to the list (4 5 6
Speaking of definitions of equality:
Writing a university project jvm to llvm 'compiler', I found myself
designing a type in Haskell whose Ord and Eq instances 'naturally' got
defined in such a way that "less than AND equal to" made sense. I doubt
anyone's sanity except mine survived the project.
Andy Fingerhut writes:
> Dave, you say "seq on a set cannot be pure unless you were to provide an
> argument to explicitly specify which order the items should be in".
>
> I think I would instead say: seq *is* a pure function, even though it
> violates the property of "x equals y implies f(x) equ
yes - ok - I agree with that.
I don't see this as a problem with the definition of equality.
D
On Thursday, 23 April 2015 00:40:20 UTC+10, Hannes Steffenhagen wrote:
>
>
> This. x = y => f(x) = f(y) obviously doesn't hold for arbitrary functions
> and arbitrary notions of equality (e.g. all se
>
> This is exactly one of the reasons a bunch of folk ( aka, purests maybe )
> don't like that map/filter etc. in Clojure convert the input collection
> into seqs, unlike Haskell or others where the those monad laws keep you in
> check that map/filter return the *same* container - so mapping a
This. x = y => f(x) = f(y) obviously doesn't hold for arbitrary functions
and arbitrary notions of equality (e.g. all sets that contain the same
elements are equal, but the structures used to implement 'equal' sets need
not be equal themselves). So if you then introduce a function that derives
Dave, you say "seq on a set cannot be pure unless you were to provide an
argument to explicitly specify which order the items should be in".
I think I would instead say: seq *is* a pure function, even though it
violates the property of "x equals y implies f(x) equals f(y)". There is
nothing impur
one thought - (set (seq a-set)) is pure even is (seq a-set) is not -
because (set a-seq) throws away the (random) order information that was
added.
Dave
On Wednesday, 22 April 2015 19:03:23 UTC+10, Mark Derricutt wrote:
>
> On 22 Apr 2015, at 20:22, Dave Sann wrote:
>
> for example: seq on a s
On 22 Apr 2015, at 20:22, Dave Sann wrote:
> for example: seq on a set cannot be pure unless you were to provide an
> argument to explicitly specify which order the items should be in. If you do
> not do this, the order is defined either by some random interaction of the of
> the data and funct
On 22 April 2015 at 10:22, Dave Sann wrote:
> "x is equal to y" to imply "f(x) is equal to f(y)" - can only be true where
> a function is really based only on its arguments. I hadn't considered this
> before - while it seems simple, it is also a bit subtle.
>
> for example: seq on a set cannot be
"x is equal to y" to imply "f(x) is equal to f(y)" - can only be true where
a function is really based only on its arguments. I hadn't considered this
before - while it seems simple, it is also a bit subtle.
for example: seq on a set cannot be pure unless you were to provide an
argument to exp
One thing I was surprised by in my investigation was the lengths that some
people are willing to go to in order to avoid such things.
Some people seem to *really* want the property "x is equal to y" to imply
"f(x) is equal to f(y)" for all functions, without exception, and consider
it a bug if a s
Just to expand on this slightly - seq applied to a set must introduce an
order that is not present in the set. This order in principle comes from
nowhere in the data. But it does in practice come from some arbitrary
decisions in the implementation. Maybe this was andy's point.
On Wednesday, 22
Agree it's an interesting writeup.
I think that the behaviour of seq should be entirely expected though. Sets
have no ordering (logically) so turning them into an ordered sequence
should be considered to be an entirely arbitrary operation (unless specific
guarantees are provided). The fact that
Thanks for sharing this. I found the write-up to be very informative and
to have good background sources.
I certainly never thought about this sneaky behavior concerning `seq` and
hash sets before now. I'll have to look out for that one!
On Tuesday, April 21, 2015 at 8:13:48 PM UTC-5, Andy
15 matches
Mail list logo