Re: Allow extra commas in module declarations or lists?

[MigMit]

I think that's the greatest idea since monads. Seriously.

Отправлено с iPad

> 11 июня 2016 г., в 21:12, Michael Burge  написал(а):
> 
> Some languages like Perl allow you to include additional commas in your 
> lists, so that you can freely reorder them without worrying about adding or 
> removing commas from the last or first item:
> 
> my @array = (
>   1,
>   2,
>   3,
> );
> 
> Perl even allows multiple redundant commas everywhere after the first 
> element, which is less useful but has come up on occasion:
> my @array = (1,,,2,3,);
> 
> I propose allowing an optional single extra comma at the end in module 
> declarations, record declarations, record constructors, and list constructors:
> 
> module Example (
>   module Example,
>   SomeConstructor(..),
>   ) where
> 
> data SomeConstructor = SomeConstructor {
>   foo :: Int,
>   bar :: Int,
> }
> 
> baz :: SomeConstructor -> SomeConstructor
> baz x = x {
>   foo = 5,
>   bar = 10,
> }
> 
> qux :: [ Int ]
> qux = [
>   1,
>   2,
>   3,
> ]
> 
> What do you think?
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[MigMit]

> On 25 Oct 2015, at 21:21, Joachim Breitner <m...@joachim-breitner.de> wrote:
> 
> Am Samstag, den 24.10.2015, 22:30 +0200 schrieb MigMit:
>> At the very least, "bound at" should help IDEs (Emacs in particular)
>> show exactly the right places.
> 
> an IDE that offers such a deep integration will hopefully not parse
> data meant for human consumption.

Hope is good. Reality, however, is different. At least haskell-mode in Emacs 
DOES parse such data, when you try to load your file in REPL.

> IDEs should ideally make use of something based on the GHC API.

I agree. But the key word here is "ideally".

Second thought though — do we really want to create a gap between error 
messages from the compiler and whatever IDE tells us? After all, text output 
from GHC is ALSO a kind of API.

> If that
> is not possible, then I’d advocate a flag, say "-fverbose-error-
> messages" or similar that includes all detail that might be relevant
> for an IDE, and maybe even in a nicer-to-parse format.

Doesn't seem worth it to me. Current format is quite parseable, and not really 
bad for human eyes either.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[MigMit]

> On 25 Oct 2015, at 21:45, Joachim Breitner <m...@joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Sonntag, den 25.10.2015, 21:30 +0100 schrieb MigMit:
>> Doesn't seem worth it to me. Current format is quite parseable, and
>> not really bad for human eyes either.
> 
> I know that you meant this as a litote,

Please, don't say "know" when you mean "assume". It's especially annoying when 
you assume wrong.

> but let me ignore that I know
> that for a moment to reply, that “not really bad” is definitely not
> good enough for me, and I want the compiler to print messages that are
> meant for my consumption to be in the _best_ possible format. Or at
> least try that.
> 
> Obviously, there is no “best” for every human. But things get easier if
> we do not have to overly worry about computers as well.

I think that's a wrong approach.

My theory is that the concepts "easy to read for a human with some experience" 
and "easy to parse for a computer" are two closely related notions.

Sure, they aren't identical — a binary format might still be quite easy to 
parse, but completely unreadable for human — but they go hand in hand. Even 
with binary formats — if, for example, there is a clear notion of "statement" 
in this binary formats, and statements are separated by the byte "0xff", it's 
easier both for a human (equipped with binary editor) and for a computer than, 
for example, if the length of the statement is determined by the first byte.

But! It's much easier to argue about "what's easier for a computer" than the 
same thing for humans.

> BTW, does Emacs really parse _this_ bit of information? Most GHC
> integrations that I have seen match on the first line to indicate the
> file and position of the overall error, and take the error verbatim.

Last time I checked, Emacs transformed such positions into hyperlinks.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[MigMit]

At the very least, "bound at" should help IDEs (Emacs in particular) show 
exactly the right places.

> On 24 Oct 2015, at 22:14, Evan Laforge  wrote:
> 
> Ok, ticket created.  I'll go see how much I can figure out on my own.
> 
> https://ghc.haskell.org/trac/ghc/ticket/11014
> 
> WRT the "bound at" bits in "relevant bindings", I have no strong opinion.  
> What about omitting them if they are in the same file as the main error?  Or 
> maybe they always are?  I'm not totally clear how it chooses which bindings 
> are relevant.
> 
> On Sat, Oct 24, 2015 at 12:50 PM, Simon Peyton Jones  
> wrote:
> I’m all for it.   Can advise.  (Make a ticket.)
> 
>  
> 
> Thanks!
> 
>  
> 
> Simon
> 
>  
> 
> From: Glasgow-haskell-users 
> [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Evan Laforge
> Sent: 24 October 2015 03:48
> To: GHC users
> Subject: type error formatting
> 
>  
> 
> Here's a typical simple type error from GHC:
> 
>  
> 
> Derive/Call/India/Pakhawaj.hs:142:62:
> Couldn't match type ‘Text’ with ‘(a1, Syllable)’
> Expected type: [([(a1, Syllable)], [Sequence Bol])]
>   Actual type: [([Syllable], [Sequence Bol])]
> Relevant bindings include
>   syllables :: [(a1, Syllable)]
> (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>   best_match :: [(a1, Syllable)]
> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)]))
> (bound at Derive/Call/India/Pakhawaj.hs:141:5)
> In the second argument of ‘mapMaybe’, namely ‘all_bols’
> In the second argument of ‘($)’, namely
>   ‘mapMaybe (match_bols syllables) all_bols’
> 
> I've been having more trouble than usual reading GHC's errors, and I finally 
> spent some time to think about it.  The problem is that this new "relevant 
> bindings include" section gets in between the expected and actual types (I 
> still don't like that wording but I've gotten used to it), which is the most 
> critical part, and the location context, which is second most critical.  
> Notice the same effect in the previous sentence :)  After I see a type error 
> the next thing I want to see is the where it happened, so I have to skip over 
> the bindings, which can be long and complicated.  Then I usually know what to 
> do, and only look into the bindings if something more complicated is going 
> on, like wonky inference.  So how about reordering the message:
> 
> Derive/Call/India/Pakhawaj.hs:142:62:
> Couldn't match type ‘Text’ with ‘(a1, Syllable)’
> Expected type: [([(a1, Syllable)], [Sequence Bol])]
>   Actual type: [([Syllable], [Sequence Bol])]
> In the second argument of ‘mapMaybe’, namely ‘all_bols’
> In the second argument of ‘($)’, namely
>   ‘mapMaybe (match_bols syllables) all_bols’
> Relevant bindings include
>   syllables :: [(a1, Syllable)]
> (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>   best_match :: [(a1, Syllable)]
> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)]))
> (bound at Derive/Call/India/Pakhawaj.hs:141:5)
> 
> After this, why not go one step further and set off the various sections 
> visibly to make it easier to scan.  The context section can also be really 
> long if it gets an entire do block or record:
> 
> Derive/Call/India/Pakhawaj.hs:142:62:
>   * Couldn't match type ‘Text’ with ‘(a1, Syllable)’
> Expected type: [([(a1, Syllable)], [Sequence Bol])]
>   Actual type: [([Syllable], [Sequence Bol])]
>   * In the second argument of ‘mapMaybe’, namely ‘all_bols’
> In the second argument of ‘($)’, namely
>   ‘mapMaybe (match_bols syllables) all_bols’
>   * Relevant bindings include
>   syllables :: [(a1, Syllable)]
> (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>   best_match :: [(a1, Syllable)]
> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)]))
> (bound at Derive/Call/India/Pakhawaj.hs:141:5)
> 
>  
> 
> Or alternately, taking up a bit more vertical space:
> 
>  
> 
> Derive/Call/India/Pakhawaj.hs:142:62:
> Couldn't match type ‘Text’ with ‘(a1, Syllable)’
> Expected type: [([(a1, Syllable)], [Sequence Bol])]
>   Actual type: [([Syllable], [Sequence Bol])]
> 
> -
> In the second argument of ‘mapMaybe’, namely ‘all_bols’
> In the second argument of ‘($)’, namely
>   ‘mapMaybe (match_bols syllables) all_bols’
> 
> -
> Relevant bindings include
> 
>   syllables :: [(a1, Syllable)]
> (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>   best_match :: [(a1, Syllable)]
> -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)]))
> (bound at Derive/Call/India/Pakhawaj.hs:141:5)
> 
>  
> 
> Thoughts?  It seems simple enough that I could do myself, but of course not 
> without buy-in.
> 
> 
> ___
> 

Re: Found hole

[migmit]

DON'T DO THAT!

Seriously, turn off compile-time type checking completely just to start an 
identifier with an underscore???

Отправлено с iPad

 20 янв. 2015 г., в 21:39, Alex Hammel ahamme...@gmail.com написал(а):
 
 You can get typed holes to compile with a warning and a runtime error with 
 the -fdefer-type-errors flag, if that's what you want.
 
 However, it's perfectly legal to use identifiers which look like typed holes. 
 This works fine on 7.8.3ghc:
 
 _exit = print
 main = _exit 0
 
 On Tue, Jan 20, 2015 at 11:25 AM, Alex Hammel ahamme...@gmail.com wrote:
 The only reference to a NoTypedHoles extension google can find is this 
 thread. Odd.
 
 On Tue, Jan 20, 2015 at 11:22 AM, Volker Wysk vertei...@volker-wysk.de 
 wrote:
 Hi!
 
 Am Dienstag, 20. Januar 2015, 13:44:01 schrieben Sie:
  The leading underscore invokes the typed holes extension. If you want to
  use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first 
  line
  of the source file.
 
 I get this error, when I use {-# LANGUAGE NoTypedHoles #-}:
 
ex.hs:1:14: Unsupported extension: NoTypedHoles
 
 I'm using GHC 7.8.3. Could it be that the NoTypedHoles extension was added
 not before 7.8.4 (the most current version).
 
 Bye
 Volker
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: confusing type error

[migmit]

I don't see a bug here. f2 is perfectly OK, so, let's examine f1 more closely.

It tries to get `m Bool` by applying f1 to three arguments: 0, 0, and 'a'. Now, 
since `f2` has the type `Int - Float - n Bool`, where `n` is of kind `* - *` 
(and an instance of `Monad` class, but it's not yet the time to look for 
instances), we have `f2 0 :: Float - n Bool` and `f2 0 0 :: n Bool`. Since 
that is applied to 'a', Haskell deduces that the last type should be something 
like `Char - Something` — or, equivalently, `(-) Char Something`. Therefore, 
it can see that `n` is in fact `(-) Char` and `Something` is `Bool`. 
Therefore, `f2 0 0 'a' :: Bool`. But it is expecting `m Bool`, not `Bool` — 
which is exactly what an error message says.

Отправлено с iPad

 4 дек. 2014 г., в 21:50, Evan Laforge qdun...@gmail.com написал(а):
 
 I recently got a confusing error msg, and reduced it to a small case:
 
 f1 :: Monad m = m Bool
 f1 = f2 0 0 'a'
 
 f2 :: Monad m = Int - Float - m Bool
 f2 = undefined
 
 From this, it's clear that f2 is being given an extra Char argument it
 didn't ask for.  However, the error msg (ghc 7.8.3) is:
 
Couldn't match type ‘m Bool’ with ‘Bool’
Expected type: Char - m Bool
  Actual type: Char - Bool
Relevant bindings include f1 :: m Bool (bound at Bug.hs:4:1)
The function ‘f2’ is applied to three arguments,
but its type ‘Int - Float - Char - Bool’ has only three
In the expression: f2 0 0 'a'
In an equation for ‘f1’: f1 = f2 0 0 'a'
 
 The confusing part is that 'f2' was applied to three arguments, but
 it's type has only three.  It includes the Char in expected and actual
 types, and implies that the type of 'f2' includes the Char.  So I took
 quite a while to realize that the type of 'f2' in fact *didn't* expect
 a Char (and had an 'm'), so that the but its type is *not* in fact
 its declared type.
 
 I suppose it infers a type for 'f2' based on its use, and that then
 becomes the actual type, but it seems less confusing if it picked
 the declared type of 'f2' as its actual type.  Perhaps this is working
 as intended, but it it is confusing!  Especially the part about
 expected three but got three.
 
 Ideally I'd like to see too many arguments or at least expected
 (Char - m Bool) but actually 'm Bool'.  Actually I'd expect the
 other way: expected 'm Bool' but got (Char - m Bool)' but I think
 ghc has always done it backwards from how I expect.  It looks like
 it's substituting (-) for 'm', so maybe it's one of those things
 where ((-) a) is also a monad.
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: include a cabal-install executable in future GHC releases

[migmit]

Agreed. That's exactly what we have Platform for: to give the user an 
integrated set of tools. My vote is to have only the things that are really 
necessary being included in the ghc distribution.

Отправлено с iPad

 21 янв. 2014 г., в 23:22, Ganesh Sittampalam gan...@earth.li написал(а):
 
 I feel this blurs the roles of GHC and the Platform.
 
 Can't the cabal-install that comes with the Platform can be used with a
 later GHC installation? If that's correct, then the only use case that
 this proposal covers is someone who wants to use a bleeding edge GHC and
 no other version on a new machine. A separate binary distribution of
 cabal-install should be more than adequate for that and it avoids
 coupling GHC to other things.
 
 So a weak -1.
 
 
 On 20/01/2014 00:02, Carter Schonwald wrote:
 Hey everyone,
 
 I'd like to propose that GHC releases 7.8.1 onwards include a
 cabal-install (aka cabal) executable, but not include the library deps
 of cabal-install that aren't already distributed with ghc.(unless ghc
 should have those deps baked in, which theres very very good reasons not
 to do.). 
 
 currently if someone wants just a basic haskell install of the freshest
 ghc  they have to install a ghc bindist, then do a boostrap build of
 cabal-install by hand (if they want to actually get anything done :) ). 
 
 This is not a human friendly situation for folks who are new to haskell
 tooling, but want to try out haskell dev on a server style vm or the like! 
 
 point being: It'd be great for haskell usability (and egads amounts of
 config time, even by seasoned users) the ghc bindists / installers
 included a cabal-install binary
 
 thoughts?
 -Carter
 
 
 
 
 
 ___
 Libraries mailing list
 librar...@haskell.org
 http://www.haskell.org/mailman/listinfo/libraries
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Enabling TypeHoles by default

[migmit]

Agreed. Having it in 7.8 would be very nice, and yes, I don't see how it can 
break anything.

Отправлено с iPad

 13 янв. 2014 г., в 22:54, Edward Kmett ekm...@gmail.com написал(а):
 
 I have to admit, I rather like this suggestion.
 
 -Edward
 
 
 On Mon, Jan 13, 2014 at 1:42 PM, Krzysztof Gogolewski 
 krz.gogolew...@gmail.com wrote:
 Hello,
 
 As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. 
 Rationale:
 
 (1) This way holes are far easier to use; just entering _ allows to check 
 type of a subexpression, no need of adding -XTypeHoles.
 
 (2) This affects error messages only; i.e. the set of programs that compile 
 stays the same - Haskell 2010. The only exception is that if you use 
 -fdefer-type-errors, then a program with a hole compiles, but this seems 
 fine with philosophy of -fdefer-type-errors.
 
 If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, 
 two people (John and Richard) suggested 7.10.
 
 -KG
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: default roles

[migmit]

Something bugs me here.

If some type variable a is used as a parameter to another type variable t, then 
it's considered nominal. I suppose, that's because it is possible that it would 
be nominal for some specific t. But we might just know that in our application 
it's always representational, for every possible t that we would ever use. In 
this case, we might want to a) explicitly state that t's type parameter should 
always be representational, and b) at the same time make a representational. 
Seems like a probable scenario to me.

Отправлено с iPad

 07 окт. 2013 г., в 17:26, Richard Eisenberg e...@cis.upenn.edu написал(а):
 
 As you may have heard, /roles/ will be introduced with GHC 7.8. Roles are a 
 mechanism to allow for safe 0-cost conversions between newtypes and their 
 base types. GeneralizedNewtypeDeriving (GND) already did this for class 
 instances, but in an unsafe way -- the feature has essentially been 
 retrofitted to work with roles. This means that some uses of GND that appear 
 to be unsafe will no longer work. See the wiki page [1] or slides from a 
 recent presentation [2] for more info.
 
 [1] : http://ghc.haskell.org/trac/ghc/wiki/Roles
 [2] : http://www.cis.upenn.edu/~eir/papers/2013/roles/roles-slides.pdf
 
 I am writing because it's unclear what the *default* role should be -- that 
 is, should GND be allowed by default? Examples follow, but the critical issue 
 is this:
 
 * If we allow GND by default anywhere it is type-safe, datatypes (even those 
 that don't export constructors) will not be abstract by default. Library 
 writers would have to use a role annotation everywhere they wish to declare a 
 datatype they do not want users to be able to inspect. (Roles still keep 
 type-*un*safe GND from happening.)
 
 * If we disallow GND by default, then perhaps lots of current uses of GND 
 will break. Library writers will have to explicitly declare when they wish to 
 permit GND involving a datatype.
 
 Which do we think is better?
 
 Examples: The chief example demonstrating the problem is (a hypothetical 
 implementation of) Set:
 
  module Set (Set) where   -- note: no constructors exported!
 
  data Set a = MkSet [a]
  insert :: Ord a = a - Set a - Set a
  ...
 
  {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-}
  module Client where
 
  import Set
 
  newtype Age = MkAge Int deriving Eq
 
  instance Ord Age where
(MkAge a) `compare` (MkAge b) = b `compare` a   -- flip operands, 
  reversing the order
 
  class HasSet a where
getSet :: Set a
 
  instance HasSet Int where
getSet = insert 2 (insert 5 empty)
 
  deriving instance HasSet Age
 
  good :: Set Int
  good = getSet
 
  bad :: Set Age
  bad = getSet
 
 According to the way GND works, `good` and `bad` will have the same runtime 
 representation. But, using Set operations on `bad` would indeed be bad -- 
 because the Ord instance for Age is different than that for Int, Set 
 operations will fail unexpectedly on `bad`. The problem is that Set should 
 really be abstract, but we've been able to break this abstraction with GND. 
 Note that there is no type error in these operations, just wrong behavior.
 
 So, if we default to *no* GND, then the deriving line above would have an 
 error and this problem wouldn't happen. If we default to *allowing* GND, then 
 the writer of Set would have to include
  type role Set nominal
 in the definition of the Set module to prevent the use of GND. (Why that 
 peculiar annotation? See the linked further reading, above.)
 
 Although it doesn't figure in this example, a library writer who wishes to 
 allow GND in the default-no scenario would need a similar annotation
  type role Foo representational
 to allow it.
 
 There are clearly reasons for and against either decision, but which is 
 better? Let the users decide!
 
 Discussion time: 2 weeks.
 
 Thanks!
 Richard
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: default roles

[migmit]

Well, it seems to be exactly like type classes. What if instead of implementing 
this roles we simply add a type class, say, HasRepresentationalArgument, 
which can be (and is) derived automatically. Of course, multiple arguments 
could be a problem, but, since we already have polymorphic kinds, not a big one.

Отправлено с iPad

 08 окт. 2013 г., в 0:16, Richard Eisenberg e...@cis.upenn.edu написал(а):
 
 You raise an excellent point, and yes, your understanding of how roles work 
 in this case is correct.
 
 The problem with your proposal is that it's rather involved to implement and 
 maintain -- essentially, every type and type variable would need to be 
 annotated with both a role and a kind. (These annotations would generally be 
 invisible to users, but quite apparent to implementors.) The current solution 
 is admittedly incomplete in this area, but it requires tracking roles only 
 for parameters to datatypes and classes. We're waiting to see how important 
 this particular issue is in practice before committing to implementing it (a 
 medium-sized project) and maintaining it into perpetuity.
 
 Richard
 
 On Oct 7, 2013, at 3:55 PM, migmit wrote:
 
 Something bugs me here.
 
 If some type variable a is used as a parameter to another type variable t, 
 then it's considered nominal. I suppose, that's because it is possible that 
 it would be nominal for some specific t. But we might just know that in our 
 application it's always representational, for every possible t that we would 
 ever use. In this case, we might want to a) explicitly state that t's type 
 parameter should always be representational, and b) at the same time make a 
 representational. Seems like a probable scenario to me.
 
 Отправлено с iPad
 
 07 окт. 2013 г., в 17:26, Richard Eisenberg e...@cis.upenn.edu написал(а):
 
 As you may have heard, /roles/ will be introduced with GHC 7.8. Roles are a 
 mechanism to allow for safe 0-cost conversions between newtypes and their 
 base types. GeneralizedNewtypeDeriving (GND) already did this for class 
 instances, but in an unsafe way -- the feature has essentially been 
 retrofitted to work with roles. This means that some uses of GND that 
 appear to be unsafe will no longer work. See the wiki page [1] or slides 
 from a recent presentation [2] for more info.
 
 [1] : http://ghc.haskell.org/trac/ghc/wiki/Roles
 [2] : http://www.cis.upenn.edu/~eir/papers/2013/roles/roles-slides.pdf
 
 I am writing because it's unclear what the *default* role should be -- that 
 is, should GND be allowed by default? Examples follow, but the critical 
 issue is this:
 
 * If we allow GND by default anywhere it is type-safe, datatypes (even 
 those that don't export constructors) will not be abstract by default. 
 Library writers would have to use a role annotation everywhere they wish to 
 declare a datatype they do not want users to be able to inspect. (Roles 
 still keep type-*un*safe GND from happening.)
 
 * If we disallow GND by default, then perhaps lots of current uses of GND 
 will break. Library writers will have to explicitly declare when they wish 
 to permit GND involving a datatype.
 
 Which do we think is better?
 
 Examples: The chief example demonstrating the problem is (a hypothetical 
 implementation of) Set:
 
  module Set (Set) where   -- note: no constructors exported!
 
  data Set a = MkSet [a]
  insert :: Ord a = a - Set a - Set a
  ...
 
  {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving #-}
  module Client where
 
  import Set
 
  newtype Age = MkAge Int deriving Eq
 
  instance Ord Age where
(MkAge a) `compare` (MkAge b) = b `compare` a   -- flip operands, 
  reversing the order
 
  class HasSet a where
getSet :: Set a
 
  instance HasSet Int where
getSet = insert 2 (insert 5 empty)
 
  deriving instance HasSet Age
 
  good :: Set Int
  good = getSet
 
  bad :: Set Age
  bad = getSet
 
 According to the way GND works, `good` and `bad` will have the same runtime 
 representation. But, using Set operations on `bad` would indeed be bad -- 
 because the Ord instance for Age is different than that for Int, Set 
 operations will fail unexpectedly on `bad`. The problem is that Set should 
 really be abstract, but we've been able to break this abstraction with GND. 
 Note that there is no type error in these operations, just wrong behavior.
 
 So, if we default to *no* GND, then the deriving line above would have an 
 error and this problem wouldn't happen. If we default to *allowing* GND, 
 then the writer of Set would have to include
  type role Set nominal
 in the definition of the Set module to prevent the use of GND. (Why that 
 peculiar annotation? See the linked further reading, above.)
 
 Although it doesn't figure in this example, a library writer who wishes to 
 allow GND in the default-no scenario would need a similar annotation
  type role Foo representational
 to allow it.
 
 There are clearly reasons for and against either decision, but which

Re: Private classes

[migmit]

Do you mean GeneralizedNewtypeDeriving?

Отправлено с iPad

17.08.2013, в 23:49, Joachim Breitner m...@joachim-breitner.de написал(а):

 Hi,
 
 Am Samstag, den 17.08.2013, 20:34 +0200 schrieb Bas van Dijk:
 I used the following in the past:
 
 module M (PublicClass(..)) where
 
 class HiddenClass a
 
 class HiddenClass a = PublicClass a where
  ...
 
  ...
 
 Now users of M can't declare instances of PublicClass because they
 don't have its superclass HiddenClass in scope.
 
 nice idea! Unfortunately not quite what I need; I still want the user to
 be able to use standalone deriving instances for the class.
 
 Greetings,
 Joachim
 
 -- 
 Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nome...@debian.org
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Compiled code

[migmit]

Suppose I compiled some module and kept it's .hi and .o files. Is it possible 
to use this module in my program if the source code was deleted for some reason?

Seems like the answer is yes — by creating a fake .hs file (with no real 
content) and touch-in .hi and .o files I tricked ghc so that it didn't attempt 
to recompile the module, so the information in .hi and .o files is sufficient. 
But ghc insists on having the .hs file around, and I didn't find a way to turn 
it off. Is there any? Or there is a specific reason not to have it?

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users