CALL FOR WORKSHOPS: ICFP'98

[Jon Mountjoy]

CALL FOR WORKSHOPS 

The 3rd ACM SIGPLAN 

International Conference on Functional Programming (ICFP '98) 

  Mt Washington Conference Center
 Baltimore, Maryland, USA
   27-29 September 1998 

The third International Conference on Functional Programming provides a
forum for researchers, developers, teachers, as well as users who love
programming with functions. The conference combines the Lisp and Functional
Programming (LFP) conference and the Functional Programming and Computer
Architecture (FPCA) conference, and is sponsored by ACM SIGPLAN.

ICFP '98 seeks a small number of workshop organizers who are interested in
co-locating a workshop on a functional programming language or on a topic
related to functional programming (in the sense of the Call for Papers). In
the past ICFP (incl. LFP, FPCA) has been co-located with workshops on:

  Teaching Introductory Courses with Functional Languages 
  Haskell 
  ML 
  Scheme 
  Types in Compilation

The workshops will take place on Saturday, September 26, 1998. The
organizers should plan for half day or full day workshops.

Potential organizers should contact the general chair: 

Matthias Felleisen, [EMAIL PROTECTED]

The deadline is June 1, 1998.

Re: Haskore: looking for a function that reads a midi file...

[John Atwood]

Natividad Vilela Carral wrote:
> 
> I'm looking for some function that reads a midi file and to generates
> Haskore.
> I'm trying to take a midi file and to generate a Mathematic function.


I don't know of such a function, but a quick glance at the
Haskore src, particularly MidiFile.lhs suggests to me that
many of the pieces are there.

> How many clocks are there in a quarter note?

Look in the file HaskToMidi.lhs



John Atwood

Re: Design Methodologies

[Fergus Henderson]

On 02-Feb-1998, Richard Emberson <[EMAIL PROTECTED]> wrote:
> I am investigating whether an organization can
> build large applications ( >> 50Kloc - thats c++ lines of code)
> using a functional language, specifically Haskell.

Since 1993 I've been working on what is now a 150Kloc project written
in Mercury (a pure logic/functional language), namely the Mercury
compiler.  The project is written in the logic subset rather than
the functional subset, but it would be easy to translate the design
to a pure functional language such as Haskell.

> I was told by another that a "very famous software engineering researcher"
> had said that the reason there was no emphasis on the use of functional
> languages in large software systems was:
> 
> "... functional approaches do not permit you to create
> an abstract notion of system state that can be modeled.
> Functional languages are great for people to think about
> problems (especially recursion), but they are no good for 
> large software systems.  It's not that people haven't looked
> at them in this context; they don't work."

Oh, codswallop.

> What I am looking for are the formal design methods and tools
> supporting those methods that lead one through the task
> of decomposing a problem (possibly specified in a requirements
> document) into a design that can be used as the starting point
> for coding with a functional language. The documentation
> should not only cover the engineering task of (using generic terms)
> top-level-design, intermediate-design, detailed-design,
> unit-coding&test, test&integration,
> requirements-testing&sell-off, etc, but also how one
> manages such a project.

Yves Deville has written a good book on systematic programming
development in logic programming languages (not quite what
you were after, I know).

But the point I want to make is that the design process for
functional or logic programming languages need not be different
to that for imperative languages.  Modern logic and functional
languages provide convenient ways of implementing imperative
style algorithms or imperative designs.  Imperative languages
let you write stateless code too.  With regard to the design
process, the differences between functional and imperative
languages are just differences in degrees; while they will
affect the trade-offs between different design choices (e.g.
with a functional language you will tend to prefer more
functional-style designs, whereas with an imperative language
you would tend to use more imperative-style designs), the overall
process need not be significantly different. The final detailed
design and coding steps and perhaps glass-box testing are of
course highly language-dependent, but the differences between
say C and COBOL are probably of similar significance to the
differences between say Java and Haskell.  Testing,
project management, source code control, documentation,
etc. are all pretty much language-independent.

> For example, for imperative langages one has the Waterfall
> design cycle with volumes of texts showing one how to design
> and manage such a project. There are also many design tools
> supporting such an approach.

And you can use these same approaches and design tools for
functional or logic languages.


If you look at the ten pages of top-level design documentation
for the Mercury compiler, which are available at
,
you will find almost nothing that is specific to the implementation
language.  The compiler could just as easily have been implemented
in C using the exact same high-level design.

-- 
Fergus Henderson <[EMAIL PROTECTED]>   |  "I have always known that the pursuit
WWW:    |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.