December 2002 - Haskell-Cafe

RE: Haskell related Debian packages
by Simon Marlow 13 Dec '02

13 Dec '02

> 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. Also see the recent discussion on glasgow-haskell-users about a library building/packaging system (which didn't really reach a conclusion). > 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. I think I would have two versions of each package: one that builds & installs a package for GHC, and one that installs source files for use with Hugs (GHCi can use the GHC package). These really are entirely different beasts, and in most cases will have zero files in common, so I think it makes sense to separate them altogether. That way you don't have to require GHC in order to install the Hugs version of the package, and vice-versa. Cheers, Simon

1 0

Re: ffi
by Martin Huschenbett 12 Dec '02

12 Dec '02

> > $ ghc -ffi -o myprog Main.hs cfile.o > When I try this I also get an error: martin:~/work/prograemmelchen> ghc -ffi -o myprog Main.hs cfile.o ghc-5.02.2: unrecognised flag: -ffi Usage: For basic information, try the `--help' option. Do I use a wrong GHC version? THX, Martin.

3 4

Re: Monads [beginner]
by Benderjgdefault＠aol.com 12 Dec '02

12 Dec '02

In a message dated 12/12/2002 2:45:31 PM Eastern Standard Time, maas(a)cin.ufpe.br writes: > What are Monads? > Where can I read about then? > > I read that there´s some mathematical foundation under this > concept, where > can read about these theories? A large set of articles on monads in the context of Haskell are collected on my bibliography web site: http://haskell.readscheme.org/monads.html There are also a few, more tutorial, articles available at http://haskell.org/bookshelf/ that are not included on my monads page. For more theoretical works-- while still being programming language related--I suggest Eugenio Moggi's site: http://www.disi.unige.it/person/MoggiE/publications.html. Jim Bender

1 0

Haskell related Debian packages
by None 12 Dec '02

12 Dec '02

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

3 2

AW: ffi
by Markus.Schnell＠infineon.com 12 Dec '02

12 Dec '02

> $ cc -c cfile.c > $ ghc -o myprog Main.hs cfile.o won't you need -fffi also? Markus

1 0

ffi
by Martin Huschenbett 11 Dec '02

11 Dec '02

Hi all, I've got a simple question concerning FFI but as I am a newbie I don't know the answet. I've got a C-source-file, maybe something like: //cfile.c void cfun() { /* ... do something ... */ } //EOF and a Haskell-source-File, maybe something like: -- Main.hs module Main where main :: IO () main = do -- do something cfun -- I wan't to call the function written in C here -- do again something -- EOF And now my question is: How do i realize this? Can you please tell me how write a binding and how tu run ghc. Thank you very much, Martin.

2 1

video4linux
by Martin Huschenbett 10 Dec '02

10 Dec '02

Hi all, does anybody know how to read a single image from a video4linux device under Haskell? Thanks for all help, Martin

2 1

Re: AW: Editor Tab Expansion
by Marcin 'Qrczak' Kowalczyk 10 Dec '02

10 Dec '02

Fri, 6 Dec 2002 12:09:46 +0100, Ingo Wechsung <iw(a)contexo.de> pisze: > No. My editor produces the ASCII code for horizontal tab, when I > hit the tab key. Just as it produces the ASCII code for a when I > hit the a key. > > That's how it should be. It shouln't, becase tabs are 8 spaces, which is too much for indentation of programs in most languages. > The real problem is, that nobody could tell from just looking at > the screen, what a program means even if you know the layout rules > very well. Of course I can. If you can't, perhaps you are using a non-standard tab width? Please fix settings of your editor and it will work. > Instead, your text editor displays some space in place of the tab. > Only if the expansion rules of your editor are compatible with > Haskell's may you grasp the source codes meaning. But they are compatible because there is one most universally accepted interpretation of a tab (move to the next multiple of 8 columns). Any other interpretation hampers portability and should be avoided. > Think of a software development team. One member (in India) > uses "convert n leading spaces to tabs", the other (in Japan) > "convert leading tabs to m spaces". Everytime one of them makes a > small change in a file that has been changed by the other before, > the source code control system will have a huge diff. All these problems are caused by people who use a different tab size than 8. With consistent tab size there is no reason to convert between tabs and spaces. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

5 5

AW: AW: Editor Tab Expansion
by Ingo Wechsung 10 Dec '02

10 Dec '02

Beg your pardon, Marcin >But they are compatible because there is one most universally accepted >interpretation of a tab (move to the next multiple of 8 columns). Any >other interpretation hampers portability and should be avoided. No. It didn't hamper portability with C, Java, Perl or any other *nix stuff since more than 30 years except with COBOL, Python (?) and Haskell, where COBOL is excused due to its origin in the punch card era. The others are not excused, since they are yet to be established newcomers. The wise new language designer should obey the unix rule "whitespace does not matter" instead to expect that the world change their .exrc (by the way, according to ls -l my .exrc is several years older than Haskell) to accomodate. >All these problems are caused by people who use a different tab size than 8. They used to do so, since Jan 1 1970 00:00 GMT, without real problems apart from pure formatting problems. The formatting problems will not go away with the advent of Haskell. But 2 new problems suddenly arise: syntax error due to formatting and formatting dependend semantic. But even if it were so and you could expand a tab to 8 columns only, there is still the tools problem. No meaningful diff -b on Haskell source. Almost every language tool has to be a haskell parser, etc. etc If you can't or won't see that, fine. But don't expect Haskell to be too successfull in the professional software engeneering business very soon. Though, it was my impression, that the FP community would like to promote their ideas of how to make more reliable, better software to more people. This "obey the 8 column rule, use emacs, change your .exrc or get lost" attitude is less than helpful, at least in my opinion. Cause it's FP that matters, not the layout thing which has absolutely nothing to do with FP. (Anyway, I still love Haskell{;}) Cheers, Ingo

5 5

Editor Tab Expansion
by Ingo Wechsung 09 Dec '02

09 Dec '02

Hello, I'm new to Haskell and FP in general and I find it great. Having more than 10 years expirience with "whitespace does not matter" languages, the only thing that drives me crazy is the layout rule. As far as I understand it, I have 2 options: 1. Use braces and semicolons and ignore the layout rules. 2. Change the settings in all my editors so that the code looks like the Haskell compiler sees it. Currently, I expand tabs to 4 spaces only, so \tx=bar looks like ____foo = bar to me when the compiler sees ________foo = bar I would not want to change dozens of .exrc files, shell startup files with and/or ultraedit settings on many different machines. I also do not want to care whether there are spaces or tabs in front of my source code lines. So I'm stuck with option 1, right? Just to be sure, can I really, really forget about layout if I write fully braced and semicolonoized code? Besides, is there any reason why the syntax is LET { decl1; decl2; ... } IN expr when LET and IN are sufficient enough to enclose the declarations? Greetings, Ingo

6 5