September 2003 - Haskell

RE: Syntax extensions: mdo and do...rec
by Simon Peyton-Jones 29 Sep '03

29 Sep '03

I agree with this. We'll move GHC to implement any consensus. My own opinion is that expr :: = ... | do { stmts } stmts :: = .. | rec { stmts } is the cleanest story. I guess that we should ensure that do rec { stmts } means what it looks like. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of | nilsson(a)cs.yale.edu | Sent: 16 September 2003 18:09 | To: haskell(a)haskell.org | Subject: Syntax extensions: mdo and do...rec | | Dear Haskellers, | | A questions. | | The do-notation has been extended to support recursive bindings by using | the "mdo" keyword. The do-notation has also been extended (through Ross | Patterson's preprocessor, and now also GHC) to support programming | with arrows. In that context, a different syntax, using the keyword "rec", | is used to enable recursive bindings. | | It seems somewhat confusing to have distinct syntax for what appears | to be very closely related purposes. Would it be possible have just a | single syntactic extension to enable recursive bindings in either context? | (Presumably the "rec" version is a bit more flexible in that it can be | applied to a subset of the bindings in a do-construct.) | | Best regards, | | /Henrik | | -- | Henrik Nilsson | Yale University | Department of Computer Science | nilsson(a)cs.yale.edu | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

5 9

Re: Syntax extensions: mdo and do...rec
by Amr A Sabry 29 Sep '03

29 Sep '03

> Another approach to value recursion was recently given by Sabry and Moggi > in their latest FICS paper: They have an mfix-like operator for > continuations there, but it doesn't satisfy left-shrinking either. The paper in question is available at: http://www.cs.indiana.edu/~sabry/papers/valuerecursion_extended.ps > (Their treatment of value recursion is rather different than ours as > well.) See Amr Sabry's papers for details. The typing of mfix given in our paper is: (m a -> m a) -> m a; by changing the (ret e) to e in rule M.2 you get exactly the same mfix of Erkok/Launchbury. The paper also shows why left-shrinking cannot hold in general and gives an example for the continuation monad. --Amr

1 0

GHC allow-overlapping-instances
by H X 29 Sep '03

29 Sep '03

Hi, Does anyone have ever used this option? I see no difference when I present this program to ghc with -fallow-overlapping-instances on/off: module Test where data T = T data F = F data OR a b = OR a b data AND a b = AND a b class C a b | a -> b instance C (OR T r) T instance C (OR r T) T instance C (AND F r) F instance C (AND r F) F -Kenny __________________________________________________ Do You Yahoo!? A free party for the most "shiok" photo! http://sg.yahoo.com/shiok

1 0

CFP: IEEE Int. Conference on Complex Computer Sys, ICECCS 2004, Florence
by ICECCS 2004 27 Sep '03

27 Sep '03

Sorry for any multiple reception of this message, Send an email with REMOVE on the subject Cheers, Pierfrancesco Bellini, Bernhard Steffen, Shawn Bohner _°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_°_° CALL FOR PAPERS IEEE International Conference on Engineering of Complex Computer Systems, IEEE ICECCS, Florence, Italy, 14-16 April, 2004 http://www.dsi.unifi.it/iceccs04 ICECCS-2004 Theme: Navigating Complexity in the e-Engineering Age As society increasingly depends on software, the size and complexity of software systems continues to grow making them more difficult to understand and evolve. Manifold dependencies between critical elements of software now drive software architectures and increasingly influence the system architecture Complexity of software systems has grown significantly, pervading several key application areas including Manufacturing, Communications, Transportation, Internet, Mobile, Healthcare, Aerospace, and Energy. These systems are frequently distributed over heterogeneous networks, recently involving Internet and Intranet technologies. Inundated by temporal constraints, boundless functionalities, complex algorithms, distributed and mobile architectures, security constraints, reliability, high performance, interoperability, and the like, these complexities are further weighing down development and evolution of today's software systems and ultimately the organizations they serve. To cope with complexity, software systems are modeled or specified using multi-paradigm approaches and require instruments and tools to visualize and understand. Whether traditional, formal models or more innovative approaches are employed; these solutions are at the frontier of the software engineering. The goal of this conference is to bring together industrial, academic and government experts, from a variety of user domain and software disciplines, to examine key complexity problems and effective solution techniques. Researchers, practitioners, tool developers and users, and technology transition experts are all welcome. The scope of the interest includes long-term research, near-term complex system requirements and promising tools, existing systems, and commercially available tools. Topic Areas: Papers are solicited in all areas related to complex computer-based systems, including the causes of complexity and means of avoiding, controlling, or coping with complexity. Topic areas includes, but are not limited to: * System and software architecture and system engineering * Tools, environments, and languages for complex systems * Formal methods and approaches to manage and control complex systems * Integration of heterogeneous technologies * Software and system development and control processes for complex systems * Human factors and collaborative aspects * Interoperability and standardization * Systems and software safety and security * Industrial automation, embedded and/or real time systems * Content production and distribution systems, mobile and multi-channel systems * Software complexity visualization * Virtual environments for managing complexity Research papers, case studies, lessons learned, status reports, and discussions of practical problems faced by industry and user domains are all welcome submissions. For review, submissions are divided into two categories: Technical Papers and Experience Reports. All submissions will be reviewed by program committee members on the basis of technical quality, relevance, significance, and clarity; and those accepted will be published in the conference proceedings. Technical papers should describe original research, and industrial experience should include practical projects or lessons learned emphasizing outcomes, insights gained, and lessons learned. ICECCS 2004 will also feature Panels and Special Sections. Proposals of 1 page length for their organization, should come with the list of involved people as well as their agreement of cooperation. SUBMISSION: Papers, panels and special sections should be submitted electronically via the Conference Service http://sttt.cs.uni-dortmund.de:80/iceccs04/servlet/Conference by November 1, 2003. Full submission details will be published on the conference web site. General Co-Chairs Paolo Nesi, Alessandro Fantechi Dep of Systems and Informatics University of Florence, Italy {nesi,fantechi}@dsi.unifi.it Program Co-Chairs Bernhard Steffen Dep. of Computer Science, University of Dortmund, Germany steffen(a)cs.uni-dortmund.de Pierfrancesco Bellini Dep of Systems and Informatics University of Florence, Italy pbellini(a)dsi.unifi.it Shawn Bohner Dep. of Computer Science, Virginia Tech, USA sbohner(a)vt.edu Local Arrangement Chair Davide Cerrai, Boehringer Ingelheim, Italy Sponsored by: IEEE Computer Society IEEE Technical Committee on Complexity in Computing In Cooperation with: University of Florence Boehringer Ingelheim - Italy Important Dates Paper Submission: 1 November 2003 Notification of acceptance: 5 January 2004 Camera ready submission: 20 January 2004 Conference: 14-16 April 2004 WWW pages http://www.dsi.unifi.it/iceccs04 Secretariat: Simonetta Ceglia ceglia@dsi.unifi.it+39-055-4796567

1 0

learning to love laziness
by nr＠eecs.harvard.edu 26 Sep '03

26 Sep '03

Consider the following Haskell function: > asPair x = (fst x, snd x) This function has type forall a b. (a, b) -> (a, b) and is almost equivalent to the identity function, except it can be used to make programs terminate that might otherwise fall into a black hole. My students are extremely mystified by such functions---and I can hardly blame them! Is there a good place to read about programming with lazy evaluation that will cover such functions and when to use them? Norman

6 5

GHC 6.2
by Simon Peyton-Jones 26 Sep '03

26 Sep '03

| > BTW, in GHC 6.2 with the -fglasgow-exts -farrows flags, you will be able | > to use either mdo or do...rec for monads and for arrows, as an experiment. | > (Maybe "rec" wasn't such a great keyword to take from the identifier | > space.) | | When can we expect 6.2? [Widening to GHC users.] Here's the GHC release situation. We've forked the tree for 6.2. Simon M is doing a bunch of house-cleaning on it (principally eliminating "casm", "ccall" and all their dirty cousins); there's still an open question of how much of the "bound threads" stuff goes into it; and we really have to fix the "errno bug", but there's some debate about exactly how. So the long and short of it is that if times were normal we'd release 6.2 in two or three weeks. But times are not entirely normal. Simon M is about to become a father (a second child, human this time, to add to GHC), and this event may distract him without warning. So far we have not been regarding 6.2 as ultra-urgent because we don't know of anyone who is really stuck with 6.0. Please let us know if you are in fact stuck. Simon

2 1

Re: lexer puzzle
by b.i.mills＠massey.ac.nz 25 Sep '03

25 Sep '03

Hi, > Haskell to me seems to be a great language with a syntax problem, > and a bad case of too many ways to do the same thing; thus every > programmer does things their own way and it's difficult to grasp > the language by looking at examples. int fact(int x){int t=1; while(x) t*=x--;} int fact(int x){int t=1; for(int i=1;i<=x;i++) t=t*i;} int fact(int x){if(x=0) return 1; else return x * fact(x-1);} int fact(int x){return aux(x,1);} int aux(int x, int t){ return x ? t : aux(x-1,t*x);} int fact(int x){int t=1; while(x && (t*=x--)); return t;} #define TRUE 1 #define FALSE 0 int fact(int x) { if((x==0)==TRUE) return 1; else { t = fact(x-1); return(t*x); } } x = x + 1; x += 1; x++; #include <stdio.h> main(t,_,a) char *a; { return!0<t?t<3?main(-79,-13,a+main(-87,1-_,main(-86,0,a+1)+a)): 1,t<_?main(t+1,_,a):3,main(-94,-27+t,a)&&t==2?_<13? main(2,_+1,"%s %d %d\n"):9:16:t<0?t<-72?main(_,t, "@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/n{n+,/+#n+,/#\ ;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l \ q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# \ ){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' \ iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \ ;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# \ }'+}##(!!/") :t<-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1) :0<t?main(2,2,"%s"):*a=='/'||main(0,main(-61,*a, "!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1); } I'm not being facetious here, but deadly serious. Your average language that is worth anything allows programmers to program in more than one way. If the language truely constrained everyone to produce a given program looking exactly the same way, then it is probably a nightmare to program in. Speaking as someone who comes from a C/C++/Java/Scheme/Assembler/Algebra background, I don't find Haskell syntax to be any more annoying than any other typical syntax. And I did not find any particular clash with `.' It's like the the game of Go, the rules (syntax) you learn in one sitting, but the strategy can take a life time. Any programmer should be able to pick up a new syntax in a week. (not that you want to do that every week, because you want to get down to playing the game). Regards, Bruce. Institute for Information and Mathematical Sciences Massey University at Albany, email: B.I.Mills(a)massey.ac.nz web: http://www.massey.ac.nz/~bimills

1 0

lexer puzzle
by Iavor Diatchki 25 Sep '03

25 Sep '03

hi everyone, what do people think should be the tokens produced by a haskell lexer when applied to the following input: A... bye iavor & thomas h. -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

8 9

"Real world" example needed for ...
by Steffen Mazanek 25 Sep '03

25 Sep '03

Hello, I am looking for a real world example of a type constructor, that expects another type constructor as an argument in the context of subtyping, e.g., one could define --not Haskell98 data T a b c = F (a b c) a::T (->) Pt Pt a = F id b::T (->) CPt CPt b = F id l = [a,b] Thereby CPt is assumed to be a subtype of Pt. From my expectations l should be typable [T (->) CPt Pt], because of contravariance of (->). Using c::T (Either) Pt Pt and d::T (Either) CPt CPt one would gain [c,d]::T (Either) Pt Pt. I need this "real world" example for the sake of motivation, that variance can be expressed by Haskell kinds, e.g., in a kind system the kind of T could be (a->b->*)->a->b->*. Thereby the "kind variables" a and b can be instantiated by "special kinds" + and -, that represent co- and contravariance, respectively. So one would have T (->)::- -> + -> * and T (Either)::+ -> + -> * and so on... Any ideas are very appreciated. Ciao, Steffen

1 0

Library Infrastructure Proposal & Home Page
by Isaac Jones 24 Sep '03

24 Sep '03

Followups to libraries(a)haskell.org please. Greetings, After many rounds of email and discussion, some wiki work, and discussion at the HIM, I've finally put together a proposal for the Library Infrastructure Project. I've inserted the introduction below. The draft proposal itself is available in a variety of formats. I've also started a web page for the project under the haskell.org site: http://www.haskell.org/libraryInfrastructure/ Please let me know if there's anything that needs to be added, if anything is confusing, etc. Comments and questions are welcome by email or on the libraries(a)haskell.org mailing list. peace, isaac ps. I expect to be moving a lot of stuff off of the wiki page since it is duplicated here. ------------------------------------------------------------ Library Infrastructure Project Proposal The Library Infrastructure Project is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. The Haskell Implementations[1] come included with a good set of standard libraries, but this set is constantly growing and is maintained centrally. This model does not scale up well, and as Haskell grows in acceptance, the quality and quantity of available libraries is becoming a major issue. There are a wide variety of Haskell Implementations (both compilers and interpreters), each of which target a variety of hardware architectures and operating systems. There are also a number of different groups and individuals providing libraries, and these libraries depend upon each other and they depend upon external systems such as Java or GTK. It can be very difficult for an end user to manage these dependencies and build all the necessary software at the correct version numbers on their platform: there is currently no generic build system to abstract away differences between Haskell Implementations and operating systems [2]. The Library Infrastructure Project seeks to provide some relief to this situation by building tools to assist developers, end users, and operating system distributers. This is a draft proposal. If you have comments, please email Isaac Jones. The latest version of this document should be available in a variety of formats from the Library Infrastructure Project home page. _________________________________________________________ Table of Contents 1. High-Level Overview 2. Issues Facing Developers 2.1. Issues Facing Packagers 2.2. Why We Should Solve This 3. A Solution for Haskell in Haskell 3.1. The Module Design 3.2. But Why Should We Use Haskell? 3.3. Setup.lhs Command-Line Interface 3.4. An Example Setup.lhs Script 4. Distribution Module 4.1. Distribution.Build 4.2. Distribution.Install 4.3. Distribution.Package 4.3.1. PackageConfig Data Structure 4.4. haskell-config Command-line interface 4.5. haskell-pkg? 4.6. Distribution.Config 5. Use Cases 6. Means of Distribution and Layered Tools 7. Development Plan A. Related Systems A.1. Debian A.2. Python Distutils A.3. CPAN and Boost A.4. FreeBSD's Ports System A.5. The XEmacs Packaging System A.6. Make-Based Systems A.7. hmake 1. High-Level Overview On a high level, we say that we want the system to help the user to install packages (whether they be libraries or applications) and their dependencies. To accomplish this, we propose a system similar to Python's Distutils (Section A.2) where each Haskell tool is distributed with a script (Section 3.4) which has a standard command-line interface. This script will provide a familiar user interface (Section 3.3) for compiling, installing, and removing packages and their dependencies. For instance, to install the HUnit package, the user might download the source code from the web site, change into the HUnit directory, and type ./Setup.lhs install default, which would build and install the HUnit package for the default compiler. Similarly, he might type ./Setup.lhs install nhc to install the package for NHC. Other tasks might be necessary to make the package known to the system, such as registering it with the Haskell Implementation of interest (Section 4.3). Such tasks would also be performed by this Setup program. FULL TEXT AT: http://www.haskell.org/libraryInfrastructure/proposal/index.html

1 0