Re: [Haskell-cafe] Backward compatibility
Ertugrul Söylemez wrote: Often demanded changes that may or may not happen in the future: * base: Make Functor a superclass of Monad. One of the two most commonly demanded change to the base library. Will break lots and lots of code. Reason: Would greatly simplify a lot of code. * base: Fix the numeric type classes. The other most commonly demanded change. Will break lots and lots of code, including most of the base library. Reason: Would make numeric code much more sensible and algebraic. That's what I thought of when I saw the original complaint - GHC is too backwards compatible! There's far too much boilerplate because of the Functor = Applicative = Monad mess. Float/Double being Enums is ridiculous. None of this gets fixed because of the fear that new GHC won't compile old code. Perhaps we need some system for maintainers to vote on whether they consider the value of a breaking change to be worth the effort of fixing their packages to work with it. In my own code, I usually find that this effort is minor, and I'm more than happy to do it in return for a better language/library. PS The proposal to fix Functor = Applicative = Monad has patches attached for GHC and base, but the backwards compatibility bogeyman always seems to trump something that will break a lot of code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
David Thomas wrote: I'd also like to see these two. It occurs to me there may be language tweak that could reduce breakage and add some convenience in both cases. It would not surprise me at all if this has been thought of, examined, and discarded, but I don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know where. The idea is to allow definitions of superclass operations in subclass instances. If there are such definitions, it's treated as if there were instances defined for each class (potentially a source translation, even). I think default definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the superclass, and only if the superclass didn't have a default for that). This should allow existing instances of Num to just work (and I think Monad too, with some care). It would also mean if you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit of boilerplate. At the same time, you'd have the flexibility to just use the superclasses where you just want pieces. http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why were datatype contexts removed instead of fixing them?
Dan Doel wrote: I don't really think they're worth saving in general, though. I haven't missed them, at least. Maybe you haven't :-) My code is cluttered with redundant type contexts - I can't think of a similar redundancy in any other language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Constraints on Data Constructors
Can this be extended to records, without redundant repetition?
data Baz f a = Baz {baz :: Foo f = f a, baz2 :: Foo f = f a}
The type constraint for baz2 adds no information, as it's the same f as baz,
but I can't leave it out.
- Original Message -
From: Daniel Schüssler dan...@gmx.de
To: haskell-cafe@haskell.org
Cc: Guy guytsalmave...@yahoo.com
Sent: Thursday, 9 June 2011, 2:06
Subject: Re: [Haskell-cafe] Type Constraints on Data Constructors
Hello,
you might be thinking of this type?
{-# LANGUAGE Rank2Types #-}
class Foo f where
foo :: a - f a
data Baz f a = Baz (forall f. Foo f = f a)
instance Foo (Baz f) where
foo a = Baz (foo a)
Maybe the difference between Bar and Baz ist best explained by writing it
with
an explicit class dictionary for Foo:
{-# LANGUAGE Rank2Types #-}
data FooDict f = FooDict {
foo :: forall a. a - f a
}
data Bar f a = Bar (FooDict f) (f a)
data Baz f a = Baz (FooDict f - f a)
fooDict_Baz :: FooDict (Baz f)
fooDict_Baz = FooDict (\a - Baz (\d - foo d a))
-- fooDict_Bar :: FooDict (Bar f)
-- fooDict_Bar = FooDict (\a - Bar ? ?)
-- Doesn't work - you'd have to create a 'FooDict f' and a
'f a' out of just
an 'a'
Cheers,
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Constraints on Data Constructors
Malcolm Wallace malcolm.wallace at me.com writes: The class context on the data constructor buys you nothing extra in terms of expressivity in the language. All it does is force you to repeat the context on every function that uses the datatype. For this reason, the language committee has decided that the feature will be removed in the next revision of Haskell. Regards, Malcolm Why not infer class contexts from type or data constructors, instead of ignoring them? Having to repeatedly state redundant type information is not a desirable state of affairs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type Constraints on Data Constructors
{- continuing discussion from beginners@ -}
I have code such as
class Foo f where
foo :: a - f a
data Bar f a = Foo f = Bar {bar :: f a}
instance Foo (Bar f) where
foo a = Bar $ foo a
GHC insists that I put Foo f = on the instance declaration, even though the
constructor for Bar implies this.
Is there any reason why GHC cannot infer this constraint from the Bar constructor? One issue raised in the beginners
thread is that
undefined :: Bar f a
is not Foo f, but as undefined cannot be evaluated, this would not appear to be
a problem.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 06/06/2011 22:14, Evan Laforge wrote: Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have --| start a comment too might break too much code (and eliminating -- as a comment starter would certainly break far too much code). I like that you have to put a space in for haddock comments. I originally posted because I found that --| stood out much more clearly as a structured comment than -- |. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 07/06/2011 10:45, Ivan Lazar Miljenovic wrote: On 7 June 2011 17:41, Guyguytsalmave...@yahoo.com wrote: On 06/06/2011 22:14, Evan Laforge wrote: Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have --| start a comment too might break too much code (and eliminating -- as a comment starter would certainly break far too much code). I like that you have to put a space in for haddock comments. I originally posted because I found that --| stood out much more clearly as a structured comment than -- |. How does a missing space character make that stand out any more? :/ (Admittedly, I rely more on emacs using a different colour for Haddock comments than non-Haddock comments.) Try it without emacs :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 07/06/2011 10:55, Ivan Lazar Miljenovic wrote: On 7 June 2011 17:50, Guyguytsalmave...@yahoo.com wrote: On 07/06/2011 10:45, Ivan Lazar Miljenovic wrote: On 7 June 2011 17:41, Guyguytsalmave...@yahoo.comwrote: I originally posted because I found that --| stood out much more clearly as a structured comment than -- |. How does a missing space character make that stand out any more? :/ (Admittedly, I rely more on emacs using a different colour for Haddock comments than non-Haddock comments.) Try it without emacs :-) I've also read un-highlighted Haskell code; I don't see --| standing out any more than -- | does. My guess is that you just get used to it... Another argument against special-casing --|: what happens if you want to use a _different_ documentation generator (I don't know why you would, but someone might) than Haddock, which uses a different markup identifier? Out of interest, is there any other language where the comment delimiter is invalid if immediately followed by a symbol? Haskell seems to be parsing -- as if it was an operator (hence other legal lexemes could mean something else). Other languages say stop parsing here, so the comment delimiter can be followed by anything. (I could, of course, be completely wrong there.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 07/06/2011 10:55, Ivan Lazar Miljenovic wrote: Another argument against special-casing --|: what happens if you want to use a _different_ documentation generator (I don't know why you would, but someone might) than Haddock, which uses a different markup identifier? We can declare new operators - why not new comment delimiters? That way Haddock could define --| and --^, other generators could declare whatever they wanted. The downside of this is that Haddock would have to be imported into every file which uses the markup. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Comment Syntax
-- followed by a symbol does not start a comment, thus for example, haddock declarations must begin with -- |, and not --|. What might --| mean, if not a comment? It doesn't seem possible to define it as an operator. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 03/06/2011 12:01, Malcolm Wallace wrote: I believe the motivating example that persuaded the Language Committee to allow these symbols was -- which is not of course used anywhere in the standard libraries, but is an extremely nice symbol to have available in user code. Seeing as no library actually defines such a symbol, is it worth forcing an extra space into comments? --| and --^ would be an extremely nice symbols for haddock comments. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 03/06/2011 12:26, Ivan Lazar Miljenovic wrote:
On 3 June 2011 19:19, Guyguytsalmave...@yahoo.com wrote:
On 03/06/2011 12:01, Malcolm Wallace wrote:
I believe the motivating example that persuaded the Language Committee to
allow these symbols was
--
which is not of course used anywhere in the standard libraries, but is an
extremely nice symbol to have available in user code.
Seeing as no library actually defines such a symbol, is it worth forcing an
extra space into comments? --| and --^ would be an extremely nice symbols
for haddock comments.
We already have to forms of comments: -- and {- -}; why do we need another two?
Think of it this way: the -- defines the comment, and then we use
the | or ^ to indicate to _haddock_ to interpret this differently.
I don't think we need to special-case symbols starting with -- just
to avoid having to put a space in to delimit the comment indicator and
the markup indicator.
I wasn't proposing additional comment symbols; I'm proposing that anything
beginning with -- is a comment.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: converting capital letters into small letters
On Thu, 2002-07-25 at 19:07, Andrew J Bromage wrote: G'day all. On Fri, Jul 26, 2002 at 01:27:48AM +, Karen Y wrote: 1. How would I convert capital letters into small letters? 2. How would I remove vowels from a string? As you've probably found out, these are very hard problems. Glossing over that concern, current implementations don't support the relevant UnicodePrims fully, so to do it properly you'll probably need to parse the case folding files yourself. See: http://www.unicode.org/unicode/reports/tr21/ Vowels are even harder because I don't think the Unicode standard even defines what a vowel is. Removing vowel _marks_ should be straightforward once you expand combining characters, but that doesn't help with the general case. Frankly, I don't like your chances. Shouldn't the solution also take care of languages without upper casing? Clearly the translation problem is easy enough with such languages ( id will work just fine), but determining (from context?) that the string is in such a language is more than a bit difficult (especially given that numeric codes can correspond to most everything). Vowels are much more difficult - even given that the language is recognizable, what would happen with languages such as Chinese or Arabic which (I believe) have nothing that even resembles a vowel? Of course, Chinese is a whole problem by itself. -- jeff putnam -- [EMAIL PROTECTED] -- http://home1.get.net/res0tm0p ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
