> On 18 Sep 2021, at 04:29, Anthony Clayden wrote:
> "InstanceSigs is a mis-feature. Don't use it. It is less confusing to just
> give no signature at all. If you really, really want to bind tyvars, use
> PatternSignatures."
I would strongly disagree with this statement. I think instance
Hi Adam,
On 9 Feb 2015, at 17:44, Adam Gundry a...@well-typed.com wrote:
In the absence of a coherent story for polymorphism, I think the right
thing to do is to be able to specify a particular validator, rather than
try to have type inference determine a monomorphic type and otherwise
get
Hi Adam,
On 6 Feb 2015, at 21:31, Adam Gundry a...@well-typed.com wrote:
What does all monomorphic cases mean? Is the idea what GHC
would typecheck an expression involving a literal integer, determine
that the occurrence had type Even, then evaluate the TH splice *after*
typechecking?
as $$(validate 38). But it's still noisy.
So: what is the non-noisy scheme you want to propose? You don't quite get to
that in the wiki page!
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Merijn
| Verstraaten
| Sent: 05 February 2015
While I am certainly in favour of better and more flexible approaches to
enforcing this in the type system (I'm a big fan of all the dependent
Haskell/singletons stuff), I don't think this is an appropriate solution here.
First off, a lot of interesting and important cases can't feasibly be
haven't thought this through very far, so there may be other
advantages/disadvantages/glaring-holes-in-the-idea that I'm missing.
Regards,
Dominique
2015-02-06 11:07 GMT+01:00 Merijn Verstraaten mer...@inconsistent.nl:
And no one of my proofreaders noticed that .
I would propose to have
Ryan,
Unfortunately, yes, you are understanding that correctly.
The reason I qualified it with monomorphic only is that, I want to avoid
breakage that would render the extension practically unusable in real code.
Let's say I right now have:
foo :: Num a = [a] - [a]
foo = map (+1)
I have two
I've been repeatedly running into problems with overloaded literals and partial
conversion functions, so I wrote up an initial proposal
(https://ghc.haskell.org/trac/ghc/wiki/ValidateMonoLiterals) and I'd like to
commence with the bikeshedding and hearing other opinions :)
Cheers,
Merijn
Typed holes is not an extension, because it's considered a warning/error. The
reason for this is that code with typed holes is NOT valid haskell to begin
with, therefore the behaviour doesn't conflict with any description in the
report.
Additionally, the ability to disable the typed holes
Hi Simon,
Thanks for the comments. I think most of the confusion stems from people
overthinking the scope of what I was proposing. I'll clear up the page a bit as
it's currently conflating implementation details with semantics.
On 14 Nov 2014, at 2:29, Simon Peyton Jones simo...@microsoft.com
On 16 Nov 2014, at 14:09, Simon Peyton Jones simo...@microsoft.com wrote:
Thanks. Can you make sure that you update the wiki page to reflect what you
say here? Email is transitory; the wiki page gives the *specification* of
the feature, and says unambiguously what you intend.
As requested on my ticket I summarised the entire proposal on the wiki here:
https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension
I don't expect a lot of disagreement on discussion, aside from minor bike
shedding on the flavour of the extension. I've started implementing this
Strong +1 from me, this is *especially* annoying when you want to selectively
re-export parts of a module from somewhere or in case of exports generated by
TH.
Cheers,
Merijn
On 26 Oct 2014, at 12:28, Tom Murphy amin...@gmail.com wrote:
(Not to be confused with the hiding import behavior
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
when testing Tom's shiny new version.
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Merijn Verstraaten
| Sent: 03 September 2014 06:59
| To: GHC Users List
| Subject: GHC not able to detect
I’ve been trying to stretch GHC’s type system again and somehow managed to get
myself into a position where GHC warns about a non-exhaustive pattern where
adding the (according to GHC) missing pattern results in a type error (as
intended by me). It seems that even with closed type families GHC
+lhs pattern/convention is a good one, and
prevents any misinterpretations that current plague literate tools + willl be
treated as an unknown format rather than eagerly as .format or .lhs
On Sat, Aug 16, 2014 at 5:05 PM, Merijn Verstraaten mer...@inconsistent.nl
wrote:
Hey Philip
+lhs pattern/convention is a good one, and
prevents any misinterpretations that current plague literate tools + willl be
treated as an unknown format rather than eagerly as .format or .lhs
On Sat, Aug 16, 2014 at 5:05 PM, Merijn Verstraaten mer...@inconsistent.nl
wrote:
Hey Philip
to the bit-rot of the flag to
employ external unlitters. I didn't quite understand that objection, but
didn't pursue it)
Regards,
Philip
Van: Glasgow-haskell-users glasgow-haskell-users-boun...@haskell.org namens
Merijn Verstraaten mer
to the bit-rot of the flag to
employ external unlitters. I didn't quite understand that objection, but
didn't pursue it)
Regards,
Philip
Van: Glasgow-haskell-users glasgow-haskell-users-boun...@haskell.org namens
Merijn Verstraaten mer
2014, at 05:56 , Merijn Verstraaten mer...@inconsistent.nl wrote:
Ola!
I didn't know what the most appropriate venue for this proposal was so I
crossposted to haskell-prime and glasgow-haskell-users, if this isn't the
right venue I welcome advice where to take this proposal.
Currently
2014, at 05:56 , Merijn Verstraaten mer...@inconsistent.nl wrote:
Ola!
I didn't know what the most appropriate venue for this proposal was so I
crossposted to haskell-prime and glasgow-haskell-users, if this isn't the
right venue I welcome advice where to take this proposal.
Currently
Cross-post to haskell-prime in case there's any interest for including this
into the report's FFI specification.
Proposal - Foreign enum support
===
At the moment the FFI does not have a convenient way with interacting enums
(whether proper enums or CPP defines) in C
Ola!
I didn't know what the most appropriate venue for this proposal was so I
crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right
venue I welcome advice where to take this proposal.
Currently the report does not specify the mapping between filenames and module
My personal approach would have been to make ghc accept Foo.*.lhs,
maintaining a list of potential file format seems arduous and error prone.
Cheers,
Merijn
On Mar 16, 2014, at 14:13 , Joachim Breitner wrote:
Hi,
Am Sonntag, den 16.03.2014, 13:56 +0100 schrieb Merijn Verstraaten:
Cons
.
-Edward
On Sun, Mar 16, 2014 at 8:56 AM, Merijn Verstraaten mer...@inconsistent.nl
wrote:
Ola!
I didn't know what the most appropriate venue for this proposal was so I
crossposted to haskell-prime and glasgow-haskell-users, if this isn't the
right venue I welcome advice where to take
Ola!
I didn't know what the most appropriate venue for this proposal was so I
crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right
venue I welcome advice where to take this proposal.
Currently the report does not specify the mapping between filenames and module
.
-Edward
On Sun, Mar 16, 2014 at 8:56 AM, Merijn Verstraaten mer...@inconsistent.nl
wrote:
Ola!
I didn't know what the most appropriate venue for this proposal was so I
crossposted to haskell-prime and glasgow-haskell-users, if this isn't the
right venue I welcome advice where to take
Lectori salutem,
What is the actual state of ImpredicativeTypes? It appears documented as a
properly finished GHC extension, but on IRC and other places I keep hearing
it's poorly tested, buggy or incomplete. Is this true or just FUD?
Cheers,
Merijn
signature.asc
Description: Message signed
On Feb 6, 2014, at 10:33 , Christian Maeder wrote:
or (as I've seen elsewhere) better (?)
#!/usr/bin/env bash
Definitely use this, FreeBSD (for example) does not ship with bash so /bin/bash
will *not* exist.
Cheers,
Merijn
signature.asc
Description: Message signed with OpenPGP using
I was trying to fix one of my closed type families examples for the new syntax,
and run into an unfortunate issue. Due to a kind error in my code one of my
constraints was being silently discarded (see ticket:
https://ghc.haskell.org/trac/ghc/ticket/8669)
The main reason I resorted to this (in
this. Is there a specific reason for not allowing this syntax?
Cheers,
Merijn Verstraaten
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
32 matches
Mail list logo
