Re: tuple component functions

1999-09-16 Thread Ron Wichers Schreur

Jón Fairbairn wrote (to the Haskell mailing list):

 pi1_3 or proj1_3 or select_1_3 or sel_1_3, even s_1_3 -- omitting the
 "_" means sel is ambiguous (!).  We should choose a scheme that can
 cope with such things even if they are unlikely.

 I don't think pi_m_n looks right unless you replace pi with the greek
 letter (UNICODE, anyone?).

Or adopt the proposal by Mark Jones and Simon Peyton Jones for records and its extension
to tuples, and you can write x.1, x.2, x.3 etc. Tbey don't seem sure
about the syntax, but I don't mind using integers as field names for

I think in all cases records are a better data structure. Just use tuples
for functions with multiple results.


Ronny Wichers Schreur

Re: standard Haskell

1997-12-11 Thread Ron Wichers Schreur

Fergus Henderson wrote (to the Haskell Mailing List):

 But it is difficult to track the ongoing discussion, because
 - the interface is slowww (they don't call it the "World Wide Wait"
   for nothing)

I tried it yesterday and had no complaints about the performance.

 - it is difficult to keep track of which parts you have read already
   and which parts are new

The colour of the author's name changes according to the age of the
message (from red to blue). Perhaps you don't have a colour monitor?


Ronny Wichers Schreur

Re: Haskell 1.4 and Unicode

1997-11-10 Thread Ron Wichers Schreur

Carl R. Witty wrote (to the Haskell mailing list):
 The Report could give up and say that column numbers in the
 presence of \u escapes are explicitly implementation-defined.
 [This] sounds pretty bad (effectively prohibiting layout in portable
 programs using Unicode characters);

I do agree that an implementation defined rule is undesirable, but
it is possible to write portable programs with the layout rule. Just
make sure you only use tabs at the beginning of a line.

This has a few advantages. The tab size of the editor and the
implementation don't have to correspond and you can use proportional
fonts (or a Unicode aware editor). Disadvantage is that the program
will get longer. I don't mind this, I like white space.


Ronny Wichers Schreur

Re: Coercions and type synonyms

1996-07-05 Thread Ron Wichers Schreur

Marnix Klooster wrote (to the Haskell Mailing List):

 (1) a `type' declaration introduces a new type + two anonymous
 (4) if an expression is of type A when type B is expected, and a
 coercion function is defined of type A - B, then it is
 automatically inserted (this is _implicit_ coercion);

 I think that (1) and (4) together give an interpretation of type
 synonyms that works the same in practice as the current Haskell view 
 that was cited above.  

Your system seems more restrictive. For example

   type Fruit = Int
   type Apples = Fruit
   type Bananas = Fruit

   noBananas :: Bananas - Bool
   noBananas bananas
= bananas == 0

= noBananas 0

= noBananas (0 :: Apples)

is a valid Haskell program. In your system yesWeHaveNoBananas
would be rejected, because there is no coercion :: Int
- Bananas. Maybe you want add the transitive closure of
anonymous coercions.

  (5) if there is a anonymous coercion c1 :: A-B and a anonymous
  coercion c2 B-C than there is an anonymous coercion
  c3 :: A-C.

You can't add (5) for programmer defined coercions on algebraic
types, because this would make it ambiguous. All in all, it gets
pretty wild.

I would like a type system where yesWeHaveNoBananas would be
accepted and yesWeHaveNoApples would be rejected ("Can't unify
Apples with Bananas"). Perhaps you can accomplish this by doing
restricted type synonym expansions during unification. Like Marnix,
I'm no expert in type systems, so I don't know where this would
lead to.

Haskell 1.3 has the newtype feature, example:

   newtype Fruit = Int
   newtype Apples = Apples Fruit
   newtype Bananas = Bananas Fruit

   noBananas :: Bananas - Bool
   noBananas (Bananas bananas)
= bananas == 0

= noBananas (Bananas 0)

= noBananas (Apples 0)

(Hope this is correct, I don't have a Haskell 1.3 compiler handy)

Maybe this is what I want, but I'm not sure if it's always convenient
to write down the constructors everywhere (even if they don't have a
run time overhead).


Ronny Wichers Schreur

Re: Haskell 1.3

1996-03-08 Thread Ron Wichers Schreur

Lennart Augustsson wrote:

 It looks ugly, but we could say that a data declaration does not 
 have to have any constructors:
   data Empty =

Philip Wadler responded:

 I'm not keen on the syntax you propose.  How about if we allow the
 rhs of a data declaration to be just `empty', where `empty' is a

 data Empty = empty

Another suggestion is to omit the equal sign, as in

  data Empty


Ronny Wichers Schreur

FPLE '95 second Call For Participation

1995-10-25 Thread Ron Wichers Schreur



  The First International Symposium
   Functional Programming Languages


4 - 6 December 1995,
   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 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.


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

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 Turner - Elementary strong functional programming

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

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