[Haskell-cafe] Re: [Haskell] Re: Streams: the extensible I/O library
Hey Bulat, I tried removing the "import System.Win32", but unfortunately it only got me so far: | Examples$ ghc -i.. -O2 -funbox-strict-fields --make wc.hs -o wc | Chasing modules from: wc.hs | [ 1 of 16] Compiling System.FD( ../System/FD.hs, ../System/FD.o ) | | /tmp/ghc9376_0.hc:6:16: io.h: No such file or directory | /tmp/ghc9376_0.hc: In function `SystemziFD_zdwccall_entry': | | /tmp/ghc9376_0.hc:1670:0: | warning: implicit declaration of function `_eof' | /tmp/ghc9376_0.hc: In function `SystemziFD_zdwccall1_entry': | | /tmp/ghc9376_0.hc:1951:0: | warning: implicit declaration of function `filelength' | /tmp/ghc9376_0.hc: In function `SystemziFD_zdwccall2_entry': | | /tmp/ghc9376_0.hc:2055:0: | warning: implicit declaration of function `tell' | [abort] I also downloaded the new release archive, just to be sure. but it doesn't contain a file "io.h" either. Is that a system header? The problem seems to be _eof. > btw, my "wc" has about the same speed as yours :) I expected nothing less. All your code I've seen so far has been exceptionally clever. I'm quite curious to try it out. Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re[2]: Fast Mutable Variables for the IO and ST monads
On Mon, Feb 06, 2006 at 04:19:03PM -0800, John Meacham wrote: > On Mon, Feb 06, 2006 at 11:13:47PM +0300, Bulat Ziganshin wrote: > > btw, i have the counter proposal - automatically convert IORefs of > > simple types to the fast internal variables like the Int automatically > > converted to the Int#. The same applies to automatic conversion of > > arrays to the unboxed arrays > > Yeah, I have thought about doing this optimization for jhc. the only > issue is that figuring out 'strictness' through an updatable variable > is pretty darn tricky. It would be good if there were an IOSRef which is > a strict IORef (this can be simulated with normal IORefs and seq) but > with secret internal compiler support to automatically turn them into > their unboxed equivalants. heh. After some more thought, I realized it is not only relativly easy for jhc to implement this optimization generally, but that it already does! the arity raising transformation is basically an unboxing style transformation, that will take arguments with a known heap layout and just pass its components to functions. since suspended functions and mutable variables are both just heap locations, the arity raising transformation of functions incidentally does the same for IORefs. meaning that if every update looks like this (which would be the case if you only stored strict integer values in it) update v1 (Prelude.Int (i::Int#)) then the arity raising will see that that heap location always has a boxed Int#, and just drop the box, turning it into update v1 (i::Int#) now an interesting thing is that this transformation applies even if the value isn't strict. take this function foo 0 = error "is zero" foo x = x now, imagine you want to store (foo x) in an IORef for various calls of foo, obviously using a strict IORef would be bad, as it might invoke the error prematurely. in grin, the writeIORefs will end up looking like update v1 (Ffoo (i::Int#)) Ffoo is the tag that means a suspended call to 'foo' since there is absolutely no differenc between data constructors and suspended functions, the same optimization applies, and you end up turning it into a mutable fast int in the heap, even though it is not strict... note there are some other complications, like you need to make sure you can identify all the use sites of said heap location so that you can transform them too, but in practice this can be done for the majority of heap locations I have found. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re[2]: Fast Mutable Variables for the IO and ST monads
On Mon, Feb 06, 2006 at 11:13:47PM +0300, Bulat Ziganshin wrote: > btw, i have the counter proposal - automatically convert IORefs of > simple types to the fast internal variables like the Int automatically > converted to the Int#. The same applies to automatic conversion of > arrays to the unboxed arrays Yeah, I have thought about doing this optimization for jhc. the only issue is that figuring out 'strictness' through an updatable variable is pretty darn tricky. It would be good if there were an IOSRef which is a strict IORef (this can be simulated with normal IORefs and seq) but with secret internal compiler support to automatically turn them into their unboxed equivalants. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] main features of functional programming paradigm
> I would like to ask about what are tha main features > of functional programming? If you are new to functional programming, read this http://haskell.org/haskellwiki/Introduction > What kind of software can i develop with this > methodology? I'm not sure what you mean by your question as it is very general. (If you are refering to the "methodology" in the FAD paper at http://www.cs.kent.ac.uk/pubs/2001/1152/ , I haven't read it so I can't help you there.) With Haskell, you can develop pretty much any kind of software, as any other programming language. See http://haskell.org/haskellwiki/Applications (If you want to develop a compiler or interpreter, you are in luck as functional programming languages are very good for developing this kind of software.) What kind of software are you intending to develop? Jared. -- http://www.updike.org/~jared/ reverse ")-:" ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] main features of functional programming paradigm
--- Abigail <[EMAIL PROTECTED]> wrote: > Hi, > > I would like to ask about what are tha main features > of functional programming? Caveat: I'm a relative newcomer to functional programming myself, certainly not an expert. There's the obvious definition: Functional programming is writing programs in the form of functions that are evaluated, as opposed to procedures that are evaluated. but even if it's tecnically correct, I'm not that such a distinction helps very much. I know it uses Scheme (a variety of Lisp) rather than Haskell, but ch. 3 of "The Structure and Interpretation of Programming Languages" (SICP) has a nice treatment of mutable data structures on the one hand, and delayed evaluation on the other. It's interesting because it gives some insight into the complementary nature of the approach taken by pure languages like Haskell (called streams in SICP), and non-functional techniques such as assignment. I like to think of this as a kind of time/space duality. If you think about the sequence of "events" during a computation, then you are squarely on the side of time, and your computational model is decidely imperative. If you're willing to let go a bit of time, and instead start thinking about comprehensions and (potentially) infinite lists, then you've moved over into the space camp, and your programming style becomes more functional. === Gregory Woodhouse <[EMAIL PROTECTED]> "All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." --Arthur Schopenhauer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] main features of functional programming paradigm
Hi, I would like to ask about what are tha main features of functional programming? Additionally, about FAD: A Functional Analysis and Design Methodology What kind of software can i develop with this methodology? thanks for your answers Abigail. __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead of left associative?
G'day all. Quoting Tomasz Zielonka <[EMAIL PROTECTED]>: > Is there any chance that Haskell' will change the definition of $ ? > > Well, if there is any moment where we can afford introducing backward > incompatible changes to Haskell', I think it's now or never! I'm not convinced about this. The purpose of Haskell', as I understand it, is to fix the problem that no large Haskell programs (to a first approximation) are valid H98 because they require some quite reasonable language extensions. Partly this is because research is an ongoing area. Partly this is because the purpose of H98 was to make a simple language suitable for teaching. There _is_ a time coming when H98's true successor will need to be made. I'm not convinced that that time is now or never. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
On 2/6/06, John Hughes <[EMAIL PROTECTED]> wrote: > The trouble with monad comprehensions was that it became far too easy to > write ambiguous programs, even when you thought you were just working > with lists. Would the Haskell98-style solution be to add defaulting for Monads? -- Taral <[EMAIL PROTECTED]> "Computer science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] extending bang proposal Re: strict Haskell dialect
On Feb 6, 2006, at 19:33, Brian Hulley wrote: Clean allows (AFAIK) several distinctions to be made: 1) ![a] means that the list of a's is a strict argument, just like writing !b 2) [!a] means that the list is head strict (List1 a) 3) [a!] means that the list is tail strict (List2 a) 4) [!a!] means that the list is head and tail strict (List3 a) 5) ![!a!] means that the head-and-tail-strict-list-argument is strict!!! Right. I think it's worth stressing that the four possible list types are all different as far as type checking is concerned. There's special list syntax however to denote lists that are overloaded in the list type. At run time the different list types share the same nil and cons constructors. This means that conversions between list types are often cheap. I have a small library that does this, with the following costs (monospaced table): \to \[ ] [! ] [ !] [!!] frm\ [ ] 0ce! !e! [! ] 00e! e! [ !] 0c0 !e [!!] 0000 0 = doesn't traverse list e = traverses list (evaluating elements (!e), spine (e!), or both (! e!)) c = copies list (lazily, evaluating elements) I think also (though I'm not entirely sure) that these distinctions are generalized for other data types by talking about element strictness and spine strictness. No, there's no such generalisation. Cheers, Ronny Wichers Schreur ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Streams: the extensible I/O library
Hello Peter, Monday, February 06, 2006, 10:24:01 PM, you wrote: moving to nescafe :) PS> > You can find further information about the library at the PS> > page http://haskell.org/haskellwiki/Library/Streams and PS> > download it as http://freearc.narod.ru/Streams.tar.gz PS> Is there any chance of running this code on a non-Windows PS> system? I tried to compile the example programs, but failed PS> for lack of a System.Win32 module. I might be able to port PS> the code, but I figured it would be wise to ask first. of course, it should work under other systems! it's my fault and you can fix this just by adding #ifdef around this import: #if defined(mingw32_HOST_OS) || defined(__MINGW32__) || defined(_MSC_VER) import System.Win32 #endif btw, my "wc" has about the same speed as yours :) thank you for the first bug-report! i re-uploaded the fixed version just now :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re[2]: Fast Mutable Variables for the IO and ST monads
Hello Simon, Monday, February 06, 2006, 4:41:50 PM, you wrote: SM> The Var class is interesting - basically the equivalent of the MArray SM> class for mutable variables. Is there a reason you couldn't use the SM> same pattern as the MArray class? MArray of Ptr works fine, but for SM> some reason you couldn't do it with Var, why not? quick answer: because it don't use fundeps: class (HasBounds a, Monad m) => MArray a e m where vs class (Monad m) => Var m r a | r->a, m a->r where and fundeps used to avoid needing to specify type of created reference, as should be done with arrays: main = do arr <- newArray (1,10) 37 :: IO (IOArray Int Int) main = print $ runST (do arr <- newArray (1,10) 127 :: ST s (STArray s Int Int) while in my library one can write the following code: chars <- newVar (0::Int) inWord <- newVar False that will work in ANY monad (at least ST and IO with current Var instances). btw, Ptrs is not very useful outside of IO monad (although they can be very useful for extended-IO sort of monads) i will check this more thoroughly SM> I suggest you follow the same scheme as the unboxed array types, and SM> have IOURef/STURef types, parameterised over the element type. Of SM> course, we should have instances for all of the primitive numeric types SM> plus Ptr, ForeignPtr, StablePtr, Bool. i think that i should implement this and add my own Var class as the user of this more general library, that serves my own purpose of writing monad-independent code btw, i have the counter proposal - automatically convert IORefs of simple types to the fast internal variables like the Int automatically converted to the Int#. The same applies to automatic conversion of arrays to the unboxed arrays -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] extending bang proposal Re: strict Haskell dialect
Hello Robert, Monday, February 06, 2006, 8:40:11 PM, you wrote: foo :: !Int -> !Int >> btw, it's just implemented in the GHC HEAD >> RD> Actually, I think strict _patterns_ are implemented. You are talking RD> about strict _type annotations_, which is rather different. yes, i was wrong RD> There has been some work dealing with folding strictness and totality RD> information into types systems; I find the resulting type systems RD> pretty ugly, and I think they'd be pretty hard to bolt onto an HM base. i'm not a professor, just a programmer who needs to optimize some code :) so, that can be really hard or impossible to implement. what i mean: given expression "a*b+c" and know that a/b/c is strict Int values, GHC can determine that whole expression is strict. how it is fone? i don't know. but i think that strictness annotation on result type should say compiler just about this -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: extending bang proposal Re: strict Haskelldialect
Ben Rudiak-Gould wrote: As Robert Dockins said, it's not implemented, and it isn't clear how to implement it. At this point it's looking fairly likely that my PhD thesis will be on this very topic, so stay tuned. Isn't all this already implemented in Clean? Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] extending bang proposal Re: strict Haskell dialect
Bulat Ziganshin wrote: yes, i remember this SPJ's question :) "[!a]" means that list elements are strict, it's the same as defining new list type with strict elements and using it here. "![a]" means "strict list", it is the same as defining list with "next" field strict: data List1 a = Nil1 | List1 !a (List1 a) data List2 a = Nil2 | List2 a !(List2 a) data List3 a = Nil3 | List3 !a !(List3 a) Clean allows (AFAIK) several distinctions to be made: 1) ![a] means that the list of a's is a strict argument, just like writing !b 2) [!a] means that the list is head strict (List1 a) 3) [a!] means that the list is tail strict (List2 a) 4) [!a!] means that the list is head and tail strict (List3 a) 5) ![!a!] means that the head-and-tail-strict-list-argument is strict!!! I think also (though I'm not entirely sure) that these distinctions are generalized for other data types by talking about element strictness and spine strictness. One motivation seems to be that in the absence of whole program optimization, the strictness annotations on a function's type can allow the compiler to avoid creating thunks at the call site for cross-module calls whereas using seq in the function body itself means that the thunk still has to be created at the call site because the compiler can't possibly know that it's going to be immediately evaluated by seq. Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: extending bang proposal Re: strict Haskell dialect
Bulat Ziganshin wrote: Hello Ketil, KM> (Is the second ! actually meaningful?) yes! it means that the function is strict in its result - i.e. can't return undefined value when strict arguments are given. Unfortunately this interpretation runs pretty quickly into theoretical difficulties. A ! on the right hand side of a function arrow isn't like a ! on the left hand side. If you used this notation for this purpose, it would have to be special-cased. Note that in GHC at present, a function of type Int# -> Int# can diverge. KM> foo :: [!a] -> ![a] -> a "![a]" means "strict list", it is the same as defining list with "next" field strict: data List2 a = Nil2 | List2 a !(List2 a) This isn't consistent with the general rule that ! means absence of _|_. The semantics that you want could be implemented as a special case for the [] constructor, but polymorphism breaks this, e.g. data Foo a = MkFoo Int !a data Bar a = MkFoo Int a Foo [Bool] /= Bar ![Bool] for example, the following definition type Map a b = [(a,b)] will be instantiated to Map !Int String ==> [(!Int, String)] As long as you're only specializing datatypes this works fine, but when you try to do the same with polymorphic functions acting on those datatypes, you run into serious problems. E.g. f :: forall a. a -> Maybe a f _ = Just undefined Now we have (f :: Int -> Maybe Int) 3 == Just _|_, but (f :: !Int -> Maybe !Int) 3 == _|_. This means that either f and all of its callers must be specialized at compile time (despite having no type class constraints) or f must inspect its implicit type argument at run time. such proposal already exists and supported by implementing this in GHC HEAD As Robert Dockins said, it's not implemented, and it isn't clear how to implement it. At this point it's looking fairly likely that my PhD thesis will be on this very topic, so stay tuned. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] extending bang proposal Re: strict Haskell dialect
On Feb 6, 2006, at 9:19 AM, Bulat Ziganshin wrote: Hello Ketil, Monday, February 06, 2006, 4:06:35 PM, you wrote: foo :: !Int -> !Int KM> (Is the second ! actually meaningful?) yes! it means that the function is strict in its result - i.e. can't return undefined value when strict arguments are given. this sort of knowledge should help a compiler to "propagate" strictness and figure out the parts of program that can be compiled as strict code. really, i think ghc is able to figure functions with strict result just like it is able to figure strict function arguments KM> Personally, I think is much nicer than sprinkling seq's around, and KM> generally sufficient. However, there could perhaps be disambiguities? btw, it's just implemented in the GHC HEAD Actually, I think strict _patterns_ are implemented. You are talking about strict _type annotations_, which is rather different. As I understand it, strict patterns are just sugar for putting 'seq' in the right places. There has been some work dealing with folding strictness and totality information into types systems; I find the resulting type systems pretty ugly, and I think they'd be pretty hard to bolt onto an HM base. Robert Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Why is $ right associative instead of left associative?
Hello Henning, Monday, February 06, 2006, 4:12:44 PM, you wrote: >> In my opinion all the special syntactic sugar for lists should go >> away. I don't think lists are special enough to motivate it. HT> Fine, someone shares my attitude towards the list sugar. Nevertheless, do HT> you mean with 'no sugar for lists' also no infix operator for list HT> construction? I would still like an operator of low precedence for list HT> construction for writing e.g. (1,'a"):(2,'b'):[]. i prefer to have ":" and "[]" as general collection constructors: class Collection c a where [] :: c a -- creates empty collection (:) :: a -> c a -> c a -- adds value to the head of collection and having "default rules" that instatiates this collection type to list if there is no type signatures and other information what allows to find proper type of collection constructed this way - just like the "default Int" language construct defaults all untyped numeric constants to Int -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] extending bang proposal Re: strict Haskell dialect
Hello Ketil, Monday, February 06, 2006, 4:06:35 PM, you wrote: >> foo :: !Int -> !Int KM> (Is the second ! actually meaningful?) yes! it means that the function is strict in its result - i.e. can't return undefined value when strict arguments are given. this sort of knowledge should help a compiler to "propagate" strictness and figure out the parts of program that can be compiled as strict code. really, i think ghc is able to figure functions with strict result just like it is able to figure strict function arguments KM> Personally, I think is much nicer than sprinkling seq's around, and KM> generally sufficient. However, there could perhaps be disambiguities? btw, it's just implemented in the GHC HEAD KM> Last time this came up, I think examples resembling these were brought KM> up: KM> foo :: [!a] -> ![a] -> a yes, i remember this SPJ's question :) "[!a]" means that list elements are strict, it's the same as defining new list type with strict elements and using it here. "![a]" means "strict list", it is the same as defining list with "next" field strict: data List1 a = Nil1 | List1 !a (List1 a) data List2 a = Nil2 | List2 a !(List2 a) data List3 a = Nil3 | List3 !a !(List3 a) the type List3 is a simple strict list, like in any strict programming language. foo :: [!a] -> ![a] -> ![!a] -> a translates to foo :: List1 a -> List2 a -> List3 a -> a KM> foo' :: Map !Int String -> Int -> String that means that keys in this map saved as strict values. for example, the following definition type Map a b = [(a,b)] will be instantiated to Map !Int String ==> [(!Int, String)] KM> Anyway, if a reasonable semantics can be formulated, I think KM> strictness type annotations would be a great, useful, and KM> relatively non-intrusive (AFAICT, entirely backwards compatible) KM> addtion to Haskell'. such proposal already exists and supported by implementing this in GHC HEAD -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] map and list comprehensions
John Peterson wrote: I think the point was that all syntax (like list comprehensions or pattern matching) in Haskell is tied directly to the Prelude. So [ f x ...] is ALWAYS using the Prelude definitions of things while "map" could be hidden and redefined. Yes, of course. I was implicitly assuming that we were talking about Prelude's map. > The inability to change the meaning of constructs expanded from syntax as considered a bug by some, a feature by others. And I don't rember where Paul stood on this ... It has always seemed to me that there should be a way to define something as syntactic expansion into things that cannot be redefined, otherwise the language definition becomes vague. -Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling hdirect on windows with COM support
> echo "Press Ctrl-d when finished or enter exit to continue this script" > bash dozip afterConfiguring I did make a small mistake here: it should look like this: bash dozip afterConfiguring Oh.. and I did use gcc from mingw as you can see. I don't know yet how to specify gcc.exe from ghc-6.4.1/gcc.exe without the configure script complaining gcc can't produce executables becaus cc1 is missing. Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Fast Mutable Variables for the IO and ST monads
Bulat Ziganshin wrote: only for the souls interesting in writing efficient programs :) i included in this letter my own module used for fast variables - "DataVariables.hs". and "wc.hs" contains example of using these vars. The Var class is interesting - basically the equivalent of the MArray class for mutable variables. Is there a reason you couldn't use the same pattern as the MArray class? MArray of Ptr works fine, but for some reason you couldn't do it with Var, why not? I suggest you follow the same scheme as the unboxed array types, and have IOURef/STURef types, parameterised over the element type. Of course, we should have instances for all of the primitive numeric types plus Ptr, ForeignPtr, StablePtr, Bool. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead of left associative?
On Sun, 5 Feb 2006, Lennart Augustsson wrote: > I don't use lists very much. They are not the right data structure > for many things. Certainly, but lists are useful as interim data structure or for initialising complex data structures. > So : is not as common as :: in my code. I checked a small sample of > code, about 2 lines of Haskell. It has about 1000 uses of ':' and > 2000 of '::'. > > In my opinion all the special syntactic sugar for lists should go > away. I don't think lists are special enough to motivate it. Fine, someone shares my attitude towards the list sugar. Nevertheless, do you mean with 'no sugar for lists' also no infix operator for list construction? I would still like an operator of low precedence for list construction for writing e.g. (1,'a"):(2,'b'):[]. > But this is not what Haskell' is about. It's supposed to be some > modest extensions to Haskell. Not designing a new perfect language. Yes, this discussion is definitely beyond Haskell'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead of leftassociative?
On Sun, 5 Feb 2006, Tomasz Zielonka wrote: > On Sun, Feb 05, 2006 at 01:14:42PM -, Brian Hulley wrote: > > > This is similar to how people often format lists: > > > > a = > > [ first > > , second > > , third > > ] > > I am one of those people, and I am slightly annoyed with I have to > add something at the beginning of the list. In this case I prefer the non-sugar variant: a = first : second : third : [] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re[2]: strict Haskell dialect
Bulat Ziganshin <[EMAIL PROTECTED]> writes: > JM> data Foo = Bar !Int !Char > JM> the bangs arn't being assosiated with the Int and Char types, but rather > JM> the Bar data constructor. > foo :: !Int -> !Int (Is the second ! actually meaningful?) Personally, I think is much nicer than sprinkling seq's around, and generally sufficient. However, there could perhaps be disambiguities? Last time this came up, I think examples resembling these were brought up: foo :: [!a] -> ![a] -> a foo' :: Map !Int String -> Int -> String Anyway, if a reasonable semantics can be formulated, I think strictness type annotations would be a great, useful, and relatively non-intrusive (AFAICT, entirely backwards compatible) addtion to Haskell'. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
Hello John, Monday, February 06, 2006, 10:39:59 AM, you wrote: >>That said, I'd *really* like to see monad comprehensions come back, JH> We did consider more aggressive defaulting to address the ambiguity JH> problems with monad comprehensions--defaulting Monad to lists, for JH> example, or user-declared defaulting rules--but this introduces yet more JH> complexity without really addressing the problem of keeping types simple JH> for beginners, so the idea was abandoned. why not allow some sort of module-wide pragma to "enable" use of this and any other features for expert programmers? just recalling last "import extension" proposal, we can add: import extension i-am-expert-programmer-enable-monad-comprehension-please! :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re[2]: strict Haskell dialect
Hello John, Monday, February 06, 2006, 10:58:06 AM, you wrote: >> I must admit I'm a bit confused as to why the strictness annotations in >> Haskell (and Clean) are only allowed in data declarations and not function >> declarations JM> data Foo = Bar !Int !Char JM> the bangs arn't being assosiated with the Int and Char types, but rather JM> the Bar data constructor. with foo :: !Int -> !Int bangs are also associated with type of foo, is not? :) and Clean already has this sort of annotations -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
Cale Gibbard wrote: How about a compiler switch for beginners (maybe with an included script that adds it to the command line) that turns off a bunch of the more complex issues involved, and uses a beginner's version of the Prelude? Well, right now, the complex issues are turned off by having separate types and separate functions, which works pretty well. Would such a switch resolve overloading silently to "beginners' types"? If so, some code would compile with the switch, but not without it--which is pretty scary. You'd need to check when compiling each module whether it was "beginners" or not. Is explaining Functor really that hard? It's just container types with a way to apply a function to all of their elements. :) Also, it seems that classes are one of the first things one has to teach now anyway, as they're bound to come up in error messages in any actual programs you try to write. When teaching my friend, I taught the basics of classes along with types in the first and second lesson (including how to define them) and presented various values and functions as examples. Something tells me your friend wasn't an undergraduate of only moderate ability, with no programming experience of any kind. Honestly, the difference between a singleton list and its element is a big deal at this stage--words like "container types" would go right over almost all students' heads. You're right that classes must be mentioned early, but there's no need for more than a very basic understanding. I tell my students always to write type signatures at the start, so the error messages they see say things like "No instance Num Bool". I just tell them that means booleans aren't numbers--they don't need to even see a class or instance definition to understand that. I don't think it should be necessary to completely rule out useful features because they might be difficult to newcomers. There should always be ways to turn things off, and construct a simpler language for new users. Dr. Scheme seems to take this approach, and has a pretty fine gradation of languages for leading users from their first steps into the finer points of Scheme. It would be interesting to see a "Dr. Scheme" like approach to Haskell. But there is a risk with that approach--namely, that students get the impression (correctly) that they are learning a toy language which isn't usable for real applications. That is a big-time motivation killer. (I'm not criticizing Dr Scheme here, but rather how I imagine a flag of the sort we're discussing might work with Haskell). It's important that there is a smooth route to infinity and beyond, so one can show students cool stuff like wxHaskell without discontinuities along the way. Otherwise they're just glad to finish their Haskell course, and move on to a real programming language like Java. Separate syntax for easy and more difficult concepts--separating comprehensions from do--does provide a very smooth progression for beginners. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
On 06/02/06, John Hughes <[EMAIL PROTECTED]> wrote: > Cale Gibbard wrote: > > >That said, I'd *really* like to see monad comprehensions come back, > >since they align better with the view that monads are container types, > >dual to the view that monads are computations, which is supported by > >the do-syntax. This view is actually much easier to teach (in my > >experience). Giving lists a little extra syntax is nice, but giving > >things unnecessarily restrictive types seems to be the point at which > >I'd consider it going too far. > > > The trouble with monad comprehensions was that it became far too easy to > write ambiguous programs, even when you thought you were just working > with lists. Haskell overloading works really nicely *as long as there's > a judicious mixture of overloaded and non-overloaded functions*, so that > the overloading actually gets resolved somewhere. Overload too many > things, and you end up having to insert type annotations in the middle > of expressions instead, which really isn't nice. > > Lists are special, not least because they come very early in a Haskell > course--or, in my case, in the first ever programming course my students > have ever taken. Getting error messages about ambiguous overloading when > they are still trying to understand what comprehension notation means > (without even the concept of a for-loop to relate it to) is very > destructive. And this is in the case where the code is otherwise > type-correct--the kind of error message you would get by trying to > append a number to a monad comprehension doesn't bear thinking about! > > The class system is already something of an obstacle in teaching, > because you have to mention it in the context of arithmetic (even if you > tell students always to write monomorphic type signatures, they still > see classes mentioned in error messages). After all, that is surely why > Helium doesn't have it. I find classes manageable for arithmetic, even > if students do take some time to learn to distinguish between a class > and a type (or a type and a value, for that matter!). But it's a relief > that list programs, at least, have simple non-overloaded types. List > functions provide an opportunity to introduce polymorphism in a simple > context--it's much easier to understand why (++) should have the type > [a] -> [a] -> [a], than to start talking about MonadPlus m => m a -> m a > -> m a. > > There is a lot to learn in Haskell, especially in the type and class > system. It's an advantage if you don't have to learn it all at once--if > you can master lists and list comprehensions without exposure to monads > (which are a much harder concept). We should never forget that beginners > have somewhat different needs from expert programmers--and those needs > are also important. If we want Haskell to be used for first programming > courses (and it's a big advantage to catch 'em early), then there needs > to be a learning path into the language that goes quite gently. > Monomorphic lists help with that. > > We did consider more aggressive defaulting to address the ambiguity > problems with monad comprehensions--defaulting Monad to lists, for > example, or user-declared defaulting rules--but this introduces yet more > complexity without really addressing the problem of keeping types simple > for beginners, so the idea was abandoned. > > John > > How about a compiler switch for beginners (maybe with an included script that adds it to the command line) that turns off a bunch of the more complex issues involved, and uses a beginner's version of the Prelude? Helium exists as well, which is a simplified version of Haskell for beginners, without even typeclasses. It has very careful and detailed error messages. Having monad comprehensions actually helps with another newbie problem, albeit one which is a little farther along the garden path -- learning about monads. Defaulting monad comprehensions is probably a good idea. List comprehensions are probably the most common case anyway, just because lists are the most common container type. :) This also further helps in introducing monads as generalisations of lists. If extensions to the language get standardised, I'd be fine with having monad comprehensions among them. Adding an extension declaration or compiler switch to any module using them wouldn't be so bad either, though I'd really like them in the actual language. I'd also want to include the usual changes to the prelude. The situation with map I find especially grating. Having two versions of common functions is one thing, but 3 is getting out there! :) Is explaining Functor really that hard? It's just container types with a way to apply a function to all of their elements. :) I don't think it should be necessary to completely rule out useful features because they might be difficult to newcomers. There should always be ways to turn things off, and construct a simpler language for new users. Dr. Scheme seems to take this approac
