On Jan 25, 2007, at 2:08 , John Ky wrote:
On 1/25/07, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote:
data ANode = Branch { name :: String, description :: String,
children :: [AnyNode] }
| Leaf { name :: String, value :: String } -- this reuse
is legal
-- leaving Node available
On 1/25/07, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote:
I'm probably missing something, but:
(a) Why not:
data ANode = Branch { name :: String, description :: String,
children :: [AnyNode] }
| Leaf { name :: String, value :: String } -- this reuse
is legal
-- leaving Node a
On Wednesday 24 January 2007 20:20, Stefan Monnier wrote:
> > FYI, don't try to run this in GHC, because it gives the simplifier fits.
>
> You mean it triggers a bug in the inliner?
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html
Third bullet in secion 12.2.1.
I gather that GH
Marco Túlio Gontijo e Silva wrote:
Hello,
I'm trying to define a partition__ function that is like
Data.Set.partition, but use State Monad:
import Data.Set
import Control.Monad.State
partition__ f =
do
snapshot <- get
let
(firsts, rest) = Set.partition f snapshot
put
> FYI, don't try to run this in GHC, because it gives the simplifier fits.
You mean it triggers a bug in the inliner?
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Thu, Jan 25, 2007 at 11:34:55AM +1100, John Ky wrote:
> A while back I asked about OO programming in Haskell and discovered
> existential types. I understood that existential types allowed me to write
> heterogeneous lists which seemed sufficient at the time.
>
> Now trying to combine those id
On Jan 24, 2007, at 19:34 , John Ky wrote:
class Node -- yadda yadda
data Branch = Branch { name :: String, description :: String,
children :: [AnyNode] }
data Leaf = Leaf { name :: String, value :: String }
The problem here is I can't use the same 'name' field for both
Branch and Leaf.
Limiting the value recursion is not enough, of course. You'd have to
limit the type recursion as well.
-- Lennart
On Jan 24, 2007, at 10:41 , Robert Dockins wrote:
On Jan 24, 2007, at 8:27 AM, Lennart Augustsson wrote:
Well, I think fix destroys parametricity too, and it would be
Hi,
A while back I asked about OO programming in Haskell and discovered
existential types. I understood that existential types allowed me to write
heterogeneous lists which seemed sufficient at the time.
Now trying to combine those ideas with records:
data AnyNode = forall a. Node a => AnyNode
Ketil Malde <[EMAIL PROTECTED]> writes:
> jamin1001 wrote:
> > What if I want to do something like data Chair = Chair
> > {pos:: Int, color :: Int} data Table = Table {pos:: Int,
> > color :: Int}
> data Properties = Props { pos, color :: Int }
> data Chair = Chair Props
> data Table = Table Props
Hello Hans,
Sunday, January 21, 2007, 10:00:53 PM, you wrote:
> I understand this cannot be done in Haskell98, but it can with the GHC
> extension? Does {-# OPTIONS_GHC -fallow-undecidable-instances #-} refer
> to possibly infinite definitions? Thanks again!
as usual i suggest you to read
http
John Meacham wrote:
> On Mon, Jan 22, 2007 at 09:37:21PM -0500, Bryan Donlan wrote:
>
>>Or you can get the best of both worlds by using Data.ByteString.Lazy :)
>>Even with laziness, all the indirections that String causes hurts
>>performance.
>
>
> actually, strictness analysis is really good a
On Jan 24, 2007, at 8:27 AM, Lennart Augustsson wrote:
Well, I think fix destroys parametricity too, and it would be better
to get rid of fix. But I'm not proposing to do that for Haskell,
because I don't have a viable proposal to do so. (But I think the
proposal would be along the same lines
This is what I mean by "machinery":
-- CASE 1
data Furniture = Furniture { pos, color :: Int }
data Chair = Chair Furniture
data Table = Table Furniture
data Wooden = Wooden { grain :: Int }
data WoodenFurniture = WoodenFurniture Wooden Furniture
data WoodenTable = WoodenTable Wooden Table
Lennart Augustsson wrote:
Well, I think fix destroys parametricity too, and it would be better
to get rid of fix. But I'm not proposing to do that for Haskell,
because I don't have a viable proposal to do so. (But I think the
proposal would be along the same lines as the seq one; provide fix
in
Thanks, that's much clearer now.
Following this further, it seems that this could get monotonous/verbose if
you have more than a handful of classes. I looked into "deriving" but it
seems that is only useful for a set of builtin Haskell types (Eq, Ord, Show,
etc.).
Is Template Haskell the answer
I'll take a look at that, since one of the next things on my list is
error propagation and reporting.
In Pierce's code, source information is carried through as an explict
part of the type that represents terms in the language. I think that
would be more naturally expressed in a monad transformer,
There is no good solution to your problem. But one way to have
both the type A and the type B as you define them is to put them
in separate modules and then use qualified names for the `test'
function.
-- Lennart
On Jan 24, 2007, at 06:12 , jamin1001 wrote:
Hi, I am new at Haskell an
Well, I think fix destroys parametricity too, and it would be better
to get rid of fix. But I'm not proposing to do that for Haskell,
because I don't have a viable proposal to do so. (But I think the
proposal would be along the same lines as the seq one; provide fix
in a type class so we can kee
good, it felt like something that might have occurred to someone before.
On 1/23/07, Nicolas Frisby <[EMAIL PROTECTED]> wrote:
Jeremy Gibbons thought of it; that's good company ;)
http://portal.acm.org/citation.cfm?id=289457
On 1/23/07, Steve Downey <[EMAIL PROTECTED]> wrote:
> (overall cont
jamin1001 wrote:
Hi, I am new at Haskell and have some basic questions.
So then how should this be done? What if I want to do something like
data Chair = Chair {pos:: Int, color :: Int}
data Table = Table {pos:: Int, color :: Int}
Unfortunately you have to think up different names for all con
Hallo,
On 1/24/07, Ketil Malde <[EMAIL PROTECTED]> wrote:
jamin1001 wrote:
> What if I want to do something like
>
> data Chair = Chair {pos:: Int, color :: Int}
> data Table = Table {pos:: Int, color :: Int}
>
data Properties = Props { pos, color :: Int }
data Chair = Chair Props
data Table = T
jamin1001 wrote:
What if I want to do something like
data Chair = Chair {pos:: Int, color :: Int}
data Table = Table {pos:: Int, color :: Int}
data Properties = Props { pos, color :: Int }
data Chair = Chair Props
data Table = Table Props
or:
data Chair = Chair Int Int
data Table = Table
Hallo,
On 1/24/07, jamin1001 <[EMAIL PROTECTED]> wrote:
So then how should this be done? What if I want to do something like
data Chair = Chair {pos:: Int, color :: Int}
data Table = Table {pos:: Int, color :: Int}
data Chair = Chair { chairPos :: Int, chairColor :: Int }
Also, could
Hi, I am new at Haskell and have some basic questions.
Is there any way to do this more effectively? This causes the GHC
compile error "Multiple declarations of Main.test":
data A = A {test :: Int}
data B = B {test :: Int}
The Haskell 98 report in 4.2.1 under Labelled Fields says
"A label
On Tue, 2007-01-23 at 19:47 -0800, Aaron Tomb wrote:
> On Jan 23, 2007, at 5:13 PM, Clifford Beshers wrote:
>
> > I don't suppose anyone has any Haskell code that understands the
> > PDF format, do they?
>
> I know of one, though I'm not sure how complete it is:
>
> http://www.alpheccar.o
On Wed, 2007-01-24 at 00:33 +0200, Yitzchak Gale wrote:
> My challenge is:
>
> 1. Find a way to model strictness/laziness properties
> of Haskell functions in a category in a way that is
> reasonably rich.
The reason it's not obvious for categories is because the semantics for
Haskell comes from
Janis Voigtlaender wrote:
Janis Voigtlaender wrote:
Lennart Augustsson wrote:
There is a good reason seq cannot be defined for functions in
the pure lambda calculus... It doesn't belong there. :)
How about the same argument for general recursion? As in: There is a
good reason (typability
Janis Voigtlaender wrote:
Lennart Augustsson wrote:
There is a good reason seq cannot be defined for functions in
the pure lambda calculus... It doesn't belong there. :)
How about the same argument for general recursion? As in: There is a
good reason (typability) that fixpoint combinators ca
Lennart Augustsson wrote:
I don't think disallowing seq for functions makes them any more
second class than not allow == for functions. I'm willing to
sacrifice seq on functions to get parametricity back.
The underlying assumption that having seq makes us lose parametricity is
a (widely spread
Hi,
I am new to haskell, and now working on embedding haskell into html.
Thus we will write webapp using haskell as server-side language like
php. Here I explain my plan and ask some questions, looking for
experienced ones to discuss with.
Maybe you should look at
http://www.haskell.org/haske
31 matches
Mail list logo