- Haskell-Cafe - Haskell.org

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 11 Dec '02

11 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 10 Dec '02

10 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 07 Dec '02

07 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

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

06 Dec '02

Kevin, thanks for your helpfull comments. Ingo> Or, to turn it another way: "What you see is not necessarily Ingo> what you get". This may be fine for ad hoc scripts that one Ingo> examines in hugs. >So is that the language's fault (because of what you get) or the >editor's fault (because of what you see)? It depends on the abstraction level. Sure, I don't see Tabs and Spaces on the character level. I was not supposed to, up to now. On a higher level I see whitespace. Whitespace didn't matter, except for making things look nicer, up to now. I don't say the language is wrong. Beware. I only have my doubts about the question if its a good idea to cast a whitespace aware thing into an environment, namely *nix, where whitespace didn't matter. Up to now. Now that I know I can use semicolons and braces safely with any spacing, I can live with it. It's fine for me. I could write a haskell-insert-braces-and-semicolons-where-needed program if I feel like it. I think I will not feel like so, except for amusement. But then, I've got to get checks from my customers by the end of the month. So, perhaps I'll rather try to get my work done. But the problem will hurt others, again and again. Good night Ingo

1 0

Completeness of pattern matching
by Ingo Wechsung 06 Dec '02

06 Dec '02

Hi there, I wonder if the compiler could check, if all possible combinations have been checked in a pattern match. For example: data Colour = Red | Yellow | Green | Blue; trafficlight Red = True; trafficlight Yellow = True; trafficlight Green = True; trafficlight Blue = False; This is complete and okay. But, if somebody adds Magenta to Colour, then the function trafficlight becomes incomplete and the program might terminate at runtime whereas before it could not. (Of course, there could be dozens of more complicated case scattered over multiple files ...) If this could be checked, shouldn't it be an compile time error to have incomplete functions? Cheers, Ingo

3 2