Re: [Haskell-cafe] Joy Combinators (Occurs check: infinite type)
Keean Schupke wrote: Daniel Fischer wrote: And, BTW, that's why Keean et al's HList library doesn't help here either, the type of an HList determines the number of elements and the type of each, so there we face the same problems as with nested tuples. What we need is type Stack = [ArbitraryType] (from the HList paper, I surmise that [Dynamic] would be possible, but that seems to have it's own problems). Well it depends on what you want to do... If the types of elements are determined by the computation then you can use an HList as is, and there is no problem. The problem is that for the recursion combinators we need polymorphic recursion functions. For fact3 we need rec2 :: forall l. (HCons a (HCons a l) - HCons a l), which is illegal in an HList (at least, I haven't found a way to make it acceptable) and in tuples. For the general recursion combinator it's even worse, because rec2 may take n2 elements of certain types from the stack, does something with them and put k2 elements of certain types determined by the types of the consumed elements on the stack, leaving the remainder of the stack unchanged, rec1 takes n1 elements etc. And the numbers n2, n1 . . . and the types depend on the supplied recursion functions. So (reverting to nested pairs notation), we would have to make linrec to accept arguments for rec2 of the types (a,b) - (r,b), (a,(a1,b)) - (r,(r1,(r2,b))), (a,(a1,b)) - (r,b) (a,(a1,(a2,b))) - (r,b) and so on, for arbitrary munch- and return-numbers, where we don't care what b is. These can't be unified however, so I think it's impossible to transfer these combinators faithfully to a strongly typed language. [Dynamic] won't work either, I believe, because Dynamic objects must be monomorphic, as I've just read in the doc. The point is, in Joy all these functions would have type Stack - Stack and we can't make a stack of four elements the same type as a stack of six elements using either nested pairs or HLists (correct me if I'm wrong, you know HList better than I do). However, Joy has only very few datatypes (according to the introduction I looked at), so data Elem = Bool Bool | Char Char | Int Integer | Double Double | String String | Fun (Stack - Stack) | List [Elem] | Set [Int] type Stack = [Elem] type Joy = State Stack (IO ()) looks implementable, probably a lot to write, but not too difficult - maybe, I'll try. The only time there is a problem is if the _type_ of an element to be put in an HList depends on an IO action. In this case you need to existentially quantify the HList. How would I do that? What the user's guide says about existential quantification isn't enough for me. So you can use the HList in both cases, but you have to deal with existential types if the type of the HList is dependant on IO (you dont have to do this if only the value of an element depends on IO). Keean. If you can faithfully implement Greg's code (including fact3-5) using HList, I'd be interested to see it, I think HList suits other purposes far better. Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with Haddock
Hi,
I have the problem that I can't haddock literate modules (latex-style),
haddock -h -o docs Test.lhs
Test.lhs:1:1: Parse error
the file begins with \begin{code}.
Does anybody know what's up and what to do about it?
Furthermore, in the documentation of ghc-6.4.2005...,
only four modules from base/GHC are included, in the documentation for
ghc-6.2.2 there were 29. In particular, the absence of GHC.List, GHC.Show and
GHC.Read is extremely annoying.
Any suggestions how to remedy this?
Thanks in advance,
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with Haddock
On Tue, Mar 08, 2005 at 04:25:49PM +0100, Daniel Fischer wrote: Furthermore, in the documentation of ghc-6.4.2005..., only four modules from base/GHC are included, in the documentation for ghc-6.2.2 there were 29. In particular, the absence of GHC.List, GHC.Show and GHC.Read is extremely annoying. Any suggestions how to remedy this? You could use the recommended interface: Data.List, Text.Show, Text.Read and GHC.Exts. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Problem with Haddock
On 08 March 2005 15:26, Daniel Fischer wrote:
I have the problem that I can't haddock literate modules
(latex-style),
haddock -h -o docs Test.lhs
Test.lhs:1:1: Parse error
the file begins with \begin{code}.
Does anybody know what's up and what to do about it?
Haddock doesn't understand literate files on its own. The documentation
describes how to get around this... er, well the documentation in CVS
describes how to get around this, but the 0.6 docs on the web don't.
Here's the relevant text:
section id=cpp
titleUsing literate or pre-processed source/title
paraHaddock only accepts plain, non-literate, Haskell source.
This means that if you program in Literate Haskell, or you need
to use the C pre-processor in your Haskell source, then you need
to pre-process the files before feeding them to Haddock. This
is easily accomplished using GHC; for example, suppose we have a
Literate Haskell source file filenameFoo.lhs/filename, on
which we also need to run the C pre-processor:/para
screen
$ ghc -cpp -E -optP-P -D__HADDOCK__ Foo.lhs -o Foo.hs
$ haddock -h Foo.hs ...
/screen
paraThe option-E/option option to GHC says stop after
pre-processing, the option-cpp/option option turns on the C
pre-processor, the option-optP-P/option option tells the C
pre-processor not to leave any extra dropping behind (see the
description of the option-P/option option in the gcc manual
for details), and the option-D__HADDOCK__/option option
defines the symbol literal__HADDOCK__/literal when
pre-processing (this is sometimes handy if you need to any
pre-processing conditionals in your source which depend on
whether the source is going to be fed to Haddock)./para
/section
Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Joy Combinators (Occurs check: infinite type)
Am Dienstag, 8. März 2005 17:31 schrieben Sie: Daniel Fischer wrote: The problem is that for the recursion combinators we need polymorphic recursion functions. For fact3 we need rec2 :: forall l. (HCons a (HCons a l) - HCons a l), I dont see why this is illegal... what do we want? take the top two items from the stack? It's illegal, because a type variable may not be instantiated by a forall-type; section 7.4.9 of the user's guide: There is one place you cannot put a forall: you cannot instantiate a type variable with a forall-type. So you cannot make a forall-type the argument of a type constructor. So these types are illegal: x1 :: [forall a. a-a] x2 :: (forall a. a-a, Int) x3 :: Maybe (forall a. a-a). I'd say that also applys to HList, HCons (forall l. (HCons a (HCons a l) - HCons a l)) blah won't work (and my ghci doesn't swallow it). Take the to N elements from the stack: class Take l n h t | l n - h t where take :: l - n - (h,t) instance Take l HZero HNil l where take l _ = (HNil,l) instance Take t n (h',t') = Take (HCons h t) (HSucc n) (HCons h h',t') where take (HCons h t) (_::HSucc n) = (HCons h h',t') where (h',t') = take t (undefined::n) Good, but cumbersome. And I'm not sure what the type signature should be for genrec (HCons rec2 (HCons rec1 (HCons t (HCons b stack | hHead (b stack) = t stack | otherwise = rec2 (HCons (genrec.quote rec2.quote rec1.quote t.quote b) (rec1 stack)) I dare say it would be easier in Haskell-style: genrec rec2 rec1 t b stack. For the general recursion combinator it's even worse, because rec2 may take n2 elements of certain types from the stack, does something with them and put k2 elements of certain types determined by the types of the consumed elements on the stack, leaving the remainder of the stack unchanged, rec1 takes n1 elements etc. And the numbers n2, n1 . . . and the types depend on the supplied recursion functions. So (reverting to nested pairs notation), we would have to make linrec to accept arguments for rec2 of the types (a,b) - (r,b), (a,(a1,b)) - (r,(r1,(r2,b))), (a,(a1,b)) - (r,b) (a,(a1,(a2,b))) - (r,b) and so on, for arbitrary munch- and return-numbers, where we don't care what b is. These can't be unified however, so I think it's impossible to transfer these combinators faithfully to a strongly typed language. [Dynamic] won't work either, I believe, because Dynamic objects must be monomorphic, as I've just read in the doc. The point is, in Joy all these functions would have type Stack - Stack and we can't make a stack of four elements the same type as a stack of six elements using either nested pairs or HLists (correct me if I'm wrong, you know HList better than I do). They are not the same type, but that are the same Kind, or Type-Familly... Aye, but as I understand it, once we push the recursion functions on the stack, they must be monomorphic, which means, the scheme won't work in general. class Stack s instance Stack HNil instance Stack s = Stack (HCons a s) Isn't this exactly the HList class? isItAStack :: Stack s = s - s isItAStack = id However, Joy has only very few datatypes (according to the introduction I looked at), so data Elem = Bool Bool | Char Char | Int Integer | Double Double | String String | Fun (Stack - Stack) | List [Elem] | Set [Int] type Stack = [Elem] type Joy = State Stack (IO ()) looks implementable, probably a lot to write, but not too difficult - maybe, I'll try. The above can be translated to HLists, the difference is that with HLists the types (classes) are extensible. Might well be, only I don't see how (would have to take a log look at HList, probably). Of course, doing it the primitive way means a lot of work every time you add a new datatype :-( But for these types, I did it (with a few modifications) and all works fine. There appears to be no IO in the example Joy code so existentials are unneccessary. No IO around, I only thought I might wish to write an interactive frontend, printing out the top of the stack (might be an error message) after each step. I haven't got round to that yet, and I don't know whether I will, but I think if I do, I'd better use type Joy = IO (State Stack Elem). Keean. Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Joy Combinators (Occurs check: infinite type)
Keean Schupke wrote:
I dont see why this is illegal... what do we want? take the top two
items from the stack?
With the code below (direct translation from tuples to HLists) I
still get an occurs check error when trying to define fact5...
Compiling Main ( joy3.hs, interpreted )
joy3.hs:23:
Occurs check: cannot construct the infinite type: l = HCons e l
Expected type: HCons
(HCons e (HCons e l) - HCons e l)
(HCons
(HCons e3 l3 - HCons e3 (HCons e3 l3))
(HCons
(HCons e1 l2 - HCons e1 l2)
(HCons (HCons e2 l1 - HCons Bool l1) a)))
- c
Inferred type: HCons
(HCons e (HCons e l) - HCons e (HCons e l))
(HCons
(l4 - l4)
(HCons (l4 - HCons e (HCons e l))
(HCons (l4 - l5) l4)))
- HCons e (HCons e l)
In the second argument of `(!)', namely `linrec'
In the definition of `fact5':
fact5 = quote (nul)) ! (quote (suc))) ! (quote (dup ! pre)))
! (quote (mult)))
! linrec
Failed, modules loaded: MainGhcGeneric1, TypeCastGeneric1, Label3,
TypeEqGeneric1, TypeEqBoolGeneric, GhcExperiments, GhcSyntax,
CommonMain, Datatypes2, Variant, TIC, TIP, HTypeIndexed, GhcRecord,
Record, HZip, HOccurs, HArray, HListPrelude, FakePrelude.
Looks to me like a very similar error to the tuple case.
Greg Buchholz
--Joy combinators in Haskell
{-# OPTIONS -fglasgow-exts #-}
{-# OPTIONS -fallow-overlapping-instances #-}
import MainGhcGeneric1
import Data.Typeable
main = do print $ ((lit 10)!(lit 4)!mult) bot -- 4*10
print $ ((lit 3) ! cube ) bot-- 3^3
print $ ((lit 4) ! fact5) bot-- 4!
bot = HNil
square = dup ! mult
cube = dup ! dup ! mult ! mult
nul = (lit 0) ! eq
suc = (lit 1) ! add
pre = (lit 1) ! sub
--In Joy: [null] [succ] [dup pred] [*] linrec
fact5 :: HCons Integer a - HCons Integer a
fact5 = quote(nul) ! quote(suc) ! quote(dup ! pre) ! quote(mult) ! linrec
--}
--primitive combinators
(!) f g = g.f
i(a, b) = (a b)
add (HCons a (HCons b c)) = (HCons (b+a) c)
sub (HCons a (HCons b c)) = (HCons (b-a) c)
mult (HCons a (HCons b c)) = (HCons (b*a) c)
swap (HCons a (HCons b c)) = (HCons b (HCons a c))
pop (HCons a b) = b
dup (HCons a b) = (HCons a (HCons a b))
dip (HCons a (HCons b c)) = (HCons b, (a c))
eq (HCons a (HCons b c)) | a == b= (HCons True c)
| otherwise = (HCons False c)
ifte (HCons f (HCons t (HCons b stack)))
| hHead(b stack) = (t stack)
| otherwise = (f stack)
linrec (HCons rec2 (HCons rec1 (HCons t (HCons p stack
| hHead (p stack) = (t stack)
| otherwise = rec2 (linrec (HCons rec2
(HCons rec1
(HCons t
(HCons p (rec1 stack))
lit val stack = (HCons val stack)
quote = lit
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with Haddock
Am Dienstag, 8. März 2005 17:12 schrieben Sie: On Tue, Mar 08, 2005 at 04:25:49PM +0100, Daniel Fischer wrote: Furthermore, in the documentation of ghc-6.4.2005..., only four modules from base/GHC are included, in the documentation for ghc-6.2.2 there were 29. In particular, the absence of GHC.List, GHC.Show and GHC.Read is extremely annoying. Any suggestions how to remedy this? You could use the recommended interface: Data.List, Text.Show, Text.Read and GHC.Exts. Yes, but I like to sometimes look at the nitty-gritty bits, and at least from Data.Dynamic and Data.Typeable there are hyperlinks to GHC.Show.html and GHC.Base.html, which don't exist anymore :-( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with Haddock
On Tue, Mar 08, 2005 at 11:22:10PM +0100, Daniel Fischer wrote: Am Dienstag, 8. März 2005 17:12 schrieben Sie: On Tue, Mar 08, 2005 at 04:25:49PM +0100, Daniel Fischer wrote: Furthermore, in the documentation of ghc-6.4.2005..., only four modules from base/GHC are included, in the documentation for ghc-6.2.2 there were 29. In particular, the absence of GHC.List, GHC.Show and GHC.Read is extremely annoying. Any suggestions how to remedy this? You could use the recommended interface: Data.List, Text.Show, Text.Read and GHC.Exts. Yes, but I like to sometimes look at the nitty-gritty bits, and at least from Data.Dynamic and Data.Typeable there are hyperlinks to GHC.Show.html and GHC.Base.html, which don't exist anymore :-( Ah, you need to build the library documentation for 6.4 with the CVS version of Haddock, which doesn't make hyperlinks to hidden modules. Have a look at http://www.haskell.org/ghc/docs/6.4/html/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
