bitonic 2017-02-07 23:47:46
erisco: interesting historical note: when Haskell was designed, there was a big debate on whether tuples should behave like newtypes or not with this regard, see section 5.4 in
bitonic 2017-02-07 23:48:07
All in all it is definitely something to be aware of when programming in Haskell
erisco 2017-02-07 23:48:32
well, fine, if in your perspective these things matter than I cannot argue that. In mine they should not matter to a beginner
erisco 2017-02-07 23:49:56
I generally avoid anything that is too similar to something else
erisco 2017-02-07 23:50:08
take note at how much confusion there is on pattern matching lists, for example
bitonic 2017-02-07 23:50:17
Is there?
erisco 2017-02-07 23:50:20
yes
bitonic 2017-02-07 23:50:32
What's the point of confusion?
bitonic 2017-02-07 23:50:34
I mean
bitonic 2017-02-07 23:50:38
What confuses you?
erisco 2017-02-07 23:50:39
so last on my list is adding a second but only subtly different way of defining data
phadej 2017-02-07 23:51:04
we disagree on "subtly"
bitonic 2017-02-07 23:51:21
erisco: but they're not the same thing at all
erisco 2017-02-07 23:51:31
or we disagree on what qualifies as beginner material :P
bitonic 2017-02-07 23:51:32
And they serve a specific purpose
phadej 2017-02-07 23:51:43
it's almost as big as struct D { Foo *foo }; ofr struct N { Foo foo; }
bitonic 2017-02-07 23:52:22
erisco: what is rarely needed is `data Foo = Foo A`, I'll grant you that. But newtypes are very important
erisco 2017-02-07 23:52:46
okay, I disagree, sorry :P
erisco 2017-02-07 23:54:53
bitonic, http://stackoverflow.com/documentation/haskell/2281/lists#t=201702081054039105395&a=remarks
erisco 2017-02-07 23:55:10
I clarify most of the misconceptions there
erisco 2017-02-07 23:55:41
they are all based on mistakes I've seen
erisco 2017-02-07 23:56:23
and recalling learning Haskell, the overlap of brackets, commas, and colons was confusing
phadej 2017-02-07 23:58:14
but that's just syntax, the data and newtype are different "below" the syntax as well
bitonic 2017-02-07 23:58:21
erisco: so, the list type has two constructors: (:) and []. You can pattern match on them as you would with any data constructor, `a : (b : [])` etc. What's added is a shortcut to pattern match on whole lists using the syntax that you use to construct lists
erisco 2017-02-07 23:58:41
I wrote that section I linked to you
bitonic 2017-02-07 23:58:59
Would you prefer it to only be able to pattern match using `:` and `[]`? I find the full list pattern matching quite handy
bitonic 2017-02-07 23:59:25
But yes that's syntactic sugar that does not add expressiveness, while `newtype` does
erisco 2017-02-07 23:59:39
this isn't the point I am making. I am saying that having more than one way to do the same thing is confusing
phadej 2017-02-07 23:59:54
it's _not_ the same thing
bitonic 2017-02-07 23:59:55
erisco: well then you won't like Haskell's syntax, it's full of duplication
erisco 2017-02-07 23:59:55
things that look different but are the same, or just subtly different, leaves a lot of confusion
bitonic 2017-02-08 00:00:02
But this is not about `newtype`
bitonic 2017-02-08 00:00:08
`newtype` is not the same thing as `data`
erisco 2017-02-08 00:00:25
you're right that I have some qualms with Haskell's syntax but it is hard to complain given every other language in common use
bitonic 2017-02-08 00:00:26
While pattern matching using [a,b,c] is the same as pattern matching with (a : (b : (c : [])))
bitonic 2017-02-08 00:00:52
Some languages are really adamant about having non-redundant syntax, like Python. I think it's a non-problem
bitonic 2017-02-08 00:01:05
People are going to have difficulties learning Haskell for different reasons imo
erisco 2017-02-08 00:01:11
you are concluding newtype is not the same as data because there are differences. I am saying newtype is too difficult to distinguish from data because those differences are not in reach of a beginner
phadej 2017-02-08 00:01:52
well, I'd say it's beneficial to say "use newdata whenever you have single field single constructor data"
bitonic 2017-02-08 00:01:54
erisco: they're not in reach of a beginner because the beginner does not know Haskell yet. In the process of learning Haskell the differences will become apparent :)
erisco 2017-02-08 00:02:30
that's why I said that :P if you want a way to decide without knowing what you're doing then that is it
phadej 2017-02-08 00:02:58
yes, maybe it's possible to make syntax so the useful thing (i.e. newtype) is "the obvious", then in new languages we probably should
bitonic 2017-02-08 00:02:58
erisco: you gave a wrong rule of thumb though, phadej's suggestion is better even if you don't know what the difference is
erisco 2017-02-08 00:03:14
what was my rule of thumb? I said the very thing
bitonic 2017-02-08 00:03:23
erisco: to ignore `newtype` for now
erisco 2017-02-08 00:03:54
no, I first said exactly what phadej said and then added that you're fine just using data for now
erisco 2017-02-08 00:08:57
jle`, I am still not fully clear on it, but I think the inductive equality is an alright approach
erisco 2017-02-08 00:10:49
jle`, this will usually coincide with type equality but that is alright. Those proofs can uniquely be promoted to the context. However, there are potentially other equalities such as on * which is not the same as type equality
erisco 2017-02-08 00:11:26
and I suppose I enjoy the thoroughness of the inductive definitions *shrug*
athan 2017-02-08 00:14:12
Hey all, I asked a little while ago if it were "possible"[tm] to lens into a lens, so to speak
athan 2017-02-08 00:14:59
for instance, if I lens into some deep substructure, but in the middle there's an `nth` array element I'm getting to first, how could I modify the lens to change that `nth`?
athan 2017-02-08 00:15:17
I'm just postulating some ideas here, not looking for anything practically applicable
athan 2017-02-08 00:16:56
I feel like it /could/ be possible, if there was a god-aweful spanning tree at the type level or something, but I'm not sure
erisco 2017-02-08 00:17:06
not looking for anything practically applicable? you came to the right place :P
tabaqui1 2017-02-08 00:17:58
back to haskell Set
tabaqui1 2017-02-08 00:18:10
IntSet has no take/drop/splitAt methods
tabaqui1 2017-02-08 00:18:59
and I don't know how to implement them with O(log n) asymptotic using only library functions
tabaqui1 2017-02-08 00:19:19
because I cannot directly take left branch of a tree
athan 2017-02-08 00:19:25
tabaqui1: Can't you peek left and right pretty quickly though? hm
athan 2017-02-08 00:19:45
ahh shoot, you can always hack on it yourself though
erisco 2017-02-08 00:20:55
athan, I don't know much about lenses, but they're composable. If you had a way to get to the array, and a way to edit the nth element, those should compose
tabaqui1 2017-02-08 00:21:46
yesterday you've talked that IntSet has not fast "size" method, because we don't need it
halogenandtoast 2017-02-08 00:21:48
I'm coming into the middle of a conversation but `[1,2,3] ^? ix 0` gets an element
tabaqui1 2017-02-08 00:22:19
but when you implement any basic structure, like set, you have some objectives
tabaqui1 2017-02-08 00:22:50
f.e., set - is a structure with O(log n) complexity insert/query/delete operations
bartavelle 2017-02-08 00:24:02
athan, you want to combine an 'over' with a 'view' ?
athan 2017-02-08 00:24:24
bartavelle, erisco: not quite, it's more like treating the lens itself as data
tabaqui1 2017-02-08 00:24:32
and looks like your objectives contain "scan" function, and don't contain "size" and "take"
athan 2017-02-08 00:24:33
composing two functions make the result opaque
erisco 2017-02-08 00:24:53
well the lens is a function and so you can lens it as you would a function
athan 2017-02-08 00:24:56
I'll try and hack something, but it won't be pretty :|
athan 2017-02-08 00:25:08
oh woah, you can lens into functions?
bartavelle 2017-02-08 00:25:14
athan, yeah, if you have code that does what you want to do, that might help
athan 2017-02-08 00:25:19
I thought it was restructed to sums/products
erisco 2017-02-08 00:25:42
well I don't know the lens operators, but this is as trivial as (.)
athan 2017-02-08 00:25:45
erisco: Basically, the idea is recomposing a composition
bartavelle 2017-02-08 00:25:46
look at the 'to' combinator for example
athan 2017-02-08 00:26:09
so, if I have `a -> b` & `b -> c`, that makes `a -> c`, but if I want `b -> d` to replace, that should make `a -> d`
athan 2017-02-08 00:26:16
oh hm
erisco 2017-02-08 00:26:21
(.) edits the return, flip (.) edits the argument
bartavelle 2017-02-08 00:26:58
athan, you mean 'foo = ix 3 . ix 2', and you want 'changeEnd' so that changeEnd (ix 4) foo = ix 3 . ix 4 ?
bartavelle 2017-02-08 00:27:38
(if so I don't think that's possible)
athan 2017-02-08 00:28:20
bartavelle: Well, only if the lenses are functions though :)
athan 2017-02-08 00:28:27
I might be able to make something more data-oriented
bartavelle 2017-02-08 00:29:40
lenses from the lens package are functions
bartavelle 2017-02-08 00:29:57
that's why you can combine them with Prelude's (.)
erisco 2017-02-08 00:30:14
:t (.)
lambdabot 2017-02-08 00:30:17
(b -> c) -> (a -> b) -> a -> c
erisco 2017-02-08 00:30:31
interesting that this hasn't been generalised by Category yet
bartavelle 2017-02-08 00:30:47
imagine the error messages :/
erisco 2017-02-08 00:31:04
hey, they generalised a bunch of other stuff, but I guess Category is a class too far
athan 2017-02-08 00:31:28
erisco: I'm pretty sure it has, the identity lens is just function application for `over`, and get is `id`
bartavelle 2017-02-08 00:31:28
yeah, it would probably break too much code
athan 2017-02-08 00:32:21
bartavelle: I think I'll be doing a lot of type-level machinery to make it happen, which means I get to use GHC 8's Error type! So hopefully it will be... readable >.>
erisco 2017-02-08 00:32:41
I'm in favour of Prelude.ForDummies. I could use this for a number of packages :P
bartavelle 2017-02-08 00:32:51
athan, we were talking about the fact that there is an alternative definition of (.), with the Category type class
athan 2017-02-08 00:35:15
bartavelle: Oh! Derp, I thought that was integrated already :)
athan 2017-02-08 00:41:51
It looks like GHCJS doesn't have any releases on their repository... is it fully-compatible with GHC 7.10 or something? I'd just like to know what version of GHC it claims to mimick
