April 2003 - Haskell - Haskell.org

Enum on Float/Double
by George Russell 23 Oct '03

23 Oct '03

The situation with Enum on Ratio is pretty bad but at least it's not hopeless, since rational numbers are at least exact. But for Float/Double it seems to be a total disaster area. Since it seems to be impossible to abolish Enum Float/Double altogether, would it at least be possible to make it rather more useful, by making succ x return the next representable float after x (or x if x is non-finite) and pred x the previous representable float. This would (a) be useful; (b) make mathematical sense; (c) is tricky to implement with the existing primitives. Before someone else points it out, this is of course unimplementable should someone in the future implement infinite-precision reals in Haskell, but as (barring a solution to the halting problem) Eq would be as well, that does not bother me. My preference would be for succ (+-0) to return the smallest positive real, since then you could define succ x to be the unique y with x < y and forall z . z < y => not (x < z), where such a y exists, and I'm not sure if the Haskell standard knows about signed zeros. Feri wrote > Everybody working with floats should know their quirks While in an ideal world, everyone who represented a mouse position or anything else as a float should have a PhD in numerical analysis, in practice they do not. Indeed I think the Haskell Library Report contains quite a few examples of floating point code which a numerical analyst would have written rather better. So I don't think it's good enough to treat every Float/Double operation as if it had an implicit "UNSAFE" flag indicating that the compiler was entitled to wierd behaviour only comprehensible to experts, as seems to be the case with floating enumerations now.

8 11

Multiparameter classes in HUGS and GHC
by Graham Klyne 28 May '03

28 May '03

I've trying to understand better how to use multiparameter classes, and in particular the things that can be declared as instances. I've consulted the following: [1] http://www.haskell.org/onlinereport/decls.html#sect4.3.2 [2] http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.htm… (particularly 7.3.5.1 item 3) [3] http://research.microsoft.com/Users/simonpj/Papers/type-class-design-space/ [4] http://cvs.haskell.org/Hugs/pages/hugsman/exts.html (section 7.1) From my reading, it seems that while strict Haskell 98 does not permit type expressions or synonyms to be declared as class instances, both GHC and HUGS claim to relax this restriction (presumably following the analysis in [3]). My problem is that I can't get HUGS to accept a type expression or synonym to be declared as an instance of a (multiparameter) class; I'm getting the error "Illegal type in class constraint". After some wrestling with the system, I have managed to figure how to declare instances that use type constructors. I feel I may be missing something blindingly obvious. My spike code is below: the uncommented sections compile OK, but the commented-out sections do not. #g -- [[ class (Eq k, Show k) => Pair a k v where newPair :: (k,v) -> a k v getPair :: a k v -> (k,v) newtype MyPair1 k v = P1 (Int,String) instance Pair MyPair1 Int String where newPair (x,y) = P1 (x,y) getPair (P1 (x,y)) = (x,y) data MyPair2 k v = P2 Int String instance Pair MyPair2 Int String where newPair (x,y) = P2 x y getPair (P2 x y) = (x,y) data (Eq a, Show a) => MyPair3 a b = P3 a b instance Pair MyPair3 Int String where newPair (x,y) = P3 x y getPair (P3 x y) = (x,y) {- -- The following DO NOT work because instances -- "must take the form of a type constructor T applied -- to simple type variables" (though this may be relaxed -- in the multiparameter case: see [1]). -- -- Apparently, GHC *does* allow this, though HUGS -- apparently does not, though it does claim to [2]. -- -- [1] http://research.microsoft.com/Users/simonpj/Papers/type-class-design-space/ -- -- [2] http://cvs.haskell.org/Hugs/pages/hugsman/exts.html (section 7.1) -} type MyPair4 k v = (k,v) {- instance Pair (Int,String) Int String where newPair = id getPair = id instance Pair (MyPair4 Int String) Int String where newPair = id getPair = id instance Pair (MyPair4 k v) Int String where newPair = id getPair = id -} ]] I'm using the November 2002 release of HUGS with Hugs extensions enabled: [[ Current settings: +fewuiRWX -stgGl.qQkoOIHTN -h250000 -p"%s> " -r$$ -c40 Search path : -P{Hugs}\lib:{Hugs}\lib\exts:{Hugs}\lib\win32:{Hugs}\lib\hugs; {Hugs}\libraries\HUnit-1.0 Project Path : Source suffixes : -S.hs;.lhs Editor setting : -E"C:\\Program Files\\TextPad 4\\TextPad.exe" Preprocessor : -F Compatibility : Hugs Extensions (-98) ]] ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

3 3

unsafe parsing
by Kenny Lu Zhuo Ming 03 May '03

03 May '03

Hi all, I am currently write a program to type a dynamic string consist of 'A' or 'B' for short, it works in this manner: for 'A', it returns A :: A for 'B', it returns B :: B for "A", it returns Cons A Nil :: Cons A Nil for "AB", it returns Cons A (Cons B Nil) :: Cons A (Cons B Nil) ... The problem is I have to specifically annotate the output type, which is unaffordable, because I might have arbitrary-long string, and I have infinitely many possible singleton types. It seems it is impossible to do it in a type-safe way. Anyone of you have any idea to walk around that? Regards, Kenny module Test where data Content = C1 Char | C2 String deriving Eq class MyType a where parse :: Content -> (Maybe a) data A = A deriving (Show,Eq) instance MyType A where parse (C1 'A') = Just A parse _ = Nothing data B = B deriving (Show,Eq) instance MyType B where parse (C1 'B') = Just B parse _ = Nothing data Cons x xs = Cons x xs deriving Show instance (MyType x,MyType xs) => MyType (Cons x xs) where parse (C2 (x:xs)) = let maybehd = parse (C1 x) in case maybehd of Just hd -> let maybetl = parse (C2 xs) in case maybetl of Just tl -> Just ((Cons hd) tl) Nothing -> Nothing Nothing -> Nothing parse _ = Nothing data Nil = Nil deriving (Show,Eq) instance MyType Nil where parse (C2 []) = Just Nil parse _ = Nothing %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Hugs session for: /usr/share/hugs/lib/Prelude.hs Test.hs Type :? for help Test> parse (C2 "A") :: Maybe (Cons A Nil) Just (Cons A Nil)

2 3

GHC doesn't like its own type?
by oleg＠pobox.com 01 May '03

01 May '03

The previously message "Deeply uncurried products, as categorists might like them" can be used to demonstrate certain behavior of GHC that seems a bit odd. If we save the text of that message in a file, /tmp/a.lhs, we can load it into GHC: $ ghci -fglasgow-exts /tmp/a.lhs GHC Interactive, version 5.04.1 Ok, modules loaded: Main. *Main> The whole code loads and typechecks. The code contains the following definition, without an explicit type signature: > fcomp a = (. fapp) (mcomp a) We can ask GHCi to tell us the type of fcomp: *Main> :type fcomp forall result f1 a f2 c cp. (FApp a cp c, MCompose f2 cp c result) => (f1 -> f2) -> a -> f1 -> result and make that type, verbatim, to be the signature of fcomp: > fcomp:: forall result f1 a f2 c cp. (FApp a cp c, MCompose f2 cp c result) => (f1 -> f2) -> a -> f1 -> result > fcomp a = (. fapp) (mcomp a) If we reload the file, we get an error: /tmp/a.lhs:124: Could not deduce (FApp a cp c1) from the context (FApp a cp c, MCompose f2 cp c result) Probable fix: Add (FApp a cp c1) to the type signature(s) for `fcomp' arising from use of `fapp' at /tmp/a.lhs:124 In the second argument of `(.)', namely `fapp' In the definition of `fcomp': (. fapp) (mcomp a) /tmp/a.lhs:124: Could not deduce (MCompose f2 cp c1 result) from the context (FApp a cp c, MCompose f2 cp c result) Probable fix: Add (MCompose f2 cp c1 result) to the type signature(s) for `fcomp' arising from use of `mcomp' at /tmp/a.lhs:124 In the first argument of `(. fapp)', namely `(mcomp a)' In the definition of `fcomp': (. fapp) (mcomp a) I used to think that the inferred type is the most general type, and that the compiler would accept as explicit the type that it itself inferred. I was wrong? The second odd circumstance is best illustrated by the following transcript. Assume that /tmp/a.lhs is the text of the previous message as it was posted: $ ghci -fglasgow-exts /tmp/a.lhs GHC Interactive, version 5.04.1, for Haskell 98. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Compiling Main ( /tmp/a.lhs, interpreted ) /tmp/a.lhs:76: Warning: No 'main' defined in module Main Ok, modules loaded: Main. *Main> let x = \f -> fapp f (('a','b'),('c',('d','e'))) Bus error (core dumped) Incidentally, if I enter > x = \f -> fapp f (('a','b'),('c',('d','e'))) into /tmp/a.lhs and load the file into GHCi, I get ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): rdrNameModule zddFApp

3 2

RE: GHC doesn't like its own type?
by Erkok, Levent 30 Apr '03

30 Apr '03

Sometimes ghc/hugs will reject a program when you provide a type signature that it can deduce itself. This has been observed before: See Simon PJ's message: http://www.mail-archive.com/haskell@haskell.org/msg06764.html Of course, the "bus error" and the "panic" are truly GHC bugs, you might be better off reporting them at: http://sourceforge.net/tracker/?group_id=8032&atid=108032 -Levent. > -----Original Message----- > From: oleg(a)pobox.com [mailto:oleg@pobox.com] > Sent: Wednesday, April 30, 2003 3:48 PM > To: haskell(a)haskell.org > Subject: GHC doesn't like its own type? > > > The previously message "Deeply uncurried products, as categorists > might like them" can be used to demonstrate certain behavior of GHC > that seems a bit odd. If we save the text of that message in a file, > /tmp/a.lhs, we can load it into GHC: > > $ ghci -fglasgow-exts /tmp/a.lhs > GHC Interactive, version 5.04.1 > Ok, modules loaded: Main. > *Main> > > The whole code loads and typechecks. The code contains the following > definition, without an explicit type signature: > > > fcomp a = (. fapp) (mcomp a) > > We can ask GHCi to tell us the type of fcomp: > > *Main> :type fcomp > forall result f1 a f2 c cp. > (FApp a cp c, MCompose f2 cp c result) => > (f1 -> f2) -> a -> f1 -> result > > and make that type, verbatim, to be the signature of fcomp: > > > fcomp:: forall result f1 a f2 c cp. (FApp a cp c, MCompose f2 cp c > result) => (f1 -> f2) -> a -> f1 -> result > > fcomp a = (. fapp) (mcomp a) > > If we reload the file, we get an error: > > /tmp/a.lhs:124: > Could not deduce (FApp a cp c1) > from the context (FApp a cp c, MCompose f2 cp c result) > Probable fix: > Add (FApp a cp c1) to the type signature(s) for `fcomp' > arising from use of `fapp' at /tmp/a.lhs:124 > In the second argument of `(.)', namely `fapp' > In the definition of `fcomp': (. fapp) (mcomp a) > > /tmp/a.lhs:124: > Could not deduce (MCompose f2 cp c1 result) > from the context (FApp a cp c, MCompose f2 cp c result) > Probable fix: > Add (MCompose f2 cp c1 result) to the type signature(s) for > `fcomp' > arising from use of `mcomp' at /tmp/a.lhs:124 > In the first argument of `(. fapp)', namely `(mcomp a)' > In the definition of `fcomp': (. fapp) (mcomp a) > > I used to think that the inferred type is the most general type, and > that the compiler would accept as explicit the type that it itself > inferred. I was wrong? > > The second odd circumstance is best illustrated by the following > transcript. Assume that /tmp/a.lhs is the text of the previous message > as it was posted: > > $ ghci -fglasgow-exts /tmp/a.lhs > GHC Interactive, version 5.04.1, for Haskell 98. > Loading package base ... linking ... done. > Loading package haskell98 ... linking ... done. > Compiling Main ( /tmp/a.lhs, interpreted ) > > /tmp/a.lhs:76: Warning: No 'main' defined in module Main > Ok, modules loaded: Main. > *Main> let x = \f -> fapp f (('a','b'),('c',('d','e'))) > Bus error (core dumped) > > Incidentally, if I enter > > x = \f -> fapp f (('a','b'),('c',('d','e'))) > into /tmp/a.lhs and load the file into GHCi, I get > > ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): > rdrNameModule zddFApp > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

Deeply uncurried products, as categorists might like them
by oleg＠pobox.com 30 Apr '03

30 Apr '03

This is a belated answer to a Haskell-categorical question posted two years ago on comp.lang.functional [1]: ] It is common in (say) category theory to write ] ] max3 = max . (max * id) Can we write this in Haskell? Specifically, can we write something more complex: max7 = max3 . ((max2 * max3) * max2) We show that we can, exactly in this notation (modulo alpha conversion). A potentially useful side-effect is a deep uncurrying of arbitrarily complex pairs, such as ((1,2),(3,(4,5))) The simplest max3 can be expressed in the desired form: *> prod x y = \(argx,argy) -> ((x argx),(y argy)) *> max2 x y = if x < y then y else x *> *> max3:: Ord a => a->a->a->a *> max3 = (curry (curry ((uncurry max2) . ((uncurry max2) `prod` id)))) Alas, the solution uses too much curry to be palatable. Generalizations to longer functions are mind-racking. Thus the problem is how to get the compiler (GHC) put and take the right amount of curry automatically. It seems that a polyvariadic composition combinator [2] can help. The combinator is specified as follows: given f:: a1->a2->.... ->cp, where cp is not functional and g:: cp->d then f `mcomp` g:: a1->a2->.... ->d of obvious meaning. In the simplest case of f::a->b (b not functional), "f `mcomp` g = g . f" . For a reason I can't recall `mcomp` has the reverse order of arguments compared to the regular composition. Given such a combinator, defined in the appendix, we can introduce a categorical product as *> prod f g = f `mcomp` (\fresult -> g `mcomp` (\gresult -> (fresult,gresult))) or, after some eta-reductions, *> prod f g = mcomp f ((mcomp g) . (,)) Given two functions, f:: a1->a2->...->an->c |c,d non-exponential types g:: b1->b2->...->bn->d their product f `prod` g:: a1->a2->...->an->b1->b2->...->bn->(c,d) The number of as and bs is arbitrary. We can subject the expression for prod to even more eta-reductions, yielding the following compact, combinational definition: > prod:: (MCompose a b (c -> d) e, MCompose f g (b,g) d) => > (h -> a) -> (c -> f) -> h -> e > prod = (. ((. (,)) . mcomp)) . mcomp The constraints in the prod's type are intricately related. The final expression for prod bears some similarity with Unlambda code. Perhaps because both Unlambda and the category theory eschew "elements" in favor of combinations of arrows. Probably there are other similarities. Now we are ready to define our maxima. To make our approach truly polymorphic, we have to restrict it first by the following declaration. It's not much a restriction because the type under the wrapper can be anything at all. Unfortunately, the intuitionist logic of class instances makes it impossible to say directly "forall x. (NOT Constraint x)". Thus we have to resort to the contortions: > newtype W a = W a deriving Show We also need a projected identity and the basic max: > tid:: (Ord a) => (W a)->(W a) > tid = id > max2 (W x) (W y) = if x < y then W y else W x We also need to "invert" the prod operation -- to deeply uncurry arbitrarily complex pairs. > -- An uncurrying application: flattening the product > class FApp f a c | a c -> f where > fapp:: f -> a -> c > > instance FApp (Char->c) Char c where > fapp = ($) > > instance FApp ((W a)-> c) (W a) c where > fapp = ($) > > instance (FApp fx a r, FApp r b c) => FApp fx (a,b) c where > fapp f = uncurry (fapp . (fapp f)) > -- test > fappt = fapp (\a b c d e -> [a,b,c,d,e]) (('a','b'),('c',('d','e'))) Combinators fapp and mcomp will occur together. Therefore, we define > fcomp a = (. fapp) (mcomp a) That expression can be further reduced to "fcomp = (. fapp) . mcomp" However, doing so blows the Unlambda fuse in GHC. Now we can indeed write our maxima: > max3:: Ord a => W a->W a->W a->W a > max3 = (max2 `prod` tid) `fcomp` max2 which looks almost the same as the categorical expression for max3. We can easily generalize: > max4:: Ord a => W a->W a->W a->W a -> W a > max4 = (max2 `prod` max2) `fcomp` max2 which would, in the categorical notation, be written as max2 . (max2 * max2) Our notation is almost a literal translation. There are other expressions for max4, for the other commuting branches: > -- max41 = max2 . (max3 * id) > max41:: Ord a => W a->W a->W a->W a -> W a > max41 = (max3 `prod` tid) `fcomp` max2 > -- max42 = max2 . (id * max3) > max42:: Ord a => W a->W a->W a->W a -> W a > max42 = (tid `prod` max3) `fcomp` max2 > -- max51 = max2 . ((max2 * id) . (max2 * max2)) > max51:: Ord a => W a->W a->W a->W a -> W a -> W a > max51 = ((max2 `prod` max2) `fcomp` (max2 `prod` tid)) `fcomp` max2 And finally, > max7:: Ord a => W a->W a->W a->W a->W a->W a->W a->W a > max7 = ((max2 `prod` max3) `prod` max2) `fcomp` max3 > > max7t = max7 (W 'a') (W 'b') (W 'c') (W 'd') (W 'e') (W 'f') (W 'g') Perhaps the wrapper W also has some categorical significance. [1] "Re: On products and max3" A thread on a newsgroup comp.lang.functional, Thu, 12 Apr 2001 02:14:27 +0000 [2] http://pobox.com/~oleg/ftp/Haskell/polyvar-comp.lhs The code was originally posted as "Re: composition" on a newsgroup comp.lang.functional on Wed, 30 Oct 2002 19:09:32 -0800 Appendix: polyvariadic composition, to make this whole code work. Excerpted from [2]. Compilation flags: -fglasgow-exts > class MCompose f2 cp gresult result | f2 cp gresult -> result, f2->cp > where > mcomp:: (f1->f2) -> (cp->gresult) -> (f1 -> result) > > -- Class instances. Please keep in mind that cp must be a non-functional type > -- and f2 and cp must be the same. These instances enumerate the base cases. > > instance MCompose (Maybe b) (Maybe b) c c where > --mcomp f::(a->(Maybe b)) g::((Maybe b)->c) :: a->c > mcomp f g = g . f > > instance MCompose [b] [b] c c where > --mcomp f::(a->[b]) g::([b]->c) :: a->c > mcomp f g = g . f > > instance MCompose Int Int c c where > --mcomp f::(a->Int) g::(Int->c) :: a->c > mcomp f g = g . f > > instance MCompose Char Char c c where > --mcomp f::(a->Char) g::(Char->c) :: a->c > mcomp f g = g . f > > instance MCompose (W a) (W a) c c where > --mcomp f::(x->(W a)) g::((W a)->c) :: x->c > mcomp f g = g . f > > instance MCompose (a,b) (a,b) c c where > mcomp f g = g . f > > -- Induction case > instance (MCompose f2 cp gresult result) => > MCompose (f1->f2) cp gresult (f1->result) where > mcomp f g = \a -> mcomp (f a) g >

1 0

seeking lore of the QuickCheck masters
by nr＠eecs.harvard.edu 30 Apr '03

30 Apr '03

I am playing around with an implementation of a little language, and I would like to use QuickCheck to test my code. My problem is that I want to test only well-typed terms. I don't know how to craft my `arbitrary' functions so that the probability of generating a well-typed term is more than vanishingly small. Can anybody pass on interesting tips and tricks that might help? Norman

8 16

Re: Is it possible to build in a file in a haskell program??
by Alexandre Weffort Thenorio 29 Apr '03

29 Apr '03

Yeah just as I expected it. It wrote the whole program OK but when it comes to: mybinfile = It just wrote all the weird stuff that you see if you try opening a bin file in notepad. The weird part is that it didn't write the whole thing, just part of it. Is it supposed to be like that?? I did use readfile function to read the bin file, but just in case how to make a handle into a string, for example: basic = "module MyBinFile ( mybinfile ) where\nmybinfile :: String\nmybinfile = \"" do handle <- openFile "mybinfile.hs" WriteMode --File to be written to hand <- readfile "file.bin" hPutStrLn handle (basic ++ hand ++ "\"") That's what I did basically and I only used readFile to read the bin file because hPutStrLn requires a String and openFile gives me a Handle so is it possible to make a handle to a String?? Also what am I doing wrogn because apparently I am not getting stuff like /x01/x02 but weird stuf like: DÅÍo in the created file. Best Regards Alex ----- Original Message ----- From: "Keith Wansbrough" <Keith.Wansbrough(a)cl.cam.ac.uk> To: "Alexandre Weffort Thenorio" <alethenorio(a)home.se> Sent: Tuesday, April 29, 2003 8:11 PM Subject: Re: Is it possible to build in a file in a haskell program?? > > Thanks but I am not sure what exactly you mean. I've done this: > [..] > > Tried compiling main.hs file but it says "Failed to load interface for > > MyBinFile". > > This means you haven't compiled MyBinFile. > > Do you know about Haskell modules? You should read the relevant section of the Haskell Report (www.haskell.org/onlinereport/) and also the documentation of your compiler. > > --KW 8-) > -- > Keith Wansbrough <kw217(a)cl.cam.ac.uk> > http://www.cl.cam.ac.uk/users/kw217/ > University of Cambridge Computer Laboratory. > >

1 0

Re: Is it possible to build in a file in a haskell program??
by Alexandre Weffort Thenorio 29 Apr '03

29 Apr '03

Sorry. As a begginner (Kinda) with haskell I completelly forgot how to work with Modules but anyway I completelly understood what you meant now. My problem actually is writing the program thats write the little haskell program (Or a String) out of the bin file. Can you give me a clue? Of course most of the code is easy but the tricky part comes to the string representing the file, I mean won't haskell just write exactly like the bin file is written (Thus in weird stuff can't just be copied and pasted) Or maybe if I read the file in Binary mode and write it in Text mode (Using IOExts Library)??? Best Regards Alex ----- Original Message ----- From: "Keith Wansbrough" <Keith.Wansbrough(a)cl.cam.ac.uk> To: "Alexandre Weffort Thenorio" <alethenorio(a)home.se> Sent: Tuesday, April 29, 2003 8:11 PM Subject: Re: Is it possible to build in a file in a haskell program?? > > Thanks but I am not sure what exactly you mean. I've done this: > [..] > > Tried compiling main.hs file but it says "Failed to load interface for > > MyBinFile". > > This means you haven't compiled MyBinFile. > > Do you know about Haskell modules? You should read the relevant section of the Haskell Report (www.haskell.org/onlinereport/) and also the documentation of your compiler. > > --KW 8-) > -- > Keith Wansbrough <kw217(a)cl.cam.ac.uk> > http://www.cl.cam.ac.uk/users/kw217/ > University of Cambridge Computer Laboratory. > >

1 0

ESS2003: Language and Speech Technology for Language Learning
by Steven Krauwer 29 Apr '03

29 Apr '03

SECOND ANNOUNCEMENT and CALL for PARTICIPATION The 11th ELSNET Summer School on Language and Speech Communication Topic: Language and Speech Technology in Language Learning Lille (France), Monday July 7 - Friday July 18, 2003 Organized by the University of Lille 3 We are happy to announce that registration for the 11th ELSNET Summer School is now open. For this school we have chosen a topic of great relevance to researchers and developers in Europe and in other multilingual environments: the use of language and speech technology in language learning, both of spoken and of written language. The goal of this workshop is to get young researchers on a track that will eventually contribute to an important application area. The underlying vision (or dream) is The automatic animated language tutor. + Audience and aims: We see the school as mainly research and development oriented, and hence the primary audience are researchers, developers and integrators who will make our vision happen (rather than teachers who would use it). Both technological and pedagogical aspects will be taken into consideration The aims are: * to make the students familiar with the main principles and problems of language learning/teaching * to make them familiar with current best practice in computer assisted language learning * to make them familiar with the main challenges in computer assisted language learning Participants are expected to have a general computational background and some familiarity with language or speech research and/or processing. After completion of the summer school participants should be able to function in teams aimed at designing or implementing tools, environments or courses for Computer Assisted Language Learning (abbreviated CALL). + Course programme: The provisonal programme is available at http://www.elsnet.org/ess2003/schedule.html The 2-weeks programme comprises the following courses: * Introduction to CALL (Teacher: Jozef Colpaert, [Univ of Antwerp]) * Introduction to natural language processing for CALL (Teacher: Wolfgang Menzel [Univ of Hamburg]) * Introduction to speech processing for CALL (Teacher: Philippe Delcloque [MSEC Manchester]) * Using NLP tools in CALL (hands-on) (Teacher: Wolfgang Menzel [Univ of Hamburg]) * Using Speech tools in CALL (hands-on) (Teacher: Michael McTear [Univ of Ulster]) * CALL design and interfaces (Teacher: Philippe Delcloque [MSEC Manchester]) * Grammatical and morphological error diagnosis (Teacher: Lars Borin [Univ of Gothenburg]) * Systems for pronunciation training (Teacher: Anne-Marie Oster [KTH Stockholm]) * Building a grammatical CALL system (hands-on) (Teacher: Lars Borin [Univ of Gothenburg]) * Building a speech CALL system (hands-on) (Teacher: Michael McTear [Univ of Ulster]) All students attend the same full programme, except for the hands-on sessions, where students can sign up for either NLP or Speech oriented streams. In special student sessions students can present their own work. The presentations will be published on the ELSNET website. Please note that the number of places for this summer school is limited and that early registration is recommended. The working language of the Summer School will be English. + Fees: Category Registration fee (euro) Students 125 Academic staff 250 Commercial organisations 500 ELSNET members are entitled to a 20% discount + Food and accommodation: The cost of accommodation (on campus) will be 20 euro per night Meals will be free. + Registration, grants and other information: For detailed information about registration procedures and deadlines, fees, accommodation, grant possibilities, venue, course and social programme, etc visit the ESS2003 website at http://www.univ-lille3.fr/ESS2003 or send an email to the local organizers at elsnetadmin(a)univ-lille3.fr A limited number of grants (covering the cost of accommodation) may be available. Details and application forms will be published on the website. For information about the programme visit the ESS2003 website or http://www.elsnet.org/ess2003 or contact the chair of the programme committee, Steven Krauwer (steven.krauwer(a)elsnet.org) __________________________________________________________________________ Steven Krauwer, ELSNET coordinator, UiL-OTS, Trans 10, 3512 JK Utrecht, NL phone: +31 30 253 6050, fax: +31 30 253 6000, email: s.krauwer(a)elsnet.org http://www.elsnet.org

1 0