Richard,
I'm interested by your argument at the bottom of the wiki page about
the alternative (non-)solution of disallowing non-linear patterns
altogether. I'll quote it for reference:
One way we (Simon, Dimitrios, and Richard) considered proceeding was
to prohibit nonlinear unbranched
insta
Richard,
Thanks for your answers.
2013/6/24 Richard Eisenberg :
>
> The nub of the difference is that type families can pattern-match on kinds,
> whereas term-level functions cannot pattern-match on types. So, while the @a
> is repeated in the pattern as written above, GHC does not, when matching
I think it's a good idea to push forward on the records design because
it seems futile to hope for an ideal consensus proposal.
The only thing I dislike though is that dot notation is special-cased to
record projections. I would prefer to have dot notation for a
general, very tightly-binding reve
Simon,
Yes, your summary is exactly what I meant.
2013/6/26 Simon Peyton-Jones :
> In fact, your observation allows us to regard our proposal as consisting of
> two entirely orthogonal parts
> * Generalise the type of record field selectors
> * Introduce period as reverse function applicatio
Simon,
I see your point. Essentially, the original proposal keeps the
namespace for field names syntactically distinguishable from that of
functions, so that the type given to "r.foo" doesn't depend on what is
in scope. (.foo) is always defined and it is always a function of
type "(r { foo::t })
Perhaps an alternative for this could be extending McBride's idiom brackets:
https://personal.cis.strath.ac.uk/conor.mcbride/pub/she/idiom.html
with a form of top-level let, something like:
(| let x = expr1
y = expr2
z = expr3
in x*y + y*z + z*x |)
=
pure (\x y z -> x*y + y*z
Merijn,
Perhaps only for the sake of discussion: have you considered doing
something at the type-level instead of using TH? I mean that you could
change the type of 42 from `forall a. Num a => a` to `forall a.
HasIntLiteral a '42 => a` where HasIntegerLiteral is a type class of
kind `* -> 'Integer
Hi Merijn,
2015-02-06 13:45 GMT+01:00 Merijn Verstraaten :
> I don't see how that would replace the usecase I describe?
I've written out the Even use case a bit, to hopefully clarify my
suggestion. The code is a bit cumbersome and inefficient because I
can't use GHC type-lits because some type-l
2015-02-06 14:20 GMT+01:00 Adam Gundry :
> It seems to me that what you would describe would work, and the
> avoidance of TH is a merit, but the downside is the complexity of
> implementing even relatively simple validation at the type level (as
> opposed to just reusing a term-level function). For
