- Haskell - Haskell.org

Gallopping Tab characters
by George Russell 26 Jan '04

26 Jan '04

Andreas wrote: > The most flexible but safe solution is to simply define the indentation > as the sequence of indentation characters used. Two consecutive lines > are indented consistently whenever one indentation is a prefix of the > other. Hence you may freely mix different indentation characters, but > you must be consistent across lines. Any decent editor should be able to > ensure that. Well no they won't, because some editors might replace blocks of 8 spaces at the start of a line with TABs (or something like that), meaning that 8 and 7 spaces would go to "\t" and " ", which your algorithm would reject. On the other hand, so would mine, so perhaps your algorithm is better, being simpler Simon Marlow wrote: > As for the width of the tab character: tab stops are every 8 columns. > Period. The Haskell report says so Yes, true. I think it was Leslie Lamport who wrote in TeXHaX that anyone defining an input format which includes tabs should be sentenced to ten years programming COBOL in Nijny-Novgorod. Off you go, Simon ... :)

4 3

Simple Fudgets-question
by Henrik Berg 26 Jan '04

26 Jan '04

Hi! I can't find any function in the Fudgets-library to do this: (F a b) -> (F a (a, b)) That is, I have a fudget taking input of type a and giving output of type b, and I want to convert it to a fudget taking input of type a and giving output of type (a, b). All I want to do is to resend the input out on the output. I'm quite new to Fudgets (and Haskell in general), and feel quite stuck on this problem. Anyone here care to give me a hint? -- Henrik

1 0

More on HXML toolbox with Hugs/Windows: matchRegex
by Graham Klyne 26 Jan '04

26 Jan '04

I think I've managed to create a version of POpen to go with Hugs under Windows. (It all compiles/links, but I haven't yet got a stand-alone test case for it). So now I'm pushing ahead with trying to get the HXML toolbox running under Hugs/Windows, and I've hit a snag with the Regex library. The oldlibs version of Regex apparently exports a function matchRegex, but the Text.Regex module which it calls upon to supply that function does not appear to define it. The problem can be seen by trying to load module Network.URI that is supplied with Hugs (2003 edition). Any pointers, please? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Re: [Haskell] Re: Use of tab characters in indentation-sensitive code
by Jeff Dalton 26 Jan '04

26 Jan '04

> This just shows how deeply ingrained the ascii plain text mindset is > in the programming community. I don't expect anything like this to ever > fly, for this reason. You guys won't let it. :( (Sorry, but how did ascii get in there? Was the argument for Unicode or HTML?) As for mindset, the programming community was one of the first to try "structure editors" and other tools that gave a more abstract view of source code. The programming community has also been pretty quick to start using HTML and XML. That plain-text syntaxes for source code have survived suggests that there are good reasons for that and that the answer to the question in an earlier message Don't we have similar needs as other electronic document manipulators? is "no, not similar enough". I work with HTML and XML all the time, and I have never felt any desire to represent programs that way; and when I do have to deal with an XML syntax for anything like a program (such as ant acripts, xslt stylesheets), I find it very unpleasant. -- Jeff

1 0

RE: [Haskell] Re: Use of tab characters in indentation-sensitive code
by Simon Marlow 26 Jan '04

26 Jan '04

> Wolfgang Thaller writes (to the Haskell mailing list): > > > IMHO, there should only be warnings about tabs when their > > size makes a difference to the meaning of the program, > > I agree and would suggest an even more stringent test to > warn against > > > a = let x = 1 > > y = 2 -- OK > > in ... > > because the (visual) interpretation depends on the font > you use (fixed width vs. proportional). The Revised Haskell 98 Report contains this paragraph (sec. 9.3): For the purposes of the layout rule, Unicode characters in a source program are considered to be of the same, fixed, width as an ASCII character. However, to avoid visual confusion, programmers should avoid writing programs in which the meaning of implicit layout depends on the width of non-space characters. As for the width of the tab character: tab stops are every 8 columns. Period. The Haskell report says so :-P Cheers, Simon

1 0

Re: Use of tab characters in indentation-sensitive code
by Wolfgang Thaller 26 Jan '04

26 Jan '04

Graham Klyne wrote: > I think that compilers should issue a warning when indentation that > determines the scope of a construct is found to contain tab characters. I'd say, when it "is found to contain a mixture of tab and space characters". I have successfully written a lot of Haskell code that uses tabs *exclusively* - in that case, the meaning of the program *doesn't* depend on how the tab characters are interpreted. IMHO, there should only be warnings about tabs when their size makes a difference to the meaning of the program, as shown in the examples below: let <spaces>x = 1 <TAB--->y = 1 -- warning let <TAB--->x = 1 -- OK <TAB--->y = 2 -- OK <spaces>z = 3 -- warning a = let x = 1 y = 2 -- OK in ... b = let x = 1 <TAB--->y = 2 -- warning in ... There are many editors that automatically mix tabs and spaces in indentation (and I don't like that - what's it good for?), but some people will certainly want to continue to use them, so I'm not sure if adding warnings like these would be acceptable to them. Cheers, Wolfgang

12 13

Re: Use of tab characters in indentation-sensitive code
by George Russell 26 Jan '04

26 Jan '04

Graham Klyne wrote (according to Wolfgang Thaller, snipped): > I think that compilers should issue a warning when indentation that > determines the scope of a construct is found to contain tab characters. In an ideal world, TAB characters would never have been put into ASCII, and this would be my preferred solution. However, since there would be some people who would object to such purity, a better alternative might be (a) to allow m TABs followed by n spaces at the start of lines. (b) to denote the indention of the line by the two numbers (m,n). (c) to give an error message when comparing two indentions (m1,n1),(m2,n2) where neither m1<=m2,n1<=n2, nor m1>=m2,n1>=n2. Incidentally Unicode allows far more possibilities for fun with indentation (for example half-spaces, IIRC).

2 1

RE: [Haskell] Re: Use of tab characters in indentation-sensitive code
by Bayley, Alistair 26 Jan '04

26 Jan '04

{-# OPTIONS -tabsize 4 #-} I think it's still a bit of a hack, but at least the author tells you what their tabsize was when they wrote it, so you can recover their layout. You could always pre-process the source yourself with sed, if the compiler doesn't understand the option. > -----Original Message----- > From: Ronan Klyne [mailto:ronan@ninebynine.org] > Sent: 26 January 2004 03:53 > To: The Haskell Mailing List > Subject: [Haskell] Re: Use of tab characters in indentation-sensitive > code > > > I support the idea that somthing should be done. I would like > to suggest > that the compiler references an environment variable to > determine how many > spaces a tab represents. I realise that this would cause the > same code to > run on some systems and fail on others, but it would allow a > developer to > set up a comfortable working system without tab characters > ruining the > logic of a program. > > # r ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com ________________________________________________________________________

2 1

Implicit return values
by Ben Rudiak-Gould 26 Jan '04

26 Jan '04

I'm sure we've all used the Writer monad from time to time when we want to yield a value which will propagate up several levels of a recursive call tree "behind the scenes". And we've all been annoyed at having to rewrite the whole function in monadic style. WriterT is less intrusive, but not much so, since we have to pepper the code with calls to "lift". I think there's a better solution. It should be possible to turn the idea of linear implicit parameters upside-down, to get values which are automatically propagated upwards and merged as necessary. We would need a class "Mergeable", a counterpart to "Splittable". But we already have such a class (Monoid). Here's a possible syntax. An expression like (123, ^x = "foo") would have the type (Integer, ^x :: String), which is like a tuple but with all but one of the elements having a name. An expression like (123, ^x="foo") - (45, ^x="bar", ^y="baz") would be converted by the compiler to (123 - 45, ^x=("foo" `mappend` "bar"), ^y="baz"), even if the two values passed to (-) were returned from a recursive call and not written out explicitly as I've done here. These return values could then be extracted by matching against the pattern (a, ^x = b), which would return the value of ^x in b, and the scrutinee with ^x removed in a. The semantics seems very simple -- virtually identical to implicit parameters. Implicit return values are dual to exceptions-as-values in some sense: they use an implicit product return type instead of a sum. It should be possible to implicitly return values which are not instances of Monoid: the compiler errors out if it ever needs to merge such a type. Wouldn't this provide a form of uniqueness typing a la Clean? In fact, couldn't we implement safe state threads on top of this, instead of the ST monad? In fact, couldn't we work within several state threads at once? -- Ben

3 7

CFP: JELIA'04 - 9th European Conference on Logics in Artificial Intelligence
by JELIA'04 25 Jan '04

25 Jan '04

/------------------------------------------------------------------/ CALL FOR PAPERS 9th European Conference on Logics in Artificial Intelligence JELIA'04 Lisbon, Portugal, September 27-30 http://centria.di.fct.unl.pt/~jelia2004 Submission deadline: May 9th (abstracts due May 6th) /------------------------------------------------------------------/ INTRODUCTION Logics have, for many years, laid claim to providing a formal basis for the study and development of applications and systems in Artificial Intelligence. With the depth and maturity of formalisms, methodologies and logic-based systems today, this claim is stronger than ever. The European Conference on Logics in Artificial Intelligence (or Journées Européennes sur la Logique en Intelligence Artificielle - JELIA) began back in 1988, as a workshop, in response to the need for a European forum for the discussion of emerging work in this field. Since then, JELIA has been organised biennially, with English as official language, and with proceedings published in Springer-Verlag's Lecture Notes in Artificial Intelligence. Previous meetings took place in Roscoff, France (1988), Amsterdam, Netherlands (1990), Berlin, Germany (1992), York, U.K. (1994), Évora, Portugal (1996), Dagstuhl, Germany (1998), Málaga, Spain (2000) and Cosenza, Italy (2002). The increasing interest in this forum, its international level with growing participation from researchers outside Europe, and the overall technical quality, has turned JELIA into a major biennial forum for the discussion of logic-based approaches to artificial intelligence. AIM AND SCOPE The aim of the 9th European Conference on Logics in Artificial Intelligence, JELIA'04, is to bring together active researchers interested in all aspects concerning the use of logics in artificial intelligence to discuss current research, results, problems and applications of both a theoretical and practical nature. JELIA strives to foster links and facilitate cross-fertilisation of ideas among researchers from various disciplines, among researchers from academia and industry, and between theoreticians and practitioners. Authors are invited to submit papers presenting original and unpublished research in all areas related to the use of Logics in AI. A non-exhaustive list of topics of interest includes: -Abductive and inductive reasoning -Applications of logic-based systems -Automated reasoning and theorem proving -Computational complexity and expressiveness in AI -Description logics -Foundations of logic programming and knowledge-based systems -Hybrid reasoning systems -Knowledge representation and reasoning -Logic based AI systems -Logic based applications to the Semantic Web -Logic based planning and diagnosis -Logic programming and nonmonotonic reasoning -Logics and multi-agent systems -Logics in machine learning -Modal, temporal, spacial and hybrid logics -Non-classical logics -Nonmonotonic reasoning, belief revision and updates -Reasoning about actions, causal reasoning and causation -Uncertain and probabilistic reasoning SUBMISSIONS Papers should be written in English, formatted according to the Springer LNCS style, and not exceed 13 pages including figures, references, etc. Please refer to the conference web pages for further instructions concerning the submission procedures. IMPORTANT DATES Abstract Submission: May 6th, 2004 Paper Submission: May 9th, 2004 Notification: June 21st, 2004 Camera Ready Copy: July 5th, 2004 PROCEEDINGS Proceedings will be published by Springer-Verlag as a volume of the Lecture Notes on Artificial Intelligence series. It is also foreseen the publication of a special issue of a journal collecting extended versions of selected papers presented at the conference. SYSTEM PRESENTATIONS There will be a special session devoted to the presentation of implemented systems. Please refer to the conference web pages for further information. CONFERENCE OFFICIALS Conference Chair: João Leite, Universidade Nova de Lisboa, Portugal Program Chair: José Júlio Alferes, Universidade Nova de Lisboa, Portugal PROGRAM COMMITTEE -José Júlio Alferes, Universidade Nova de Lisboa, Portugal -Franz Baader, TU Dresden, Germany -Salem Benferhat, Université d'Artois, France -Alexander Bochman, Holon Academic Institute of Technology, Israel -Gerhard Brewka, University of Leipzig, Germany -Walter Carnielli, Universidade Estadual de Campinas, Brazil -Luis Fariñas del Cerro, Université Paul Sabatier, France -James Delgrande, Simon Fraser University, Canada -Jürgen Dix, TU Clausthal, Germany -Roy Dyckhoff, University of St Andrews, UK -Thomas Eiter, TU Wien, Austria -Patrice Enjalbert, Université de Caen, France -Michael Fisher, University of Liverpool, UK -Ulrich Furbach, University Koblenz-Landau, Germany -Michael Gelfond, Texas Tech University, USA -Sergio Greco, Università della Calabria, Italy -João Leite, Universidade Nova de Lisboa, Portugal -Maurizio Lenzerini, Università di Roma "La Sapienza", Italy -Nicola Leone, Università della Calabria, Italy -Vladimir Lifschitz, University of Texas at Austin, USA -Maarten Marx, Universiteit van Amsterdam, The Netherlands -John-Jules Meyer, Universiteit Utrecht, The Netherlands -Bernhard Nebel, Universität Freiburg, Germany -Ilkka Niemelä, Helsinki University of Technology, Finland -Manuel Ojeda-Aciego, Universidad de Málaga, Spain -David Pearce, Universidad Rey Juan Carlos, Spain -Luís Moniz Pereira, Universidade Nova de Lisboa, Portugal -Henry Prakken, Universiteit Utrecht, The Netherlands -Luc de Raedt, Universität Freiburg, Germany -Ken Satoh, National Institute of Informatics, Japan -Renate Schmidt, University of Manchester, UK -Terrance Swift, SUNY at Stony Brook, USA -Mirek Truszczynski, University of Kentucky, USA -Wiebe van der Hoek, University of Liverpool, UK -Toby Walsh, University College Cork, Ireland -Mary-Anne Williams, The University of Technology, Sydney, Australia -Michael Zakharyaschev, King's College, UK CONTACT Send your questions and comments to jelia04(a)di.fct.unl.pt

1 0