Haskell related Debian packages
I'm considering packaging several Haskell libraries for Debian, and wonder what people think about where things should go. Please excuse me if anyone feels that this email isn't appropriate for this mailing list. Though these are somewhat Debian-specific questions, I thought that some Haskell folks could lent their insight. You would be the users after all. There aren't many examples of libraries (without any binaries) that are packaged thus far. I noticed that ctklight installs stuff in /usr/share/hugs98/extentions, but it can be used with GHC also, so I am not sure why its done this way. I don't use hugs too much though, also I don't know anything about nhc. So I'm considering sticking the *.lhs files for HUnit, for example, in /usr/share/hunit. Then people can alter their Makefiles to include that directory in either hugs or ghc, but I see one problem with that: GHC would want to compile the source files, and stick them in /usr/share/hunit, but would be unable to (because of permissions problems when users compile). The package could install binary files, but then it would build-depend on ghc which doesn't exist for several Debian platforms. So I guess it could check to see if ghc is installed on the building computer and stick binaries in /usr/lib. Another option would be to compile packages for GHC in the post-install script if ghc is installed, and stick those installed files in /usr/lib, and the .hs files in /usr/share/hugs98/extentions if hugs is installed. So my question is: if you were / are using Debian, what do you think that a well-behaved Haskell library package should do? Also Debian users might email me privately with suggestions on what are the most important programs to package: I plan to start with the ones I use the most. peace, Isaac ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: representation getting verbose...
Thanks for your reply... Paul Hudak <[EMAIL PROTECTED]> writes: > > case expr of > > C f -> ... > > V (Variable (VVariable s)) -> ... > > ... > > I think you mean: > > case expr of > C f -> ... > V (VVariable s) -> ... > > which is not quite as verbose. Yes, I think I should have checked my examples more carefully. > I don't think that the problem is as bad as you make it out to be. If > you adopt my use of short constructor names, then something like: > (snip) Well, my example wasn't very good, and is quite a bit simpler than the actual application I'm developing. I think I will take your advice on shorter names, however. To give you an idea of the kind of code I'm ending up with, here's a construction from my program: Variable (VVariable(varName, (Value (Number (NNumber (varValue, varDimension)) Here VVariable and NNumber are newtype constructors of tuples, and the entire expression is an "Expression" which, among other things has: data Expression = Value Value | Variable Variable | ... and Value has "data Value = Number Number | ..." Now the newtype constructors seem a bit unnecessary, perhaps, but I guess they increase the type-checking. So I still feel that the above construtor is overly verbose. > On the other hand, there are much deeper issues at play here > regarding the representation of a language with variables as a data > type. The reference you gave on "higher-order abstract syntax" may be quite useful. I have also been looking over your paper on using Haskell as an Embedded DSL, which is extremely appealing for my application. I'm attempting to synthesize all of this into a coherent game plan... > What I did in my book was very simple, and the use of variables was > only given as an exercise (by the way, you left out the "Let" > constructor, which presuambly has the form "Let String Expr"). Yes indeed. I guess I should have tried compiling my example. I have the urge to post my solution to that exercise just so you know I did it right :-) I'm about to post an SOE question separately. peace, Isaac ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
representation getting verbose...
Greetings Haskellers, I'm running into a problem representing some fairly complicated types, and I'll try to put together a simpler example to get your suggestions. In Paul Hudak's SOE, I find a definition of expression: data Expr = C Float | V String | Expr :+ Expr | Expr :- Expr | Expr :* Expr | Expr :/ Expr Now this is compelling, but sometimes, I might want to have a function that takes a variable only, not just any kind of expression. I could write something like: typeOfVariable :: Expression -> Type typeOfVariable (V s) = ... _= error... But thats not very satisfying from a type-checking perspective. So it makes sense to create a constructor: data Variable = VVariable String data Expr = C Float | V Variable | Expr :+ Expr | Expr :- Expr | Expr :* Expr | Expr :/ Expr and make typeOfVariable :: Variable -> Type. But then when I want to match or create a variable expression, things are starting to get verbose: case expr of C f -> ... V (Variable (VVariable s)) -> ... ... And if I want a still more accurate hierarchy, the construction and destruction of Variables can really become cumbersome. For an interpreter I'm writing, I found myself writing a function "constructVarExpr :: String -> Expr" just to make it easier. This all seems very inelegant, and I get the feeling that there's a better way to do this. Any suggestions on how I could better represent Expressions or Variables to keep the type-checking but decrease the verbosity? peace, Isaac Jones ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
