On 21 February 2006 18:14, Einar Karttunen wrote:
On 21.02 16:50, Simon Marlow wrote:
I lost the argument for include files, but this is why libraries
cannot currently be specified inside source files. Back in the FFI
discussion, we didn't have Cabal, but now that we do, Cabal is the
I would not say that it's well-specified, no. What we do know is this:
GHC may loop if you use -fallow-undecidable-instances -- but if it
terminates, the program is well typed and should not go wrong at
runtime.
S
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
| Perhaps this e-mail could be read more generally as a
| request to consistencify/update the (Data) libraries
| in general
...
|
| Is this possible for Haskell'? Or is this too much
| of a break? If it's possible, I'm happy to build a
| wiki page for discussion (I noticed that a short page
On 22 February 2006 01:33, John Meacham wrote:
On Tue, Feb 21, 2006 at 04:50:20PM -, Simon Marlow wrote:
First of all, my position on this has always been (since we argued
about this during the design of the FFI) that include files and
libraries should be kept out of the source file and
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 _always_ declares the
John Meacham [EMAIL PROTECTED] wrote:
Malcolm Wallace wrote:
There is also the issue that we might adopt the proposal to allow
(and perhaps eventually, to require) type signatures on export
lists.
All I have to say is please, no to the requiring part that is.
I don't seriously propose
Malcolm Wallace wrote:
... but that if there are thus two signatures for an entity, they
must be identical. This is to prevent the case where one modifies the
definition of the function, making it more general, but forgets to
modify the corresponding export.
Sounds like the perfect example
On Wed, Feb 22, 2006 at 12:07:44PM +, Malcolm Wallace wrote:
At the moment, only one type signature is permitted per entity (except
for FFI foreign exports, where the exported signature may be more
specific than the definitional signature). My proposal is that the
normal export list can
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
Hello Simon,
Wednesday, February 22, 2006, 12:53:09 PM, you wrote:
SM simplicity, packages are the unit in several concepts: distribution,
SM dependency, versioning, licensing, dynamic linking, include file
SM dependencies, external library dependencies, and more. If we start
SM confusing the
Johannes Waldmann [EMAIL PROTECTED] wrote:
Sounds like the perfect example to illustrate the point
that information shouldn't be doubled in the first place.
Yes, I suppose one could argue that.
Can you say why you want the type in the export list?
As a compact description of the module
David Roundby wrote:
I'd like to second this. I've been annoyed by the fact that ghc
requires extra subdirectories in order to use hierarchical modules,
and would be doubly annoyed if the language definition declared that
this couldn't be fixed. jhc's behavior sounds nicer, but I'd rather
Simon Marlow wrote:
there's a lack of modularity in the current
design, such that renaming the root of a module hierarchy requires
editing every single source file in the hierarchy. The only good reason
for this is the separation between language and implementation.
I don't see how this is
Simon Peyton-Jones [EMAIL PROTECTED] wrote:
| I don't seriously propose for haskell-prime that signatures should
| be required on exports. Just permitting them would be a large and
| useful step up already.
If this is to be a serious proposal, someone had better think what to
do about
Am Dienstag, 21. Februar 2006 21:59 schrieb Ketil Malde:
Wolfgang Jeltsch [EMAIL PROTECTED] writes:
On the other hand, sometimes it makes sense to have a mostly qualified
import. For example, if you import Data.Set or Data.Map you might want
only the type constructors to be imported
Am Dienstag, 21. Februar 2006 22:10 schrieb Ketil Malde:
[...]
Template Haskell breaks expressions with $,
It's very bad that with TH enabled you cannot write sections of the form ($ x)
anymore which are sometimes very handy.
[...]
(Perhaps it would be better to always require whitespace
Malcolm Wallace wrote:
An explicit interface would be useful for many purposes besides
machine-checked documentation.
I don't see why you need the signature in two places
(at the point at declaration and in the export list) for that.
Do you want the compiler to check conformance
(of the
On Wednesday 22 February 2006 15:53, Malcolm Wallace wrote:
Simon Peyton-Jones [EMAIL PROTECTED] wrote:
| I don't seriously propose for haskell-prime that signatures should
| be required on exports. Just permitting them would be a large and
| useful step up already.
If this is to be a
Dear all,
Malcolm wrote:
As far as I can see, there is very little to change. Here is a
concrete proposal.
[...]
Anyone see any difficulties?
Georg asked:
No, but one question: If the type signature is given in the export
lists, is it then necessary (or even allowed) later on?
I would
Ashley Yakeley wrote:
foo :: (Monad m) = [m a] - m [a]
instance Integral a = Eq (Ratio a)
class Monad m = MonadPlus m
I think the most consistent (not most convenient!) syntax would be
foo :: forall m a. (Monad m) = [m a] - m [a]
instance forall a. (Integral a) = Eq (Ratio a)
On 22 February 2006 14:54, Malcolm Wallace wrote:
Simon Peyton-Jones [EMAIL PROTECTED] wrote:
I don't seriously propose for haskell-prime that signatures should
be required on exports. Just permitting them would be a large and
useful step up already.
If this is to be a serious proposal,
Hello Ben,
Wednesday, February 22, 2006, 9:47:19 PM, you wrote:
BRG While we're on the topic, I have a couple of problems with the current
array
BRG system that cut deeper than the naming:
BRG * The function for getting the bounds of an MArray is pure, so the
BRGinterface can't
22 matches
Mail list logo
