how to parse

[S.D.Meshveliani]

Could anybody explain me how to organize parsing in Haskell ?


Examples.


lex  " ( + 2 3)"  --  [ ( "(", " + 2 3)" )  ]

  - it does too little, only separates one lexeme.


reads  " 12+3"  :: [(Int,String)] --  [ (12, "+3" )  ]

reads  " (1+2)" :: [(Int,String)] --  []

  - this is poor too.


And what I need is like this:

parse?  " 1+2* 3 +4 x 2"   --  
[  ( "(+ (+ 1 + (* 2 3)) 4)",  " x 2"  )  ]

Here the operation arities and priorities may be of the Haskell 
program syntax ones, but it is better to give them explicitely in 
additional argument of `parse?'.

If one has such Standard parse, then one can obtain canonical 
string and further read it to Haskell data as one likes.

Am I missing something ?


Thanks.

Sergey Mechveliani   [EMAIL PROTECTED]

Call for Participation FPLE'95

[parijs]

CALL FOR PARTICIPATION

  The First International Symposium
 on
   Functional Programming Languages
 in
  Education

  (FPLE'95)

4 - 6 December 1995,
 Nijmegen-Plasmolen,
   The Netherlands


Functional languages are gathering momentum in education because they
facilitate the expression of concepts and structures at a high level of
abstraction. The high level of abstraction makes functional languages
very suited for teaching students how to program. It is the aim of the
FPLE Symposium to show that functional languages can also be used
successfully to teach other important areas, such as algorithms and
data structures, compiler construction, computer architecture, data
base systems, computer graphics, mathematics, problem solving and the
semantics of programming languages.

In the FPLE Symposium the state-of-the-art is presented in the use of
functional languages to support computer science education. Functional
languages are to be understood here in a broad sense, including lazy
and strict functional languages, languages with a powerful functional
subset and algebraic specification formalisms.

Many of the authors who contribute to this symposium advocate that by
using a functional language it is possible to cover more ground than
when using a more traditional approach to teaching.

We are very proud to have David A. Turner as guest speaker.

This symposium, organized in collaboration with the IFIP 2.8 working
group on functional programming, is a must for anyone who is interested
in improving computer science education. We would greatly appreciate
your participation in this symposium. Please come and help to make this
first international symposium to be a success.


PRELIMINARY PROGRAMME

Monday 4 December:

8:45Rinus Plasmeijer - Welcome to FPLE' 95

Programming in the small - I

9:00Elpida Keravnou - Introducing computer science undergraduates
to principles of programming through a functional language
9:45Andrew Davison - Teaching C after Miranda

10:30   coffee

Programming in the large

11:00   Simon Thompson, Steve Hill - Functional programming through the
curriculum
11:45   S. Jarvis, S. Poria, R. Morgan - Understanding LOLITA:
Experiences in teaching large scale functional programming

12:30   lunch

Mathematics
---
14:00   Jerzy Karczmarczuk - Functional Programming and Mathematical Objects
14:45   Jeroen Fokker - Explaining algebraic theory with functional programs

15:30   tea

16:00   Invited speaker: David A. Turner
title to be announced

17:00   Discussion

19:00   Conference diner


Tuesday 5 December

8:45Pieter Hartel -  Report from the FPLE programme committee

Programming in the small - II
-
9:00Jean-Pierre Jacquot, J. Guyard - Requirements for an ideal first
language
9:45Manuel Nunez, Pedro Palao, Ricardo Pena - A second year course on data
structures based on functional programming

10:30   coffee

Induction and recursion
---
11:00   David Lester, Sava Mintchev - Inducing Students to Induct
11:45   C. T. P. Burton - Conceptual Structures in Recursion

12:30   lunch

Functional languages in data bases and architecture
---
14:00   John O'Donnell - From Transistors to Computer Architecture:
Teaching functional circuit specification in Hydra
14:45   Pieter Koopman, Vincent Zweije -
Functional programming in a basic database course

15:30   tea

16:00   Invited lecture: John O'Donnell -
A model lecture on Computer Architecture

17:00   Discussion: Which suited text books and programming environments are
(becoming) available


Wednesday 6 December

8:45Pieter Hartel and Rinus Plasmeijer - The future of FPLE

Compilers
-
9:00Werner E. Kluge, Carsten Rathsack, Sven-Bodo Scholz -
Using pi-red as a Teaching Tool for Functional Programming
9:45Erik Hilsdale, J. Michael Ashley, R. Kent Dybvig, D. P. Friedman -
Compiler Construction Using Scheme

10:30   coffee

Teaching experience
---
11:00   Pieter Hartel, Bert van Es, Dick Tromp -
Basic proof skills of Computer Science students
11:45   Chris Clack, Colin Myers - The Dys-Functional Student

12:30   lunch

14:00   Discussion: the future of functional languages in education


Programme Committee:
--
Hugh GlaserUniversity of Southampton, UK
Pieter Hartel  University of Amsterdam, The Netherlands
Paul Hudak Yale University, USA
John Hughes  

suggestion for Prelude,Library style

[S.D.Meshveliani]

A very simple suggestion for the programming style of
Prelude, Library ... :

 to minimize the number of function names using options.


Thus, we see in  ghc-0.26  library

quicksort:: (a - a - Bool)  - [a] - [a]
sortLt   :: (a - a - Bool)  - [a] - [a]
stableSortLt :: (a - a - Bool)  - [a] - [a]


I think, it should be like this:


sort ::  String - (a - a - Bool)  - [a] - [a]
 --mode   

sort mode cp xs =  (case  mode  of  
""   - quick  xs
"lt" - lt xs
"st" - stable xs
_- error "(sort ..):  wrong mode"
   )
  where   quick xs =
  ...
  lt xs = 
  ...
  stable xs = 
  ...


This implies that if you recently have only one variant of `sort', 
still introduce the mode String in the format, to preserve room
for the future versions - if they are likely to appear. 
-

However, I do not propose supplying a single function for all 
functions of the same format !



Sergey Mechveliani   [EMAIL PROTECTED] 

Re: Modules and interfaces

[Simon L Peyton Jones]

The goal of having a human-written interface is to give the programmer the
opportunity to say (and document) just what the interface of a module is.  I
think of this as analogous to specifying a type signature for a function...
often illuminating, but should not be obligatory.  Especially when
writing abstract data types I'd like to be able to write a signature
for a module, but currently I have no way to do so that is (a) part of the
language and hence in some standard form, and (b) checked.

Machine written/read ones are fine for conveying info between compilation
units, but they don't need to be specified as part of the language.  Current
Haskell 1.2 interface files sit uneasily between the two worlds.

Simon

| From: [EMAIL PROTECTED] (F. Warren Burton)
| Date: Tue, 26 Sep 1995 16:22:34 -0700
| Simon and John,
| 
| In practice, when do you want an interface other than the automatically
| generated one?  In practice, except in the case of mutual recursive
| modules, do you ever need to modify an interface in order to get a program
| to do what you want?  In theory, to what extent can the information in an
| interface file differ from what a compiler would generate?  Do you look at
| an interface file while writing a module that uses the interface?
| 
| I have only recently realized that I am not really clear on the purpose of
| interface files!  Am I the only one on the committee who is a bit confused?
| 
| Warren
| 
|