- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] Re: [Haskell] pros and cons of static typing andside effects ?
by Ralf Lammel 18 Aug '05

18 Aug '05

I don't even want this feature. :-) The point being that datatype declarations, *as such*, are explicit anyhow. Why bother about the explicit quantifiers then? Of course, in a language with inferred datatypes I would mind. That's an interesting question! I also wouldn't (yet?!) support this feature request because we will still confuse beginners, but that's just my feeling. Ralf > -----Original Message----- > From: Stefan Holdermans [mailto:stefan@cs.uu.nl] > Sent: Tuesday, August 16, 2005 11:48 PM > To: Ralf Lammel > Cc: haskell-cafe(a)haskell.org; Benjamin Franksen > Subject: Re: [Haskell-cafe] Re: [Haskell] pros and cons of static typing > andside effects ? > > Ralf, > > > Technically this is trivial it seems. I think that some people > > consider this proposal a problem because typos (misspelled type > > parameters) immediately lead to the accidental exploration of a more > > advanced type-system feature and correspondingly more involved error > > messages. Of course, the type checker could perhaps consider adding > > "Did you really mean to ...?". > > Well, okay, but as soon as the type checker starts to asking these > questions, I would immediately start adding the explicit quantifiers, > just to get rid of those annoying warning messages. ;) So one would we > also need to be able to control the behaviour of the type checker with > respect to these warnings by means of a compiler flag like > "fno-warn-on-implicit-existential-quantification". All of this is, of > course, still trivial. :) > > Have we thought about it enough to make it a feature request? > > Regards, > > Stefan

2 1

RE: [Haskell-cafe] Re: [Haskell] pros and cons of static typing andside effects ?
by Ralf Lammel 17 Aug '05

17 Aug '05

Technically this is trivial it seems. I think that some people consider this proposal a problem because typos (misspelled type parameters) immediately lead to the accidental exploration of a more advanced type-system feature and correspondingly more involved error messages. Of course, the type checker could perhaps consider adding "Did you really mean to ...?". Ralf > I once read a paper about type classes and existentials (can't remember > exact title or author, was it Läufer?) where the proposal was to make > existential quantification implicit (just as the universal one is in > Haskell98). That is, any type variable that appears on the rhs of a > data type, but not on the lhs, is implicitly existentially quantified, > as in > > data XWrap = Show a => XWrap a > > I always thought this was a pretty nice idea.

2 1

Seeking a small bug-fix for previously-posted code
by Andy Elvey 17 Aug '05

17 Aug '05

Hi all - I'm trying to run some code posted recently on this list ( the exact URI is as follows - http://comments.gmane.org/gmane.comp.lang.haskell.cafe/7860 ( The reason I'm doing this is because this code is quite close to what I'm trying to do. ) Anyway, I saved the code in a file called andy1.hs . The exact code is as follows - module Main where readVecs :: String -> IO [Vector3 GLfloat] readVecs f = do str <- readFile f let mkVec [x,y,z] = Vector3 x y z return $ map (mkVec . read . words) $ lines str ( I can see what the code seems to be doing : it's reading the file line-by-line, splitting it into "words", and filling the vectors with them. Not too bad a guess for a "Haskellista" of a few minutes standing ..... ;-) I created a small file with whitespace-separated floats so that I could run the above code. This data file looks like this - 23.596 38.201 79.903 32.647 65.559 15.438 21.648 34.978 90.089 55.587 76.763 96.634 When I run the above code (in GHCi , version 6.4) I get the message - Prelude> :load andy1 Compiling Main ( andy1.hs, interpreted ) andy1.hs:4:7: The last statement in a 'do' construct must be an expression Failed, modules loaded: none. So - I'm just wondering if anyone can see how the above code should be fixed in order to run. And just one last question - If the file looked like this (with column headings ) Name Ethnicity Age Mary_Smith NZ_European 27 Joe_Brown NZ_European 34 John_Watson Canadian 45 Mike_Tangaroa NZ_Maori 38 - what change would the above code need to run? Very many thanks in advance ... - Andy

3 7

Re: [Haskell] pros and cons of static typing and side effects ?
by Mark Carroll 17 Aug '05

17 Aug '05

The previous comments make sense to me. The lots-of-unit-tests aspect of static typing I find really useful, far exceeding any BDSM cost. If I'm engaging in exploratory programming, the type inference combined with the ability to write 'error "armadillo"' in stubs for values I can't be bothered to generate right now really works conveniently for me. Although I agree that lots-of-lists is very handy in early prototyping, I don't feel at all constrained by using homogeneous lists, although very occasionally I may use existential types, and the way I write programmes is exactly to think in advance and then write the code: to do otherwise just wastes my time because then the code doesn't work in some confusing way and I have to do that thinking I postponed to figure out why - or, if it does work, I have to think about it to satisfy myself that appearances aren't deceiving. I'm not quite sure what macros would look like in Haskell, but I've not missed those either. In Lisp I would tend to use them for things that involved changing the values of variables, but that's not really a Haskellish thing to be doing anyway. Mind you, I learned Lisp after learning ML, so to some extent I was thinking in ML when writing in Lisp. Alas, dead-tree versions of "On Lisp" are hard to come by affordably, but I am now trying to learn more about what I might have missed about Lisp. I find monads useful because I find it a helpful debugging aid for functions to be quite clear about what side effects they may want to have. I posted this to Haskell-Cafe instead of the main Haskell list, because I'm rambling a bit. Puzzled Haskell-Cafe readers may like to check http://www.mail-archive.com/haskell@haskell.org/msg17009.html -- Mark

4 7

Creating a Haskell section in Autoconf Macro Archive
by Peter Simons 12 Aug '05

12 Aug '05

Fellow Haskell'ers, I've been maintaining the site <http://autoconf-archive.cryp.to/> for a while now, and I can't help but notice that there is no Haskell section. I know that GHC comes with a lot of useful Haskell-related Autoconf macros, so does Darcs, and so do a lot of other projects too. Thus, I was wondering whether the respective macro authors would be willing to submit their macros to the archive for distribution, so that other software developers around the world can find them, and re-use them. To have a macro added to the archive, all you need to do is to e-mail it to me in the proper mark-up format, so that the software which generates the archive can extract the necessary meta information and documentation. I'll use one of David Roundy's macros as an example to show what that looks like. Hope you don't mind, David. ;-) Here it is: | dnl @synopsis AX_TRY_COMPILE_GHC(PROGRAM, [ACTION-IF-TRUE], [ACTION-IF-FALSE]) | dnl | dnl AX_TRY_COMPILE_GHC tries to compile and link the given | dnl program using $GHC for the compiler, and $GHCFLAGS as | dnl flags passed to the compiler. | dnl | dnl @category Haskell | dnl @author David Roundy <droundy(a)abridgegame.org> | dnl @version 2005-08-12 | dnl @license AllPermissive | | AC_DEFUN([AX_TRY_COMPILE_GHC],[ | cat << \EOF > conftest.hs | -- [#]line __oline__ "configure" | [$1] | EOF | rm -f Main.hi Main.o | if AC_TRY_COMMAND($GHC $GHCFLAGS -o conftest conftest.hs) && test -s conftest | then | dnl Don't remove the temporary files here, so they can be examined. | ifelse([$2], , :, [$2]) | else | echo "configure: failed program was:" >&AC_FD_CC | cat conftest.hs >&AC_FD_CC | echo "end of failed program." >&AC_FD_CC | ifelse([$3], , , [ rm -f Main.hi Main.o | $3 | ])dnl | fi]) One of the more interesting keywords is @license, obviously. The license recommended by the Free Software Foundation for Autoconf macros is the all-permissive license, which reads like this: | Copying and distribution of this file, with or without | modification, are permitted in any medium without royalty | provided the copyright notice and this notice are preserved. Other valid choices are "GPL2", "GPLWithACException", and "BSD". A more thorough description of the keywords is available on the archive's homepage. Peter

2 2

Re: [Haskell] pros and cons of static typing and side effects ?
by Bernard Pope 12 Aug '05

12 Aug '05

[Moved to the Haskell cafe] It's Friday afternoon here so I thought I'd join in the fun. On Thu, 2005-08-11 at 23:01 -0400, ajb(a)spamcop.net wrote: > While you can't be certain that once your code typechecks, it's bug-free > (though that does often happen), you can be almost guaranteed that if > your code typechecks after a refactoring, the refactoring didn't > introduce any bugs. (I tend to agree with ajb's sentiment, but I'll play the devil's advocate anyway). Perhaps we can reach a fixed point of violent agreement? I'm a bit concerned with "can't be certain" on the one hand, and "_almost_ guaranteed", on the other. I guess there are nuances to be explored here, and it is all about degree of confidence. Sometimes I have high confidence in my refactoring, like introducing a state monad. Other times I have much less confidence, like swapping the order of arguments in numerical calculations. However, if it weren't for static type checking then I would be much less game to even _try_ introducing a state monad in my code in the first place. (Maybe that's just me). Another colleague of mine gave the opinion that one of the reasons higher-order code is less common in Prolog than Haskell is that in Prolog does not have static type checking (it's just one factor out of many). It seems to me like static type checking has the capacity to make some refactorings much less heroic than they would be in the non-static setting. That's my "log on the fire" for today. Bernie.

1 0

Re: [Haskell-cafe] Creating a Haskell app to do crosstabs
by Andy Elvey 12 Aug '05

12 Aug '05

Greg Buchholz wrote: >Andy Elvey wrote: > > >>a) Using Haskell to read a delimited file (with column-headings) into a >>columnar or tabular data-structure - >> >> >> Parsec (http://www.cs.uu.nl/~daan/parsec.html) is a great parsing >>library in Haskell. >> >> >>Greg Buchholz >> >> >> Hi Greg - thanks very much for this! I'll check Parsec out - thanks for the link - - Andy

1 0

Creating a Haskell app to do crosstabs
by Andy Elvey 11 Aug '05

11 Aug '05

Hi everyone - I'm a relative newcomer to Haskell, and am very much besotted with it - it's a great language! :-) At the moment, I'm in the early stages of putting together a little "Haskell-like" language using the Spirit parser framework (Spirit is part of the Boost C++ libraries). Spirit also has a functional-programming "sister" library (Phoenix), which includes lambdas, lazy functions and lots more. Phoenix is currently being merged with the Boost Lambda Library. ( Sorry for the off-topic digression - just giving the background to what I'm doing .... ;-) ) I've done a couple of "toy parsers" for Spirit already, but now I'm looking to do something that is more of a challenge - doing a small-ish Haskell-like language. The language is aimed at being able to read in a comma-delimited file (with column-headings), and putting the data into "columns". ( I envisage maybe a Haskell "pair". The first item being the column heading, the second being a list, with the data in it. ) Then, the user would select one of those "columns" for a "page" variable (that one would be optional), and one or more "columns" for the crosstab rows and columns. What I'm needing to do is to first put together the code in Haskell itself, and get it running. Then, that will give me a good feel as to how much of "core" Haskell I need to implement, in order to do the crosstab app. So, I was wondering - has anyone in the Haskell community used Haskell to do crosstabs? ( And if so, is there any code available? ). Any help in the two areas - a) Using Haskell to read a delimited file (with column-headings) into a columnar or tabular data-structure - b) Using Haskell to do crosstabs - - would be very welcome! I should also stress that full credit will be given to the writers of any code supplied. Very many thanks in advance for any help received! - - Andy

3 4

RE: [Haskell-cafe] Functional dependenices in class declarations
by Simon Peyton-Jones 11 Aug '05

11 Aug '05

It's intentional. Consider this data type declaration data B b = MkT (A a b) Should that be accepted? The only thing it could possibly mean would be data B b = MkT (forall a. A a b) and I suppose that might possibly be useful. But in this case you're also saying that "a" determines "b". But you can hardly say *forall* a, if the choice of a determines the (fixed by context) b. These functional dependencies are tricky things. Martin Sulzmann and I wrote a paper about some of the trickiness (http://research.microsoft.com/%7Esimonpj/Papers/fd-chr/index.htm) and we're working on a journal version. My wild guess is that you are trying to convert an O-O idiom into Haskell, and that's led you to a rather strange program. Maybe there's another way to do it. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Frank | Sent: 08 August 2005 18:17 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] Functional dependenices in class declarations | | In ghc 6.4 (fine work - many gratulations to all who did it!) it is | permitted | to have type parameters which are reachable (7.4.3.1 context of type | signatures). | I tried the following: | | module TypeDependencies where | | class A a b | a -> b | | class (A a b) => B b where | op :: a -> a | | x :: A a b => a -> a | x = id | | Which compiles fine for the function x, but does complain | "not in scope: type variable 'a' " for the class (A a b) => B b. | | Is this an intentional restriction that 'reachable' type variables are only | permitted in type definitions, but not in classes? or do I misunderstand | something? | | Any help appreciated! | Andrew Frank | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: [Haskell-cafe] Internal error: scavenge_one
by Simon Marlow 09 Aug '05

09 Aug '05

On 08 August 2005 20:22, Dinh Tien Tuan Anh wrote: > i have the following error when running my program: > > <interactive>: internal error: scavenge_one: strange object 47 > > does anyone know what it is ? Yes, it's probably a bug. Please report it to glasgow-haskell-bugs(a)haskell.org, giving your GHC version, platform, the program that produces the bug, and any other relevant options that we need to reproduce it. Cheers, Simon

1 0