On Fri, Feb 17, 2006 at 01:45:27AM +0200, Einar Karttunen wrote:
I would like to propose two pragmas to be included in Haskell'
for use with FFI. One for specifying the include file defining
the foreign import (INCLUDE in ghc) and an another for defining
a library that the foreign import
Jared Updike [EMAIL PROTECTED] wrote:
I am not sure if this has been mentioned before, but something I
would really find useful is the ability to tell Haskell to export
everything in a function except for some named functions.
No one has responded so ...
I believe some people (perhaps
On 21/02/06, Malcolm Wallace [EMAIL PROTECTED] wrote:
There is also the issue that we might adopt the proposal to allow (and
perhaps eventually, to require) type signatures on export lists. If so,
then it would be kind of ridiculous to have interface signatures only
for the things you are
On Mon, 2006-02-20 at 19:59 -0800, John Meacham wrote:
On Fri, Feb 17, 2006 at 01:45:27AM +0200, Einar Karttunen wrote:
I would like to propose two pragmas to be included in Haskell'
for use with FFI. One for specifying the include file defining
the foreign import (INCLUDE in ghc) and an
On Tuesday 21 February 2006 11:40, Malcolm Wallace wrote:
Jared Updike [EMAIL PROTECTED] wrote:
I am not sure if this has been mentioned before, but something I
would really find useful is the ability to tell Haskell to export
everything in a function except for some named functions.
Hello,
I have some proposals for changes of the hierarchical module system as it is
at the moment.
Goals:
- easy refactoring at Module/Package level
- easier import/export of trees of modules (useful for any larger library)
- relative imports/exports
- deep import or export lists
Hi all,
Georg Martius wrote:
I have some proposals for changes of the hierarchical module system as
it is at the moment.
[...]
The hierarchical name can be derived from the place in the filesystem.
This is not a comment about the above proposal in itself, which arguably
has its merits,
Not quite the same complaint, but I've always been bothered by the
inconsistent use of =. I would prefer A = B to mean if A, then
B.
that keeps bugging me, too. but switching the implication is not going
to help (although others have proposed the same). here's how I keep
my peace with that
On Tue, Feb 21, 2006 at 03:50:29PM +, Henrik Nilsson wrote:
I'm already somewhat unhappy about the way most present Haskell tools
map module names to path names (I'd generally prefer to have the
possibility to flatten my file hierarchies by, say, using dots in
my file names), but at least
On 2/22/06, Claus Reinke [EMAIL PROTECTED] wrote:
class Monad m= MonadPlus mwhere ... class Ord a= Ix awhere ... instance Integral a= Eq (Ratio a)where ...
still difficult?-) works just as well when the constraint lists get longer.This is the style I've adopted and it makes things a little better
Claus Reinke wrote:
class Monad m = MonadPlus mif ..oops..
if Monad m, then declare MonadPlus m as follows..
This gloss doesn't make sense. The act of declaration is a constant
static property of the module, and cannot be conditional on the property
of a variable. The module
On 21/02/06, Ashley Yakeley [EMAIL PROTECTED] wrote:
Sebastian Sylvan wrote:
Not quite the same complaint, but I've always been bothered by the
inconsistent use of =. I would prefer A = B to mean if A, then
B. Accordingly:
class Monad m = MonadPlus m
By your definition, couldn't
alson:
We had a short discussion on the IRC channel the other
day about Arrays. I advocated that we do some
refactoring work and didn't meet with overwhelming
disagreement, so I wanted to propose that the Arrays
interfaces be refactored in Haskell'.
As a Haskell new-ish-bie, the various
When I said type class acrobats I didn't mean to make fun
of people like you who use type classes in a very skillfull way.
Though, I tried (successfully :) ) to be provocactive.
I agree with you there's a real need for unrestricted type class
programming. After all, the Hindley/Milner subset of
On Wed, Feb 22, 2006 at 03:39:48PM +1100, Donald Bruce Stewart wrote:
And unsafeRead/unsafeWrite are too verbose. They are usually (almost
always?) safe (since the code does its own checks),
The same can be said about most uses of unsafePerformIO - you wouldn't
be using it if you weren't
15 matches
Mail list logo
