Haskell Prime: Ticket Query
https://prime.haskell.org/query?status=!closed&owner=none&desc=1&order=milestone
Haskell Language Report Working Groupen-USHaskell Primehttps://prime.haskell.org/chrome/site/HaskellLogo_2.jpg
https://prime.haskell.org/query?status=!closed&owner=none&desc=1&order=milestone
Trac 1.2
https://prime.haskell.org/ticket/22
https://prime.haskell.org/ticket/22#22: create DerivedInstances proposalFri, 16 Dec 2005 22:49:37 GMTijones<p>
There are a number of issues relating to <a class="wiki" href="https://prime.haskell.org/wiki/DerivedInstances">DerivedInstances</a>. Create concrete proposal(s) for them. See also <a class="wiki" href="https://prime.haskell.org/wiki/NewtypeDeriving">NewtypeDeriving</a>.
</p>
Resultshttps://prime.haskell.org/ticket/22#changelog
https://prime.haskell.org/ticket/37
https://prime.haskell.org/ticket/37#37: add GADTsFri, 16 Dec 2005 23:34:31 GMTijones<p>
see <a class="wiki" href="https://prime.haskell.org/wiki/GADTs">GADTs</a>.
</p>
Resultshttps://prime.haskell.org/ticket/37#changelog
https://prime.haskell.org/ticket/43
https://prime.haskell.org/ticket/43#43: add Linear implicit paramsFri, 16 Dec 2005 23:46:01 GMTijones<p>
see <a class="wiki" href="https://prime.haskell.org/wiki/LinearImplicitParams">LinearImplicitParams</a>.
</p>
Resultshttps://prime.haskell.org/ticket/43#changelog
https://prime.haskell.org/ticket/52
https://prime.haskell.org/ticket/52#52: Generalised deriving for newtypeSat, 17 Dec 2005 00:21:09 GMTijones<p>
see <a class="wiki" href="https://prime.haskell.org/wiki/NewtypeDeriving">NewtypeDeriving</a>.
</p>
Resultshttps://prime.haskell.org/ticket/52#changelog
https://prime.haskell.org/ticket/54
https://prime.haskell.org/ticket/54#54: add overlapping or incoherent instancesSat, 17 Dec 2005 00:31:28 GMTijones<p>
see <a class="wiki" href="https://prime.haskell.org/wiki/OverlappingInstances">OverlappingInstances</a> and <a class="wiki" href="https://prime.haskell.org/wiki/IncoherentInstances">IncoherentInstances</a>.
</p>
Resultshttps://prime.haskell.org/ticket/54#changelog
https://prime.haskell.org/ticket/78
https://prime.haskell.org/ticket/78#78: Add infix type constructorsWed, 25 Jan 2006 13:29:21 GMTSimon Marlow<p>
see <a class="wiki" href="https://prime.haskell.org/wiki/InfixTypeConstructors">InfixTypeConstructors</a>.
</p>
Resultshttps://prime.haskell.org/ticket/78#changelog
https://prime.haskell.org/ticket/80
https://prime.haskell.org/ticket/80#80: Reform the monomorphism restrictionMon, 30 Jan 2006 16:47:21 GMTSimon Marlow<p>
See <a class="wiki" href="https://prime.haskell.org/wiki/MonomorphismRestriction">MonomorphismRestriction</a>. There are several proposals on the table.
</p>
Resultshttps://prime.haskell.org/ticket/80#changelog
https://prime.haskell.org/ticket/81
https://prime.haskell.org/ticket/81#81: scoping of type variables in class instancesTue, 31 Jan 2006 10:23:17 GMT<p>
The scoping of type variables in class instances is underspecified. GHC scopes them for the entire instance, Hugs does not.
</p>
<p>
GHC's approach is more expressive, it is sometimes needed - especially in combination with multi-parameter classes.
Example:
</p>
<pre class="wiki">class Ping a b where ping:: a->b
newtype A a = A a
instance (Show b,Ping a b) => Show (A a) where
show (A x) = show (ping x)
</pre><p>
This is ambiguous and thus rejected, but we could resolve the ambiguity by annotating 'ping' with its expected type a→b, but that only works if the scoping of the class instance extends to the member definition.
</p>
<h2 id="pros">pros</h2>
<p>
: extends expressiveness, implemented in GHC anyway, was underspecified in Haskell anyway
</p>
<h2 id="cons">cons</h2>
<p>
: very minor: it could break some existing programs as it makes some local functions non-polymorphic, though these would have been badly written
</p>
<p>
See also: <a class="ext-link" href="http://hackage.haskell.org/trac/haskell-prime/wiki/ScopedTypeVariables"><span class="icon"></span>http://hackage.haskell.org/trac/haskell-prime/wiki/ScopedTypeVariables</a>
</p>
Resultshttps://prime.haskell.org/ticket/81#changelog
https://prime.haskell.org/ticket/82
https://prime.haskell.org/ticket/82#82: Allow import declarations anywhere at the top levelTue, 31 Jan 2006 11:31:02 GMTSimon Marlow<p>
See <a class="wiki" href="https://prime.haskell.org/wiki/AllowImportAnywhere">AllowImportAnywhere</a>.
</p>
Resultshttps://prime.haskell.org/ticket/82#changelog
https://prime.haskell.org/ticket/84
https://prime.haskell.org/ticket/84#84: Kind AnnotationsThu, 02 Feb 2006 11:07:15 GMTmalcolm.wallace@…<p>
Add <a class="wiki" href="https://prime.haskell.org/wiki/KindAnnotations">KindAnnotations</a> to the language of type expressions.
</p>
Resultshttps://prime.haskell.org/ticket/84#changelog
https://prime.haskell.org/ticket/86
https://prime.haskell.org/ticket/86#86: add PartialTypeAnnotations?Thu, 02 Feb 2006 18:03:20 GMTflippa<p>
See <a class="wiki" href="https://prime.haskell.org/wiki/PartialTypeAnnotations">PartialTypeAnnotations</a>.
</p>
Resultshttps://prime.haskell.org/ticket/86#changelog
https://prime.haskell.org/ticket/88
https://prime.haskell.org/ticket/88#88: unified and extensible annotationsWed, 08 Feb 2006 10:27:17 GMTwaldmann@…<p>
We have several annotations in current Haskell:
deriving, <a class="ext-link" href="http://www.haskell.org/ghc/docs/6.4/html/users_guide/pragmas.html"><span class="icon"></span>pragmas</a> {-# #-}, {-! !-} (<a class="ext-link" href="http://repetae.net/~john/computer/haskell/DrIFT/"><span class="icon"></span>DrIFT</a>), <a class="ext-link" href="http://www.haskell.org/haddock/"><span class="icon"></span>haddock</a>…
These are ad-hoc, and not extensible by the programmer.
</p>
<p>
There are better ways:
</p>
<ul><li>C-sharp has <a class="ext-link" href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfcreatingcustomattributes.asp"><span class="icon"></span>custom attributes</a>.
</li><li>Java (1.5) has <a class="ext-link" href="http://java.sun.com/docs/books/tutorial/java/javaOO/annotations.html"><span class="icon"></span>annotations</a>.
</li></ul><p>
For me the important features are
</p>
<ul><li>An annotation is allowed basically at any declaration,
</li><li>and programmers can define their own annotations,
</li><li>and annotations can also have values.
</li><li>Also, they have a retention policy saying whether they should be visible at compile time or at run time, where compile time is for tools/preprocessors, and visibility at run time is helpful for reflection. (Would need some support from Data.Generics or thereabouts.)
</li></ul><p>
I have brought this <a class="ext-link" href="http://www.haskell.org//pipermail/haskell-prime/2006-February/000279.html"><span class="icon"></span>proposal</a> up on the mailing list and there was one <a class="ext-link" href="http://www.haskell.org//pipermail/haskell-prime/2006-February/000366.html"><span class="icon"></span>response</a>.
</p>
Resultshttps://prime.haskell.org/ticket/88#changelog
https://prime.haskell.org/ticket/91
https://prime.haskell.org/ticket/91#91: Unify various annotation proposalsSat, 11 Feb 2006 01:39:24 GMTijones<p>
Is an elegant, more specific proposal possible that will solve these problems?
</p>
<ol><li>Waldmann proposed <a class="new ticket" href="https://prime.haskell.org/ticket/88" title="#88: enhancement: unified and extensible annotations (new)">unified and extensible annotations</a>.
</li><li>Zadarnowski proposed <a class="ext-link" href="http://www.haskell.org//pipermail/haskell-prime/2006-February/000335.html"><span class="icon"></span>specifying language extensions</a>.
</li><li>There are some <a class="wiki" href="https://prime.haskell.org/wiki/NewPragmas">NewPragmas</a> which are <a class="new ticket" href="https://prime.haskell.org/ticket/51" title="#51: enhancement: add new pragmas (new)">under consideration</a>. These might be eliminated by annotations.
</li></ol>Resultshttps://prime.haskell.org/ticket/91#changelog
https://prime.haskell.org/ticket/92
https://prime.haskell.org/ticket/92#92: add First Class LabelsSat, 11 Feb 2006 22:52:21 GMTclaus.reinke@…<p>
Designing the <em>right</em> record system for Haskell has proven to be tricky, the
only general agreement appearing to be that the old Haskell 98 records are not
sufficient. Yet the only record-related proposal ticket for Haskell' at this
stage is <a class="new ticket" href="https://prime.haskell.org/ticket/27" title="#27: task: create proposal(s): tweak the existing records system (new)">ticket:27</a>, "create proposal(s): tweak the existing records system".
</p>
<p>
Between the extremes of designing and implementing a new record systems on the
one hand and just trying to tweak what we've got, there are <em>opportunities
provided by Haskell's type class and instance language</em>. While not offering a
replacement for a well-integrated proper record system, <em>libraries
implementing record functionality can help to explore the gap between what we
want and what we have in Haskell records</em>. Examples include
</p>
<ul><li><a class="ext-link" href="http://homepages.cwi.nl/~ralf/HList/"><span class="icon"></span>Strongly typed heterogeneous collections</a>
</li><li><a class="attachment" href="https://prime.haskell.org/attachment/ticket/92/Data.Record.hs" title="Attachment 'Data.Record.hs' in Ticket #92">attachment:Data.Record.hs</a><a class="trac-rawlink" href="https://prime.haskell.org/raw-attachment/ticket/92/Data.Record.hs" title="Download"></a>
</li></ul><p>
<em>Any such libary will need to represent record field labels, and if record
field selection is based on type-level programming, each of these labels needs
to inhabit its own type.</em>
</p>
<p>
<strong>I propose to add implicitly declared record field labels as first class
values to Haskell' (<a class="wiki" href="https://prime.haskell.org/wiki/FirstClassLabels">FirstClassLabels</a>)</strong>, to support experimentation with and
use of such record libraries (such typed constants have other uses in
type-level programming as well).
</p>
<hr />
<p>
<span class="wikiextras phrase todo">TODO</span>
</p>
<ol><li>need to identify which interfaces labels should support
<ul><li>like constructors/constants: <a class="missing wiki">Read/Show/Matching?</a>
</li></ul></li></ol><ul><li>a type-level equality predicate would also be useful, but seems hard to define with current extensions (we want it to be generic, but with functional dependencies)
</li></ul><ol start="2"><li>could refine some of the record variants as libraries under Data.Record.VariantX
</li></ol><hr />
<p>
add impact information below:
</p>
<pre class="wiki">> option 1: syntax change (and '#' as an identifier prefix might
> conflict with other uses)
> option 2: non-trivial change of module/type system
> option 3: change of module hierarchy, re-interpretation of
> import behaviour for specific modules
>
> option 3 is the smallest change I could think of (perhaps with
> John's modification to import constructors instead of variables),
> and I've selected minor impact..
</pre>Resultshttps://prime.haskell.org/ticket/92#changelog
https://prime.haskell.org/ticket/94
https://prime.haskell.org/ticket/94#94: Syntax for specifing language extensionsThu, 16 Feb 2006 23:44:15 GMTpatrykz@…<p>
One of the original Haskell goals was to define a language for experimentation
with functional language features. This will not change with Haskell' - we
already know that at least one feature that is in high demand (FDs) is not ready
for inclusion in Haskell'.
</p>
<p>
However, Haskell still does not provide any internal mechanism to facilitate
language experimentation. In particular, the language does not provide
a mechanism for keeping track of the languaged extensions in used by
a particular piece of code.
</p>
<p>
To make things worse, many (most?) extension require lexical and/or
syntactic changes to the language. Some extensions in the past proved
to be incompatible, and not all compilers implement all extensions.
</p>
<p>
So, looking at a particular piece of code, how do we know which compiler
it can be compiled with, and which command-line flags do we pass to
which compiler? The answer is, simply, we don't.
</p>
<p>
Currently, we do this by introducing ugly GHC-specific pragmas, comments
in the documentation, and a plethora of similar half-measures.
</p>
<p>
I would like to propose a language feature to address this concern
once and for all. I know that a similar proposal has been circulated on the
Haskell mailing list in the past, but to the best of my knowledge, none of
the current tickets addresses this problem.
</p>
<h2 id="TheProposal">The Proposal</h2>
<p>
Add explicit syntax for documenting language extensions required to
compile a module.
</p>
<h2 id="TheProblem">The Problem</h2>
<ul><li>Current language does not provide a uniform extension mechanism.
</li><li>Pragmas (as currently used in GHC) are NOT suitable for this. Specifically,
by their design they are COMMENTS, and therefore should have no impact on
the language semantics. Unrecognized pragmas should be ignorable without
warnings, while, currently, if you omit the GHC options pragma for a module
that requires some syntactic extension, you will receive thousands of lexical
and syntactic errors completely unrelated to your extension.
</li><li>I <em>strongly</em> believe that compiler pragmas should ONLY be used for
extensions (such as <code>INLINE</code>, various <code>SPECIALIZE</code>, etc.) that have no impact
on the program semantics.
</li></ul><h2 id="TheSolution">The Solution</h2>
<p>
Add an <code>extension</code> clause to the language.
</p>
<p>
To avoid introduction of a new keyword, I propose to use the following syntax:
</p>
<pre class="wiki"> module -> [extensions;] "module" modid [exports] "where" body
| body
extensions -> extension_1 ; ... ; extension_n
extension -> "import" "extension" varid [extparam_1 ... extparam_n]
extparam -> varid | conid | literal
</pre><p>
A module using some GHC woo-hah extension would look like:
</p>
<pre class="wiki"> import extension GHC "woo-hah!"
module Foo ...
</pre><p>
Or, if an extension is common enough:
</p>
<pre class="wiki"> import extension fundeps
module Foo ...
</pre><p>
This is a very conservative syntax. It does not support grouping, aliasing and
renaming of extensions (as previously circulated on the haskell mailing list)
which I personally believe would be very a bad idea. I want to be able to look
at a piece of Haskell code and tell immediately which extensions it uses,
without being forced to browse through the included modules, etc. Further,
the parsers and lexers must be able to tell where the list of extensions finishes
and the module code (which uses these extensions) starts. The "module" keyword
is a natural candidate for that.
</p>
<p>
Extensions would NOT be exported by a module that uses that
extension, but would have to be specified separately by each module that uses the
features provided by that extension. For example, one often hides uses of unboxed
types, functional dependencies, etc, behind a curtain of abstract data types, and
such data type implemented using non-standard features can be happily used within
standard-conforming Haskell programs. On the other hand, if an extension is visible in
an interface exported by a module, it has to be named explicitly (with <code>import extension</code>
clauses) by any module importing that interface.
</p>
<p>
Extensions could be parametized, since I can readily imagine extensions that
would require such a thing. I would also recommend in the standard
that every compiler groups its own extensions under a common name (for
example, GHC, HUGS, JHC, NHC, etc.) until they are in sufficiently common use to be
standardized independently (such as fundeps), at which stage there should
probably be a corresponding addendum to the standard for that extension.
</p>
<p>
Specifying extensions before the <code>module</code> keyword ensures that the
lexer and parser can find them before parsing of the actual module. I
recommend that bare modules without the <code>module</code> keyword cannot specify any
extensions, and therefore must be written in pure Haskell'.
</p>
<p>
The standard itself should not define any extensions and state that
the standard grammar and semantics describes the base language in
absence of any <code>import extension</code> clauses.
</p>
<p>
Each extension, including FFI, should be described in a separate addendum.
Once an extension has been fully defined and tested in production code, it
may be <em>blessed</em> by including it in the list of addenda to the standard, at
which case its name will change from compiler-specific (eg. <code>GHC woohoo</code>)
to standard (eg. <code>woohoo</code>.)
</p>
<h3 id="Pros">Pros</h3>
<ul><li>Addresses a pending language design goal.
</li><li>Useful for automatic documentation tools such as Haddock, which could
even generate a hyperlink from an extension name to the relevant
addendum when available.
</li><li>Simple to implement.
</li><li>Neat syntax.
</li><li>Backwards-compatible (introduces no keyword polution.)
</li><li>Makes all information required to compile a program available directly
in the source code, rather than in ad-hoc places such as command-line,
Cabal package descriptions, documentation, comments, pragmas and what-not.
</li><li>Returns all comments (including pragmas) to their original code as
semantically-neutral annotations on the source program.
</li></ul><p>
</p>
<h3 id="Cons">Cons</h3>
<ul><li>Some implementation hassles. The compiler must use either a predicated
parser and lexer (I believe most do already) or else parse the module
until it finds the "module" keyword collecting the extension clauses,
and then parse the actual module using an appropriate parser and
lexer chosen according to the specified extensions.
</li></ul>Resultshttps://prime.haskell.org/ticket/94#changelog
https://prime.haskell.org/ticket/95
https://prime.haskell.org/ticket/95#95: improve module interfacesWed, 22 Feb 2006 15:45:28 GMTmalcolm.wallace@…<p>
Proposal:
</p>
<p>
adopt <a class="wiki" href="https://prime.haskell.org/wiki/TagExportsWithNamespace">TagExportsWithNamespace</a> and <a class="wiki" href="https://prime.haskell.org/wiki/PermitSignaturesInExports">PermitSignaturesInExports</a>
</p>
<p>
I don't understand the <a class="missing wiki">NameSpace?</a> proposal: neither what it is trying to accomplish, not what it achieves. Could you be a little more explicit? Thanks, John
</p>
Resultshttps://prime.haskell.org/ticket/95#changelog
https://prime.haskell.org/ticket/97
https://prime.haskell.org/ticket/97#97: Collection library interfaceWed, 22 Mar 2006 00:04:48 GMT<p>
We should make a collection library interface, using whatever new features end up in Haskell'. See: <a class="ext-link" href="http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework</a>
</p>
Resultshttps://prime.haskell.org/ticket/97#changelog
https://prime.haskell.org/ticket/98
https://prime.haskell.org/ticket/98#98: Restricted Data Types NowWed, 22 Mar 2006 00:12:00 GMT<p>
We should adopt Oleg's "Restricted Data Types Now" approach for simpler cases, like Functor, that don't involve creating new type classes.
</p>
<pre class="wiki">class Functor f a b where
fmap :: (a -> b) -> f a -> f b
instance (Ord a, Ord b) => Functor Data.Set.Set a b where
...
</pre>Resultshttps://prime.haskell.org/ticket/98#changelog
https://prime.haskell.org/ticket/99
https://prime.haskell.org/ticket/99#99: Move existing named field (record) system to an addendum.Thu, 23 Mar 2006 16:03:58 GMTmalcolm.wallace@…<p>
This is a proposal to explicitly reject any new record system for Haskell-prime, but to keep the current named field system, possibly with some minor tweaking. However, the named field system would be moved to an addendum, which a future committee may see fit to discard in favour of some other record system.
</p>
<p>
See <a class="wiki" href="https://prime.haskell.org/wiki/ExistingRecords">ExistingRecords</a>.
</p>
Resultshttps://prime.haskell.org/ticket/99#changelog
https://prime.haskell.org/ticket/100
https://prime.haskell.org/ticket/100#100: Replace named fields with an extensible record systemThu, 23 Mar 2006 16:07:05 GMTmalcolm.wallace@…<p>
This proposal is to remove the existing named field system, and replace it with an extensible record system. Candidates for this new system are open for discussion, but Daan Leijen has several interesting variations which might be a good starting point.
</p>
Resultshttps://prime.haskell.org/ticket/100#changelog
https://prime.haskell.org/ticket/101
https://prime.haskell.org/ticket/101#101: Class AliasesSun, 26 Mar 2006 00:43:25 GMT<p>
See <a class="ext-link" href="http://repetae.net/john/recent/out/classalias.html"><span class="icon"></span>http://repetae.net/john/recent/out/classalias.html</a>
</p>
<pre class="wiki">class alias Num a = (Additive a, AdditiveNegation a,
Multiplicative a, FromInteger a) where
one = fromInteger 1
zero = fromInteger 0
negate x = zero - x
</pre>Resultshttps://prime.haskell.org/ticket/101#changelog
https://prime.haskell.org/ticket/102
https://prime.haskell.org/ticket/102#102: add Liberal Type SynonymsTue, 28 Mar 2006 11:14:57 GMTSimon Marlow<p>
See <a class="wiki" href="https://prime.haskell.org/wiki/LiberalTypeSynonyms">LiberalTypeSynonyms</a>
</p>
Resultshttps://prime.haskell.org/ticket/102#changelog
https://prime.haskell.org/ticket/104
https://prime.haskell.org/ticket/104#104: Add Time LibraryThu, 30 Mar 2006 05:38:12 GMTashley@…<ol><li>Add Data.Fixed module to the base package.
<a class="ext-link" href="http://semantic.org/TimeLib/doc/html/Data-Fixed.html"><span class="icon"></span>http://semantic.org/TimeLib/doc/html/Data-Fixed.html</a> <br />
<a class="ext-link" href="http://darcs.haskell.org/packages/time/fixed/Data/Fixed.hs"><span class="icon"></span>http://darcs.haskell.org/packages/time/fixed/Data/Fixed.hs</a>
</li></ol><ol start="2"><li>Add package "time" to the standard libraries.
<a class="ext-link" href="http://semantic.org/TimeLib/doc/html/"><span class="icon"></span>http://semantic.org/TimeLib/doc/html/</a> <br />
<a class="ext-link" href="http://darcs.haskell.org/packages/time/"><span class="icon"></span>http://darcs.haskell.org/packages/time/</a>
</li></ol><ol start="3"><li>Deprecate System.Time.
<a class="ext-link" href="http://haskell.org/ghc/dist/current/docs/libraries/base/System-Time.html"><span class="icon"></span>http://haskell.org/ghc/dist/current/docs/libraries/base/System-Time.html</a>
</li></ol>Resultshttps://prime.haskell.org/ticket/104#changelog
https://prime.haskell.org/ticket/105
https://prime.haskell.org/ticket/105#105: Disambiguate MonadPlusThu, 30 Mar 2006 05:49:17 GMTashley@…<p>
Reform the <code>MonadPlus</code> class along these lines:
</p>
<pre class="wiki">class Monad m => MonadZero m where
mzero :: m a
class MonadZero m => MonadPlus m where
mplus :: m a -> m a -> m a
class MonadZero m => MonadOr m where
morelse :: m a -> m a -> m a
</pre><p>
<a class="ext-link" href="http://haskell.org/haskellwiki/MonadPlus_reform_proposal"><span class="icon"></span>http://haskell.org/haskellwiki/MonadPlus_reform_proposal</a>
</p>
Resultshttps://prime.haskell.org/ticket/105#changelog
https://prime.haskell.org/ticket/107
https://prime.haskell.org/ticket/107#107: Add assertionsTue, 04 Apr 2006 20:48:26 GMT<p>
GHC currently has a nice feature for assertions, which allow the programmer to insert a condition which is asserted to be true. If the condition is in fact false, an error is raised which contains the source code line of the assertion. A compiler flag allows all assertions to be disabled.
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-assertions.html"><span class="icon"></span>http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-assertions.html</a>
</p>
<p>
Possible variations:
</p>
<ol><li>Have a form of 'assert' which can take an arbitrary string to which the source file location is prepended.
</li><li>assert can tie in to imprecise exceptions, if they are adopted, or a failed assertion can be bottom
</li><li>Remove the source line feature (makes the proposal simpler, but less useful because now all you get is the compiler flag to turn assertions off)
</li></ol>Resultshttps://prime.haskell.org/ticket/107#changelog
https://prime.haskell.org/ticket/108
https://prime.haskell.org/ticket/108#108: make toEnum and fromEnum take and return IntegersSun, 09 Apr 2006 23:07:00 GMT<p>
Change the signature of toEnum and fromEnum in the Enum a typeclass to
</p>
<pre class="wiki"> toEnum :: Integer -> a
fromEnum :: a -> Integer
</pre><p>
(they currently use Int)
</p>
<p>
It's possible, for example, to have Enumeratable types that are larger than Int
</p>
<p>
pros: No overflow possibilities
</p>
<p>
cons: efficiency
</p>
Resultshttps://prime.haskell.org/ticket/108#changelog
https://prime.haskell.org/ticket/109
https://prime.haskell.org/ticket/109#109: split Enum into two typeclassesSun, 09 Apr 2006 23:26:41 GMT<p>
The current uses of Enum are somewhat confusing — this is partially because of the name, but partially because two seperate interfaces are glued together. One provides Enumeration of all possible values and conversion to integers for binary storage, and the other provides sequences of values (usually arithmetic) (which [a..b], etc desugar to).
</p>
<pre class="wiki">class Enum a where
succ, pred :: a -> a
toEnum :: Int -> a
fromEnum :: a -> Int
instance Enum Integer
instance Enum Int
instance Enum Bool
instance Enum Ordering
instance Enum Word...
</pre><pre class="wiki">class ArithmeticSequence a where
stepFrom :: a -> [a] -- [n..]
stepFromThen :: a -> a -> [a] -- [n, n'..]
stepFromTo :: a -> a -> [a] -- [n..m]
stepFromThenTo :: a -> a -> a -> [a] -- [n,n'..m]
instance ArithmeticSequence Integer
instance ArithmeticSequence Int
instance ArithmeticSequence Bool
instance ArithmeticSequence Ordering
instance ArithmeticSequence Float
instance ArithmeticSequence Double
instance ArithmeticSequence Rational
instance ArithmeticSequence Word...
...
</pre><p>
Steppable may be a preferrable name.
</p>
<p>
pros:
</p>
<ul><li>Clearly divides two seperate uses, while keeping functionality.
</li><li>Can re-introduce relationship between Ix and Enum?
</li></ul><p>
cons:
</p>
<ul><li>Yet another typeclass.
</li><li>Slightly misleading name, as non-arithmetic structures _should_ be supported. Also a bit long.
</li><li>Automatically supporting such isn't trivial if they're not in Enum, though.
</li></ul>Resultshttps://prime.haskell.org/ticket/109#changelog
https://prime.haskell.org/ticket/110
https://prime.haskell.org/ticket/110#110: Generalize types of IO actionsFri, 21 Apr 2006 18:33:30 GMT<p>
One nice way to structure programs is to use monad transformers on top of IO. For example, one common technique is to use StateT or ReaderT to propagate custom state through IO code. This technique has two problems
</p>
<p>
1) It requires one to use 'liftIO' rather a lot, which is mildly irritating
</p>
<p>
2) It makes it very difficult to use higher-order IO combinators, such as try or bracket, which is highly irritating
</p>
<p>
This proposal involves generalizing the types of standard IO functions to make this use-case easier.
</p>
<p>
Conservative proposal:
</p>
<p>
Generalize higher order IO combinators to take a MonadIO context. For example, try and catch would then have types
</p>
<pre class="wiki">try :: MonadIO m => m a -> m (Either Exception a)
catch :: MonadIO m => m a -> (Exception -> m a) - > m a
</pre><p>
This allows one to use custom monads built on IO and still do correct exception handling, etc. without having to do lots of nasty monad unwrapping/rewrapping.
</p>
<p>
NOTE: This is not possible to implement. there is no way to 'rewind' a monad
in a generic way in order to implement try or catch. - <a class="missing wiki">JohnMeacham?</a>
</p>
<p>
NOTE: An alternative is to use a different version of Control.Exception that defines a typeclass as follows:
</p>
<pre class="wiki">class MonadIO m => MonadException m where
catch :: m a -> (Exception -> m a) -> m a
block, unblock :: m a -> m a
</pre><p>
This can be implemented for the common monad transformers, and all the other exception functions can be implemented just using the methods in the above typeclass, or using liftIO with the existing functions. A full implementation (not fully tested though) is attached. — Brian Hulley
</p>
<p>
NOTE: Even though not all uses of IO can be eliminated (eg when defining callback functions to use with FFI), the importance of having an Exception module which is not tied to concrete <code>IO</code> is that it would allow library writers which require <code>block</code>, <code>bracket</code> etc to use the more general <code>MonadException</code> in place of <code>IO</code>. If library writers do not do this, users of the library, which may be other libraries etc, are also tied down to concrete <code>IO</code>, so the longer we leave it, the more difficult it will be to "unconcretise" the code base. — Brian Hulley
</p>
<p>
More radical proposal:
</p>
<p>
Generalize the types of all standard library IO routines to take MonadIO contexts. For example,
</p>
<p>
putChar :: MonadIO m ⇒ Char → m ()
</p>
<p>
getChar :: MonadIO m ⇒ m Char
</p>
<p>
These could easily be defined in terms of lower level IO primitives:
</p>
<p>
putCharIO :: Char → IO ()
</p>
<p>
putCharIO = …
</p>
<p>
putChar c = liftIO (putChar c)
</p>
<p>
Now you can eliminate a bunch of noisy calls to liftIO in client code.
</p>
<p>
NOTE: This should be quite trivial to implement for all functions which just use <code>IO</code> in the return value. When <code>IO</code> is used in other positions it is unlikely to be possible to implement except by replacing the other occurrence of <code>IO</code> by <code>MonadIOU</code> defined by:
</p>
<pre class="wiki"> class MonadIO m => MonadIOU m where
getUnliftIO :: m (m a -> IO a)
</pre><p>
Unfortunately only a few of the monad transformers support this operation (eg <code>ReaderT</code> ) but at least it's better than nothing. An alternative would be to define special typeclasses for related sets of operations if this would allow more monad transformers to be supported by the particular operations, or to add first-order api functions which a library user could use to build a specialised version of the higher order function for a specific monad. — Brian Hulley
</p>
Resultshttps://prime.haskell.org/ticket/110#changelog
https://prime.haskell.org/ticket/111
https://prime.haskell.org/ticket/111#111: remove local fixity declarationsMon, 18 Sep 2006 00:34:14 GMTDoaitse Swierstra<p>
On page 38 the language definition allows local fixity declarations. Since no-one seems to be using these, not to be aware of the possibility to do so, I propose to remove them. The necessity to inspect every block to see whether there are fixity declarations, and the necessity to parse all expressions twice is cumbersome.
</p>
Resultshttps://prime.haskell.org/ticket/111#changelog
https://prime.haskell.org/ticket/112
https://prime.haskell.org/ticket/112#112: Break unnecessary dependencies between Haskell numeric classesWed, 20 Sep 2006 19:51:39 GMT<p>
Motivation:
</p>
<p>
The Haskell numeric classes contain some interdependencies that look rather odd to a mathematician. For example, why do you have to be Show in order to be Num, and why do you have to be Enum in order to be Integral. These dependencies are not justified by mathematical considerations, and make it hard to represent some mathematical concepts in Haskell.
</p>
<p>
For example, consider the Gaussian integers - numbers of the form a+bi, where a and b are integers, and i is the square root of -1. (Complex Integer, if you like.) There is a division with remainder algorithm for the Gaussian integers, so that we would like to declare them as an instance of Integral, and define the quotRem function. However, to do this we would have to declare them as an instance of Enum - and this makes no sense - there is no natural way to define the Enum functions on the Gaussian integers.
</p>
<p>
For similar reasons, the dependency of Integral on Real is suspect - there is no natural way to define toRational on the Gaussian integers.
</p>
<p>
The dependency of <a class="missing wiki">RealFrac?</a> on Fractional is also unnecessary - what have floor, ceiling etc got to do with recip?
</p>
<p>
Note that breaking these dependencies will not break any existing code. At present, if I declare a type T to be a Num instance, I must also declare it to be an Eq instance and a Show instance. If the dependency is broken, that is, if
</p>
<p>
class (Eq a, Show a) ⇒ Num a
</p>
<p>
is replaced by
</p>
<p>
class Num a
</p>
<p>
then existing code will still work.
</p>
<p>
What will have changed is that it will now be possible to declare a type T to be a Num instance without also declaring it to be an Eq and a Show instance.
</p>
<p>
Proposal:
</p>
<p>
Conservative version:
</p>
<p>
Replace the existing Prelude class declarations with:
</p>
<ol><li>class Eq a ⇒ Num a — remove dependency on Show
</li></ol><ol start="2"><li>class Num a ⇒ Integral a — replace dependency on Real, Enum by dependency on Num
</li></ol><ol start="3"><li>class Real a ⇒ <a class="missing wiki">RealFrac?</a> a — remove dependency on Fractional
</li></ol><p>
Radical version:
</p>
<p>
In addition to the above:
</p>
<ol start="4"><li>Split abs and signum out from Num into a new
</li></ol><p>
class Num a ⇒ Quantity a
</p>
<p>
(There are plenty of objects in mathematics for which the arithmetical operations +,-,* make sense, but the size and direction operations abs and signum do not - for example polynomials, matrices.)
</p>
<ol start="5"><li>Amalgamate classes Real and <a class="missing wiki">RealFrac?</a> - Real no longer has any purpose as a distinct class. The new class should probably be called Real.
</li></ol><p>
See also: <a class="wiki" href="https://prime.haskell.org/wiki/NumericClasses">NumericClasses</a>.
</p>
Resultshttps://prime.haskell.org/ticket/112#changelog
https://prime.haskell.org/ticket/114
https://prime.haskell.org/ticket/114#114: introduce lambda-match (explicit match failure and fall-through)Mon, 30 Oct 2006 23:19:16 GMTclaus.reinke@…<h2 id="name:">name:</h2>
<p>
<strong>introduce lambda-match (explicit match failure and fall-through)</strong>
</p>
<h2 id="summary:">summary:</h2>
<p>
Haskell 98 provides *two different translations* of lambda
abstractions involving pattern matching, only one of which is
directly accessible (Section 3.3 - the other is embedded in the
translation of do-notation, see "ok" in Section 3.14).
</p>
<p>
Providing explicit source notation for the second translation,
substantially simplifies programmability of pattern-match
fall-through by reification of pattern-match failure, two
central language features that are so far only available
through the built-in, non-composable case construct.
</p>
<h2 id="what:">what:</h2>
<p>
In Section 3.3, the translation for conventional lambda
abstractions with patterns is given as
</p>
<pre class="wiki"> [| \p1 .. pn-> e |] = \x1 .. xn-> case (x1,..,xn) of
(p1,..,pn) -> e
</pre><p>
with xi fresh identifiers, and pattern-match failure resulting in
_|_. the latter is unfortunate, and results in partial functions the
coverage of which cannot be combined, but it is forced by
translation into conventional lambda calculus.
</p>
<p>
since computational lambda calculus (\-M) has become a central part
of Haskell programming practice, there shall be an alternative form
of lambda abstraction, dubbed here <strong>lambda-match</strong>, with associated
translation into \-M:
</p>
<pre class="wiki"> [| |p1 .. pn-> e |] = \x1 .. xn-> case (x1,..,xn) of
{ (p1,..,pn) -> return e;
_ -> fail "no match" }
</pre><p>
<em>[note1: this is the translation in principle - in practice, to enable composition of lambda-matches without further language extensions, a slight modification is needed, wrapping the right-hand sides of the case in a Match constructor, see library, examples, and patch]</em>
</p>
<p>
a library for composing these lambda-matches provides for
composition of alternative lambda-matches ( <code>(+++)</code> ), match failure
(<code>nomatch</code>, <code>matchError <message></code>) and embedding of the explicit
match monad into pure expressions (<code>splice</code>, where
<code> \p1..pn->e = splice |p1..pn->e </code>, also <code>spliceE</code> -preserving
error messages by using <code>(Either String)</code> as the match monad, and
<code>allMatches</code>, using the <code>[]</code> monad to deliver all successful matches).
other lambda-match related auxiliaries include <code>caseOf</code> as a
user-defined version of <code>case _ of _</code>, argument supply to matches
( <code>(>|)</code> ), and joining of nested matches (so that, for instance
</p>
<pre class="wiki"> nest (|<outer>-> (|<inner>-> expr)) = (|<outer> <inner>-> expr)
</pre><p>
).
</p>
<p>
<em>[note2: an alternative translation would use do-notation instead of case as the target:
</em></p>
<pre class="wiki"> [| |p1 .. pn-> e |] = \x1 .. xn-> do {
(p1,..,pn) <- return (x1,..,xn);
return e }
</pre><p>
both translations easily accomodate guards and pattern guards as well, the former by building on existing support for these two features in case constructs, the latter without requiring any previous implementation of pattern guards, by lifting (pattern)guards into the match monad:
</p>
<pre class="wiki"> [| pat <- expr |] = pat <- return expr
[| expr |] = guard expr
</pre><p>
]<em>
</em></p>
<h2 id="implementationimpact:">implementation impact:</h2>
<p>
minimal - limited to an extension in parser/desugarer, employing
previously inaccessible syntax for lambda-match, and a slight
variation of the existing lambda translation; also adds a small
library to support composition of matches.
</p>
<p>
<em>[note3: an updated draft of the composition library and a patch for GHC (about a dozen new lines in the parser, changed from the original proposal email only in requiring parentheses) are provided as attachments to this proposal, together with some examples (updated since original email). please add patches for other Haskell implementations, and test whether they can handle the library code (tried for Hugs and GHC)]</em>
</p>
<h2 id="motivation:">motivation:</h2>
<ol><li>patterns/guards in lambda abstractions are of limited use if match failure cannot be handled
</li></ol><ul><li>match failure in lambda abstractions can only lead to an exception
</li></ul><ol start="2"><li>the only direct way of handling match-failure and fall-through to other alternatives, without something like lambda-match, is not by composing alternatives, but within the built-in construct case; a slightly more indirect way employs the built-in do notation, where again the functionality is not available to (monadic) composition, but only within the do notation
</li></ol><ol start="3"><li>workarounds to mimick the functionality of lambda-match without syntactic sugar (translating into lambda+do or lambda+case) are so cumbersome and unreadable as to be unusable in practice (translating into lambda+list-comprehension is almost readable, but restricted to lists). compare:
<pre class="wiki"> (|(Just x)-> x)
\fresh->do { Just x <- return fresh; return x }
\fresh->case fresh of { Just x -> return x; _ -> fail "no match" }
\fresh->[ x | Just x <- [fresh] ]
</pre></li></ol><ol start="4"><li>since the functionality is already available in the language, and even explicitly used in the report for a feature as frequently used as the do notation, there should be a language construct making this functionality directly accessible
</li></ol><ul><li>the functions named "ok", constructed in Section 3.14 of the report, can be expressed directly using lambda-match (the library contains a function <code>ok</code> for this purpose)
<pre class="wiki"> do { p <- e; stmts } = e >>= ok (|p-> stmts)
</pre></li></ul><ol start="5"><li>unlike lambda, lambda-match truly expresses a single alternative in a case statement, as a first-class language expression - it can be named, passed as parameter or result, manipulated as a function, and composed with other alternatives. as a corollary, lambda, case, and other monadic abstractions can be defined easily in terms of lambda-match and its support library
<pre class="wiki"> - splice (|x->expr) = \x->expr
- case expr of { pat -> expr; ..} = caseOf expr $ (| pat -> expr ) +++ ..
- ok (|pat->do statements) = \fresh->do { pat <- return fresh; statements }
</pre></li></ol><ol start="6"><li>while the present proposal suggests lambda-match as a small extension to the language, it also lays the groundwork for a major simplification
</li></ol><ul><li>as points 4 and 5 indicate, several core constructs of Haskell need no longer be considered as built into the language, but become user-definable; this would simplify the language definition, implementations, teaching, learning, and tool building
</li></ul><ol start="7"><li>although the present lambda-match proposal is fairly conservative, it also aims to lay the groundwork for a substantial increase in language expressiveness
</li></ol><ul><li>the fundamental idea, used here only to reify pattern-match failure and fall-through, is that of replacing built-in pattern matching with user-definable monadic data parsers and associated combinators
</li></ul><ul><li>this same idea lies at the heart of a more radical decomposition of pattern-matching, which has been studied in the literature as first-class patterns (eg, Tullsen, PADL2000)
</li></ul><ul><li>having pattern-match alternatives as first-class language constructs also paves the way for user-defined pattern abstractions, or more generally, views (various literature)
</li></ul><p>
this completes the main part of this proposal.
</p>
<hr />
<p>
relevant mailing list threads include the main proposal thread and an examples thread demonstrating monadic data parsing and views:
</p>
<ul><li><a class="ext-link" href="http://www.haskell.org/pipermail/haskell-prime/2006-October/001797.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-prime/2006-October/001797.html</a>
</li></ul><ul><li><a class="ext-link" href="http://www.haskell.org/pipermail/haskell-prime/2006-November/001892.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-prime/2006-November/001892.html</a>
</li></ul><ul><li><a class="ext-link" href="http://www.haskell.org/pipermail/haskell-prime/2006-November/001915.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-prime/2006-November/001915.html</a>
</li></ul><hr />
<h2 id="contextandreferences:">context and references:</h2>
<p>
as has been pointed out in the thread on replacing and improving
pattern guards, Haskell's pattern matching support, even before
pattern guards, is monolithic (built-in case is the only way to handle
multiple alternative matches) rather than compositional (lambdas
seem to represent individual alternatives, but cannot be composed on
match fall-through). this implies increased complexity of the language
definition, limited expressiveness of its features, and more difficult
reasoning, when compared with alternative models (eg, Wolfram Kahl has
suggested to adapt his pattern match calculus for Haskell). see, eg.:
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-prime/2006-October/001713.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-prime/2006-October/001713.html</a>
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-prime/2006-October/001720.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-prime/2006-October/001720.html</a>
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-prime/2006-October/001723.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-prime/2006-October/001723.html</a>
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-prime/2006-October/001724.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-prime/2006-October/001724.html</a>
</p>
<p>
as well as the PMC home page
</p>
<p>
<a class="ext-link" href="http://www.cas.mcmaster.ca/~kahl/PMC/"><span class="icon"></span>http://www.cas.mcmaster.ca/~kahl/PMC/</a>
</p>
<p>
and a newer thread discussing some differences between
this lambda-match proposal and PMC
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-prime/2006-October/001823.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-prime/2006-October/001823.html</a>
</p>
<p>
in principle, replacing Haskell's current pattern matching support
with a simpler, more compositional model, and defining the current
constructs on top of that new core is the way forward, IMHO. in
practice, however, I suspect that the committee is less than tempted
to introduce such a substantial simplification for Haskell'.
</p>
<p>
the present proposal is an attempt at a compromise, suggesting a
minimal language change to introduce compositional pattern-match
failure and fall-through. with lambda-match, it implements only a
single language extension (as syntactic sugar), delegating the rest
of the functionality to a library. without the sugar, the result of the
by-hand translation becomes so hard to read as to be near
unusable, while the chosen form of sugaring allows to provide
most of the language features discussed in the earlier threads to
be provided as a library. this does seem to be a useable balance.
</p>
<p>
building constructs of the simpler pattern-match model on top of
the more complex one is somewhat irksome from a language design
perspective, but does at least gain the expressiveness of the simpler
model. if programmers make substantial use of this new functionality
in Haskell' (as I strongly suspect they will - I have been doing similar
translations by hand for some time now), it will be up to Haskell' ' to
turn the table, and to define the current complex model on top of a
compositional one.
</p>
<p>
as a preview of this anticipated language refactoring;), it is instructive
to compare the two alternative translations of lambda-match sketched
above:
</p>
<ul><li>the first directly builds on the existing, complex case constructs with their built-in (pattern) guards and match fall-through support; this eases adding the new, simpler features to implementations that support the old, complex ones (like GHC), but completely foregoes any attempt to simplify those implementations in the process; <em>[the attached patch for GHC follows this route]</em>
</li></ul><ul><li>the second translation avoids any direct reference to case, employing do-notation instead; this requires slightly more effort, eg. in translating pattern guards into the match monad, but is eminently suitable for adding the new features to implementations that do not support pattern guards yet, or that simply want to reduce the number of built-in constructs. <em>[patchers for Hugs, etc., might want to follow this route]</em>
</li></ul><p>
finally, while it is not directly relevant for the present proposal,
Tullsen's PADL 2000 paper investigates one way in which monadic data
parsing can be built on to go beyond first-class match alternatives
all the way to first-class patterns:
</p>
<p>
<a class="ext-link" href="http://citeseer.ist.psu.edu/tullsen00first.html"><span class="icon"></span>http://citeseer.ist.psu.edu/tullsen00first.html</a>
</p>
<p>
this, in turn, relates directly to Views and <a class="wiki" href="https://prime.haskell.org/wiki/PatternSynonyms">PatternSynonyms</a>.
</p>
Resultshttps://prime.haskell.org/ticket/114#changelog
https://prime.haskell.org/ticket/116
https://prime.haskell.org/ticket/116#116: Read Char instance, for [Char], and ['a', 'b'] syntaxSun, 04 Mar 2007 14:30:30 GMTIan Lynagh<p>
Haskell 98, in section 10.4, states:
</p>
<pre class="wiki">readsPrec will parse any valid representation of the standard types apart
from strings, for which only quoted strings are accepted
</pre><p>
hugs follows this:
</p>
<pre class="wiki">Hugs.Base> read "['a', 'b']" :: String
"
Program error: Prelude.read: no parse
</pre><p>
while GHC ignores it:
</p>
<pre class="wiki">Prelude> read "['a', 'b']" :: String
"ab"
</pre><p>
The GHC libraries source shows that this is a wilful variation from H98:
</p>
<pre class="wiki"> readListPrec =
parens
( do L.String s <- lexP -- Looks for "foo"
return s
+++
readListPrecDefault -- Looks for ['f','o','o']
) -- (more generous than H98 spec)
</pre><p>
I do not see the point of this inconsistency, so I believe we should consider changing it for Haskell'.
</p>
Resultshttps://prime.haskell.org/ticket/116#changelog
https://prime.haskell.org/ticket/117
https://prime.haskell.org/ticket/117#117: Allow unnamed record fieldsSun, 04 Mar 2007 14:37:57 GMTIan Lynagh<p>
It would be nice to be able to have unnamed fields in a record to save having to invent names for everything, e.g.
</p>
<pre class="wiki">data Foo = Foo { _ :: Int, _ :: Char, pos :: Position }
| Bar { _ :: String, pos :: Position }
</pre><p>
The <code>Show</code> instance would have to use the non-record syntax, but other than that I don't think there would be any problems.
</p>
Resultshttps://prime.haskell.org/ticket/117#changelog
https://prime.haskell.org/ticket/118
https://prime.haskell.org/ticket/118#118: Remove libraries from the report (to the greatest extent possible)Mon, 05 Mar 2007 22:23:14 GMTIan Lynagh<p>
There is a tension between having the
ability to fix and evolve the libraries, and people wanting to write
books on how to use Haskell' (without having to define (+) and map etc
themselves!).
</p>
<p>
We've been lucky thus far that having the hierarchial libraries
completely disjoint with the report has meant that we have been able add
to and alter things even in the base package without breaking anything
assuming Haskell 98. We haven't had to worry about clashing with a user's
<code>Data.Function</code> module as the Haskell 98 namespace is flat, nor worry whether
adding an <code>on</code> function will cause ambiguous-import errors in someone's
Haskell 98 program.
</p>
<p>
We still get the occasional person in #haskell asking why they can't
find the <code>fromInt</code> their book talks about, and I think that was probably
published in the 90s?
</p>
<p>
This proposal is that books should be about
</p>
<pre class="wiki">Haskell', base 3.0.* and mtl 2.1.*
</pre><p>
and Haskell'
should say pretty much nothing about libraries. This gives book writers
the ability to target something (and even if newer library versions come out,
the old ones will still be available; old branches can even be maintained so they
stay working with newer implementations if necessary) while still letting us
remain agile.
</p>
<p>
The report will probably need to continue to use things like <code>head</code> in
non-normative sections such as examples.
</p>
<p>
There will probably also need to be a package defined by Haskell' that includes things like seq and the derivable classes. It might also define IO primitives etc,
but these might be better left unspecified, with the (portable) <code>io</code> package depending on <code>$impl-io</code> (e.g. <code>ghc-io</code>) which defines suitable primitives for the implementation.
</p>
Resultshttps://prime.haskell.org/ticket/118#changelog
https://prime.haskell.org/ticket/119
https://prime.haskell.org/ticket/119#119: splitAt should be strict in its first argumentMon, 05 Mar 2007 22:55:37 GMTIan Lynagh<p>
The below is a slightly editted version of <a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/1182"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/1182</a>
</p>
<hr />
<p>
The <a class="ext-link" href="http://haskell.org/onlinereport/standard-prelude.html"><span class="icon"></span>H98 report</a> defines <code>splitAt</code> by:
</p>
<pre class="wiki">splitAt :: Int -> [a] -> ([a],[a])
splitAt n xs = (take n xs, drop n xs)
</pre><p>
So we would expect:
</p>
<pre class="wiki">splitAt _|_ xs = (take _|_ xs, drop _|_ xs)
</pre><p>
however, both GHC and hugs have (different) implementations that are strict in 'n', that is:
</p>
<pre class="wiki">split _|_ xs = _|_
</pre><p>
These cases can be distinguished with the expression:
</p>
<pre class="wiki">case splitAt undefined [] of (_,_) -> ()
</pre><p>
We propose splitAt be changed to be strict in its first argument for Haskell'.
</p>
Resultshttps://prime.haskell.org/ticket/119#changelog
https://prime.haskell.org/ticket/120
https://prime.haskell.org/ticket/120#120: Should sum and product be strict? Or have strict variants?Sun, 11 Mar 2007 22:59:55 GMTIan Lynagh<p>
Currently sum and product are lazy according to the report. GHC matches the report, while hugs makes them strict. nhc98 recently made them strict, but reverted to lazy upon the report's definition being pointed out.
</p>
<p>
For most cases, such as summing a list of Ints or Integers, strict behaviour is desirable. Thus we propose that either sum and product are made strict (i.e. use foldl') or strict variants sum' and product' are made available as well.
</p>
<p>
Here is a program to demonstrate the difference:
</p>
<pre class="wiki">import Data.List
data Foo = Zero | A | B | C
deriving (Eq, Show)
instance Num Foo where
_ + Zero = error "Adding Zero"
_ + A = error "Adding A"
_ + B = error "Adding B"
_ + C = C
fromInteger 0 = Zero
xs = [A, B, C]
f = foldl (+) 0 xs
f' = foldl' (+) 0 xs
s = sum xs
</pre><p>
GHC and Haskell 98 say:
</p>
<pre class="wiki">*Main> f
C
*Main> f'
*** Exception: Adding A
*Main> s
C
*Main>
</pre><p>
while hugs and this proposal say:
</p>
<pre class="wiki">Main> f
C
Main> f'
Program error: Adding A
Main> s
Program error: Adding A
Main>
</pre>Resultshttps://prime.haskell.org/ticket/120#changelog
https://prime.haskell.org/ticket/121
https://prime.haskell.org/ticket/121#121: ExitCode consistencyWed, 14 Mar 2007 23:26:56 GMTIan Lynagh<p>
Haskell 98 says
</p>
<pre class="wiki">Computation system cmd returns the exit code produced when the operating system processes the command cmd.
</pre><p>
and
</p>
<pre class="wiki">The exact interpretation of code is operating-system dependent.
</pre><p>
However, on Unix systems <code>system "exit 3" >>= print</code> prints <code>ExitFailure 3</code> under ghc and hugs, but <code>ExitFailure 768</code> under nhc98, despite both being the same operating system.
</p>
<p>
It may not be possible to fix this within the boundaries of the report, but Something Must Be Done somewhere.
</p>
<p>
Additionally, the report says
</p>
<pre class="wiki">The value exitFailure is equal to exitWith (ExitFailure exitfail), where exitfail is implementation-dependent.
</pre><p>
while <code>operating-system dependent</code> seems better than <code>implementation-dependent</code>.
</p>
Resultshttps://prime.haskell.org/ticket/121#changelog
https://prime.haskell.org/ticket/122
https://prime.haskell.org/ticket/122#122: clarify literate script syntaxThu, 15 Mar 2007 01:13:57 GMTIan Lynagh<p>
The syntax for literate scripts needs to be clarified. See the thread
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2007-March/023027.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2007-March/023027.html</a>
for more details.
</p>
<p>
The report should also give a reference unlitter. I'll attach (an untested) one from the above thread.
</p>
Resultshttps://prime.haskell.org/ticket/122#changelog
https://prime.haskell.org/ticket/123
https://prime.haskell.org/ticket/123#123: Fix Ord so Ord Double and Ord Float make senseThu, 22 Mar 2007 00:08:36 GMTIan Lynagh<p>
Consider:
</p>
<pre class="wiki">let n = 0/0 :: Double in (n `compare` n, n < n, n == n, n > n)
</pre><p>
In GHC and YHC this gives
</p>
<pre class="wiki">(GT,False,False,False)
</pre><p>
while in hugs it gives
</p>
<pre class="wiki">(EQ,False,False,False)
</pre><p>
Neither of these is very satisfactory, as I would expect
</p>
<pre class="wiki">x `compare` y === EQ => (x == y) === True
x `compare` y === GT => (x > y) === True
</pre><p>
and it's even less pleasant that the implementations differ for no good
reason.
</p>
<p>
The Haskell report isn't currently very helpful on how comparing exceptional
Doubles should behave, as it doesn't even say you need to have NaN etc:
</p>
<pre class="wiki">http://haskell.org/onlinereport/basic.html#sect6.4
The results of exceptional conditions (such as overflow or
underflow) on the fixed-precision numeric types are undefined; an
implementation may choose error (_|_, semantically), a truncated
value, or a special value such as infinity, indefinite, etc.
</pre><p>
Four possible solutions to the problem have been proposed.
While Haskell' would presumably continue not to legislate what
implementations should do in this case, some of the solutions
require changes to the report, so we do need to discuss it in
the context of Haskell'.
</p>
<p>
The possible solutions are:
</p>
<ul><li><code>compare</code> should raise an exception (Haskell' doesn't need to be changed)
</li><li><code>compare</code>, <code>(<)</code>, <code>(>)</code>, etc should raise an exception (Haskell' doesn't need to be changed)
</li><li>There should be no <code>Ord</code> instance for <code>Float</code> and <code>Double</code> (changes needed for Haskell')
</li><li>Add an <code>Incomparable</code> constructor to <code>Ordering</code> (changes needed for Haskell')
</li></ul>Resultshttps://prime.haskell.org/ticket/123#changelog
https://prime.haskell.org/ticket/124
https://prime.haskell.org/ticket/124#124: Do not import the Prelude by default for proper modulesSun, 25 Mar 2007 15:03:22 GMTIan Lynagh<p>
In a cross-posted thread starting:
</p>
<ul><li><a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2007-March/007236.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2007-March/007236.html</a>
</li><li><a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2007-March/023826.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2007-March/023826.html</a>
</li></ul><p>
it was proposed that a module beginning <code>module Foo</code> would not implicitly import the Prelude. Modules without this would still import the Prelude. Interactive environments would have the Prelude in scope unless they have loaded a module beginning <code>module Foo</code>.
</p>
<p>
In terms of changes to the report, 5.1 "Module Structure" would be changed to say that if no header is given then
</p>
<pre class="wiki">module Main (main) where
import Prelude
</pre><p>
is prepended.
</p>
<p>
See also <a class="new ticket" href="https://prime.haskell.org/ticket/58" title="#58: task: prelude re-organisation proposal (new)">#58</a> and <a class="wiki" href="https://prime.haskell.org/wiki/Prelude">Prelude</a>.
</p>
Resultshttps://prime.haskell.org/ticket/124#changelog
https://prime.haskell.org/ticket/41
https://prime.haskell.org/ticket/41#41: add LambdaCaseFri, 16 Dec 2005 23:41:54 GMTijones<p>
See <a class="wiki" href="https://prime.haskell.org/wiki/LambdaCase">LambdaCase</a> (see also <a class="wiki" href="https://prime.haskell.org/wiki/MultiWayIf">MultiWayIf</a>, <a class="new ticket" href="https://prime.haskell.org/ticket/77" title="#77: enhancement: add MultiWayIf (new)">#77</a>)
</p>
Resultshttps://prime.haskell.org/ticket/41#changelog
https://prime.haskell.org/ticket/77
https://prime.haskell.org/ticket/77#77: add MultiWayIfWed, 25 Jan 2006 13:06:04 GMTSimon Marlow<p>
see <a class="wiki" href="https://prime.haskell.org/wiki/MultiWayIf">MultiWayIf</a>
</p>
Resultshttps://prime.haskell.org/ticket/77#changelog
https://prime.haskell.org/ticket/106
https://prime.haskell.org/ticket/106#106: Adding deepSeq/strict to Haskell' beside seq.Thu, 30 Mar 2006 22:51:03 GMTandy@…<p>
We are considering deepSeq for Haskell'.
See <a class="wiki" href="https://prime.haskell.org/wiki/deep_seq">deep_seq</a> for more details.
</p>
Resultshttps://prime.haskell.org/ticket/106#changelog