> What about packages with multiple module trees like, say, Cabal?
That's a good question, and I think the right answer is not to do
anything special to support them. I assume that what you're referring
to with Cabal is that there is no common prefix for all of the module
names, but rather a small
On Sun, Oct 29, 2006 at 10:03:32PM -0400, Samuel Bronson wrote:
> On 10/25/06, Frederik Eaton <[EMAIL PROTECTED]> wrote:
>
> >http://hackage.haskell.org/trac/ghc/wiki/PackageMounting
>
> It looks nice, but don't you think the -package-base flag ought to
> take
Hi lists,
I recently read Simon Peyton Jones' proposal:
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
and disagreed with some of the design decisions. (To be fair, the
aspects I disagree with are shared with most or all of the other
proposals) So I've put an alternative proposal here:
ht
> Furthermore, can we move this thread from the Haskell mailing list
> (which should not have heavy traffic) to either Haskell-Café, or
> the libraries list?
Sure, moving to haskell-cafe.
Frederik
--
http://ofb.net/~frederik/
___
Haskell mailing list
On Tue, Aug 08, 2006 at 04:21:06PM +0300, Einar Karttunen wrote:
> On 07.08 13:16, Frederik Eaton wrote:
> > > How would this work together with the FFI?
> >
> > It wouldn't, at least I wouldn't care if it didn't.
>
> Suddenly breaking libraries that
Hi Simon,
It is good that you support thread-local variables.
I have initialized a wiki page:
http://haskell.org/haskellwiki/Thread_local_storage
The main difference between my and your proposals, as I see it, is
that your proposal is based on "keys" which can be used for other
things.
I think
On Sun, Aug 06, 2006 at 01:36:15PM +0300, Einar Karttunen wrote:
> On 06.08 02:41, Frederik Eaton wrote:
> > Also, note that my proposal differs in that thread local variables are
> > not writable, but can only be changed by calling (e.g. in my API)
> > 'withIOParam'
> > Here is a naive and dirty implementation. The largest problem is that
> > TypeRep is not in Ord. An alternative approach using Dynamic would be
> > possible, but I like the connection between the key
> > and the associated type.
> >
> > http://www.cs.helsinki.fi/u/ekarttun/haskell/TLS/
> >
Hi Robert,
I looked over your proposal.
I'm not sure if I'm in favor of introducing a new keyword. It seems
unnecessary.
Also, note that my proposal differs in that thread local variables are
not writable, but can only be changed by calling (e.g. in my API)
'withIOParam'. This is still just as g
> > > As said before the monadic approach can be quite clean. I haven't used
> > > implicit parameters that much, so I won't comment on them.
> >
> > Perhaps you can give an example? As I said, a single monad won't
> > suffice for me, because different libraries only know about different
> > parts
> > Maybe I'm misunderstanding your position - maybe you think that I
> > should use lots of different processes to segregate global state into
> > separate contexts? Well, that's nice, but I'd rather not. For
> > instance, I'm writing a server - and it's just not efficient to use a
> > separate pr
> As for the subject under discussion (thread local state), I am
> personally sceptical about it. Why do we need it? Are we talking
> about safety or just convenience/API elegance? I've never
> encountered a situation where I've needed thread local state,
> (but this does not necessarily make it ev
On Mon, Jul 31, 2006 at 03:09:59PM +0300, Einar Karttunen wrote:
> On 31.07 03:18, Frederik Eaton wrote:
> > I don't think it's necessarily such a big deal. Presumably the library
> > with the worker threads will have to be invoked somewhere. One should
> > just make
On Mon, Jul 31, 2006 at 03:54:29AM +0300, Einar Karttunen wrote:
> On 30.07 11:49, Frederik Eaton wrote:
> > No, because the thread in which it runs inherits any thread-local
> > state from its parent.
>
> So we have different threads modifying the thread-local state?
&
On Sun, Jul 30, 2006 at 12:35:42PM +0300, Einar Karttunen wrote:
> On 29.07 13:25, Frederik Eaton wrote:
> > I think support for thread-local variables is something which is
> > urgently needed. It's very frustrating that using concurrency in
> > Haskell is so easy and
Hi,
Sorry to bring up this thread from so long ago.
On Wed, Mar 01, 2006 at 11:53:42AM +, Simon Marlow wrote:
> Ashley Yakeley wrote:
> >Simon Marlow wrote:
> >>Simon & I have discussed doing some form of thread-local state, which
> >>covers many uses of implicit
> >>parameters and is much
An index-aware linear algebra library in Haskell
I've been exploring the implementation of a library for linear
algebra, i.e. manipulating vectors and matrices and so forth, which
has as a fundamental design goal the exposure of index types and
ranges to the type system so that operand conformabil
Hi,
Why not just call it, say, Test.QuickCheck2?
I think module names should reflect only their functionality. I don't
see how "External" or "Contrib" or "Chalmers" would say anything
useful about the functionality of the modules.
A while ago I sent a proposal for "package mounting", which I thi
On Wed, Oct 19, 2005 at 08:20:10PM +0200, Georg Martius wrote:
> Hi folks,
>
> I was really annoyed by the fact that for Data.Map and Data.Set are no Read
> instances declared, but Show instances are! I believe there should be some
> kind of unwritten rule that in the standart lib the Show and R
> weak one for use in Maps, and a strong one that you can use with
> throwTo. But then building a Map in which some elements can be garbage
> collected is a bit tricky (it can be done though; see our old Memo table
> implementation in fptools/hslibs/util/Memo.hs).
>
> Cheers,
ld be implemented from
that.
Frederik
On Sun, Oct 16, 2005 at 04:40:40AM -0700, Frederik Eaton wrote:
> Hi,
>
> I'm trying to get MonadReader-like functionality in the IO monad. It
> doesn't appear possible implement it with the interfaces that
> Haskell98 or GHC provide.
Hi,
I'm trying to get MonadReader-like functionality in the IO monad. It
doesn't appear possible implement it with the interfaces that
Haskell98 or GHC provide. I'm looking for something like "thread-local
variables". The interface could be something like this:
newTLRef :: a -> IO (TLRef a)
withT
But they all have a largest and smallest possible value, as I have
already indicated.
On Sun, Oct 02, 2005 at 04:35:02PM +0200, Lennart Augustsson wrote:
> Not all FP representations have infinity, and even if
> they do, they might only have one infinity.
>
> -- Lennart
>
&
I've previously mentioned that I would like to see an 'instance
Bounded Double' etc., as part of the standard, which would use 1/0 for
maxBound, or the largest possible value (there must be one!) for
platforms where that is not possible. I don't see a problem with
looking at Double values as if the
> I have another proposal, though. Introduce a new keyword, which I'll
> call "borrow" (the opposite of "return"), that behaves like a
> function of type (Monad m) => m a -> a inside of do statements. More
> precisely, a do expression of the form
>
> do { ... ; ... borrow E ... ; ... }
>
> i
On Sat, Sep 10, 2005 at 12:55:15AM +0100, Claus Reinke wrote:
> life is funny, isn't it? so many people so eagerly
lazily, in my case
> discussing conversion between non-monadic and monadic code,
I'm trying to discuss a new syntax, not code transformations. I agree
that the two are related. I'm
rrated). I think
most such shorthand can be understood simply in terms of lifting, and
I hypothesize that we can find an automatic lifting rule along the
lines I've described which will not be as ambiguous as you suggest.
Frederik
> On 09/09/05, Frederik Eaton <[EMAIL PROTECTED]> wro
By the way, I thought it would be obvious, but a lot of people seem to
be missing the fact that I'm not (as Sean, I believe, isn't)
requesting limited support for 1 or 2 or 3 argument functions or
certain type classes to be applied to monads, or for certain
operations to defined on certain types. I
I'm talking about "lift" as in 'liftM', not 'lift'
from MonadTrans.
On Fri, Sep 09, 2005 at 01:17:57PM -0700, Frederik Eaton wrote:
> On Thu, Sep 08, 2005 at 09:34:33AM +0100, Keean Schupke wrote:
> > Can't you do automatic lifting with a &
On Thu, Sep 08, 2005 at 09:34:33AM +0100, Keean Schupke wrote:
> Can't you do automatic lifting with a "Runnable" class:
>
> class Runnable x y where
>run :: x -> y
>
> instance Runnable (m a) (m a) where
> run = id
>
> instance Runnable (s -> m a) (s -> m a) where
>
On Thu, Sep 08, 2005 at 09:30:34AM -0700, Scherrer, Chad wrote:
> One of Mark Jones's articles suggests something like
>
> class Plus a b c | a b -> c where
> (+) :: a -> b -> c
>
> Would
>
> instance (Plus a b c, Monad m) => Plus (m a) (m b) (m c) where
> mx + my = do x <- mx
>
On Thu, Sep 08, 2005 at 10:35:49AM +0200, Wolfgang Lux wrote:
> Frederik Eaton wrote:
>
> >I want the type system to be able to do "automatic lifting" of monads,
> >i.e., since [] is a monad, I should be able to write the following:
> >and have it interpreted as
s explicit as an extra
> data dependency, then compile the resulting code.
which sounds sort of the same as the semantics I'm envisioning.
Frederik
On Wed, Sep 07, 2005 at 11:41:41PM -0700, Frederik Eaton wrote:
> > Frederik,
> > To do "automatic lifting" you need
On Thu, Sep 08, 2005 at 08:39:29AM +0200, Tomasz Zielonka wrote:
> On Wed, Sep 07, 2005 at 12:46:42PM -0700, Frederik Eaton wrote:
> > Hi all,
>
> Hi!
>
> > After some weeks of squinting, I've ended up settling with the
> > following partial solution in
> Frederik,
> To do "automatic lifting" you need to do a (higher-order) effect analysis,
> then make sure the
> compiler doesn't rearrange applications which have conflicting effects.
Hrm, I disagree. I don't think this is what I was advocating in my
message.
What I'm advocating is a reasonably
Hi,
Sean's comment (yeah, it was like a billion years ago, just catching
up) is something that I've often thought myself.
I want the type system to be able to do "automatic lifting" of monads,
i.e., since [] is a monad, I should be able to write the following:
[1,2]+[3,4]
and have it interpret
Hi all,
I've been trying for some time to get threading to work properly on
this mailing list. The problem is that I don't want to thread by
subject in all of my folders, because then messages with short
subjects like "hi", "hey", etc., in my personal folders will end up
together. However, threadi
On Mon, Sep 05, 2005 at 06:53:21PM -0400, Stefan Monnier wrote:
> > Hmm. I use font-lock, but I use xemacs (21.4). Maybe that's the cause
> > of the difference.
>
> IIRC XEmacs's support for syntax-table text-properties (and more
> specifically for font-lock-syntactic-keywords) has been generally
On Mon, Sep 05, 2005 at 11:48:12AM -0400, Stefan Monnier wrote:
> > Sorry if I've asked this before, but is version 2.0 of haskell-mode on
> > your website really the newest version?
>
> It's the latest released version. There's newer code in the CVS, of course.
>
> > I ask because the file hask
Hi Stefan,
Sorry if I've asked this before, but is version 2.0 of haskell-mode on
your website really the newest version? I ask because the file
haskell-mode.el says "Version: 1.43" in the header, and I thought I
remembered certain bugs being fixed which are present in your version.
For instance,
er bad
examples in "The Design and Evolution of C++". :)
Frederik
> If you don't like that way, you can use {;} as you say.
>
> -- Lennart
>
> Frederik Eaton wrote:
> >Huh, that seems patronizing. Well at least I can override it with {}.
> >
> >
> call it) is there to give visual cues. If you were allowed to override
> these easily just because it's parsable in principle then your code
> would no longer have these visual cues that make Haskell code fairly
> easy to read.
>
> -- Lennart
>
> Frederik Eat
Compiling the following module (with ghc) fails with error message
"parse error (possibly incorrect indentation)", pointing to the let
statement. The error goes away when I indent the lines marked "--*".
But I don't understand how what I've written could be ambiguous. If I
am inside a parenthesize
(By the way, sorry about cross-posting again. People have already
replied to just 'haskell@' and just 'libraries@' but I'll try to stick
to 'libraries@' after this since it seems that some users' mail
clients show them two copies otherwise)
> This idea has been raised before, but it was a while ba
Hi all,
It looks like there's been a bit of recent discussion regarding module
and package namespaces. There is a certain possible design feature
that I don't think has been mentioned yet, that I think would be very
helpful, so I thought I should at least bring it up.
What I want is to be able to
how it should be compiled,
> but I've now implemented something similar to gcc's -x flag.
>
> Cheers,
> Simon
>
> On 14 May 2005 20:04, Frederik Eaton wrote:
>
> > (moving to a separate thread)
> >
> > Also, how hard would it be to make it so tha
amble.
>
> Bob
>
> On Mar 13, 2005, at 11:02 PM, Lennart Augustsson wrote:
>
> >And what would you have minBound and maxBound be?
> >I guess you could use +/- the maximum value representable.
> >Going for infinity is rather dodgy, and assumes an FP
> >represent
son wrote:
> Haskell does not guarantee that 1/0 is well defined,
> nor that -(1/0) is different from 1/0.
> While the former is true for IEEE floating point numbers,
> the latter is only true when using affine infinities.
>
> -- Lennart
>
> Frederik Eaton wrote:
>
Shouldn't Double, Float, etc. be instances of Bounded?
I've declared e.g.
instance Bounded Double where
minBound = -(1/0)
maxBound = 1/0
in a module where I needed it and there doesn't seem to be any issue
with the definition...
Frederik
--
http://ofb.net/~frederik/
__
Wouldn't it be more useful if the type was
when :: Monad m => Bool -> m a -> m ()
not
when :: Monad m => Bool -> m () -> m ()
...?
Frederik
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
50 matches
Mail list logo
