Wolfgang Jeltsch [EMAIL PROTECTED] writes:
Also, toEnum and fromEnum would make more sense mapping from and to
Integer.
Why do we need toEnum and fromEnum at all? As far as I know, they are merely
there to help people implement things like enumFrom.
They are often useful for writing
On 21 March 2006 03:10, John Meacham wrote:
On Mon, Mar 20, 2006 at 09:39:41AM -0500, Manuel M T Chakravarty
wrote:
Apart from the syntactic issues, does anybody else support the idea
of strict tuples as proposed? I just want to know whether I am
alone on this before putting it on the
On 3/21/06, Simon Marlow [EMAIL PROTECTED] wrote:
By all means have strict tuples in a library somewhere.They don't needto have special syntax.I have a module Data.Pair which provides pairs with different strictness properties. Perhaps it can be used as a startingpoint.
Cheers,/Josef
John Meacham:
On Mon, Mar 20, 2006 at 09:39:41AM -0500, Manuel M T Chakravarty wrote:
Apart from the syntactic issues, does anybody else support the idea of
strict tuples as proposed? I just want to know whether I am alone on
this before putting it on the wiki.
I have a few issues
On Tue, Mar 21, 2006 at 02:27:37PM -0500, Manuel M T Chakravarty wrote:
strictness does not belong in the type system in general. strictness
annotations are attached to the data components and not type components
in data declarations because they only affect the desugaring of the
you're right about interactions in general. but do you think constructor
classes specifically would pose any interaction problems with FDs?
You have to be more careful with unification in a higher-kinded setting.
I am not sure how to do that with CHRs.
to quote from the ATS paper: just like
Greetings,
While discussion on this mailing list has been coming fast furious,
actual tangible progress, even as measured on the wiki, has not been as
fast.
To remedy this, we propose to focus immediately and intently on a few of
the most critical topics, and to focus all of our energies on
Am Dienstag, 21. März 2006 02:47 schrieb Aaron Denney:
[...]
No, I use them. In my opinion, it makes much more sense to write succ n
than n + 1.
Agreed, for non-arithmetical types.
I think, it's perfectly sensible for arithmetical types like Integer. If you
mean “the next integer” then
Am Dienstag, 21. März 2006 10:08 schrieb Malcolm Wallace:
Wolfgang Jeltsch [EMAIL PROTECTED] writes:
[...]
Why do we need toEnum and fromEnum at all? As far as I know, they are
merely there to help people implement things like enumFrom.
They are often useful for writing serialisation
Am Dienstag, 21. März 2006 11:28 schrieb Bulat Ziganshin:
[...]
as i said, shebang patterns allow only to specify that IMPLEMENTATION
of some function is strict. this helps only when this function are
called directly. they can't help when function is passed as parameter
or enclosed in data
On 3/20/06, Ashley Yakeley [EMAIL PROTECTED] wrote:
Never as far as I can imagine. The 'a' parameter will be taken by a
phantom type.
http://haskell.org/haskellwiki/Phantom_type
Now I don't recall, but is it allowed to do:
data HasResolution a = Fixed a = ...?
--
Taral [EMAIL PROTECTED]
You
On 3/21/06, isaac jones [EMAIL PROTECTED] wrote:
I'd like to ask folks to please bring currently open threads to a close
and to document the consensus in tickets. Anyone can edit tickets, so
please don't be shy.
Claus, can you document some of your FD work in the
FunctionalDependencies
On 3/18/06, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
Of course, the caller could invoke addmul using a bang patterns, as in
let ( !s, !p ) = addmul x y
in ...
but that's quite different to statically knowing (from the type) that
the two results of addmul will already be
Taral wrote:
Now I don't recall, but is it allowed to do:
data HasResolution a = Fixed a = ...?
Not usefully.
data T a = MkT a
data C a = T a = MkT a
It's allowed, but it doesn't do what you probably want. All it does is
change the type of the constructor MkT.
If the parameter a to
On Tue, 2006-03-21 at 15:27 -0800, Ashley Yakeley wrote:
isaac jones wrote:
The topics that John and I feel are critical, and rather unsolved,
are:
* The class system (MPTC Dilemma, etc)
* Concurrency
* (One more, perhaps standard libraries)
Could you summarise the current state
I have created a ticket to make a standard collection interface. It is here:
http://hackage.haskell.org/trac/haskell-prime/ticket/97
Obviously, it will be tough to figure out what the library can look
like without knowing what MPTC's will look like.
Jim
On 2/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
It seems we can emulate the restricted data types in existing
Haskell.
I have proposed this for Haskell' libraries. See
http://hackage.haskell.org/trac/haskell-prime/ticket/98
Jim
___
Does this come under the standard libraries topic? I would like to see
the MonadPlus class disambiguated:
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
On 3/21/06, Ashley Yakeley [EMAIL PROTECTED] wrote:
Not usefully.
data T a = MkT a
data C a = T a = MkT a
It's allowed, but it doesn't do what you probably want. All it does is
change the type of the constructor MkT.
I think it also allows the inference of HasResolution a from Fixed a,
19 matches
Mail list logo
