- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Default implementation of type class member function not working as expected.
by David Banas 21 May '14

21 May '14

That worked, Brandon; thanks! Gurus, I’d still love to understand exactly what I broke, trying to do it the other way. Any thoughts? Thanks, -db On May 21, 2014, at 12:14 AM, haskell-cafe-request(a)haskell.org wrote: > if there's only one definition, then define it > *outside* the typeclass. > >> I have a typeclass, which defines the following two member functions: >> (t is a Rose Tree.) >> >> getCompNodes :: t -> [CompNode a] >> >> getAllCompNodes :: t -> [CompNode a] >> getAllCompNodes t = getCompNodes t >> ++ (concatMap getAllCompNodes (subForest t)) >> The first one must be defined uniquely by each instance, but the second >> never needs a unique definition. >> So, I provided its implementation in the typeclass definition, as shown. >>

3 2

ghc-mod version 4.1.0
by Kazu Yamamoto 21 May '14

21 May '14

Hello guys, I have released ghc-mod version 4.1.0. In this version, ghc-modi provides "info" and "type" commands. This means that you can display types and information of expressions very quickly on Emacs. http://hackage.haskell.org/package/ghc-mod Thanks to GHC's -fdefer-type-errors, "type" and "info" can work even if the file contains type errors. Yay! Of course, you can make use of GHC's hole. For more information, please read the "Types" subsection of the following page: http://mew.org/~kazu/proj/ghc-mod/en/emacs.html Enjoy! --Kazu

7 9

One PhD position is available at the University of Dundee, Scotland
by Ekaterina Komendantskaya 21 May '14

21 May '14

One PhD position is available at the University of Dundee, Scotland. Contact ——————————— Katya Komendantskaya - katya(a)computing.dundee.ac.uk Profile ——————————— The subject of the studentship is programming language semantics and implementation. The specific topic for the studentship will depend on the interests and expertise of the potential candidate. Possible topics are: computational logic, interactive or automated theorem proving, verification, type systems, type inference, logics and applications, program analysis tools. Conditions ——————————— The studentship covers 3 years with a standard stipend of about £13-14k a year plus some eligible travel and consumables. Requirements ——————————— The ideal candidate must show a solid Mathematical or Computer Science background and interest in theoretical and/or practical aspects of declarative programming languages. Previous experience in one or more of the areas described in the profile will be considered a plus. How to apply ——————————— The position is available immediately. Candidates please contact Katya Komendantskaya - katya(a)computing.dundee.ac.uk Dundee and the university ——————————— Dundee is the fourth-largest city in Scotland and it is well connected with Edinburgh, Glasgow and Aberdeen. Dundee is promoted as 'One City, Many Discoveries' in honor of Dundee's history of scientific activities and of the RRS Discovery exploration vessel, which is berthed in the city harbor. Biomedical, technological and video game industries have been important for the development of the city in the last 20 years. The University of Dundee counts about 18.000 students and is situated in the city center. The university is ranked in the World's Top 250 Universities and has been voted one of the best universities in the UK for student experience. http://en.wikipedia.org/wiki/Dundee http://www.dundee.ac.uk The Theory of Computation group ——————————— The Theory of Computation group focuses on research into different areas covering functional programming, program analysis, computational logic, theorem proving, machine learning, constraint programming, graph theory, algorithms and applications like privacy, security, complexity, optimisation, and artificial intelligence. ************************ Ekaterina Komendantskaya Senior Lecturer, Head of PhD Studies Room 1.04, Queen Mother Building School of Computing, University of Dundee Scotland, DD14HN Tel: (+44) 01382384820

1 0

TemplateHaskell forces manual declaration ordering?
by Michael Alan Dorman 21 May '14

21 May '14

Hey, all, While refactoring some code, I moved a newtype declaration, and suddenly the compiler (up-to-date ghc-7.6.3 on Debian) started complaining that it wasn't in scope when I attempted to use it in an ADT. I'm still new to Haskell, so I assumed it was my misunderstanding, and looked for documentation of declaration ordering constraints and couldn't find any. So then I went to make a toy case to demonstrate the problem, and it worked: data Baz = Baz { foo :: Foo, bar :: !(Maybe Bar) } newtype Foo = Foo String newtype Bar = Bar String So I started looking at the differences between that and my real code, and the only thing that seemed at all signficant was that I was using TH to generate some lenses. And sure enough, adding that caused it to fail: {-# LANGUAGE TemplateHaskell #-} import Control.Lens data Baz = Baz { foo :: Foo, bar :: !(Maybe Bar) } makeLenses ''Baz newtype Foo = Foo String newtype Bar = Bar String If you feed this to ghci, you now get: test.hs:3:25: Not in scope: type constructor or class `Foo' test.hs:3:45: Not in scope: type constructor or class `Bar' Perhaps you meant `Baz' (line 3) Wondering if lens was somehow doing something so exotic it was breaking things, I tried aeson's TH support instead: {-# LANGUAGE TemplateHaskell #-} import Data.Aeson data Baz = Baz { foo :: Foo, bar :: !(Maybe Bar) } deriveJSON defaultOptions ''Baz newtype Foo = Foo String newtype Bar = Bar String Exact same error. That said, if I move the splices to the end of the file, everything works: {-# LANGUAGE TemplateHaskell #-} import Data.Aeson data Baz = Baz { foo :: Foo, bar :: !(Maybe Bar) } newtype Foo = Foo String newtype Bar = Bar String deriveJSON defaultOptions ''Baz I looked at the GHC docs on TH, and read the wiki page, and didn't see anything suggesting that this was a known limitation, nor did I see a bug in the known bug list that seemed pertinent. So, I'm wondering if I've found an actual bug, or a known limitation whose documentation should be made more prominent (since it seems to me that it has pretty dramatic implications for program structure), or what? And is there any way around it other than moving all the splices to the end of the source file? Mike.

4 6

Manually control linker options in Cabal build system
by Oleg Durandin 21 May '14

21 May '14

Hi all! Not long ago, I faced with problem building library with Cabal. I'm trying to build simple Haskell project as a shared library for use in MS Visual Studio (yes, I use FFI for this). And I created simple test project: / {-# LANGUAGE ForeignFunctionInterface #-} module GrepWrap where import Foreign import Foreign.C.String import Data.Char printCString :: CString -> IO () printCString s = do ss <- peekCString s putStrLn ss getCStringFromKey :: IO CString getCStringFromKey = do guess <- getLine newCString guess hello :: IO() hello = do putStrLn "Hi there!" foreign export stdcall В В В В hello :: IO () foreign export stdcallВ В printCString :: CString -> IO () foreign export stdcallВ В getCStringFromKey :: IO CString/ Also, I created file for safe initialization with wrappers for hs_init() and hs_exit() calls: /// StartEnd.c #include <Rts.h> extern void __stginit_GrepWrap(void); void HsStart() { int argc = 1; char* argv[] = {"ghcDll", NULL}; // argv must end with NULL // Initialize Haskell runtime char** args = argv; hs_init(&argc, &args); } void HsEnd() { hs_exit(); }/ I compile these files with the next commands: /*> ghc -c GrepWrap.c*//* *//*> ghc -c StartEnd.c*//* *//*> ghc -shared -o grepWrap.dll grepWrap.hs StartEnd.o*/ /Linking grepWrap.dll ...// //Creating library file: grepWrap.dll.a// /// After it, I've got grepWrap.dll and grepWrap.dll.a files. I successfully linked that library with my simple C++ test app, that uses these functions. And I was able to use my Haskell functions in my simple C++ app. Further, I'd like to use Cabal build system for building the same Haskell library filles. My cabal file looks like this: /*name: GrepWrap version: 1.0 synopsis: example shared library for C use build-type: Simple cabal-version: >=1.10 library default-language: Haskell2010 exposed-modules: GrepWrap extra-libraries: HSbase-4.6.0.1, wsock32, user32, shell32, HSinteger-gmp-0.5.0.0, HSghc-prim-0.3.0.0, HSrts, gdi32, winmm c-sources: StartEnd.c extensions: ForeignFunctionInterface build-depends: base >= 4 --ghc-options: "-v"*/ After build, in directory dist/build I got a set of files and among them there are: _/libHSGrepWrap-1.0-ghc7.6.3.dll/_ , ___/libHSGrepWrap-1.0-ghc7.6.3.dll.a/_ and /_GrepWrap_stub.h_/ . I use these files in the same Visual Studio project (of course, I changed names of dependent libraries in dependencies configuration in Visual Studio). Application successfully builds, but after run this app, I've got the next exception: Unhandled exception at 0x6D7905FB (libHSrts-ghc7.6.3.dll) in GrepWrapCabalUseDll.exe: 0xC0000005: Access violation reading location 0x00000000 It occurs, when I call functions from library (but when HsStart() already called). When I use "-v" flag with compilation (using ghc) I saw such linker message log: /*** Linker:// //"C:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib/../mingw/bin/gcc.exe" "-fno-stack-protector" "-Wl,--hash-size=31" "-Wl,--reduce-memory-overheads" "-o" "grepWrap.dll" "-shared" "-Wl,--out-implib=grepWrap.dll.a" "grepWrap.o" "-Wl,--enable-auto-import" "StartEnd.o" "-LC:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\base-4.6.0.1" "-LC:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\integer-gmp-0.5.0.0" "-LC:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib\ghc-prim-0.3.0.0" "-LC:\Program Files (x86)\Haskell Platform\2013.2.0.0\lib" "-lHSbase-4.6.0.1" "-lwsock32" "-luser32" "-lshell32" "-lHSinteger-gmp-0.5.0.0" "-lHSghc-prim-0.3.0.0" "-lHSrts" "-lm" "-lwsock32" "-lgdi32" "-lwinmm" "-u" "_ghczmprim_GHCziTypes_Izh_static_info" "-u" "_ghczmprim_GHCziTypes_Czh_static_info" "-u" "_ghczmprim_GHCziTypes_Fzh_static_info" "-u" "_ghczmprim_GHCziTypes_Dzh_static_info" "-u" "_base_GHCziPtr_Ptr_static_info" "-u" "_ghczmprim_GHCziTypes_Wzh_static_info" "-u" "_base_GHCziInt_I8zh_static_info" "-u" "_base_GHCziInt_I16zh_static_info" "-u" "_base_GHCziInt_I32zh_static_info" "-u" "_base_GHCziInt_I64zh_static_info" "-u" "_base_GHCziWord_W8zh_static_info" "-u" "_base_GHCziWord_W16zh_static_info" "-u" "_base_GHCziWord_W32zh_static_info" "-u" "_base_GHCziWord_W64zh_static_info" "-u" "_base_GHCziStable_StablePtr_static_info" "-u" "_ghczmprim_GHCziTypes_Izh_con_info" "-u" "_ghczmprim_GHCziTypes_Czh_con_info" "-u" "_ghczmprim_GHCziTypes_Fzh_con_info" "-u" "_ghczmprim_GHCziTypes_Dzh_con_info" "-u" "_base_GHCziPtr_Ptr_con_info" "-u" "_base_GHCziPtr_FunPtr_con_info" "-u" "_base_GHCziStable_StablePtr_con_info" "-u" "_ghczmprim_GHCziTypes_False_closure" "-u" "_ghczmprim_GHCziTypes_True_closure" "-u" "_base_GHCziPack_unpackCString_closure" "-u" "_base_GHCziIOziException_stackOverflow_closure" "-u" "_base_GHCziIOziException_heapOverflow_closure" "-u" "_base_ControlziExceptionziBase_nonTermination_closure" "-u" "_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure" "-u" "_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure" "-u" "_base_ControlziExceptionziBase_nestedAtomically_closure" "-u" "_base_GHCziWeak_runFinalizzerBatch_closure" "-u" "_base_GHCziTopHandler_flushStdHandles_closure" "-u" "_base_GHCziTopHandler_runIO_closure" "-u" "_base_GHCziTopHandler_runNonIO_closure" "-u" "_base_GHCziConcziIO_ensureIOManagerIsRunning_closure" "-u" "_base_GHCziConcziSync_runSparks_closure" "-u" "_base_GHCziConcziSignal_runHandlers_closure"// //Creating library file: grepWrap.dll.a// //link: done/ But, when I call cabal build with "-v2" option to get build log, I get the following: /> cabal build -v2 I've got the next log: creating dist\build creating dist\build\autogen Building GrepWrap-1.0... Preprocessing library GrepWrap-1.0... Building library... creating dist\build C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin\ghc.exe --make -fbuilding-cabal-package -O -odir dist\build -hidir dist\build -stubdir dist\build -i -idist\build -i. -idist\build\autogen -Idist\build\autogen -Idist\build -optP-include -optPdist\build\autogen\cabal_macros.h -package-name GrepWrap-1.0 -hide-all-packages -package-db dist\package.conf.inplace -package-id base-4.6.0.1-f0c2cc6dcf0e12bf75312a2e7f354095 -XHaskell2010 -XForeignFunctionInterface GrepWrap [1 of 1] Compiling GrepWrap ( GrepWrap.hs, dist\build\GrepWrap.o ) C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin\ghc.exe --make -fbuilding-cabal-package -O -prof -osuf p_o -hisuf p_hi -odir dist\build -hidir dist\build -stubdir dist\build -i -idist\build -i. -idist\build\autogen -Idist\build\autogen -Idist\build -optP-include -optPdist\build\autogen\cabal_macros.h -package-name GrepWrap-1.0 -hide-all-packages -package-db dist\package.conf.inplace -package-id base-4.6.0.1-f0c2cc6dcf0e12bf75312a2e7f354095 -XHaskell2010 -XForeignFunctionInterface GrepWrap [1 of 1] Compiling GrepWrap ( GrepWrap.hs, dist\build\GrepWrap.p_o ) C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin\ghc.exe --make -fbuilding-cabal-package -O -dynamic -fPIC -osuf dyn_o -hisuf dyn_hi -odir dist\build -hidir dist\build -stubdir dist\build -i -idist\build -i. -idist\build\autogen -Idist\build\autogen -Idist\build -optP-include -optPdist\build\autogen\cabal_macros.h -package-name GrepWrap-1.0 -hide-all-packages -package-db dist\package.conf.inplace -package-id base-4.6.0.1-f0c2cc6dcf0e12bf75312a2e7f354095 -XHaskell2010 -XForeignFunctionInterface GrepWrap [1 of 1] Compiling GrepWrap ( GrepWrap.hs, dist\build\GrepWrap.dyn_o ) Building C Sources... creating dist\build C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin\ghc.exe -c -prof -odir dist\build -Idist\build -optc-O2 -package-db dist\package.conf.inplace -package-id base-4.6.0.1-f0c2cc6dcf0e12bf75312a2e7f354095 StartEnd.c C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin\ghc.exe -c -prof -dynamic -fPIC -osuf dyn_o -odir dist\build -Idist\build -optc-O2 -package-db dist\package.conf.inplace -package-id base-4.6.0.1-f0c2cc6dcf0e12bf75312a2e7f354095 StartEnd.c Linking... C:\Program Files (x86)\Haskell Platform\2013.2.0.0\mingw\bin\ar.exe -r dist\build\libHSGrepWrap-1.0.a dist\build\GrepWrap.o dist\build\StartEnd.o C:\Program Files (x86)\Haskell Platform\2013.2.0.0\mingw\bin\ar.exe: creating dist\build\libHSGrepWrap-1.0.a C:\Program Files (x86)\Haskell Platform\2013.2.0.0\mingw\bin\ar.exe -r dist\build\libHSGrepWrap-1.0_p.a dist\build\GrepWrap.p_o dist\build\StartEnd.o C:\Program Files (x86)\Haskell Platform\2013.2.0.0\mingw\bin\ar.exe: creating dist\build\libHSGrepWrap-1.0_p.a C:\Program Files (x86)\Haskell Platform\2013.2.0.0\mingw\bin\ld.exe -x --hash-size=31 --reduce-memory-overheads -r -o dist\build\HSGrepWrap-1.0.o dist\build\GrepWrap.o dist\build\StartEnd.o C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin\ghc.exe -shared -dynamic -lHSbase-4.6.0.1 -lwsock32 -luser32 -lshell32 -lHSinteger-gmp-0.5.0.0 -lHSghc-prim-0.3.0.0 -lHSrts -lgdi32 -lwinmm -package-name GrepWrap-1.0 -no-auto-link-packages -package-db dist\package.conf.inplace -package-id base-4.6.0.1-f0c2cc6dcf0e12bf75312a2e7f354095 dist\build\GrepWrap.dyn_o dist\build\StartEnd.dyn_o -o dist\build\libHSGrepWrap-1.0-ghc7.6.3.dll Creating library file: dist\build\libHSGrepWrap-1.0-ghc7.6.3.dll.a In-place registering GrepWrap-1.0... C:\Program Files (x86)\Haskell Platform\2013.2.0.0\bin\ghc-pkg.exe update - --global --user --package-db=dist\package.conf.inplace/ I'm confused.. Cabal uses a batch of options, it adds multiple options that I can't control. I'd like to control this options. How can I build my Haskell library with Cabal build system as same as building it with simple ghc? I can call ghc manually, but it will be a hard task, when I'll compile library for multiple files. Best regards, Oleg Durandin

1 0

Fwd: extending Do notation
by Miguel Mitrofanov 21 May '14

21 May '14

Forgot to reply the list -------- Пересылаемое сообщение -------- 20.05.2014, 18:26, "Miguel Mitrofanov" <miguelimo38(a)yandex.ru>: 20.05.2014, 18:14, "Kim-Ee Yeoh" <ky3(a)atamo.com>: >> 2) you can't use >>= in an if condition > Could you give an example of the if condition you want an >>= in? Actually, something like do ... if <- checkCondition then doReportSuccess else doReportFailure as well as do ... case <- generateResult of Nothing -> ... Just r -> ... instead of do ... b <- checkCondition if b ... and do ... r <- generateResult case r of ... would be very nice. -------- Завершение пересылаемого сообщения --------

8 13

Default implementation of type class member function not working as expected.
by David Banas 21 May '14

21 May '14

Hi all, I have a typeclass, which defines the following two member functions: (t is a Rose Tree.) getCompNodes :: t -> [CompNode a] getAllCompNodes :: t -> [CompNode a] getAllCompNodes t = getCompNodes t ++ (concatMap getAllCompNodes (subForest t)) The first one must be defined uniquely by each instance, but the second never needs a unique definition. So, I provided its implementation in the typeclass definition, as shown. However, I don’t get the expected behavior! If I copy and paste the code, above, for getAllCompNodes into my instance definition, then I get the expected results. Does anyone know why this is happening? Thanks, -db

2 1

Hackage Down?
by Alexander Solla 20 May '14

20 May '14

I can get to the Hackage website, but I'm having problems doing things with cabal. I have plenty of disk space. I deleted my package cache, since it was complaining about a truncated tar archive for a specific package. Now I'm trying: $ cabal update Downloading the latest package list from hackage.haskell.org cabal: truncated tar archive

1 0

Imports at bottom, why not?
by Thiago Negri 20 May '14

20 May '14

When reading code, I find it quite distracting to have to get past the import list to reach the actual module code, as the import list can be (and often is) quite big. So, why not issue import statements at the bottom of a module file? Likewise, we can use "where" statements to define names used in a function after using them, so they don't distract the reader. I'm against imports at the middle of the file. But I guess being able to issue them at the end of the module could make sense if you want to get the reader straight to the code. A language pragma could be used to select between top imports or bottom imports (can't use both). What do you think? Example: """ {-# LANGUAGE LateImports #-} module Foo where bar :: String bar = "quux" baz :: Fiz baz = mkFiz import Fiz (Fiz, mkFiz) """

13 16

ML Family workshop - Extended deadline
by oleg＠okmij.org 20 May '14

20 May '14

Extended submission deadline: May 23 (Friday), any time zone Four more days to write a 2-page abstract Submissions of demos, case studies and informed opinions are particularly encouraged! Higher-order, Typed, Inferred, Strict: ACM SIGPLAN ML Family Workshop Thursday September 4, 2014, Gothenburg, Sweden (immediately following ICFP and preceding OCaml Users and Developers Workshop) Call For Papers http://okmij.org/ftp/ML/ML14.html ML is a very large family of programming languages that includes Standard ML, OCaml, F#, SML#, Manticore, MetaOCaml, JoCaml, Alice ML, Dependent ML, Flow Caml, and many others. All ML languages, beside the great deal of syntax, share several fundamental traits. They are all higher-order, strict, mostly pure, and typed, with algebraic and other data types. Their type systems inherit from Hindley-Milner. The development of these languages has inspired a significant amount of computer science research and influenced a number of programming languages, including Haskell, Scala and Clojure, as well as Rust, ATS and many others. ML workshops have been held in affiliation with ICFP continuously since 2005. This workshop specifically aims to recognize the entire extended ML family and to provide the forum to present and discuss common issues, both practical (compilation techniques, implementations of concurrency and parallelism, programming for the Web) and theoretical (fancy types, module systems, metaprogramming). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Scala, Rust, Nemerle, ATS, etc.), to exchange experience of further developing ML ideas. The ML family workshop will be held in close coordination with the OCaml Users and Developers Workshop. Format Since 2010, the ML workshop has adopted an informal model. Presentations are selected from submitted abstracts. There are no published proceedings, so any contributions may be submitted for publication elsewhere. We hope that this format encourages the presentation of exciting (if unpolished) research and deliver a lively workshop atmosphere. Each presentation should take 20-25 minutes, except demos, which should take 10-15 minutes. The exact time will be decided based on the number of accepted submissions. The presentations will likely be recorded. Post-conference proceedings The post-proceedings of selected papers from the ML Family and the OCaml Users and Developers workshops will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). The Program Committee shall invite interested authors of selected presentations to expand their abstract for inclusion in the proceedings. The submissions are to be reviewed according to the EPTCS standards. Coordination with the OCaml Users and Developers Workshop The OCaml workshop is seen as more practical and is dedicated in significant part to the OCaml community building and the evolution of the OCaml system. In contrast, the ML family workshop is not focused on any language in particular, is more research oriented, and deals with general issues of the ML-style programming and type systems. Yet there is an overlap, which we are keen to explore in various ways. The authors who feel their submission fits both workshops are encouraged to mention it at submission time or contact the Program Chairs. Scope We acknowledge the whole breadth of the ML family and aim to include languages that are closely related (although not by blood), such as Rust, ATS, Scala, Typed Clojure. Those languages have implemented and investigated run-time and type system choices that may be worth considering for OCaml, F# and other ML languages. We also hope that the exposure to the state of the art ML might favorably influence those related languages. Specifically, we seek research presentations on topics including but not limited to * Design: concurrency, distribution and mobility, programming for the web and embedded systems, handling semi-structured data, facilitating interactive programming, higher forms of polymorphism, generic programming, objects * Implementation: compilation techniques, interpreters, type checkers, partial evaluators, runtime systems, garbage collectors, etc. * Type systems: fancy types, inference, effects, overloading, modules, contracts, specifications and assertions, dynamic typing, error reporting, etc. * Applications: case studies, experience reports, pearls, etc. * Environments: libraries, tools, editors, debuggers, cross-language interoperability, functional data structures, etc. * Education: ML and ML-like languages in college or high-school, in general or computer science curriculum. Four kinds of submissions will be accepted: Informed Positions, Research Presentations, Experience Reports and Demos. * Informed Positions: A justified argument for or against a language feature. The argument must be substantiated, either theoretically (e.g., by a demonstration of (un)soundness, an inference algorithm, a complexity analysis), empirically or by a substantial experience. Personal experience is accepted as justification so long as it is extensive and illustrated with concrete examples. * Research Presentations: Research presentations should describe new ideas, experimental results, or significant advances in ML-related projects. We especially encourage presentations that describe work in progress, that outline a future research agenda, or that encourage lively discussion. These presentations should be structured in a way which can be, at least in part, of interest to (advanced) users. * Experience Reports: Users are invited to submit Experience Reports about their use of ML and related languages. These presentations do not need to contain original research but they should tell an interesting story to researchers or other advanced users, such as an innovative or unexpected use of advanced features or a description of the challenges they are facing or attempting to solve. * Demos: Live demonstrations or short tutorials should show new developments, interesting prototypes, or work in progress, in the form of tools, libraries, or applications built on or related to ML. (You will need to provide all the hardware and software required for your demo; the workshop organizers are only able to provide a projector.) Important dates Friday May 23 (any time zone): Abstract submission Monday June 30: Author notification Thursday September 4, 2014: ML Family Workshop Submission Submissions should be at most two pages, in PDF format, and printable on US Letter or A4 sized paper. A submission should have a synopsis (2-3 lines) and a body between 1 and 2 pages, in one- or two-column layout. The synopsis should be suitable for inclusion in the workshop program. Submissions must be uploaded to the workshop submission website before the submission deadline (Monday May 19, 2014). For any question concerning the scope of the workshop or the submission process, please contact the program chair. Program Committee Kenichi Asai Ochanomizu University, Japan Matthew Fluet Rochester Institute of Technology, USA Jacques Garrigue Nagoya University, Japan Dave Herman Mozilla, USA Stefan Holdermans Vector Fabrics, Netherlands Oleg Kiselyov (Chair) Monterey, CA, USA Keiko Nakata Tallinn University of Technology, Estonia Didier Remy INRIA Paris-Rocquencourt, France Zhong Shao Yale University, USA Hongwei Xi Boston University, USA

1 0