August 2001 - Haskell

Erlang workshop registration
by John Hughes 20 Aug '01

20 Aug '01

(apologies if you receive more than one copy of this). Call for participation in the Erlang Workshop http://www.erlang.se/workshop/ Firenze, September 2, 2001, in connection with PLI2001 (Principles, Logics, and Implementations of high-level programming languages). Erlang must be the most widely used functional programming language in industry today. It is used in many projects at Ericsson, as well as by mobile phone operators, email companies, and internet service providers among others. Large scale use offers a golden opportunity to evaluate the functional paradigm "for real". This workshop aims to bring the academic and industrial functional programming communities together, draw lessons from the experience so far, and identify research problems relevant to industrial functional programming practice. Schedule 09:00 Invited Tutorial Lecture Joe Armstrong, Principal designer of Erlang 09.45 An Introduction to Core Erlang Richard Carlsson, Uppsala University 10.30 Coffee 11.00 Building the Next Generation Web Services with Erlang: Scalability and High Availability at Stake Mickaël Rémond, erlang-fr.org 11.45 A Model for Analyzing Erlang Software from a Code Change Perspective Lennart Öhman, Sjöland & Thyselius Telecom AB 12:30 Lunch 14.00 A Case for the Unified Heap Approach to Erlang Memory Management Marc Feeley, Université de Montréal 14.45 Extracting the Process Structure of Erlang Applications Jan Nyström and Bengt Jonsson, Uppsala University 15.30 Parallel Model Checking Tool tailored to Erlang Martin Leucker and Thomas Noll, Aachen University of Technology (RWTH) 16.15 Discussion Home page of the Erlang workshop http://www.erlang.se/workshop/ Registration is via the home page of PLI2001 http://music.dsi.unifi.it/pli01/ We are looking forward to an exciting workshop in the environment of PLI2001. Welcome! Joe Armstrong, Alteon Websystems Bjarne Däcker, Ericsson Utvecklings AB John Hughes, Chalmers University of Technology Gunilla Hugosson, Ericsson Utvecklings AB (Programme committee)

1 0

RE: How do you stop functions being inlined?
by Simon Peyton-Jones 20 Aug '01

20 Aug '01

| Well, GHC and the report still differ. They have different | semantics for the INLINE pragma. The report says that the | optional digit specifies at what level of optimization the | inlining should trigger. GHC on the other hand uses the digit | for determining which inlining pass should inline the function. | | Maybe the optional digit in the INLINE pragma should be | removed in the report? Yes, I think that's a good idea. The digit is like E.3: an example of over-eager design. Simon

1 0

RE: How do you stop functions being inlined?
by Simon Peyton-Jones 20 Aug '01

20 Aug '01

| I think in the light of the current situation, it would be | better if the Haskell standard for pragmas were changed to specify: | (1) NOTINLINE is a synonym for NOINLINE. | (2) Case in the first word of a pragma is ignored (which | everyone seems to | be assuming but isn't specified anywhere). | (3) Perhaps also SPECIALISE as a synonym for SPECIALIZE, like | GHC. It does seem to me particularly important that we should | standardise pragmas as much as possible, given that pragmas | not recognised get ignored. OK. For the Haskell 98 report I propose 1. Change "notInline" to "NOINLINE". 2. Change "specialize" to "SPECIALIZE" 3. Delete E.3 (optimize pragma) altogether Rationale a) Only GHC understands notinline/noinline, and everyone uses "noinline", which seems more gramatical. Hence the change. b) I'd rather not specify alternative spellings in the language report. Let's stick to one. (Fewer changes too.) c) It would break a lot of programs to insist on the current Report's lower-case pragma names. We could say that the thing is case-insensitive, but that's inconsistent with the rest of the language. Hence I propose upper case. Of course, compilers are free to be a bit more liberal, but my inclination is to be specific in the language report. d) No compiler implements the "optimize" pragma, and we need practical experience before fixing on a language design. Reading Appendix E I have only just realised that this pragma is specified, and it seems way over the top to me. Caveat This proposal is arguably GHC-centric, since it makes the report match GHC. On the other hand, GHC is an optimising compiler, which is what pragmas are for. Simon

3 2

trying to run programs
by Johansson Mikael 20 Aug '01

20 Aug '01

hello I'm starting up using a GHC-compiler and have successfully compiled a simple "Hello World" program. Thanks for the responses. Now I'm trying to use some simple programs from haskell.org/hugs but there are problems. Compilation Dump for: C:/cygnus/usr/local/ghc/lib/hsc C:/TEMP/ghc231.cpp 2>> error -fignore-interface-pragmas -fomit-interface-pragmas -fsimplify [ -fmax-simplifier-iterations4 ] -fwarn-overlapping-patterns -fwarn-missing-methods -fwarn-missing-fields -fwarn-deprecations -fwarn-duplicate-exports -fhi-version=408 -static "-himap=.%.hi:C:/cygnus/usr/local/ghc/lib/imports/std%.hi" "-himap-sep=:" -hifile=C:/TEMP/ghc231.hi -olang=asm -ofile=C:/TEMP/ghc231.s -F=C:/TEMP/ghc231_stb.c -FH=C:/TEMP/ghc231_stb.h +RTS -H6000000 -K1000000 AnsiDemo.hs:10: Variable not in scope: `writeStr' AnsiDemo.hs:11: Variable not in scope: `cls' AnsiDemo.hs:11: Variable not in scope: `at' AnsiDemo.hs:11: Variable not in scope: `highlight' AnsiDemo.hs:11: Variable not in scope: `pressAnyKey' AnsiDemo.hs:11: Variable not in scope: `promptReadAt' AnsiDemo.hs:21: Variable not in scope: `writeAt' AnsiDemo.hs:21: Variable not in scope: `moveTo' AnsiDemo.hs:21: Variable not in scope: `end' Compilation had errors It seems some object are missing. I have tried to find them in ghc/lib/imports and others but haven't succeded. Is there some libraries I need to run these hugs-files on my ghc-compiler? regards Mikael Johansson Volvo Aero Corporation Military Engines Trollhättan Dept. 7164MJ SE-461 81 Trollhättan, Sweden phone +46 520 940 61 e-mail: mikael.mj.johansson(a)volvo.com

1 0

Call for papers_Email
by Dr. Muhammad Sarfraz 20 Aug '01

20 Aug '01

CALL FOR PAPERS: WICS'2002 The Fourth Workshop on Information & Computer Science March 17-18, 2002 King Fahd University of Petroleum & Minerals, Dhahran, Saudi Arabia Information & Computer Scienece Department (KFUPM) in collaboration with IEEE Computer Society Saudi Arabia Chapter Theme: Internet Computing Best papers will be published in A Special Issue Of Information Sciences Journal Topics of interest: * E-Education & Distance Learning * Electronic Commerce * Information Indexing/Retrieval * Webcasting * Internet Agents * Performance * Resource Discovery/Management * Security * Graphics & Visualization * Multimedia Services * Arabization * Electronic Publishing & Digital Libraries * Distributed Systems * Internet Programming Tools * Networking Technologies * Interactive Network Games * Broad & Streaming Media Content Distribution * IP Telephony * WAP & Wireless Multimedia Systems * Web/Database Integration * Datamining * Traffic Measurement & Modeling * General Web Tools & Facilities * Web-Based Applications Languages: Arabic / English Authors are invited to submit papers in the field. All submissions must include the followings: * Paper title, name, affiliation, address, E-mail, telephone, and FAX number(s) of the author(s). * Complete paper (up to 15 double-space pages) * The contact author to communicate information related to the paper and the workshop such as acceptance, format, program, etc. Important: All submissions are appreciated to be submitted electronically. All accepted papers are expected to be presented at the Workshop. Organizing Committee * Dr. Kanaan Faisal (Chairman) * Dr. Muhammad Sarfraz (V. Chairman) * Dr. Moataz Ahmed * Dr. Sulaiman Al-Bassam * Dr. Bakr A. Hassan * Dr. Sahalu B. Junaidu * Dr. Najib A. K. Kofahi * Mr. Husni Al-Muhtaseb * Dr. Khalid Salah International Advisory Committee * Dr. Moataz Ahmed (Saudi Arabia) * Dr. Abdelhamid Abdesselam (Qatar) * Dr. Ebad Banissi (UK) * Prof. Ernesto Damiani (Italy) * Dr. Jarallah Al-Ghamdi (Saudi Arabia) * Dr. Fiaz Hussain (Dubai) * Prof. Ali Jaoua (Qatar) * Prof. Juan Llorens (Spain) * Prof. Ali Mili (USA) * Prof. Serge Miranda (France) * Prof. Ahmad Nasri (Lebanon) * Prof. J. Mark Pullen (USA) * Prof. David Rine (USA) * Dr. Khalid Salah (Saudi Arabia) * Dr. Muhammad Sarfraz (Saudi Arabia) * Prof. Joseph Urban (USA) * Prof. Paul P. Wang (USA) Important Dates September 30, 2001 Papers due (about 15 pages). November 25, 2001 Notification of acceptance. December 23, 2001 Camera-ready papers. March 17 - 18, 2002 Workshop. Contact Address : Chairman, Organizing Committee, WICS'2002 Department of Information & Computer Science KFUPM # 5066 King Fahd University of Petroleum and Minerals Dhahran 31261, Saudi Arabia Tel.: +966-3-860-2175 Fax: +966-3-860-2174 Email: wics(a)ccse.kfupm.edu.sa WWW: www.ccse.kfupm.edu.sa/wics/

1 0

(no subject)
by cs tseng 19 Aug '01

19 Aug '01

3 2

Re: Minimal definitions proposal
by Marcin 'Qrczak' Kowalczyk 18 Aug '01

18 Aug '01

Fri, 17 Aug 2001 23:45:55 -0400, Dylan Thurston <dpt(a)math.harvard.edu> pisze: > Here's one cheap proposal: > > Add a "MINDEFINITION" pragma which takes a boolean expression whose > variables are the class functions. Since it's a pragma, this should > only produce warnings if violated. You mean an expression using && and || and method names? They are indeed enough almost always. In my experience they are not enough only if the default definitions are correct for some uses and incorrect for others, e.g. "foo and bar, and also baz if this is a set rather than a bag" or "succ and pred, and also enumFrom* functions if the type doesn't fit in Int". Since these side conditions are hard to express at all, in these cases the programmer would simply not be warned. I like it, except the name MINDEFINITION, although I tend to call it "minimal definition". REQUIRED? Although "Minimal definition: nothing, all default definitions will make a correct instance" could be spelled by omitting the pragma, an explicit "True" should be allowed too, so one reading the class definition can distinguish between this case and "I didn't bother with specifying what is required". I don't feel a need of having a special shortcut for "all methods must be specified, despite some having default definitions" - just name the methods. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: How do you stop functions being inlined?
by Marcin 'Qrczak' Kowalczyk 18 Aug '01

18 Aug '01

Fri, 17 Aug 2001 10:32:05 -0700, Simon Peyton-Jones <simonpj(a)microsoft.com> pisze: > OK. For the Haskell 98 report I propose > > 1. Change "notInline" to "NOINLINE". > 2. Change "specialize" to "SPECIALIZE" > 3. Delete E.3 (optimize pragma) altogether I like it. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Minor problem with "Floating" class in Prelude
by Dylan Thurston 18 Aug '01

18 Aug '01

The 'Floating' class in the standard prelude reads: > class (Fractional a) => Floating a where > pi :: a > exp, log, sqrt :: a -> a > (**), logBase :: a -> a -> a > sin, cos, tan :: a -> a > asin, acos, atan :: a -> a > sinh, cosh, tanh :: a -> a > asinh, acosh, atanh :: a -> a > > -- Minimal complete definition: > -- pi, exp, log, sin, cos, sinh, cosh > -- asinh, acosh, atanh > x ** y = exp (log x * y) > logBase x y = log y / log x > sqrt x = x ** 0.5 > tan x = sin x / cos x > tanh x = sinh x / cosh x Please add asin, acos, and atan to the minimal complete definition list. [Incidentally, I find these minimal definition lists very useful; I'd love to see them become more than just comments.] --Dylan

1 1

Enforcing Strict Evaluation
by Bernd Holzmüller 17 Aug '01

17 Aug '01

Hi all, I wrote an application that successively reads the contents of several (big) files, building an intermediate data structure, pretty printing their contents into one accumulated output file and extracting some information from the data structure for further processing. To avoid needing huge heap space the program reads one input file, pretty prints a representation of its contents (big) to the output file (via appendFile), extracts the necessary information (small) and proceeds with that information, so that the data structure representing the file contents can be released. To achieve the latter, however, I need to force strict evaluation of the extraction. My first approach was using $! as follows: ... info <- mapM (apply outfile) files ... apply outfile infile = do result <- read infile -- parses infile and generates data structure of its contents appendFile outfile (show result) return $! (extractInfos result) -- extractInfos returns a list of some sort of information but that did not work. I tried then printing the length of the extracted list because this would require the strict evaluation, and this works: ... info <- mapM (apply outfile) files ... apply outfile infile = do result <- read infile -- parses infile and generates data structure of its contents appendFile outfile (show result) let result' = extractInfos result -- extracts necessary information from result putStrLnFlushed (show (length result')) -- forces evaluation of result'! return result' Why does the first solution not work? How can I achieve the effects of the latter solution without printing something? Thanks, Bernd

2 1