On Friday 03 March 2006 10:52, Malcolm Wallace wrote:
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes:
But if contexts-on-datatypes worked correctly,
data Set a = Ord a =
then even the real map from Data.Set:
map :: (Ord a, Ord b) = (a - b) - Set a - Set b
could be
Jim Apple wrote:
class MyMap f a b where
myMap :: (a - b) - f a - f b
instance (Functor f) = MyMap f a b where
myMap = fmap
instance (Ord a, Ord b) = MyMap Data.Set.Set a b where
myMap = Data.Set.map
OK (I guess).
But my point was that I want to use
do notation for Sets (in
On 3/1/06, Johannes Waldmann [EMAIL PROTECTED] wrote:
But my point was that I want to use
do notation for Sets (in fact, for any kind of collection)
so I'd need the original Functor and Monad.
I understand this for Monad. Why not just redefine Functor, Oleg-style?
I couldn't use ghc's
Johannes Waldmann [EMAIL PROTECTED] wrote:
For reference, in Java, ... there's nice syntactic sugar for looping
over collections: CollectionE c; for (E item : c) { ... }
I'd say this is an example of moving away from a left-biased
representation, or at least freeing the programmer from
Malcolm Wallace wrote:
Johannes Waldmann [EMAIL PROTECTED] wrote:
For reference, in Java, ... there's nice syntactic sugar for looping
over collections: CollectionE c; for (E item : c) { ... }
In Haskell, this is called 'fmap'. :-)
OK, then show me an instance Functor Set so that I can
Cale Gibbard wrote:
important point is that the elements and structure of the collection
are being constructed one at a time as you iterate over it, and they
are easily garbage collected as soon as you're done with them.
OK, I kind of buy that argument. Though the very word deforestation
Johannes Waldmann [EMAIL PROTECTED] wrote:
In Haskell, this is called 'fmap'. :-)
OK, then show me an instance Functor Set so that I can use it :-)
instance Function Set where
fmap = Data.Set.mapMonotonic
Ok, so this introduces a precondition on the function being mapped, so
there is
Malcolm Wallace wrote:
But if contexts-on-datatypes worked correctly,
data Set a = Ord a =
then even the real map from Data.Set:
map :: (Ord a, Ord b) = (a - b) - Set a - Set b
could be an instance method of Functor.
I'd love that. But I don't quite understand:
do you
But if contexts-on-datatypes worked correctly,
data Set a = Ord a =
then even the real map from Data.Set:
map :: (Ord a, Ord b) = (a - b) - Set a - Set b
could be an instance method of Functor.
I'd love that. But I don't quite understand:
do you think this
On 28 February 2006 13:37, Lennart Augustsson wrote:
John Meacham wrote:
I mean, even a for loop in haskell is done as
mapM action [0..10]
I'd say _most_ uses of lists are deforested away because they are
used to express control and dataflow and arn't actually used as
persistant
On 2/28/06, Johannes Waldmann [EMAIL PROTECTED] wrote:
Malcolm Wallace wrote:
But if contexts-on-datatypes worked correctly,
data Set a = Ord a =
then even the real map from Data.Set:
map :: (Ord a, Ord b) = (a - b) - Set a - Set b
could be an instance method of
On Fri, Feb 24, 2006 at 09:20:10AM +0100, Ketil Malde wrote:
I don't think saving one line from each file in projects using
alternative Preludes justify adding one line to each file in projects
using the standard Prelude. If there is any reason to think custom
Preludes will outnumber the
John Meacham wrote:
On Thu, Feb 23, 2006 at 10:58:36AM +, Malcolm Wallace wrote:
Some data-structures people (e.g. Chris Okasaki) are of the opinion that
lists tend to be over-used (because they are built-in), when other
datatypes might be much more appropriate.
While this may be true
Malcolm Wallace [EMAIL PROTECTED] writes:
One of the problems with the current mechanism for overriding Prelude
definitions, is that every module that /uses/ such an entity must
also explicitly hide the original Prelude:
I guess I don't quite understand what you are trying to achieve.
Case
Benjamin Franksen [EMAIL PROTECTED] writes:
If this means that you must import Data.List almost everywhere, this
won't change anything - only add yet another import to every file.
But you could import something different instead!
Yes. You can do that as it is, of course (well, more or less,
Of
| Ben Rudiak-Gould
| Sent: 23 February 2006 21:26
| To: haskell-prime@haskell.org
| Subject: Re: Export lists in modules
|
| Malcolm Wallace wrote:
| An explicit interface would be useful for many purposes besides
| machine-checked documentation. For instance, it could be used to
| eliminate
On Fri, Feb 24, 2006 at 12:13:14PM -, Simon Peyton-Jones wrote:
You could imagine
a) compiling recursive groups all at once
b) somehow magically filtering the source file to omit anything
undefined, leaving only defined stuff. which ought to be enough to
tie the knot.
jhc does a,
On 23 February 2006 01:48, John Meacham wrote:
On Wed, Feb 22, 2006 at 05:11:26PM -, Simon Marlow wrote:
Indeed, the distinction between data newtype should be a completely
private property, so we certainly shouldn't distinguish those in
exports/imports. It's less clear to me whether
On 22 February 2006 17:27, Malcolm Wallace wrote:
However, I would be
equally happy to combine type/newtype/data into a single keyword for
exports.
for the record, I am in favour of tagging export specifiers with 'class'
or 'type' (using 'type' for all type constructors, in light of yours and
Ketil Malde [EMAIL PROTECTED] wrote:
I would solve this problem by reducing the Prelude to just a core.
List function could go, for example, (mostly) into Data.List.
If this means that you must import Data.List almost everywhere, this
won't change anything - only add yet another import
On 23 February 2006 10:28, Jean-Philippe Bernardy wrote:
I lost track of what is the issue being tackled here. What's broken
with the current way of specifying exported entities? Imho it's the
best system that I've seen (across all languages I know).
A lot of language chose to separate
Simon Marlow [EMAIL PROTECTED] wrote:
However, I would be
equally happy to combine type/newtype/data into a single keyword for
exports.
for the record, I am in favour of tagging export specifiers with
'class' or 'type' (using 'type' for all type constructors, in light of
yours and
On 23 February 2006 11:14, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] wrote:
However, I would be
equally happy to combine type/newtype/data into a single keyword for
exports.
for the record, I am in favour of tagging export specifiers with
'class' or 'type' (using 'type' for
Malcolm Wallace [EMAIL PROTECTED] writes:
you would simply replace the implicit import Prelude with
an explicit import Prelude.Standard (or use a build flag like
-fimplicit-prelude, or +98).
Why not keep it implicit? If you want the alternative behavior, you
know where to get it (import
On Wed, Feb 22, 2006 at 05:12:47PM +, Malcolm Wallace wrote:
Everything else that is currently in the Haskell'98 Prelude is
re-distributed across a variety of small modules. Where a syntactic
desugaring rule currently uses an entity from the Prelude, the new
interpretation is that it uses
Simon Marlow [EMAIL PROTECTED] writes:
The main difference is that I'm doing away with parentheses, commas, and
export specifiers, and using layout and full declaration syntax instead.
(I don't really want to discuss this very rough idea any more though,
it's just a distraction, and I'm not
Malcolm Wallace wrote:
An explicit interface would be useful for many purposes besides
machine-checked documentation. For instance, it could be used to
eliminate the hs-boot or hi-boot files used by some compilers when
dealing with recursive modules.
Why *does* ghc require hs-boot files? What
On 2/23/06, Ben Rudiak-Gould [EMAIL PROTECTED] wrote:
In fact, this suggests a compromise: how about implicitly importing the
Prelude only if the module header is omitted? That way there'll be no impact
on short (single-module) programs.
+1
--
Taral [EMAIL PROTECTED]
Computer science is no
On Thu, 2006-02-23 at 21:04 +0100, Marcin 'Qrczak' Kowalczyk wrote:
Simon Marlow [EMAIL PROTECTED] writes:
The main difference is that I'm doing away with parentheses, commas, and
export specifiers, and using layout and full declaration syntax instead.
(I don't really want to discuss this
On 2006-02-21, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Am Dienstag, 21. Februar 2006 04:41 schrieb John Meacham:
on this note, I thought it would be nice to do a 'mostly unqualified'
import.
import Foo qualified(foo,bar)
which will have the effect of
import Foo hiding(foo,bar)
import
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
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
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
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
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,
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 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.
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 thought I would make a suggestion about what
the syntax might look like to do
Jared,
How about combining the two (since 'hiding' is already a reserved
word):
module Module hiding ( list, of, things, not, to, export ) where
Everything gets exported except what you explicitly hide. Is this
general enough? Are there reasons why this might not work? And does
on this note, I thought it would be nice to do a 'mostly unqualified'
import.
import Foo qualified(foo,bar)
which will have the effect of
import Foo hiding(foo,bar)
import qualified Foo(foo,bar)
since usually you can import a whole module unqualified except for a few
troublemakers.
46 matches
Mail list logo
