Re: Excellent bikeshedding opportunity! Frontend syntax for pattern synonym types
[Superb summary of pattern synonyms omitted] On 2013-12-22 9:09 AM, Dr. ERDI Gergo wrote: The one idea I've had so far is to separate (4), (3) and (5) with two double arrows: pattern P :: (Show t) = b - T t = (Num t, Eq b) pattern P :: (Show t) = ( (Num t, Eq b) = b - T t ) perhaps? Given 'Show t', you get what's on the rhs of the first = ? Another idea is pattern P :: (Show t) ~ (Num t, Eq b) = b - T t which has the drawback of introducing a new 'keyword'. As an added extra problem, there are also unidirectional and bidirectional pattern synonyms: unidirectional ones are usable only as patterns, whereas bidirectional ones can also be used as expressions. For example: pattern Single x = [x] pattern Second x - (_:x:_) in this example, `Single` is bidirectional and `Second` is unidirectional. As you can see, this is indicated by syntax in the definition (`=` vs `-`). However, I'd like to show this in the type as well, since you'd need to be able to see if you can use a given pattern synonym as a constructor, not just a destructor, by just looking at its Haddock-generated docs. Since the first is an iso, why not pattern Single :: t a ~ [ a ] or pattern Single :: t a - [ a ] ? [I definitely prefer the first] Or is your 'type' for Single somehow different than my guess? Jacques ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Let me strongly support Gaby's many points. Simon has it right: we need a way to support 'users' in a stable way, without adding enormous inertia to the development of GHC. I has lived through the slow death of a system from being rapidly innovative to having 'innovations' which exist only because a marketer says that the raft of boring, incremental improvements in each new release are innovative on some What's New blurb. Haskell is extremely useful, and GHC's flavour of Haskell is quite exciting because of the continual evolution of the language. Please don't kill the excitement! The Platform does seem to be an ideal mechanism to provide stability for users who value stability over bleeding-edge. But for that to be successful, there are to be strong community commitment [especially from library maintainers] to tracking that evolution. If the social mechanisms are not strong enough to fully support the Platform, I would say that that is the most important thing to fix. Jacques ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Source Location of DataCon objects in GHC 7.4.1 API
One bit of experience from my Maple days: we made it a policy to create
regression tests for every single bug we fixed. No bug could be marked
closed without an identifier for the test that makes sure this does not
revert.
This seemed like too much at first, but over the years, we were always
glad of this. We caught all sorts of very strange bugs because of doing
this. This is especially valuable for very long-lived software (like
GHC), where the time-span between the last time the problem showed up
and when it occurs again can be 15+ years.
In other words, I am saying that even though in the present context this
feature/bug can seem small, it is extremely hard to predict what context
will be true in 10+ years, where this regression may become a symptom of
something bigger.
Jacques
On 05/06/2012 8:36 AM, Simon Peyton-Jones wrote:
Done. I don't think it's worth a regression test.
SImon
commit cb705a38d677e2ab4cad37447c8180bd397d5576
Author: Simon Peyton Jonessimo...@microsoft.com
Date: Tue Jun 5 13:35:07 2012 +0100
Add sensible locations to record-selector bindings
compiler/typecheck/TcTyClsDecls.lhs | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Simon Peyton-Jones
| Sent: 05 June 2012 12:38
| To: JP Moresmau; glasgow-haskell-users@haskell.org
| Subject: RE: Source Location of DataCon objects in GHC 7.4.1 API
|
| Ah I see. I'm fixing this.
|
| Simon
|
| | -Original Message-
| | From: glasgow-haskell-users-boun...@haskell.org
| | [mailto:glasgow-haskell- users-boun...@haskell.org] On Behalf Of JP
| | Moresmau
| | Sent: 01 June 2012 10:25
| | To: glasgow-haskell-users@haskell.org
| | Subject: Source Location of DataCon objects in GHC 7.4.1 API
| |
| | Hello
| |
| | I have a failing test in BuildWrapper when moving from GHC 7.0.4 to
| | 7.4.1. As far I can tell, in the TypecheckedSource I get DataCon
| | objects that have no location info, and hence I can't retrieve them by
| | location... Which is useful in a IDE (tell me what's under my mouse
| | cursor, tell me where else it's used).
| |
| | Given the simple data declaration:
| | data DataT=MkData {name :: String}
| |
| | In 7.0.4 I obtain a hierarchy that ends in FunBind (on a Var called
| | name)/MatchGroup/Match/ConPatOut and the contained DataCon named
| | MkData has a SrcSpan associated with it, and so do the Var,
| | MatchGroup and Match.
| | In 7.4.1 I have the same hierarchy but the DataCon tells me no
| | location info. The Var name has a location, but the MatchGroup and
| | Match don't either.
| |
| | Is it a normal change? Do I need to change something in the way I load
| | the module? Is it a regression?
| |
| | Thanks!
| |
| | --
| | JP Moresmau
| | http://jpmoresmau.blogspot.com/
| |
| | ___
| | 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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass Cycle via Associated Type
I just thought of an additional consideration regarding this part of the
design space.
On 25/07/2011 2:02 PM, Edward Kmett wrote:
(I had said):
Here is another way to look at it: when you say
class LeftModule Whole m = Additive m
you are closer to specifying an *instance* relation than a *class
constraint* relation.
This is very true.
However, as mentioned at the outset specifying such instance requires
newtype noise (on m, to avoid incoherent overlap with the other
instances) that leads to a particularly hideous programming style.
newtype NaturalModule m = NaturalModule { runNaturalModule :: m }
instance Monoidal m = LeftModule Natural (NaturalModule m) where
It isn't so bad when working with simple examples like
fiveTimes m = runNaturalModule (5 .* NaturalModule m)
but it gets progressively worse as the hierarchy gets deeper, and I
have to deal with putting on and taking off more and more of these
silly wrappers.
Placing the superclass constraint enforces that such instances will
always be available to me, and admits optimized implementations, which
I currently have to shoehorn into the main class and expose by convention.
My understanding is that in Coq, using either Canonical Structures (as
George Gonthier does it) or Matthieu Sozeau's implementation of type
classes, one still defines the infrastructure as you have it, i.e. the
equivalent of
newtype NaturalModule m = NaturalModule { runNaturalModule :: m }
instance Monoidal m = LeftModule Natural (NaturalModule m) where
but then the inference mechanism is powerful enough to figure out that
fiveTimes m = 5 .* m
is to be resolved using that instance. Essentially because it 'knows'
that NaturalModule is a (named) identity Functor, and it is the only one
that has been encountered (and could work) during the unification phase
of type inference. So it is able to insert the necessary (identity!)
coercions. While general coercions are very evil, those which are
automatically-provable identities 'by construction', are perfectly OK.
Jacques
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass Cycle via Associated Type
On 25/07/2011 9:55 AM, Edward Kmett wrote: If you have an associative (+), then you can use (.*) to multiply by a whole number, I currently do fold a method into the Additive class to 'fake' a LeftModule, but you have to explicitly use it. class Additive m = LeftModule r m class LeftModule Whole m = Additive m This says that if you have an Additive semigroup, then there exists a LeftModule over the whole numbers, and that every leftmodule is additive, but there can exist other LeftModules than just ones over the whole numbers! Given LeftModule Integer m, you'd know you have Additive m and LeftModule Whole m. LeftModule Integer m = LeftModule Whole m = Additive m. I believe that part of the issue here is that you are using a single relation (given by class-level = ) to model what are actually two different relations: a 'constructive' inclusion and a 'view' (to use the terminology from the Specifications community, which is clearly what these class definitions are). Just like inheritance hierarchies fail miserably when you try to model more than one single relation, it should not be unsurprising that the same thing befalls '=', which is indeed a (multi-ary) relation. In my own hierarchy for Algebra, I use two relations. Slightly over-simplifying things, one of them reflects 'syntactic' inclusion while the other models 'semantic' inclusion. There are very strict rules for the 'syntactic' one, so that I get a nice hierarchy and lots of free theorems, while the semantic one is much freer, but generates proof obligations which must be discharged. The syntactic one generates a nice DAG (with lots of harmless diamonds), while the semantic one is a fully general graph. Here is another way to look at it: when you say class LeftModule Whole m = Additive m you are closer to specifying an *instance* relation than a *class constraint* relation. In a general categorical setting, this is not so surprising as 'classes' and 'instances' are the same thing. A 'class' typically has many non-isomorphic models while an 'instance' typically has a unique model (up to isomorphism), but these are not laws [ex: real-closed Archimedian fields have a unique model even though a priori that is a class, and the Integers have multiple Monoid instances]. Jacques ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On 17/06/2011 10:47 AM, Simon Peyton-Jones wrote: But Plan A is simpler. And by breaking packages it will encourage [force] libraries that use a mixture of H98 and more modern modules to move towards the more modern story. I favour Plan A. Reasoning: For many years of my previous professional life, I had to live with extreme backwards compatibility in the code base. This introduced a huge amount of inertia, to the point where past design mistakes became entrenched as 'features'. Forward progress became glacial. Very bad. Your plan A on the other hand strikes a really good balance: the only libraries affected are those which mix H98 and more modern modules. This means that the authors are already beyond Haskell 98, and realize that there is real value to go beyond that. So they should be reasonably amenable to continue to move forward. On the other hand, those who were very careful to stick to pure Haskell 98 (for whatever reason), have a very clear path for their code to continue to stay functional. They get all the backwards compatibility they desired when they chose to stick to pure Haskell 98. Plan B is actually more fragile in that respect, in that if they forget to be really really explicit about their code being pure Haskell 98, the resulting compilation errors do not make it obvious that that is actually the problem. This will in fact only get worse as time goes by. Jacques ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
