sternmull 2017-02-08 10:47:37
is there a good and portable regex package?
fsestini 2017-02-08 10:48:26
geekosaur: so when the compiler says the ambiguity prevents Read a from being solved, should i interpret it as 'you won't be able to solve it in any way' or something like that?
geekosaur 2017-02-08 10:48:48
regex-tdfa is good, portable, and slow. the others are faster but generally not portable and sometimes not good (e.g. the pcre one is dependent on your having a pcre library built with utf8 support)
sternmull 2017-02-08 10:49:18
ok, thanks
geekosaur 2017-02-08 10:49:19
fsestini, you cannot solve it from outside of f (unless you enable TypeApplications and annotate every call to f)
geekosaur 2017-02-08 10:52:40
fsestini, this is a general issue with typeclasses. lots of things can lead the compiler to not be able to pick appropriate instances; sometimes you can fix this with a type ascription, but with `f` as defined you can't do that *when calling f*. TypeApplications can in that case (and a few other messy cases) but you have to use it every time... and it becomes a question of whether `f` is worth writing if you have to annotate every single usage
dfeuer 2017-02-08 10:54:51
:t mapMaybeM
lambdabot 2017-02-08 10:54:53
error:
lambdabot 2017-02-08 10:54:53
• Variable not in scope: mapMaybeM
lambdabot 2017-02-08 10:54:53
• Perhaps you meant one of these:
fsestini 2017-02-08 10:54:58
geekosaur: i think what confused me is that from the error messages, it seemed to me that the compiler was trying to instantiate the type var, or the type class, at the point or declaration of f, rather than when using it
geekosaur 2017-02-08 10:55:15
yes, because it;s not accessible when you use it
geekosaur 2017-02-08 10:56:04
(again, unless you enable TypeApplications --- but I don't know that the current instance resolution stuff is smart enough to take that into account if you have it enabled)
monochrom 2017-02-08 10:56:05
If the type variable still existed in the overall type, yes the compiler can keep its contraint and defer to the users.
monochrom 2017-02-08 10:56:25
But you still haven't answered where does the letter "a" appear in "String -> String".
fsestini 2017-02-08 10:57:28
monochrom: it doesn't, but just deferring the instantiation of a seemed reasonable to me
geekosaur 2017-02-08 10:57:32
what monochrom said is the key point; if "a" were visible then the compiler could defer the type
geekosaur 2017-02-08 10:57:51
since it is not, it has no choice but to resolve it because there is no "hook" for the use site to control it
fsestini 2017-02-08 10:58:34
geekosaur: so if a constrained variable is ambiguous, that is not appearing in the type, the compiler tries to resolve the constraint at the point of declaration?
monochrom 2017-02-08 10:58:34
Do not value "seem reasonable" so much. Design and implement a type system that does what you said. You will see the issues, at the very least the trade-off issues.
fsestini 2017-02-08 10:58:39
i didn't know that
fsestini 2017-02-08 10:58:46
i think this clarifies
monochrom 2017-02-08 10:59:10
A lot of unsatiable human desires seem reasonable at various points to various people.
geekosaur 2017-02-08 10:59:10
fsestini, it does, because it knows there is nowhere else that it can be resolved
fsestini 2017-02-08 10:59:17
monochrom: i think i always has something like system f with explicit dictionary passing in mind
geekosaur 2017-02-08 10:59:28
the definition of f knows everything that will ever be known about the type of a
monochrom 2017-02-08 10:59:42
System F is an unfair comparison because System F doesn't even try inference.
monochrom 2017-02-08 11:00:14
And your current example does exploit inference. You are not annotation types left right and centre.
monochrom 2017-02-08 11:01:14
Also I am not convinced that Haskell type classes are equivalent to dictionary passing. For one thing the imaginary dictionary is not even exposed in any way.
fsestini 2017-02-08 11:02:20
monochrom: i mean that in my mind, it should have made sense to accept a type that was acceptable in a system f with explicit dictionaries
monochrom 2017-02-08 11:02:24
(Do not harp "that's how the compiler does it underneath" to me. Does Haskell also expose the quantum mechanics at the silicon level which is "how every computer today does it" too?)
fsestini 2017-02-08 11:02:43
because a constrained type is in the end a function type, where that 'a' appears
monochrom 2017-02-08 11:05:25
Haskell is not System F. If you want System F you should use System F directly.
monochrom 2017-02-08 11:06:16
There are going to be a million other things that make sense in System F but simply banned in Haskell even after turning on all extensions.
ph88 2017-02-08 11:06:29
we need more extensions
monochrom 2017-02-08 11:07:31
I used to hold disbelief at people who just assumed that Haskell could do highschool algebra simply because the syntax looks so like math notation.
monochrom 2017-02-08 11:07:52
"If I defined 'x = 2*x' shouldn't the computer figure out I want x=0?"
monochrom 2017-02-08 11:08:15
It makes total sense in Mathematica, you know.
fsestini 2017-02-08 11:08:30
monochrom: i'm aware that haskell in not system f
monochrom 2017-02-08 11:08:32
But Haskell is neither Mathematica nor System F.
fsestini 2017-02-08 11:09:01
i just though that example function should have been typecheckable anyway
ph88 2017-02-08 11:09:21
not too long ago i believed monads had build-in reflection and whatnot so i'm not surprised about the x = x*2
fsestini 2017-02-08 11:11:25
the thought being, how is forall a . Read a => String -> a different from forall a . (Read a, Show a) => String -> String, since in both cases a is determined by the caller?
fsestini 2017-02-08 11:11:50
but i didn't know that the compiler tries, rightfully in this case, to instantiate ambiguous type variables right away
monochrom 2017-02-08 11:11:58
But you didn't write "forall a . (Read a, Show a) => String -> String". You wrote "String -> String". Your own code.
ph88 2017-02-08 11:12:23
fsestini, i thought the part before the => (forgot what it was called) needs to be proven before anything is done with control flow
fsestini 2017-02-08 11:12:51
monochrom: my answer was "why it is not acceptable to infer (Read a, Show a) => String -> String for show . read"
fsestini 2017-02-08 11:13:13
(without MR)
monochrom 2017-02-08 11:13:22
I don't know. But I would answer "have you written a type inferer that does it?"
monochrom 2017-02-08 11:13:30
Or maybe rather s/answer/ask/
fsestini 2017-02-08 11:13:50
sorry, that was *question
monochrom 2017-02-08 11:13:55
There are trade-offs and you may like or not like what you're giving up for what you want.
monochrom 2017-02-08 11:14:22
So much for armchair type inference.
fsestini 2017-02-08 11:14:59
monochrom: does haskell already infer that type, but then discards it when not able to resolve the constraints?
fsestini 2017-02-08 11:16:46
ph88: that's true. my objection with this example was: shouldn't it be a problem at call site?
dolio 2017-02-08 11:17:00
Types like `forall a. C a => T` are unacceptable in Haskell because there is no way in the language to ever specify what `a` is. So they must be resolved in the spot where they'd occur.
ph88 2017-02-08 11:18:35
fsestini, at least the compiler message could be a bit more clear about it :/
dolio 2017-02-08 11:18:37
Where `a` doesn't occur in `T`, that is.
fsestini 2017-02-08 11:18:47
dolio: or rather, haskell's design decision is to resolve them immediately
geekosaur 2017-02-08 11:18:49
and the answer was: that'd be great, if the call site had any way at all to say what `a` is. but `a` is hidden inside `f` and the call site can't see it much less control it
geekosaur 2017-02-08 11:19:16
`a` has to be exposed in the type of `f` for the call site to have any say
fsestini 2017-02-08 11:20:06
geekosaur: in that case 'a' and its constraints would be added to the type of the expression where f is used
fsestini 2017-02-08 11:20:19
but i agree that this does not make much sense
fsestini 2017-02-08 11:20:39
just what a blind type inference would do, i guess
dolio 2017-02-08 11:27:10
Haskell specifies that they must be resolved in the spot they occur.
dolio 2017-02-08 11:28:10
And it is good that it does so.
CuriousErnestBro 2017-02-08 11:29:09
Haskell is so much fun :)
fsestini 2017-02-08 11:29:41
dolio: yes, it definitely makes sense. i just wanted a confirmation that it is indeed a design decision, not something that must be done because otherwise semantic issues occur
dolio 2017-02-08 11:31:08
One could write a compiler that never reports type errors when it detects that two types don't match, and instead carries around unsatisfiable equality constraints, but it would probably not be pleasant to use.
dmwit 2017-02-08 11:37:14
fsestini: You may also like: -XAllowAmbiguousTypes, -fdefer-type-errors
fsestini 2017-02-08 11:41:00
dmwit: actually i'm ok with the default behaviour, just wanted to understand it more. but thanks
fsestini 2017-02-08 11:41:12
also for some reason it does not type check even with that enabled
dmwit 2017-02-08 11:42:11
WFM
fsestini 2017-02-08 11:42:59
oh, it does in ghci but not on the emacs buffer i have open
fsestini 2017-02-08 11:43:15
w/e
dmwit 2017-02-08 11:43:38
Perhaps this satisfactorily answers your "Can it be done?" question satisfactorily.
dmwit 2017-02-08 11:43:51
Oops. That sentence was way too satisfied with itself.
