Re: [Haskell-cafe] Re: Typechecker to GADT: the full implementation of a typed DSL
On 10/4/07, Pasqualino 'Titto' Assini [EMAIL PROTECTED] wrote: My mental typechecker seems to diverge on the data EQ a b where Refl :: EQ a a bit so I am now reading the typing dynamic typing paper, hoping for further enlightment. Basically, if you have Refl :: Eq a b, it provides a witness that the types a and b are really the same type. Consider this function definition: typechecka' :: Maybe (EQ ta t2) - Typ tb - Term (ta-tb) - Term t2 - Either String MostlyStatic typechecka' (Just Refl) tb e1 e2 = Right $ MostlyStatic (tb,App e1 e2) On the RHS of the =, ta and t2 are unified to the same type (because of the pattern-match on the GADT Refl). Without that, App e1 e2 won't typecheck, because e1 :: Term (ta - tb) and e2 :: Term t2. Once you have a witness that those are the same type, however, the typechecker will unify ta and t2 and App can typecheck. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Typechecker to GADT: the full implementation of a typed DSL
On 10/7/07, Ryan Ingram [EMAIL PROTECTED] wrote: On 10/4/07, Pasqualino 'Titto' Assini [EMAIL PROTECTED] wrote: My mental typechecker seems to diverge on the data EQ a b where Refl :: EQ a a bit so I am now reading the typing dynamic typing paper, hoping for further enlightment. Basically, if you have Refl :: Eq a b, it provides a witness that the types a and b are really the same type. Also, something that might make it simpler to understand is that the a and b in the initial GADT declaration are irrelevant (and totally ignored). Here is an equivalent definition: data EQ :: * - * - * where Refl :: EQ a a -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] reading from stdin
On 10/5/07, Reinier Lamers [EMAIL PROTECTED] wrote: You can probably unify the behaviors of platforms a, b and c by calling hSetBuffering on stdin to turn off buffering. I'm not so sure about this. I had a similar problem (GHC6.6.1 on Windows) where I had an app that wanted character-based console input on Windows. Calling hSetBuffering stdin NoBuffering didn't actually give me no buffering; not only that, but my app seemed to have readline-like input behavior on the console where I could go back to previously typed lines using the arrow keys, and my app wouldn't see anything until I hit Enter. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs, dotnet, C#...
Hi Peter, There is a Dotnet tree in the Hugs source code files, which I believe is what supports dotnet. As far as I am aware, it probably won't work. A windows developer may be able to build it, but I've never tried. You might also be interested to know that Yhc supports --dotnet to generate a dotnet binary. I think it can FFI call the dotnet framework, but I'm not sure. IDE's are hard, and only Microsoft does them right - perhaps one day if Haskell becomes popular enough we'll get something. Thanks Neil On 10/3/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: In the (Win)Hugs documentation, I found Only the ccall, stdcall and dotnet calling conventions are supported. All others are flagged as errors. However, I fail to find any more information on how to invoke dotnet methods. This might be really handy for me, as I'm very familiar with the dotnet framework. For example, yesterday I rewrote and extended a program that I wanted to develop in Haskell in just 3 hours using dotnet, while I spend weeks trying do this in Haskell. Of course, I'm a Haskell newbie and a dotnet expert, so this is not a fair comparison. However, I got a strange feeling, which I want to share with you :) First of all, it was a *horrible* experience to program C# again; I needed to type at least 3 times the amount of code, much of which was boilerplate code, and the code is not elegant. Haskell really changed my point of view on this; before I knew Haskell, I found C# (I'm talking C# 3.0 here) a really neat and nice language. On the other hand, the great Visual Studio IDE and Resharper addin made it at least 3 times faster to type, navigate, refactor, and debug the code... Somehow, I get things done really really really fast in C#, albeit in an ugly way. Once again, I just wish Haskell had such an IDE... And yes, I know of the existance of Visual Haskell, EclipseFP, Haskell Mode for Emacs (which I'm using), VIM, YI, but still, these do not compare with the experience I have when using Visual Studio/Resharper (or Eclipse or IntelliJ/IDEA for Java). But that might just be me of course... A slightly frustrated Peter ;-) BTW: I don't want to bring up the IDE discussion again, no really ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confusing type specialisation in ghci
Isaac Dupree wrote: David Carter wrote: This is all as I would expect so far, but: Prelude let sqlist = map sq Prelude :t sqlist sqlist :: [Integer] - [Integer] And indeed, I get Prelude sqlist [2.5] interactive:1:8: No instance for (Fractional Integer) ... etc The dreaded Monomorphism Restriction, which GHCi chooses to apply after every line you input. You could say let sqlist a = map sq a (syntactically having arguments makes the defaulting of (Num a = [a] - [a]) not apply), or just use `ghci -fno-monomorphism-restriction`. Isaac Thanks -- I had a feeling I'd seen something about it before, but couldn't remember where. Anyway it's good to know the syndrome has a name and a prevention strategy, even if not a cure :-). David -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On 05/10/2007, Andrew Coppin [EMAIL PROTECTED] wrote: So the question becomes: do you want to attract/seduce this kind of programmer? Let's assume the answer is yes :-) Um... that assumpion troubles me. ... I think if we want to get anywhere we need to look at targeting people whom Haskell actually has something to offer. Now, if I could just figure out who those are... :-/ And: On 05/10/2007, Jonathan Cast [EMAIL PROTECTED] wrote: On Fri, 2007-10-05 at 20:19 +, Aaron Denney wrote: On 2007-10-05, Peter Verswyvelen [EMAIL PROTECTED] wrote: If you want to attract more people that are inside the imperative-OO-with-nice-IDE-blob, create a great looking and functional IDE. Bluntly, I don't see why the Haskell community needs those sorts of programmers. Hear, hear. At the company I work for, all the code is perl/web development --- and we wouldn't dream of hiring one of those programmers. I posed the question: do we want to attract this kind of programmer? My personal opinion, which some of you obviously don't share, is yes. It isn't about whether or not the Haskell community needs those sorts of programmers. It's whether or not those sorts of programmers need Haskell. For me, a large part of Haskell's attraction are the features which reflect good engineering practice: strong, static type checking; purely functional code; good FFI. It should be easier to write simple, reliable software in Haskell than in most other languages; IMO, getting the unwashed hordes to use Haskell would be a great improvement in software industry productivity. I realise that a large influx of mediocre programmers will have a negative effect on the community, but is that a reasonable price to pay? I understand that may of you love a small, intimate, high-quality community, but perhaps that will have to evolve if we really want to conquer the world. Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confusing type specialisation in ghci
David Carter wrote: Prelude let sqlist = map sq ... Prelude sqlist [2.5] interactive:1:8: No instance for (Fractional Integer) ... etc Isaac Dupree wrote: The dreaded Monomorphism Restriction... You could... use `ghci -fno-monomorphism-restriction`. ...it's good to know the syndrome has a name and a prevention strategy, even if not a cure :-). I put :set -fno-monomorphism-restriction in my .ghci file. That pretty much cures it for me. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Mon, 8 Oct 2007, Alistair Bayley wrote: I posed the question: do we want to attract this kind of programmer? My personal opinion, which some of you obviously don't share, is yes. It isn't about whether or not the Haskell community needs those sorts of programmers. It's whether or not those sorts of programmers need Haskell. You cannot turn any programmer into a disciplined programmer just by giving him a well designed language. I you try so, they will not like to use that language, will leave that language as soon as possible or they try to adapt the language to their style of programming. For me, a large part of Haskell's attraction are the features which reflect good engineering practice: strong, static type checking; People who are used to weak typing will use a type like data Number = Int Int | Float Float | ... for numbers, or even String for everything, they will use numbers, where enumerations are more appropriate and so on. purely functional code; Undisciplined programmers will heavily use 'unsafePerformIO' good FFI. ... and will call external C functions, where Haskell code is more appropriate. It should be easier to write simple, reliable software in Haskell than in most other languages; IMO, getting the unwashed hordes to use Haskell would be a great improvement in software industry productivity. I realise that a large influx of mediocre programmers will have a negative effect on the community, but is that a reasonable price to pay? I understand that may of you love a small, intimate, high-quality community, but perhaps that will have to evolve if we really want to conquer the world. New programmers want example programs and libraries to learn style and tricks. The higher the portion of ill-designed libraries, the harder it is too find good examples. In my experience only the other way round works: Let people use C, Perl and Python until they find their programs unmaintainable. Then they will become interested in style and discipline and programming languages which _support_ good style. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
I just had a conversation today that seems relevant to this thread. I was chatting with a friend who is working in the academic sector, and I was observing that Melbourne Uni (my old school), is switching in the new year from teaching Haskell as a first language, to teaching Python. I was dismayed, but not surprised. Anyway, I was talking about this with my friend said that he understood the main reason for the change was that students were not being switched on or excited learning Haskell as they used to be learning C. He put it down to the fact that in C, you are more obviously making the computer do stuff, and that Haskell is sufficiently high level and abstract that beginner programmers don't get that thrill of feeling like you're making the computer work for you. I must say, I get that! but at the same time, of course, the high level abstraction is exactly what *we* love about Haskell. cheers, T. -- Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal library dependencies
Hi All, To test some programs written in CABAL, I need to use a server (where I do not have root access) with GHC 6.6.1 (in-place) installed. However, many programs need more libraries that have to be installed, (such as binary, or derive) for which, even when I use ./Setup configure --prefix=something, 1) After the ./Setup build, it can not do ./Setup install correctly because I am not root, ie. Installing: /usr/local/lib/derive-0.1/ghc-6.6.1 /usr/local/bin derive-0.1... Setup: /usr/local/lib/derive-0.1: createDirectory: permission denied (Permission denied) 2) But the .o and the .a files are created. However possibly due to (1), I can not make the program see the library, so in the end when I try configuring the program, I get (for example): Setup: cannot satisfy dependency derive-any possible solutions I could think of were: 1) LD_LIBRARY_PATH 2) use configure with a --with flag 3) copying the library files to the prefix directory of the program I ultimately want to run 4) The -L flag and still no luck, so here I am asking for your help... Thanks a lot in advance, Sincerely, -Nehir Sonmez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: cabal library dependencies
Could you try ./Setup configure --prefix=$HOME/somewhere --user HTH Christian Nehir Sonmez wrote: Hi All, To test some programs written in CABAL, I need to use a server (where I do not have root access) with GHC 6.6.1 (in-place) installed. However, many programs need more libraries that have to be installed, (such as binary, or derive) for which, even when I use ./Setup configure --prefix=something, 1) After the ./Setup build, it can not do ./Setup install correctly because I am not root, ie. Installing: /usr/local/lib/derive-0.1/ghc-6.6.1 /usr/local/bin derive-0.1... Setup: /usr/local/lib/derive-0.1: createDirectory: permission denied (Permission denied) 2) But the .o and the .a files are created. However possibly due to (1), I can not make the program see the library, so in the end when I try configuring the program, I get (for example): Setup: cannot satisfy dependency derive-any possible solutions I could think of were: 1) LD_LIBRARY_PATH 2) use configure with a --with flag 3) copying the library files to the prefix directory of the program I ultimately want to run 4) The -L flag and still no luck, so here I am asking for your help... Thanks a lot in advance, Sincerely, -Nehir Sonmez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: cabal library dependencies
Sure, that did it! Thank you very much Christian... Christian Maeder wrote: Could you try ./Setup configure --prefix=$HOME/somewhere --user HTH Christian Nehir Sonmez wrote: Hi All, To test some programs written in CABAL, I need to use a server (where I do not have root access) with GHC 6.6.1 (in-place) installed. However, many programs need more libraries that have to be installed, (such as binary, or derive) for which, even when I use ./Setup configure --prefix=something, 1) After the ./Setup build, it can not do ./Setup install correctly because I am not root, ie. Installing: /usr/local/lib/derive-0.1/ghc-6.6.1 /usr/local/bin derive-0.1... Setup: /usr/local/lib/derive-0.1: createDirectory: permission denied (Permission denied) 2) But the .o and the .a files are created. However possibly due to (1), I can not make the program see the library, so in the end when I try configuring the program, I get (for example): Setup: cannot satisfy dependency derive-any possible solutions I could think of were: 1) LD_LIBRARY_PATH 2) use configure with a --with flag 3) copying the library files to the prefix directory of the program I ultimately want to run 4) The -L flag and still no luck, so here I am asking for your help... Thanks a lot in advance, Sincerely, -Nehir Sonmez ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On 10/8/07, Alistair Bayley [EMAIL PROTECTED] wrote: I realise that a large influx of mediocre programmers will have a negative effect on the community, but is that a reasonable price to pay? I understand that may of you love a small, intimate, high-quality community, but perhaps that will have to evolve if we really want to conquer the world. Well, it's often been said that Haskell's unofficial motto is avoid success at all costs. See page 4 of Wearing the hair shirt: http://research.microsoft.com/~simonpj/papers/haskell-retrospective/HaskellRetrospective-2.pdf -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Data types, opengl display loop and readIORef/writeIORef
bbrown wrote:
This is more an aesthetics question, I have a simple opengl application that
has a singleton like object I need to pass around to the display loop and
possibly to the keyboard action handler. (pseudo code)
data SimpleMech = SimpleMech {
mechPos :: !MVector,
mechRot :: !MVector
} deriving (Read)
mainMech = initMech (0, 0, 0) (0, 0, 0)
mainMechRef - newIORef(mainMech)
displayCallback $= displayGameLoop mainMechRef
rotateMech :: (Double, SimpleMech) - SimpleMech
rotateMech (angle, mech) =
-- Calculate a new rotation
let (xrot,yrot,zrot) = (mechRot mech)
newyrot = newyrot + angle
^^^
That should be
newyrot = yrot + angle
in SimpleMech { mechRot = (xrot, newyrot, zrot),
mechPos = (mechPos mech) }
displayGameLoop mechRef = do
mech - get mechRef
mechRef $= (rotateMech (0.1, mech))
For some reason in that code above, the mechRef doesnt update the value I
want to change. It is like I am getting an instance of the initial valyue
back. Also, when I use writeIORef, eg writeIORef mechRef (rotateMech (0.1,
mech)
I get stack overflow exceptions.
The bug above is probably responsible for both the stack overflows with
writeIORef and for a $= that doesn't update (it wants to update, but the
program is trapped in an infinite loop).
Btw, you don't need parenthesis about function applications, you can use
record update syntax and functions with several arguments are usually
written in curried form:
-- Calculate a new rotation
rotateMech :: Double - SimpleMech - SimpleMech
rotateMech angle mech =
mech { mechRot = (xrot, yrot + angle, zrot) }
where
(xrot,yrot,zrot) = mechRot mech
mainMech = initMech (0, 0, 0) (0, 0, 0)
main = do
mainMechRef - newIORef mainMech
displayCallback $= displayGameLoop mainMechRef
displayGameLoop mechRef = do
mech - get mechRef
mechRef $= rotateMech 0.1 mech
The latter can also be written as
displayGameLoop mechRef = do
mechRef $~ rotateMech 0.1
Regards,
apfelmus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Data types, opengl display loop and readIORef/writeIORef
On Mon, 08 Oct 2007 17:41:12 +0200, apfelmus wrote
bbrown wrote:
This is more an aesthetics question, I have a simple opengl application
that
has a singleton like object I need to pass around to the display loop and
possibly to the keyboard action handler. (pseudo code)
data SimpleMech = SimpleMech {
mechPos :: !MVector,
mechRot :: !MVector
} deriving (Read)
mainMech = initMech (0, 0, 0) (0, 0, 0)
mainMechRef - newIORef(mainMech)
displayCallback $= displayGameLoop mainMechRef
rotateMech :: (Double, SimpleMech) - SimpleMech
rotateMech (angle, mech) =
-- Calculate a new rotation
let (xrot,yrot,zrot) = (mechRot mech)
newyrot = newyrot + angle
^^^
That should be
newyrot = yrot + angle
in SimpleMech { mechRot = (xrot, newyrot, zrot),
mechPos = (mechPos mech) }
displayGameLoop mechRef = do
mech - get mechRef
mechRef $= (rotateMech (0.1, mech))
For some reason in that code above, the mechRef doesnt update the value
I
want to change. It is like I am getting an instance of the initial
valyue
back. Also, when I use writeIORef, eg writeIORef mechRef (rotateMech
(0.1,
mech)
I get stack overflow exceptions.
The bug above is probably responsible for both the stack overflows
with writeIORef and for a $= that doesn't update (it wants to update,
but the program is trapped in an infinite loop).
Btw, you don't need parenthesis about function applications, you can
use record update syntax and functions with several arguments are
usually written in curried form:
-- Calculate a new rotation
rotateMech :: Double - SimpleMech - SimpleMech
rotateMech angle mech =
mech { mechRot = (xrot, yrot + angle, zrot) }
where
(xrot,yrot,zrot) = mechRot mech
mainMech = initMech (0, 0, 0) (0, 0, 0)
main = do
mainMechRef - newIORef mainMech
displayCallback $= displayGameLoop mainMechRef
displayGameLoop mechRef = do
mech - get mechRef
mechRef $= rotateMech 0.1 mech
The latter can also be written as
displayGameLoop mechRef = do
mechRef $~ rotateMech 0.1
Regards,
apfelmus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
That should be
newyrot = yrot + angle
Thanks, I can't believe I missed that bug. I laughed out loud when I saw
that.
--
Berlin Brown
[berlin dot brown at gmail dot com]
http://botspiritcompany.com/botlist/?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Converting Double from String
(moving to haskell-cafe...) On 10/8/07, Johan Tibell [EMAIL PROTECTED] wrote: On 10/8/07, bjornie [EMAIL PROTECTED] wrote: Hi! I'm kind of new to functional programming with Haskell, I'm reading a university course you see. Now I'm having some problems with one of our lab assignments, we're supposed to write a program handling numeric operations (addition, multiplication, and some functionality like sin and cos). I've made a data type; data Expr = Num Double | Add Expr Expr | Mul Expr Expr... I.e for representing the expression: 2.4 * (4.0 + 1.5) The Haskell representation is: Mul (Num 2.4) (Add (Num 4.0) (Num 1.5)) My problem is to convert a String to an expression like the one above. I.e the String: 2.4*(4.0+1.5) If we would use plain Integers there would not be a problem, since the Prelude function 'digitToInt' :: Char - Int does nearly what I would like to do. But I'm stuck on the Doubles! How can I solve this in a smooth way? You can use read. Here's a session from GHC's interpreter: $ ghci Prelude read 1.0 :: Double 1.0 Since read is polymorphic (i.e. works for different types) you need to specify the type of the result you want using :: Double. ...although if you have something like Num (read x), you don't need the :: Double since the typechecker can figure it out (the Num constructor has to take a Double). Note that you would use the 'read' function to read integer values, too; digitToInt is just for dealing with single Chars, not entire integral values. The read function takes a String representation of anything that is readable (any type that is an instance of the Read type class) and converts it into a value of the requested type, so it works for Doubles, Ints, Integers, lists, and so on... Also, if I were you I'd use something other than Num as the name of the data constructor for numeric values in your Expr type. Num is already used for something else (it's the name of the general numeric type class), and although it's legal to have the same name for both, it might lead to confusion, especially when dealing with error messages. Good luck with learning Haskell and with your course! If you need more help there's also the #haskell IRC channel on freenode.nethttp://haskell.org/haskellwiki/IRC_channel, where you'll find lots of friendly people who would be glad to answer your questions. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confusing type specialisation in ghci
You can also remove the Monomorphism Restriction by adding an explicit type signature: Prelude let sqlist :: Num a = [a] - [a] ; sqlist = map sq Prelude :t sqlist sqlist :: (Num a) = [a] - [a] Basically, there are three things that have to be the case for the MR to kick in: 1) You are defining a function that takes no explicit arguments (or is a pattern binding). 2) You didn't specify a type signature. 3) The inferred most-general-type of the function has typeclass constraints. The reason becomes clear when you consider the following: genericLength :: Num n = [a] - n -- from Data.List f :: [a] - (Integer, Integer) f xs = (len, len) where len = genericLength xs (this example taken from http://www.haskell.org/haskellwiki/Monomorphism_restriction) Without the monomorphism restriction, len :: Num n2 = n2. This means len can't be calculated until you know its final type; it's effectively stopped being a shared constant and started being a function. This means that when evaluating the pair (len,len), the length of the list may end up being calculated twice! With the monomorphism restriction, len gets the type Integer, and can be shared. For contrast, consider this function: f2 :: [a] - (Int, Integer) f2 xs = (len, len) where len :: Num n = n len = genericLength xs In this case, you have no choice but to call genericLength twice, since the result has to be two different types. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] New slogan for haskell.org
At my school the students are learning C/C++ in the programming courses, but I'm teaching them a tiny bit of Haskell in the math courses, and most of them seem to love it. I think every programmer should see an imperative, object-oriented and lazy functional language, at least (and maybe also Prolog...). And if you really want to have control over what the computer is doing, stick to assembler... but who is still doing that these days? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Conway Sent: Monday, October 08, 2007 12:55 PM To: Don Stewart Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] New slogan for haskell.org I just had a conversation today that seems relevant to this thread. I was chatting with a friend who is working in the academic sector, and I was observing that Melbourne Uni (my old school), is switching in the new year from teaching Haskell as a first language, to teaching Python. I was dismayed, but not surprised. Anyway, I was talking about this with my friend said that he understood the main reason for the change was that students were not being switched on or excited learning Haskell as they used to be learning C. He put it down to the fact that in C, you are more obviously making the computer do stuff, and that Haskell is sufficiently high level and abstract that beginner programmers don't get that thrill of feeling like you're making the computer work for you. I must say, I get that! but at the same time, of course, the high level abstraction is exactly what *we* love about Haskell. cheers, T. -- Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: binary 0.4: high performance, pure binary parsing and serialisation
don: The main thing is porting to ghc 6.8 -- which means the new (*faster*) lazy bytestring representation, and the smp parallel quickcheck driver for the testsuite (it'll use N cores, watch the jobs migrate around). Great news... Thanks for the collective work on this. I'm looking forward to firing up hpc. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On 10/8/07, Alistair Bayley [EMAIL PROTECTED] wrote: For me, a large part of Haskell's attraction are the features which reflect good engineering practice: strong, static type checking; purely functional code; good FFI. It should be easier to write simple, reliable software in Haskell than in most other languages; IMO, getting the unwashed hordes to use Haskell would be a great improvement in software industry productivity. I recently put it thus to a friend: When it's hard writing a program in Haskell, it is usually because Haskell makes you think about what you are doing, and as a consequence you end up doing your thinking sooner rather than later. This usually ends with better software with fewer bugs. cheers, T. -- Thomas Conway [EMAIL PROTECTED] Silence is the perfectest herald of joy: I were but little happy, if I could say how much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On 08/10/2007, Henning Thielemann [EMAIL PROTECTED] wrote: You cannot turn any programmer into a disciplined programmer just by giving him a well designed language. I you try so, they will not like to use that language, will leave that language as soon as possible or they try to adapt the language to their style of programming. Well, I wasn't suggesting you'll create great programmers overnight, but you might expect that their appreciation of good design might improve after some Haskell exposure. Also, Haskell simply doesn't support some of the things that are common causes of errors in the enterprisey-language world. I recall reading something about one of the most common causes of errors in novice programs being type errors (presumably, once they'd got the program to compile i.e. there were no syntactic errors). And I'm under the (possibly mistaken) impression that some of the common errors non-novice programmers make are aliasing bugs, and/or use of global variables. Does anyone have references to studies confirming (or refuting) this? People who are used to weak typing will use a type like data Number = Int Int | Float Float | ... for numbers, or even String for everything, they will use numbers, where enumerations are more appropriate and so on. I think that the ease with which you can create a new type in Haskell (and derive useful classes like Enum, Show, etc) makes it more likely that a programmer will use an appropriate domain-specific type, rather than just reuse String, Int, or Float. In my experience only the other way round works: Let people use C, Perl and Python until they find their programs unmaintainable. Then they will become interested in style and discipline and programming languages which _support_ good style. Well, yes. Or have them learn Haskell, and *then* C/C#/C++/Java/Perl etc, and see if the experience for those languages is as good. I like to think they'll come running back to Haskell's warm bosom. Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan... (A long speculation)
Thomas Conway writes: I was observing that Melbourne Uni (my old school), is switching in the new year from teaching Haskell as a first language, to teaching Python. I was dismayed, but not surprised. ... This was commented already, but perhaps a few words from a different perspective. Computer scientists (even an illegitimate one, like myself) love teaching functional languages... I think I was one of first people in my dept., University of Caen, Normandy, France, who taught Scheme on a regular basis, to math students. The merits of Scheme contributed to our decision to teach it as the first language to Science students (in France they don't begin as Comp. Sci. students, but more generally, and specialize afterwards [[e.g., choosing physics because they hate programming, or math, because they had lousy results in physics... etc.]] We did it for 15 years, or more, but then some people from electronics, from physics, etc., our colleagues with whom we are de facto pedagogically married, began to complain. There were many silly arguments against Scheme, we could have dismissed all that. But there were arguments which were (for me) quite reasonable and relevant. One of them was quite superficial, but interesting, and I will come to it in a while: * Scheme is very different from what we practice (C++, Fortran, etc., you know the song...) It may slow down the *adaptation* of students. They *will need* all that imperative stuff you hate. But, as a first language, the FLs condition the young minds in a way we do not appreciate. -- I was personally convinced that the passage to some imperative language was after all not so bad because of another argument. The first language taught has a particular, not always wanted flavour: it is perceived as an academic language, conceived for being *taught*, and not really used. Students know that they must do some assignments, pass exams, etc. They feel coerced, and not necessarily see this training as a trampoline for their future fabulous software. So, after some negotiations, we chose Python (nobody felt that we should be worry that Python won't be used...), and I was one of the protagonists of this solution. But, simultaneously, I advertized very modestly Haskell, and now our students begin with Python, at their 2nd year they have also Java but also a bit of Haskell, and the 3rd year, their Licence diploma, they must learn Haskell not just as a programming language, but as something which permits to solve problems in AI, in compilation, in language processing, in some computational logic, etc. It turns out that having the possibility to *compare*, students assimilate Haskell with more conviction. They appreciate the compactness, *because* they have seen Java at work. Etc. == So, there is no need to be dismayed. And one more thing. I wonder whether the slogans which underline the merits of the *language* Haskell is the best possible approach. Perhaps it would be interesting to try to sell the elements of the paradigmatics of modern FP: - automatic type inference in a powerful polymorphic setting - laziness (eventually) - purity which is good for proving things, etc. - monads as universal structuring tools ... -- in a way not necessarily fusioned with a language. But this means that we should have *more* functional languages to enable some comparisons. There is no lazy untyped language. Why?? (No, don't tell me that we have the delay macro in Scheme. I cannot code my co-recursive algorithms without a lazy letrec, or a painful gymnastics.) Worse, some people from time to time complain that Clean exists, and they suggest that effort put into it could be used to improve Haskell. Such people serve the Devil! So, perhaps this is a perverse philosophy, but I see some sense in making several languages, exploiting some facettes of FP separately, as a way of throwing the bridge between our Glorious Kingdom and Le Monde des Ténèbres. Yes, finding some *comparable* competitors would do much good. Some niches are already occupied and busy, e.g., the domain where Erlang is strong. But there is yet some mileage to go. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Mon, 8 Oct 2007, Alistair Bayley wrote: On 08/10/2007, Henning Thielemann [EMAIL PROTECTED] wrote: You cannot turn any programmer into a disciplined programmer just by giving him a well designed language. I you try so, they will not like to use that language, will leave that language as soon as possible or they try to adapt the language to their style of programming. Well, I wasn't suggesting you'll create great programmers overnight, but you might expect that their appreciation of good design might improve after some Haskell exposure. Also, Haskell simply doesn't support some of the things that are common causes of errors in the enterprisey-language world. I recall reading something about one of the most common causes of errors in novice programs being type errors (presumably, once they'd got the program to compile i.e. there were no syntactic errors). And I'm under the (possibly mistaken) impression that some of the common errors non-novice programmers make are aliasing bugs, and/or use of global variables. Does anyone have references to studies confirming (or refuting) this? Thus, what happens today? People ask Haskell-Cafe how to implement global variables and they are advised to use IORefs and unsafePerformIO, although the better answer is: Why do you want to do this? Even Tackling the awkward squad considers unsafePerformIO an acceptable tool for handling global configuration files. People who are used to weak typing will use a type like data Number = Int Int | Float Float | ... for numbers, or even String for everything, they will use numbers, where enumerations are more appropriate and so on. I think that the ease with which you can create a new type in Haskell (and derive useful classes like Enum, Show, etc) makes it more likely that a programmer will use an appropriate domain-specific type, rather than just reuse String, Int, or Float. I know of popular Haskell libraries which ignore disciplined type design, but I do not want to hurt their authors ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On 10/8/07, Henning Thielemann [EMAIL PROTECTED] wrote: Thus, what happens today? People ask Haskell-Cafe how to implement global variables and they are advised to use IORefs and unsafePerformIO, although the better answer is: Why do you want to do this? Even Tackling the awkward squad considers unsafePerformIO an acceptable tool for handling global configuration files. One problem here is that the Haskell-style alternatives to global parameters aren't as convenient as to use. We should consider stealing Agda's module system for Haskell 2.0. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Mon, 2007-10-08 at 20:54 +1000, Thomas Conway wrote: I just had a conversation today that seems relevant to this thread. I was chatting with a friend who is working in the academic sector, and I was observing that Melbourne Uni (my old school), is switching in the new year from teaching Haskell as a first language, to teaching Python. I was dismayed, but not surprised. Anyway, I was talking about this with my friend said that he understood the main reason for the change was that students were not being switched on or excited learning Haskell as they used to be learning C. He put it down to the fact that in C, you are more obviously making the computer do stuff, and that Haskell is sufficiently high level and abstract that beginner programmers don't get that thrill of feeling like you're making the computer work for you. I must say, I get that! but at the same time, of course, the high level abstraction is exactly what *we* love about Haskell. Then they should teach assembly not Python. In fact, I'd recommend assembly anyway. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
since this doesn't seem to want to go away:-) 1. reverse psychology approach if you have reached this page following rumours of a language others told you every serious programmer would have to learn, the ministry of programming would like to reassure you that there is no such language. there is no need to panic! please provide us with the names of those referers, so that we may help them to understand the errors of their ways, then proceed to theusual.com for urgent reeducation. if you have been led to believe that the ideas of virtual machines, generic programming, etc have not originated in java, that map reduce was not invented by google, that pattern-matching does not need to be restricted to regular expressions, that parsers, interpreters, compilers for (embedded) domain-specific languages might be written by mere programmers without professional assistance, that neither concurrency nor maintenance need to lead to a mess, or similarly outrageous insinuations, please contact your nearest accredited consultant immediately. do not be alarmed! the ministry is here to help you! blink warning! our automated eye glance and attention monitors have detected that you have recognised at least one of the trap phrases not representing authorised trademarks of wesellyoubuy.com products in the previous paragraphs. do not attempt to leave your keyboard! one of our emergency thread supression teams has been dispatched to your present location! you have been warned! /blink 2. mantra approach there is no need to leave your warm fuzzy ide - to reassure yourself, debug some pointer errors and refactor some boilerplate code you do not need to learn haskell: - to restore your faith, buy two copies of programming for everyone plus one of the manager is always right nothing is more effective than standard meta-muddling - version 3 of our muddling tools can now generate non-executable boilerplate code from random squiggles at a rate of 20 lines per second (our integrated productivity metric analyser rates that as promotion material) - the generated code is inherently protected against analysis, modification, or composition; source code compression tools are available as extensions you do not need to look into haskell - as a penance, buy two compilers, a revision control system and a window manager there is no need to be alarmed - there will always be jobs for pascal programmers (sorry, that should have been cobol; or was that c? c++? perl? java? .. anyway, you know you're safe) 3. secret cult approach haskell: archaic, see also: programming language alegedly used by vorlon before they started tying knots in real time (cf b4). when informed that 99,9% of human programmers did not even want to look at the language, the vorlon ambassador replied: good. 4. reach for the moon approach do not ask what haskell can do for you, ask what you can do for haskell. .. interactive:1:0: No instance for (Enum Slogan) arising from the arithmetic sequence `1.2.3.4. .. ' at interactive:1:0-6 Possible fix: add an instance declaration for (Enum Slogan) In the expression: [1.2.3.4. .. ] In the definition of `it': it = [1.2.3.4. .. ] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On 08/10/2007, at 8:54 PM, Thomas Conway wrote: I just had a conversation today that seems relevant to this thread. I was chatting with a friend who is working in the academic sector, and I was observing that Melbourne Uni (my old school), is switching in the new year from teaching Haskell as a first language, to teaching Python. I was dismayed, but not surprised. Anyway, I was talking about this with my friend said that he understood the main reason for the change was that students were not being switched on or excited learning Haskell as they used to be learning C. He put it down to the fact that in C, you are more obviously making the computer do stuff, and that Haskell is sufficiently high level and abstract that beginner programmers don't get that thrill of feeling like you're making the computer work for you. I must say, I get that! but at the same time, of course, the high level abstraction is exactly what *we* love about Haskell. Presently, at Melbourne Uni we teach Haskell as a second language after C. In their first year, my class has two and a half semesters of C, followed by half a semester of Haskell. There is a parallel stream, where the split between C and Haskell is 50-50 (the so-called advanced stream). My general feeling is that students are responding well to Haskell, and it is a welcome break from segfault-land. However, it is hard for them to evaluate the merits of pure functional programming, when they've seen so little of the alternatives. We get the occasional early convert, but most of the students remain sceptical (and rightly so, I think). Also, first year students spend all their time concentrating on programming in the small, which means that they don't see _as much_ benefit from the kinds of abstraction that Haskell offers over C. In my opinion, the move to Python is motivated by other concerns, which come about because the undergraduate program is going through a radical change across the whole university. There is a corresponding shift in our first-year demographic, which motivates a change in the focus of the first year program. I'm not so concerned about losing Haskell in the first year (especially to Python). Personally, I would like to see functional/declarative programming gain more prominence later in the curriculum - at the point where students are at a higher level of programming sophistication, and are more likely to appreciate the material. I have spent a reasonable amount of time extolling the virtues of functional programming to first year students over the years. The one thing which seems to get the best response, and makes them sit up and listen, is when I tell them that GHC is maintained largely by people who work at MS research! Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
Don Stewart wrote, catamorphism: On 10/4/07, Don Stewart [EMAIL PROTECTED] wrote: It was raised at CUFP today that while Python has: Python is a dynamic object-oriented programming language that can be used for many kinds of software development. It offers strong support for integration with other languages and tools, comes with extensive standard libraries, and can be learned in a few days. Many Python programmers report substantial productivity gains and feel the language encourages the development of higher quality, more maintainable code. With the links from the start about using Python for various purposes, along with reassuring text about licenses and so on. Note its all about how it can help you. The Haskell website has the rather strange motivational text: Haskell is a general purpose, purely functional programming language featuring static typing, higher order functions, polymorphism, type classes, and monadic effects. Haskell compilers are freely available for almost any computer. Which doesn't say why these help you. Any suggestions on a 2 or 3 sentence spiel about what's available? Here's some quick points: General purpose: applications from OS kernels to compilers to web dev to ... Strong integration with other languages: FFI, and FFI binding tools Many developer tools: debugger, profiler, code coverage, QuickCheck Extensive libraries: central library repository, central repo hosting Productivity, robustness, maintainability: purity, type system, etc Parallelism! Can't we embrace the power of 'and'? It's wonderful that Haskell is seeing more practical use, but we shouldn't forget the foundations, either. Maybe we should put your second description first, and *then* have a paragraph saying, and, for those who know what these are, polymorphism, monadic effects, etc.? Only describing Haskell in terms of software engineeering doesn't seem right to me. Yes, I think that's the best step. Combine both why you'd use it, with what unique features enable this. I also agree that this is the right way to go. FWIW, the CUFP talk that started this discussion took the current text out of context. It is one thing to have the fp-speak description of Haskell in isolation (as in the CUFP talk) and another to have it on the wiki front-page, where the side bar advertises libraries, applications, etc. and the middle has news items and so forth. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type-level arithmetic
Andrew Coppin wrote,
I've seen quite a few people do crazy things to abuse the Haskell type
system in order to perform arithmetic in types. Stuff the type system
was never ever intended to do.
Well I was just wondering... did anybody ever sit down and come up with
a type system that *is* designed for this kind of thing? What would that
look like? (I'm guessing rather complex!)
Type families are a step in that direction:
http://haskell.org/haskellwiki/GHC/Type_families
Appended is a small example of defining singleton numeral types.
Manuel
-=-
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE EmptyDataDecls #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeOperators #-}
module Numerals
where
data Z -- empty data type
data S a-- empty data type
data SNat n where -- natural numbers as singleton type
Zero :: SNat Z
Succ :: SNat n - SNat (S n)
zero = Zero
one = Succ zero
two = Succ one
three = Succ two
-- etc...we really would like some nicer syntax here
type family (:+:) n m :: *
type instance Z :+: m = m
type instance (S n) :+: m = S (n :+: m)
add :: SNat n - SNat m - SNat (n :+: m)
add Zero m = m
add (Succ n) m = Succ (add n m)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
