On Dec 21, 2006, at 5:03 PM, Jacques Carette wrote:
...
What must be remembered is that full dependent types are NOT needed
to get a lot of the benefits of dependent-like types. This is what
some of Oleg's type gymnastics shows (and others too). My interest
right now lies in figuring
Yes, Bluespec has efficient type level naturals. But it only has
arithmetic and some trivial decision procedures. The slogan is the
type checker knows arithmetic, not algebra.
It worked pretty well. But you soon get into situations where you
need polymorphic recursion of functions with
On Thu, 21 Dec 2006, Ross Paterson wrote:
On Thu, Dec 21, 2006 at 07:16:16PM +0100, Henning Thielemann wrote:
About the question, whether functions should be provided in the most
general context, I refer to
http://www.haskell.org/haskellwiki/Slim_instance_declaration
Certainly we
Brian Hulley wrote:
Would it be possible to augment Haskell's type system so that it was
the same as that used in Epigram?
No, no! Epigram is a wonderfully pure research experiment in one corner
of the design space. The corner it is exploring is not particularly
Haskell like, though the
OK, just to let everybody know why I'm dropping Haskell.
Basically, the reasoning is this:
* I want to write a process that doesn't terminate.
* Since the environment can and will enforce termination occasionally,
the process must be able to write its state to some external storage
(serialize
Hello everyone,
I recently found myself attempting to use ST at the base of a stack of
transformers, ala:
type Test t r = ErrorT String (ST t) r
I imagined, given the type of ST, that I would need a run function
along the lines of:
runTest :: (forall t. Test t r) - Either String r
(which
Reto Kramer wrote:
What I'm really looking for is not so much the chaining of StateT
compositions, but rather the isolation of StateA from StateB while
they both flow from the search loop into the respective library calls
(foo, bar) transparently to the application programmer.
How about
Hi J Garrett,
I don't see any problem in GHC 6.6. with:
runTest c = runST (runErrorT c)
*Main runTest (return True)
Loading package mtl-1.0 ... linking ... done.
Right True
*Main
On the other hand, I try to define it firstly as below and got the
following error.
runTest = runST .
Chung-chieh Shan [EMAIL PROTECTED] writes:
Adam Megacz [EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in
gmane.comp.lang.haskell.cafe:
Is there any work on automatic translation of code in some tiny
imperative language into Haskell code that uses the ST and/or IO
monads (or perhaps
More generally, is there an operator version of dotted pair notation
(gasp, did I just lisp?) that works like:
data Tuple a b = () | Tuple a b
()== ()
( ) 1 == Tuple 1 ()
(2,'a',hello) == Tuple 2 (Tuple 'a' (Tuple hello ()))
And is there anyway in Haskell to restrict the type definition
Hello Joachim,
Friday, December 22, 2006, 2:30:32 AM, you wrote:
There is an interesting technique thay allows you to serialize infinite,
lazy or functional values: don't try to describe how those values look,
but how they came to be.
Ah, that's an interesting approach that I haven't
On Fri, Dec 22, 2006 at 06:44:54PM +0100, Pepe Iborra wrote:
Rank-2 types seem to interact badly with (.) and ($), but my type
theory educated neuron doesn't know why. I think this is folklore
knowledge?
You say:
runErrSt = (.) runST runErrorT
runErrorT has type ErrorT e m a - m (Either
Hmm, that was simpler than I had imagined. Thank you both!
/g
On 12/22/06, Stefan O'Rear [EMAIL PROTECTED] wrote:
On Fri, Dec 22, 2006 at 06:44:54PM +0100, Pepe Iborra wrote:
Rank-2 types seem to interact badly with (.) and ($), but my type
theory educated neuron doesn't know why. I think
G'day all.
Bulat Ziganshin [EMAIL PROTECTED] writes:
of course, we can fool any topic by changing the names. no one will say
that Haskell is small productive language, the topic was just about speed
of code generated
Actually, the topic was performance.
What performance means to a modern
Although terse, the subject really says it all.
If i've a partial function, like a parser, what is considered good
style for a library. The tradeoffs that I can see are that Maybe is a
binary operation, while Error can communicate more information in the
type of the error case.
Is there some way
On Fri, Dec 22, 2006 at 11:13:50AM -0800, Dan Weston wrote:
More generally, is there an operator version of dotted pair notation
(gasp, did I just lisp?) that works like:
data Tuple a b = () | Tuple a b
()== ()
( ) 1 == Tuple 1 ()
(2,'a',hello) == Tuple 2 (Tuple 'a' (Tuple hello
I would not advocate using the fail operation in a monad. It doesn't
belong there, and hopefully it will go away some day. :)
-- Lennart
On Dec 23, 2006, at 02:21 , Stefan O'Rear wrote:
On Fri, Dec 22, 2006 at 08:05:08PM -0500, Steve Downey wrote:
Although terse, the subject
OK, but is msg always a string? Admidtedly, in the concrete case I
have at hand (follow up posting RSN), that would be fine.
I think I've also been looking at the map lookup case, where not only
is lookup failure to be expected, it's almost an imposition to say
something other than Nothing.
On
On Fri, Dec 15, 2006 at 03:14:32AM +, Dougal Stanton wrote:
The cabal setup recognises a small set of licences which I don't think
are well explained. I'm trying to put together a canonical list for
setting up new projects.
This has bugged me about cabal, why does it have a built in
On Saturday 23 December 2006 14:21, Stefan O'Rear wrote:
On Fri, Dec 22, 2006 at 08:05:08PM -0500, Steve Downey wrote:
Although terse, the subject really says it all.
If i've a partial function, like a parser, what is considered good
style for a library. The tradeoffs that I can see are
On Fri, Dec 22, 2006 at 08:37:05PM -0500, Steve Downey wrote:
On 12/22/06, Stefan O'Rear [EMAIL PROTECTED] wrote:
All monads provide a fail operation, and any function that uses fail will
be able to work with any monad's error handling mechanism.
* Maybe - fail msg is Nothing (ignores
On Sat, Dec 23, 2006 at 02:33:51AM +0100, Lennart Augustsson wrote:
I would not advocate using the fail operation in a monad. It doesn't
belong there, and hopefully it will go away some day. :)
On Fri, Dec 22, 2006 at 08:37:05PM -0500, Steve Downey wrote:
OK, but is msg always a string?
'normal execution path' is a key phrase here. If we're truely thinking
functionally, there is no execution path. At most there are evaluation
strategies.
I suppose this is why Maybe is a monad rather than just another
algebraic data type.
Perhaps I'm thinking of the strategy of 'replacing
Actually, that is the version of Error I was looking at.
On 12/22/06, Stefan O'Rear [EMAIL PROTECTED] wrote:
On Sat, Dec 23, 2006 at 02:33:51AM +0100, Lennart Augustsson wrote:
I would not advocate using the fail operation in a monad. It doesn't
belong there, and hopefully it will go away
On Fri, Dec 22, 2006 at 09:44:35PM -0500, Steve Downey wrote:
I suppose this is why Maybe is a monad rather than just another
algebraic data type.
Maybe is an algebraic datatype. A monad is simply a structure defined on
the datatype, reflecting a normal pattern of use.
This is exactly where
25 matches
Mail list logo
