Re: FW: Haskell 98 report problem re lexical structure.
Wed, 25 Jul 2001 17:57:59 +0200 (MET DST), Christian Sievers <[EMAIL PROTECTED]>
pisze:
> The sequence of dashes must not be followed by another symbol,
> for example --> or --| do not begin a comment, they are just
> ordinary lexemes.
Nor preceded. This is symmetrical, it's not dashes that start an
operator but ones that are contained in it.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: FW: Haskell 98 report problem re lexical structure.
Simon Peyton-Jones proposed: > 1. I will use "lexeme" consistently to mean what the "lexeme" > production means. That's good. > 2. The place that "lexeme" is currently used inconsistently is in 2.3 > (Comments) Here I propose to replace paras 2 and 3 thus: > > "An ordinary comment begins with a sequence of two or more consecutive > dashes (e.g. --) and extends to the following newline. The sequence of > dashes must not be the prefix of a legal lexeme. For example, Any number of dashes is a prefix of a legal lexeme. You want to talk about what follows, but this formulation is about what might follow. (Or at least, that's how I understand it.) How about something like: The sequence of dashes must not be followed by another symbol, for example --> or --| do not begin a comment, they are just ordinary lexemes. > 5. [Re Christian S's proposal, which I sent earlier, remove "opencom" > from "lexeme"] That is consisted with the other change you suggested in 2., and indeed a nicer way to be so. The second sentence in 5.5.1 reads Since qualifier names are part of the lexical syntax, no spaces are allowed between the qualifier and the name. I think this should be Since qualified names... ^ and could as well be Since qualified names are lexemes, no spaces are allowed... All the best Christian Sievers ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Mis-attribution (was: Re: newbie conceptual question)
In my last post I goofed and attributed Neil Winstanley's "What the hell are monads?" to Philip Wadler. Sorry, Neil. // David -- David Hughes-+-office: +41 22 767 4047 UNIX Sysadmin, SERCo SA -+-mobile: +41 79 201 4732 Computing Centre, CERN -+-[EMAIL PROTECTED] This message may not represent the views of my employer or of CERN. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: newbie conceptual question
> I have been programming with imperative languages for 15 years. Now I > started learning Haskell, and functional programming (and I am very > determined to learn it well). It seems to me that I can still use functional > programming paradigm with an imperative language. How can I benefit more > from a functional programming language (i.e.Haskell)? In other words, is > having built-in language constructs for functional programming the only > reason for using a functional programming language(I can use polymorpim, and > generic programming in imperative languages, as well). I'm sure that the regular posters will have a ream of intelligent, informed comment to make about this. Just for once, though, I think there's space for a comment by a functional-programming tyro, precisely because I'm closer to being in your shoes than, say, Philip Wadler is. Just don't assume I'm right (but no doubt the experts will let us know if I'm wrong. Have a mallet, guys). I've appended to this message the names of a few publications that I particularly like. Disclaimer: the only purely functional language that I know is Haskell (and a negligible smidgen of ML). Point One: functional languages are powerful. The phrase 'built-in language constructs for functional programming' doesn't begin to describe it. Most imperative programmers don't even imagine the degree of abstraction and generality these languages afford. Polymorphism and generic programming are, as you say, possible in imperative languages, even if they're not always explicitly supported by the language. Likewise garbage-collection and (sort-of) higher-order functions. But I say: throw in lazy evaluation, -real- higher-order functions, currying and referential transparency, and find out what generality and abstraction really mean. Point Two: functional languages are beautiful. This brings tangible benefits as well as aesthetic satisfaction: unless you're doing something really dirty, your Haskell program will usually be more concise, explicit and general than its (say) Java equivalent -- often much more so. Hence readability and maintainability. Moreover, I've found learning Haskell to be a small education in itself. It's a truism that a language is only worth learning if it changes the way you think about programming; and though I still mostly program in imperative languages, a functional flavour has crept into much of my work. Even my Perl now tends towards recursion and non-destructive assignment, and I think this makes me a better Perlster. Point Three: functional languages are robust; or, rather, they very strongly encourage robust programming. This (along with Haskell's delicious typing system) is mainly because they do not permit data to be updated: if you've referred to a datum in the past, you can guarantee that it will not differ the next time you look at it. (Yes, this -does- give C programmers the heebie-jeebies. No, programs can still do useful things.) Hence referential transparency: given the same arguments, a functional function will always return the same answer. To debug an imperative program, as my lecturer used to say, you have to understand the entire history of the computation; in a functional program, whatever's going on is guaranteed to be no more complex than the particular function you're in. Functional programs rarely need debugging; when they do need debugging, the difficulty of the job is of a lower order of complexity than debugging an imperative program. Try it and you'll see. But, of course, every powerful force has its Dark Side. Point Four: functional languages are difficult are learn. The experts tend to put this statement in incredulous quotes, but I assert that it is still true if one is trying to learn Haskell on one's own without a grounding in certain mathematical principles that underlie the language. I was taught the basics by a damn' good lecturer, but most of my functional education has been self-propelled -- and frustrating. I've read some very good books, but various important concepts continue to elude me even though I've spent a fair bit of time meddling around with Haskell. What, for instance, the hell are monads? Though I've read, and pondered, and though I use the Haskell I/O system without difficulty, I still don't really grok monads except to believe that they'd make a lot of things easier if I did understand them. Presumably I'm missing some fundamental insight, probably a simple one, but what? I don't know. Point Five: there's a dearth of libraries. Functional languages lack the embarrassing plethora of libraries that come with C++ or Java or Perl. For instance, there are simply are no mature, maintained Haskell libraries for GUI development or database access (as far as I know -- I haven't checked haskell.org in a while). So I end up using Perl::Tk and DBI.pm instead, because the job needs to be done today. (By the way, I understand that other functional languages (Clean
FW: Haskell 98 report problem re lexical structure.
Title: Message
I've
looked again at what Gary says below, which relates somewhat to Christian/Thomas
Hallgren's comments about lexical matters. Here's what I
propose
1. I will use "lexeme" consistently to mean what
the "lexeme" production means.
2. The place that "lexeme" is currently used
inconsistently is in 2.3 (Comments) Here I propose to replace paras 2 and
3 thus:
"An
ordinary comment begins with a sequence of two or more consecutive dashes (e.g.
--) and extends to the following newline. The sequence of dashes must not be the
prefix of a legal lexeme. For example, ``-->''
or ``--|' do not begin a comment, because
both of these are legal lexemes.
A
nested comment begins with ``{-'' and ends with ``-}''. No legal lexeme starts with ``{-''; hence, for exmaple, ``{---'' starts a nested comment despite the
trailing dashes."
3. "--" and "---" are not legal a legal "varsym",
so the production for "varsym" should exclude "dashes" as well as
"reservedop".
4. I believe that the production for "ANY" should
include "return", "linefeed" and "uniWhite".
5. [Re Christian S's proposal, which I sent
earlier, remove "opencom" from "lexeme"]
I think that does it. Pls confirm or
deny.
Simon
-Original Message-From: Memovich, Gary
[mailto:[EMAIL PROTECTED]] Sent: 19 July 2001
18:53To: Simon Peyton-JonesSubject: Haskell 98 report
problem re lexical structure.
Hello, I've been studying the Haskell 98 report and think there are a few
problems in the section on lexical structure. First, the difference between
"lexeme" considered as a production in the grammar and "lexeme" used in the
more general sense is very confusing. The fact that "lexeme" as a grammar
production is only distinguished by being in italic font is easy to overlook.
Also, no definition of "lexeme" in the general sense, is given. I gather that
strings matching the productions "dashes", "opencom", and "closecom" are all
considered lexemes, but that strings matching "comment" and "ncomment" are
not. But this is not explicitly stated anywhere.
Also the string "---", for example, matches both the productions "varsym"
and "dashes", so the fact that it should be considered the beginning of a
comment is not decided by the maximal-munch rule alone. Perhaps the definition
of "varsym" should explicitly rule out strings matching "dashes" in the same
way it rules out strings matching "reservedop".
As a second issue, it is stated at the end of section 2.2 that characters
not in the category "ANY" are not valid in Haskell programs. But the
productions "return", "linefeed", and "uniWhite", which are not included in
the production "ANY", are explicitly included in the production "whitechar"
which implies that they can be used in programs, at least in a limited
way.
I recently posted a message to the Haskell mailing list that was related to
some of these same issues, but I now consider that message obsolete.
Thanks for your time and attention,--
Gary
IFL 2001 call for registration
IFL 2001 13th International Workshop on the IMPLEMENTATION OF FUNCTIONAL LANGUAGES Stockholm Sweden September 24 - 26, 2001 = Registration deadline 15 August 2001 <<-- Submission deadline 1 September 2001 http://www.ericsson.com/cslab/ifl2001/ email: [EMAIL PROTECTED] = We have had problems with our web server. In case you registered and did not get a response, please register again. Due to this inconvenience registration will be possible until August 15! Please register before August 15, either via the web site or by returning the following information to me: name: affiliation=: address: country: phone: fax: email: web: talk: yes/no talktitle: attending Erlang User Conference (27/9): yes/no arrival: 24 Sept (or different date) departure: 27 Sept (or different date) diet: The registration fee is 1000 sek (about 100 euro) and should be paid on arrival. The hotel you should arrange yourself. See the web page for a list of hotels. A number of rooms is reserved in Globe Hotel. For the reduced price of 995 sek, to be obtained by giving the reference number MK 1636. http://www.globehotel.se/ phone: +46 8 686 6320 +46 8 686 6300 fax: +46 8 686 6301 mailto:[EMAIL PROTECTED] Best regards Thomas --- Thomas Arts Ericsson Computer Science Laboratory Box 1505 125 25 Stockholm Sweden [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: lexical description problem in language report?
I agree with Thomas's suggestion:
a) Change the definition of lexeme
b) Move lexical discussion from 5.5.1 to 2.4
It also looks that Christian is correct in revising the details of (a).
Thomas, do you agree?
Would this resolve the various lexical issues?
Thanks for your help.
Simon
| -Original Message-
| From: Christian Sievers [mailto:[EMAIL PROTECTED]]
| Sent: 24 July 2001 20:45
| To: [EMAIL PROTECTED]
| Subject: Re: lexical description problem in language report?
|
|
| Thomas Hallgren wrote:
|
| > program -> {lexeme | whitespace }
| > lexeme -> varid | conid | varsym | consym | literal | special |
| > reservedop | reservedid
| >
| > There is no reference to qualified names here. I thought
| the purpose
| > of
| > these productions were to say that a Haskell program is
| correct on the
| > lexical level iff there is a derivation of it in the
| lexical grammar,
| > starting from the nonterminal "program". Since qualified
| names are not
| > part of this grammar, they are not part of the lexical
| syntax, which
| > contradicts the text in section 5.5.1.
| >
| > So, I repeat my improvment suggestions: include qvarid,
| qconid, etc,
| > in
| > the production for lexeme. Move the explanation of the lexical
| > properties of qualified names from section 5.5.1 to section 2.4.
|
| You could still parse a qualified name as three lexemes.
| Of course you don't want this, as this would allow white
| space between them. For the same reason, you want backquoted
| functions and constructors to be only one lexeme. In order to
| achieve this, just use qop instead of qvarsym and qconsym.
| And we need opencom, as the report says {- is a lexeme.
|
| So I suggest:
|
| lexeme -> qvarid | qconid | qop
|| literal | special | reservedop | reservedid | opencom
|
|
| It's all not new. See:
| http://www.dcs.gla.ac.uk/mail-| www/haskell/msg01596.html
|
|
http://www.dcs.gla.ac.uk/mail-www/haskell/msg01730.html
All the best
Christian Sievers
___
Haskell mailing list
[EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
newbie conceptual question
Greetings, I have been programming with imperative languages for 15 years. Now I started learning Haskell, and functional programming (and I am very determined to learn it well). It seems to me that I can still use functional programming paradigm with an imperative language. How can I benefit more from a functional programming language (i.e.Haskell)? In other words, is having built-in language constructs for functional programming the only reason for using a functional programming language(I can use polymorpim, and generic programming in imperative languages, as well). Thanks ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
ICALP 2002 Call for Papers
We apologize for possible multiple postings. In http://www.lcc.uma.es/icalp2002/c4p-jul01.pdf you can find a pdf version of this call for paper. + Call for Papers ICALP 2002 29th International Colloquium on Automata, Languages and Programming July 8-13, 2002, Málaga, Spain Camera Ready: April 16, 2002 The 29th annual meeting of the European Association of Theoretical Computer Science will be held in Málaga, Spain, July 8-13, 2002 (at the E.T.S. Ingeniería Informática). As with the Journal Theoretical Computer Science (TCS), the scientific program of the Colloquium will be split into two parts: Track A of the meeting will correspond to Algorithms, Automata, Complexity and Games, while Track B to Logic, Semantics and Theory of Programming. SUBMISIONS: Authors are invited to submit extended abstract of their papers, presenting original contributions to the theory of computer science. Detailed instructions for paper submissions will be found on the conference webpage (http://www.lcc.uma.es/icalp2002) and in future calls for papers. Submissions should consist of: a cover page, with the author's full name, address, fax number, e-mail address, a 100-word abstract, keywords and to which track (A or B) the paper is being submitted and an extended abstract describing original research. At least one author of an accepted paper should be available to present it at the conference. Simultaneous submission to other conferences with published proceedings is not allowed. Further information (dates and instructions for submissions, workshops, registration, location and travel) will be provided in future announcements. ORGANIZING COMMITEE: Buenaventura Clares (University of Granada), Ricardo Conejo (University of Málaga), Inmaculada Fortes (University of Málaga), Llanos Mora (University of Málaga), Rafael Morales (co-Chair, University of Málaga), Marlon Nuñez (University of Málaga), José Luis Pérez de la Cruz (University of Málaga), Gonzalo Ramos (University of Málaga), Francisco Triguero (co-Chair, University of Málaga), José Luis Triviño (University of Málaga). IMPORTANT DATES: Workshops proposal: November 8, 2001 Submissions: January 14, 2002 Notification: March 20, 2002 CONFERENCE CO-CHAIRS Prof. Francisco Triguero Prof. Rafael Morales Universidad de Málaga E.T.S. Ingeniería Informática Dept. Lenguajes y Ciencias de la Computación Bulevar Louis Pasteur, 35 29071 - Málaga (SPAIN) e-mail: [EMAIL PROTECTED] PROGRAM COMMITEE Track A Ricardo Baeza-Yates (U. Chile) Volker Diekert (U. Stuttgart) Paolo Ferragina (U. Pisa) Catherine Greenhill (U. Melbourne) Torben Hagerup (U. Frankfurt) Johan Håstad (KTH, Stockholm) Gabriel Istrate (Los Alamos) Claire Kenyon (U. Paris XI) Der-Tsai Lee (Acad. Sinica, Taipei) Heikki Mannila (Nokia, Helsinki) Elvira Mayordomo (U. Zaragoza) Helmut Prodinger (U. Witwatersrand, South Africa) Jan van Leeuwen(U. Utrecht) Paul Vitányi (CWI, Amsterdam) Peter Widmayer (ETH Zürich) (Chair) Gerhard Woeginger (T.U. Graz) Christos Zaroliagis (U. Patras) Track B Martín Abadi (Bell Labs Research, Lucent) Roberto Amadio (U. Provence) Gilles Barthe (INRIA-SophiaAntipolis) Manfred Droste (University of Technology Dresden) Cédric Fournet (Microsoft Cambridge) Matthew Hennessy (U. Sussex) (Chair) Furio Honsell (U. Udine) Peter O'Hearn (Queen Mary & W. C. London) Fernando Orejas (U.P.Catalunya) Ernesto Pimentel (U. Málaga) David Sands (Chalmers University of Technology and Göteborg University) Dave Schmidt (U. Kansas) Gheorghe Stefanescu (U. Bucharest) Vasco Vasconcelos (U. Lisbon) Thomas Wilke (U. Kiel) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
