- Haskell-Cafe - Haskell.org

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

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

07 Dec '02

Simon wrote: >There's no reason not to use 8 column tab stops, so please don't do it. Ok, if "it just looks better to me" is no reason, then the following also holds: There's no reason not to use braces and semicolons, so please use them. > but it will be interpreted differently by a Haskell compiler. That's exactly my point. I consider it harmful, to put it mildly. >Tab characters are a primitive compression mechanism, nothing more. Well, layout rule may be regarded as an even more primitive compression mechanism, since it saves fewer bytes than tabs. (Remember that "it looks better" was outlawed before.) I have the impression that the view is somewhat biased toward the layout. Nobody seems to care about the trouble that is luring in the long run. You can't go professional with "use another editor", "change your long established habits", "don't use diff -b". Cheers, Ingo

3 2

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

06 Dec '02

Thanks for the anserws. So I will write the braces and semicolons. It's better anyway in my opinion. I am not going to change my editing habits just to make hugs or ghc happy. Wether spaces or tabs are better in source files is a matter of taste and a language should not force me to use one or another. I can't help it, but to make the meaning of a program depend on the questions whether there are spaces or tabs in front of the line, and how many, seems silly to me. Sorry. Hal Daume III wrote: >so it needs to know where the boundaries between declarations are, hence >the need for semicolons. therefore, if you have embedded lets, you need >braces to delimit them: > let x = let y = z > q = r > in l > in q >would be ambiguous without layout/braces&semis. I don't see that. Sure, you need semis. But then let x = let y=z; q=r; in l in q or even let x = let y=z; q=r in l in q is just as unambiguous as (hypothetical) ( x = ( y=z; q=r ) l ) q I mean, you can see "let" as opening brace and "in" as closing brace. So no real need to write "let {" and "} in". Greetings, Ingo

6 5

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

06 Dec '02

Andrew wrote: >My remark was merely in response to the claim that Haskell cares >whether you put tabs or spaces in your files. It does not, so long >as the tabs are of length 8. If your editor produces tabs of a >different size, that's a problem with your editor or the way you >dislike Haskell's layout rules. 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. 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. The reason is, that the Haskell lexer sees tabs while you cannot see tabs unless you use a hex editor. 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, again, you can't know that by just looking at the screen. You have to use the :l command or the :se command in vi, for example, to make sure a) there are either only tabs or only spaces in front of the lines or b) the editor lets you view tabs expanded to 8. Or, to turn it another way: "What you see is not necessarily what you get". This may be fine for ad hoc scripts that one examines in hugs. But how can one hope to convince people that this is a good thing for reusable code, to be compiled code, serious software production! I mean business. Teams. Maintenance of code that has been written by someone else, etc. Some people suggested that the editor be configured so that it converts all tabs to spaces or vice versa on file open. Beware! 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. Because, you can't use diff -b (ignore leading white space in comparision) on Haskell source. That implies that you cannot see later what this small change was. Instead, every indended line will be displayed as changed. This is a NIGHTMARE for project leaders, quality assistance staff, code maintainers. Greetings, Ingo

2 1