Re: Injective type families

2014-07-10 Thread Isaac Dupree 
On 07/10/2014 02:34 PM, Gabor Greif wrote:
> Jan, this is great! Thanks for attacking this issue.
> 
> Regarding "result", I do not like the idea to introduce arbitrary
> words with special meanings. What if somebody writes
> 
>>injective type family F a result c | result -> a result c
> 
> it will be totally confusing.
> 
> One could write like this:
> 
>>injective type family F a b c | F a b c -> a b c  -- (*)
> 
> or even shorter:
> 
>>injective type family F a b c | F -> a b c  -- (**)
> 
> in (*) the syntax is inconsistent because to the left of the "|"
> juxtaposition is not meaning application. Also (*) would permit "... |
> F x b c -> a b c" which is confusing and would require a naming rule.
> 
> (**) can be read as "F's result uniquely determines all of a b and c".
> It sounds ok if you repeat it often enough :-)

At the risk of being too clever, one could use the keyword "type" to
reference the result.  If F is a family of types (a "type family"), then
the result is conceptually a single type in this family.

> type family F a b c | type -> a b c

-Isaac

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Again: Uniques in GHC

2014-10-07 Thread Isaac Dupree 
On 10/07/2014 02:32 AM, p.k.f.holzensp...@utwente.nl wrote:
>> But that would only work on 64 bit systems, right?
> 
> Yes, this approach to a parallel GHC would only work on 64-bit machines.
> The idea is, I guess, that we're not going to see a massive demand for
> parallel GHC running on multi-core 32-bit systems. In other words;
> 32-bit systems wouldn't get a parallel GHC.

On ARM, 32-bit quad-cores are common.  But maybe no one will care to run
GHC on (32-bit) ARM.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

2014-10-30 Thread Isaac Dupree 
There are good reasons not to require people's "real" name to participate:

http://geekfeminism.wikia.com/wiki/Who_is_harmed_by_a_%22Real_Names%22_policy%3F

Simon PJ often advocates to know people's name as part of creating a
friendly community.  There are good things about this.  It also helps
exclude people with less privilege, whom we have few enough of already,
if it is a policy.

I like most things about "Developer's Certificate of Origin", though.

-Isaac

On 10/30/2014 04:13 AM, Herbert Valerio Riedel wrote:
> Hi,
> 
> GHC's Git history has (mostly) a good track record of having properly
> attributed authorship information in the recent past; Some time ago I've
> even augmented the .mailmap file to fix-up some of the pre-Git meta-data
> which had mangled author/committer meta-data (try 'git shortlog -sn' if
> you're curious)
> 
> However, I just noticed that
> 
>   
> http://git.haskell.org/ghc.git/commitdiff/322810e32cb18d7749e255937437ff2ef99dca3f
> 
> landed recently, which did change a significant amount of code, but at
> the same time the author looks like a pseudonym to me (and apologies if
> I'm wrong).
> 
> Other important projects such as Linux or Samba, just to name two
> examples, reject contributions w/o a clearly stated origin, and
> explicitly reject anonymous/pseudonym contributions (as part of their
> "Developer's Certificate of Origin" policy[1] which involves a bit more
> than merely stating the real name)
> 
> I believe the GHC project should consider setting some reasonable
> ground-rules for contributions to be on the safe side in order to avoid
> potential copyright (or similiar) issues in the future, as well as
> giving confidence to commercial users that precautions are taken to
> avoid such issues.
> 
> Comments?
> 
> Cheers,
>   hvr
> 
>  [1]: See 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Concrete syntax for pattern synonym type signatures

2014-11-08 Thread Isaac Dupree 
On 11/04/2014 05:32 AM, Simon Peyton Jones wrote:
> The "; match-required" part is optional, and the "match-provided" part might 
> be empty.  So P1 and P2 would look like this:
> 
>   pattern P1 :: forall a. (; Num a) => b -> (a,b)
>   pattern P2 :: forall a. (; Num a, Ord a) => a -> a

How about marking the match-provided parts with a keyword, as so:

  pattern P2 :: (match_required Num a, match_required Ord a) => a -> a

Except with a better keyword. "if" might do in a pinch:

  pattern P2 :: forall a. (if Num a, if Ord a) => a -> a

or "pattern needed" (pattern being a keyword) or "pattern forall"

  pattern P2 :: (pattern needed Num a, pattern needed Ord a) => a -> a

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: OverloadedLists

2013-02-14 Thread Isaac Dupree 

On 02/14/2013 10:10 AM, Simon Peyton-Jones wrote:

| Finally I managed to build again (don't know what's wrong with my
| system, I built on a virtual machine instead now), and the tests pass. I
| attached the four patches, they were created with git diff --no-prefix,
| and their name specifies the submodule they are to be applied to. I hope
| it isn't to late to include them in 7.8. Should I publish them somewhere
| else also, or is this fine?

Great.  It's done!  Thanks for all your work on this.

Would you like to update the wiki page? 
http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists


Wiki says: "GHC, during the typechecking and desugaring phases, uses 
whatever is in scope with the names of fromList, toList and fromListN"


Does this mean that if OverloadedLists is on and more than one fromList 
or toList is in scope (even if one of them is GHC.Exts.fromList/toList), 
then list literals and patterns (resp.) will not compile?  I just 
selfishly don't want to hide those in every import list (and to give up 
polymorphic list literals altogether in modules that define/export a 
monomorphic fromList).  Anyhow, good work on this!


(Admission: I've been importing Data.Map etc. unqualified because I want 
the ambiguities with Prelude: I want to force my code to say List.filter 
just like it says Map.filter.  Is there a better way to do this? :)


-Isaac


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: OverloadedLists

2013-02-15 Thread Isaac Dupree 

On 02/15/2013 03:52 AM, Simon Peyton-Jones wrote:

| Does this mean that if OverloadedLists is on and more than one fromList
| or toList is in scope (even if one of them is GHC.Exts.fromList/toList),
| then list literals and patterns (resp.) will not compile?

No... the documentation is poor on that point:

* Normally, it'll use GHC.Exts.fromList (etc) regardless of
   whether GHC.Exts is imported, or what other fromList's are in scope.

* If you also use -XRebindableSyntax, it'll use whatever fromList is in scope.
   Then if you imported Data.Map and GHC.Exts it'd be ambiguous.

This is precisely the behaviour of, say integer literals.  Normally they 
desugar to a call of the Prelude's fromInteger, but with RebindableSyntax it 
becomes whatever fromInteger is in scope.

I'll fix the documentation.

Simon


Ah, that's what I'd expect.  Thanks!

-Isaac



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Advance notice that I'd like to make Cabal depend on parsec

2013-03-21 Thread Isaac Dupree 

On 03/18/2013 12:55 PM, Duncan Coutts wrote:

[...]  it
is not simply the outline parser for cabal-style files that we're
talking about. We also need parsers/pretty printers for all the various
little types that make up the info about packages, like versions,
package names, package ids, version constraints, module names, licenses
etc etc.


(ignorant musing that doesn't help the general difficult of writing a 
Happy parser: )

Can they not use multiple Happy parsers generated from the same Happy file?
http://www.haskell.org/happy/doc/html/sec-multiple-parsers.html

-Isaac


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [RFC] Bang constraint

2013-04-03 Thread Isaac Dupree 

On 04/03/2013 02:06 PM, Gabor Greif wrote:

Now that Constraint kinds are pretty much into the mainstream, can we
consider the '!' annotation in data declarations as a magic
constraint? Not unlike NFData, but only ensuring that said value is in
WHNF.

So the following definitions would be semantically identical


newtype Foo a = Foo a



data Foo a = Foo !a

[...]


These two are not identical because
  f (Foo _) = 3
forces the value if it's 'data' but not if it's 'newtype'.
That's irrelevant to your interesting proposal, however.

-Isaac

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: PSA: GHC can now be built with Clang

2013-06-25 Thread Isaac Dupree 
Tom Stellard is leading an effort to make dot releases for LLVM 3.3 [*];
perhaps LLVM folks could be convinced to fix the issues in a 3.3.1 release.

-Isaac (just happens to be on both email lists and doesn't know anything
more than this)

[*] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063189.html

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Repository Reorganization Question

2013-12-06 Thread Isaac Dupree 
20MB of bandwidth represents 20 additional seconds to do an initial 
clone on my 1 megabyte/second connection.  ghc.git is already about 
75MB, so it wouldn't dramatically change the experience either way. 
Just a data point.


On 12/06/2013 12:47 PM, Carter Schonwald wrote:

personally i don't care about the bandwidth, and others are correct
about the value of logs. If theres a way to get both, awesome!  If not,
20mb here and there i don't care.


On Fri, Dec 6, 2013 at 11:26 AM, Johan Tibell mailto:johan.tib...@gmail.com>> wrote:

On Fri, Dec 6, 2013 at 4:43 PM, Herbert Valerio Riedel mailto:h...@gnu.org>> wrote:

On 2013-12-06 at 13:50:55 +0100, Johan Tibell wrote:
 > Whichever way to go, we should write down the options and
consequences and
 > communicating them widely enough so no core devs get surprised.
 >
 > Commit IDs for the test suite are referenced in e.g. various
Trac issues,
 > on mailing lists (although rarely), and perhaps even in code.

...as I hinted at in an earlier post, the old commit-ids will still
allow to find the original commit; for isntance, there's already the
find-commit-by-sha1 service at

http://git.haskell.org/.findhash/

which searches all repos hosted at git.haskell.org
 for the given sha1
prefix; there's also a convenient text-entry field at
http://git.haskell.org/ which allows you to copy'n'paste any
commit-ids
you might come across in emails, irc logs, trac comments or even
commit
messages...

...does this lookup-service alleviate your concerns?


Personally I think it's still much friction; another thing to
remember. Is it really worth it for a couple of megs of bandwidth*
and some disk space?

If it really is I believe git has some facility for nuking the data
of old commits. That facility exists for the case when someone
committed something sensitive to the code base that should never
have been there.

* GitHub's bandwidth if you use that mirror.

-- Johan


___
ghc-devs mailing list
ghc-devs@haskell.org 
http://www.haskell.org/mailman/listinfo/ghc-devs




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Folding constants for floats

2014-01-13 Thread Isaac Dupree 

On 01/13/2014 05:21 PM, Kyle Van Berendonck wrote:

Hi,

I'd like to work on the primitives first. They are relatively easy to
implement. Here's how I figure it;

The internal representation of the floats in the cmm is as a Rational
(ratio of Integers), so they have "infinite precision". I can implement
all the constant folding by just writing my own operations on these
rationals; ie, ** takes the power of the top/bottom and reconstructs a
new Rational, log takes the difference between the log of the top/bottom
etc. This is all very easy to fold.


What about sin(), etc? I don't think identities will get you out of 
computing at least some irrational numbers.  (Maybe I'm missing your point?)



Since the size of floating point constants is more of an
architecture specific thing


IEEE 754 is becoming more and more ubiquitous.  As far as I know, 
Haskell Float is always IEEE 754 32-bit binary floating point and Double 
is IEEE 754 64-bit binary floating point, on machines that support this 
(including x86_64, ARM, and sometimes x86).  Let's not undermine this 
progress.



and floats don't wrap around like integers
do, it would make more sense (in my opinion) to only reduce the value to
the architecture specific precision (or clip it to a NaN or such) in the
**final** stage as apposed to trying to emulate the behavior of a double
native to the architecture (which is a very hard thing to do, and
results in precision errors


GCC uses MPFR to exactly emulate the target machine's rounding behaviour.


the real question is, do people want
precision errors when they write literals in code,


Yes. Look at GCC.  If you don't pass -ffast-math (which says you don't 
care if floating-point rounding behaves as specified), you get the same 
floating-point behaviour with and without optimizations.  This is IMHO 
even more important for Haskell where we tend to believe in 
deterministic pure code.


-Isaac

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Folding constants for floats

2014-01-14 Thread Isaac Dupree 

On 01/14/2014 11:48 AM, Sven Panne wrote:

My point was: As much as I propose to keep these current semantics,
there might be users who care more about performance than
IEEE-754-conformance.


Adding a -ffast-math flag could be fine IMHO.


For those, relatively simple semantics could be:
Regarding optimizations, numbers are considered "mathematical"
numbers, ignoring any rounding and precision issues,


How do you plan to constant-fold things like "log(cos(pi**pi))" without 
rounding?


I checked C, and apparently the optimizer is entitled to assume the 
default floating-point control modes (e.g. rounding mode, 
quiet/signaling NaN) are in effect except in scopes where "#pragma STDC 
FENV_ACCESS ON" is given.  However the standard does not entitle the 
optimizer to change rounding in any other way.  This is sufficient for 
constant-folding in regions where FENV_ACCESS is off.  GCC also has 
flags to control floating-point optimization: 
http://gcc.gnu.org/wiki/FloatingPointMath


Probably it's best not to touch floating point optimization without 
understanding all these issues.


Hmm, I can't see how non-default floating point control mode is 
compatible with Haskell's purity... Even without optimizations, (1/3 :: 
Double) could evaluate to two different values in the same program if 
the floating-point rounding mode changes during execution (e.g. by C 
fesetenv()).


-Isaac
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Backward-compatible role annotations

2014-04-08 Thread Isaac Dupree 
I've been wondering whether there are any cases where the ability to 
coerce a parameter should not be exported (as for Set) but where the 
implementation would like to use some coercions (for example, if it 
internally wanted to coerce the contained type to a specific newtype, to 
change some of the contained type's instances while being able to 
guarantee that the invariant-related instances stayed safe).


This would call for coercibility to be something you can import and 
export.  What if, in the long term, there were a flag 
ExplicitRoleExports (probably rarely used):


- with ExplicitRoleExports on, role signatures would be listed in the 
export list and must be at least as restrictive as the roles visible 
within the module.  Exported types without role signatures in the export 
list would default to being exported as all-nominal.


- with ExplicitRoleExports off, any types the modules export would be 
exported with the same roles visible inside the module.


As is currently, the default role at a type's definition site would 
allow as many coercions as is segfault-safe.


-Isaac

P.S. I think this particular proposal likely has issues.  If you import 
(T :: * -> * -> *) as "nominal, representational" and from elsewhere as 
"representational, nominal", do those roles combine somehow?  What about 
contravariant [or is it covariant] roles as in (T :: (* -> *) -> *)?  I 
haven't thought these through.  Also I haven't thought of any concrete 
use cases for export-controlled roles; perhaps there aren't any.



On 03/31/2014 02:12 PM, Dominique Devriese wrote:

Richard,

Right, but I was thinking about the debate between
"nominal/non-parametric-by-default" or
"representational/parametric-by-default" for parameters of data types
that aren't forced to nominal from inspecting the datatype
implementation.  As I understand it, representational-by-default
(currently used) may leave libraries that don't add role annotations
open for abuse, but won't unnecessarily break library users' code and
nominal-by-default prevents all abuse but may unnecessarily break code
that uses libraries that have not added proper role annotations.

What I was wondering about is if the dilemma could be solved by
choosing nominal-by-default in the long term for the role inference
(so that library writers cannot accidentally leave abstraction holes
open by forgetting to add role annotations) and use them in the
long-term-supported SafeNewtypeDeriving extension, but provide a
deprecated not-quite-as-safe GND extension for helping out users of
libraries that have not yet added role annotations. I would fancy that
this not-quite-as-safe GND could use unsafeCoerce wherever the safe
one would give an error about annotated roles.

Regards,
Dominique

2014-03-31 17:05 GMT+02:00 Richard Eisenberg :

Hi Dominique,

When implementing roles, I was indeed worried about the problem you're 
addressing: that code that previously worked with GND now won't. However, it 
turns out that few people have really complained about this. IIRC, in all of 
Hackage, only 3 packages needed to be changed because of this. If there were a 
larger impact to the GND breakage, I think your suggestion would be a good one.

The problem I'm adressing in this thread is different: that library authors 
have been given a new, not-backward-compatible way of preventing abuses of 
their datatypes, and no proposal I have seen really addresses all of the 
problems here. I'm hoping my no-role-annots package might be helpful, but it 
doesn't fully resolve the issues.

Richard

On Mar 31, 2014, at 2:51 AM, Dominique Devriese 
 wrote:


Richard,

(re-posting because I first used an address that is not subscribed to the lists)

I've been wondering about the following: it seems like the main
problem in this situation is that the GeneralizedNewtypeDeriving
extension changed meaning from "just coerce everything while deriving"
to "only coerce stuff if it's allowed by the relevant role
annotations".  Would it not be an alternative solution to split up the
GND extension into

* a backwards-compatible one (called GeneralizedNewtypeDeriving for
backwards compatibility ;)) that ignores role annotations (as before)
and uses unsafeCoerce whereever necessary
* a safe one (called e.g. SafeNewtypeDeriving) that respects role annotations

The first one could then be deprecated and removed in a release or
two. That might give library maintainers time to move their packages
to SafeNewtypeDeriving when they have tested that everything works...

Regards,
Dominique

P.S.: The above is based on a limited understanding of the problem, so
I'm sorry if it misses some aspect of the problem...

2014-03-31 2:14 GMT+02:00 Richard Eisenberg :

I spent some time thinking about what, precisely, can be done here to make
folks happier. (See the thread beginning here:
http://www.haskell.org/pipermail/libraries/2014-March/022321.html) And, the
answer seemed to all be in the concrete syntax. The only logical alternative