SepakoRayl 2017-03-03 08:45:42
Jgiyo
SepakoRayl 2017-03-03 08:46:14
that was VimFx :(
monochrom 2017-03-03 08:46:39
So you meant "yo", right?
SepakoRayl 2017-03-03 08:47:50
yup, what's everyone doing
monochrom 2017-03-03 08:48:13
We got off-topic a bit, then it died.
shapr 2017-03-03 08:50:31
greetings SepakoRayl, how's code? Tried opaleye yet?
Athas 2017-03-03 08:52:00
Is it generally considered a good or a bad thing that Prelude.union or Data.Map.union is left-biased in case of duplicates?
SepakoRayl 2017-03-03 08:52:02
nope! I'll check it out after I am done with my parser
monochrom 2017-03-03 08:52:31
Yes Athas.
Athas 2017-03-03 08:52:50
Is it generally considered a bad thing that Prelude.union or Data.Map.union is left-biased in case of duplicates?
monochrom 2017-03-03 08:52:52
At least for people who are used to left-to-right mother tongues.
monochrom 2017-03-03 08:53:19
I mean a good thing.
Athas 2017-03-03 08:53:46
Really? I'd assume that left-to-right-readers would conclude the _last_ statement to be the true one.
monochrom 2017-03-03 08:54:23
Ah.
Tuplanolla 2017-03-03 08:54:44
I'm sure there's a connection to `foldr` here, Athas.
monochrom 2017-03-03 08:54:57
Dunno. But looks like people have settled for it.
Athas 2017-03-03 08:55:00
I suspect the reason is that if you implement an association table as a list, and 'lookup' picks the first match, then union is just concatenation.
Athas 2017-03-03 08:56:00
But it never made much sense to me. I've memorised it for Data.Map.union, but I recently got tripped up by the fact that `mappend` for Data.Map.Map is also left-biased! (Because it is synonymous with union.)
nitrix 2017-03-03 08:56:05
Wouldn't concatenating the two lists risk creating duplicates though?
nitrix 2017-03-03 08:56:15
This doesn't sound like union.
Athas 2017-03-03 08:56:23
Sure, but the lookup function picks the first one it sees.
nitrix 2017-03-03 08:57:22
Ah that's interesting.
nitrix 2017-03-03 08:57:48
"Note that the implementation is left-biased -- the elements of a first argument are always preferred to the second, for example in union or insert."
Theophane 2017-03-03 08:58:00
*left-padded
Theophane 2017-03-03 08:58:01
:P
Athas 2017-03-03 08:58:16
At least that behaviour is consistent among all Haskell libraries I've used.
monochrom 2017-03-03 08:58:22
You have to break ties and someone has to pick a convention and the rest of us have to suffer it. It can't be helped.
Athas 2017-03-03 08:58:27
But I was considering whether to adopt the same design for a non-Haskell language.
Athas 2017-03-03 08:58:56
Sure, I was just wondering whether it's (in hindsigt) considered a good idea, for a clean-slate environment.
monochrom 2017-03-03 08:58:56
Make a poll in the community :)
mauke 2017-03-03 08:59:00
perl effectively is right biased
Athas 2017-03-03 08:59:07
I'd never do a Haskell library that didn't follow this convention.
Tuplanolla 2017-03-03 09:00:15
> fold [Just "yes", Nothing, Just "no"] -- Would you consider this left-biased too, Athas?
lambdabot 2017-03-03 09:00:20
Just "yesno"
Athas 2017-03-03 09:01:06
Well, I meant for functions called "union".
Tuplanolla 2017-03-03 09:01:42
Yes, but the question is whether the left-bias is somehow more universal or intrinsic to the language.
nitrix 2017-03-03 09:02:45
I'd prefer a unionWith.
dolio 2017-03-03 09:03:10
That exists.
nitrix 2017-03-03 09:03:29
I meant for his language design.
Athas 2017-03-03 09:03:51
That's not really an option here. It's for record concatenation, and what happens in the case of duplicate field names.
nitrix 2017-03-03 09:04:42
Athas: That sound very dynamically typed.
nitrix 2017-03-03 09:05:04
If so, maybe you could merge the two fields by creating another object/record that contains the two values under the same key.
nitrix 2017-03-03 09:06:42
{a = 1, b = 2} `union` {b = 3, c = 4} == {a = 1, b = [2,3], c = 4}
EvanR 2017-03-03 09:07:21
i like "extensible records with scoped labels"
EvanR 2017-03-03 09:07:41
{a = 1, b = 2} union {b = 3, c = 4} ==> {a = 1, b = 2, b = 3, c = 4}
nitrix 2017-03-03 09:08:13
data Record = Record { a :: Element Int, b :: Element Int }; data Element a = Such a | Many [a]
Athas 2017-03-03 09:08:21
Ah, but an important use case is for record updates. {a = 1, b = 2} `union` {b = 3} == {a = 1, b = 3}.
Athas 2017-03-03 09:08:21
This form of concatenation subsumes record updates, which I find elegant.
dolio 2017-03-03 09:08:23
Why do you think the right side is the update?
EvanR 2017-03-03 09:08:30
it also loses something
mauke 2017-03-03 09:09:00
dolio: because I read from left to right, so the left side happens earlier
EvanR 2017-03-03 09:09:04
theres a different abstraction for talking about updates
Athas 2017-03-03 09:10:07
mauke: that's a good point. However, in most use cases, the left-hand side will be a record-typed variable: rv `union` {b = 3} == {a = 1, b = 3}.
Athas 2017-03-03 09:10:13
I find that this reads nicely, and is close to Haskell's own 'rv { b = 3 }' notation.
EvanR 2017-03-03 09:11:10
union seems to evoke something completely different from updating to me
Tuplanolla 2017-03-03 09:11:22
The lens order would be `set id new old`, Athas.
EvanR 2017-03-03 09:11:34
actually, replacement strategies seem totally off topic for union
EvanR 2017-03-03 09:12:13
were talking about record concatenation
EvanR 2017-03-03 09:12:20
so <>
nitrix 2017-03-03 09:12:25
Now that I think about it, merging them into a list has no benefits. It makes the language more comlicated and there's no practical use of "keeping both sides" as it's immutable and you can just write "b `union` a" rather than "a `union` b" if that's what you want.
EvanR 2017-03-03 09:12:51
nitrix: there is a benefit, as described in the paper
EvanR 2017-03-03 09:12:57
for extensible records and variants
Mortenl 2017-03-03 09:13:03
I'm trying to create a new Stack project using 'stack new my-project simple', but when I try to build it it fails with "Invalid package ID: "array-0.5.1.1 base-4.9.0.0 binary-0.8.3.0 bytestring-0.10.8.1". Using Ubuntu 16.04, any ideas what's wrong?
dolio 2017-03-03 09:13:59
EvanR: That's allowing duplicate fields, though. Not allowing duplicate fields but having the types of fields change if there are duplicates in a union is different (and probably unnecessarily complicated).
EvanR 2017-03-03 09:14:51
were changin the types of fields?
dolio 2017-03-03 09:14:51
In nitrix's example, yes.
EvanR 2017-03-03 09:14:51
agreed
nitrix 2017-03-03 09:15:13
Depends. I corrected myself with an `Element` type that allowed multiple values.
nitrix 2017-03-03 09:15:24
I'm not too sure where it's headed though.
EvanR 2017-03-03 09:15:58
rather than duplicate you could think of it as scoped, or temporal
monochrom 2017-03-03 09:15:58
You need quantum superposition.
nitrix 2017-03-03 09:16:09
Maybe the field values all have to be monoids :D !?
EvanR 2017-03-03 09:17:11
monoid hammer
monochrom 2017-03-03 09:17:47
quantum states form a monoid. mappend is vector addition.
nitrix 2017-03-03 09:19:50
data Record = forall a b. (Monoid a, Monoid b) => Record { a :: a, b :: b }
nitrix 2017-03-03 09:20:03
Fixed it !
EvanR 2017-03-03 09:20:03
semigroup?
nitrix 2017-03-03 09:20:27
Mhhh... oh yeah.
nitrix 2017-03-03 09:20:48
I have no clue how practical that'd be but it's fun to think about.
byorgey 2017-03-03 09:23:03
that looks... not very practical.
byorgey 2017-03-03 09:23:19
you can put things in and combine them, as long as you never want the values back out.
nitrix 2017-03-03 09:26:07
EvanR: With a Monoid you could have {} initialize your record, a problem haskell suffers with the record syntax setting all the fields to undefined.
nitrix 2017-03-03 09:27:00
I think I would've liked that answer until knowing Haskell where magical default values became a big no-no.
nitrix 2017-03-03 09:27:11
I'd rather have an ADT now.
Ptival_ 2017-03-03 09:38:40
does anyone understand how to use NonEmpty in SmallCheck?
