Links meeting in association with ETAPS

[Philip Wadler]

Taking advantage of the fact that the world will be visiting my
doorstep, with the help of some colleagues I am organizing a
meeting on Links for 6 April 2005, to overlap with ETAPS.
The meeting is by invitation only --- please let me know if you
would like to be invited! -- P

Dear Colleagues,

If we bent our minds to it, could we produce a functional language
that was as widely used as Python? There is reason to believe that
functional languages are particularly well suited to building web
applications.

* Databases. Kleisli and Mnesia (not to mention SQL and
XQuery) have demonstrated the value of functional languages as query
languages.

* XML. Xduce, Cduce, Bigwig (not to mention XSLT and XQuery)
have demonstrated the value of functional languages for manipulating
XML.

* Continuations. PLT Scheme and WASH have demonstrated the value of
functional languages for structuring CGI interfaces.

* Distribution. Erlang and JoCaml have demonstrated the value of
functional languages for distribution and mobility.

The technique of building a coalition to design, implement, and
promote a general-purpose programming language has proven
spectacularly successful for ML and Haskell. Can we apply this
technique again, this time aimed at an application domain?

ETAPS will attract a large number of researchers to Edinburgh, and
seems an appropriate point for launching this project. We propose
to meet on *** Wednesday 6 April 2005 in Edinburgh ***. We hope you
can come.

The working name for this project is Links. A quarter of a century
ago, Burstall, MacQueen, and Sannella introduced Hope, the source of
the algebraic types of ML and Haskell. Hope was named after Hope Park
Square, located near Edinburgh University on the Meadows. Links is
named after the Bruntsfield Links, located at the other end of the the
Meadows and site of the first public golf course.

Points to be discussed at the Links meeting include:

* Presentations on work to date -- we hope you will contribute to this.

* Types. The type system of Haskell and the module system of ML
are both extremely powerful, but quite different. Regular expression
types for XML are also powerful, but it is unclear how to combine
these with polymorphism or higher-order functions. Further, to be
successful, any new language must play well with SOAP, Java, and C#,
at a minimum; how do we integrate OO and FP types?

* Effects. It is proposed that the language be strict, with an effect
type system (combining the advantages of Haskell monads with ML
effects). What variety of effects should be supported? Can we
provide support for laziness within this framework? (See Wadler and
Thiemann for relations between monads and effect type systems, see
Wadler, Taha, and MacQueen for a proposal to support laziness in a
strict language.)

* Targets. Web applications are often structures as three tiers:
browser (running HTML, XML, Javascript, Flash, Java), server
(running Java, C#, Python, Perl), and database (running SQL or
XQuery). We hope to compile code to run in all three tiers from a
single source. How can a compiler framework support multiple targets
of this kind? (See Thiemann on generating multi-tier programs from a
single source.)

* Organization. How to structure the work? Should we put in for
European and/or US grants?

Volunteers for presentations and suggestions as to topics and
organization would be most welcome.

We look forward to hearing from you!

Yours sincerely,
Xavier Leroy
Simon Peyton Jones
Benjamin Pierce
Philip Wadler

[Lauri Alanko]

I just feel like saying: wow.

[Michael Walter]

Yes - this is awesome.

[Garry Hodgson]

Philip Wadler <wad...@inf.ed.ac.uk> wrote:

> If we bent our minds to it, could we produce a functional language
> that was as widely used as Python? There is reason to believe that
> functional languages are particularly well suited to building web
> applications.

...

> * Organization. How to structure the work? Should we put in for
> European and/or US grants?
>
> Volunteers for presentations and suggestions as to topics and
> organization would be most welcome.

i hope you are successful. i worry, though, that much of the focus
in your outline is on the language technology, and not on the ecosystem
surrounding the language which, i believe, is what will make it "as widely
used as python" or not. perl, python, java, etc. are not popular primarily
based on their language design.

everyone on this list uses highly advanced languages on a daily basis.
but if i want to write a mail or http client or server, or parse or generate
xml, or run a unix process and gets its exist code and output, or whatever,
how do i do that? yes, there are libraries out there, but i have to go find
them, and build them, and integrate them, etc. and this raises the threshold
of pain sufficiently high that it's usually easier to just use what i've got.

mind you, i'm a big fan of FP. i use erlang and ocaml whenever i can.
but it costs me a lot of effort to do so, both in finding what i need and
in justifying the decision. if you want to read the vast majority of users
who don't already want to use FP, you'll need to make it easy to do so.

a while back, python was using the slogan "batteries included" to
get this idea across. while y'all are designing the ultimate "take over
the world" functional language, please don't forget the batteries.

----
Garry Hodgson, Technical Consultant, AT&T Labs

Be happy for this moment.
This moment is your life.

[Donn Cave]

In article <20050207175...@k2.sage.att.com>,
Garry Hodgson <ga...@sage.att.com> wrote:

As important as this is, would you leave it up to the
language designers, whose expertise in IMAP, HTTP, XML,
UNIX etc. may not be as notable as their skill with
computer languages?

Some exterior library support has to be taken for granted,
like buffered I/O and a reasonably comprehensive interface
to the host operating system (e.g., POSIX.) From there,
won't the language technology actually give rise to the
ecosystem around it, through the efforts of an early adopter
community? How else would you do it? That wouldn't
necessarily work out for just any cool new language, but
if something came out with the support of the people whose
names I saw on that post, that counts for a lot.

Donn Cave, do...@u.washington.edu

[Lauri Alanko]

In article <donn-E434EB.1...@gnus01.u.washington.edu>,

Donn Cave <do...@u.washington.edu> wrote:
> As important as this is, would you leave it up to the
> language designers, whose expertise in IMAP, HTTP, XML,
> UNIX etc. may not be as notable as their skill with
> computer languages?

I don't think the issue is that the language designers should provide
auxiliary libraries from day one. Rather, the big selling point of
Java and Python is that when libraries are developed, a "standard"
version emerges that is quickly included in the primary distribution.

The problem in the Scheme and ML worlds is that although lots of
libraries are available, they often need to be separately located and
installed, and there are often a number of different packages
providing similar functionality. While the availability of various
choices is not a bad thing, the lack of an "official" version slows
down and confuses people.

So I think it boils down to this: the developers of the primary
language implementation need not _develop_ all the auxiliary
libraries, but they need to manage them and package them instead of
just saying: "If you want extra stuff, go search it from the web,
don't ask us".

Lauri

[Jeff Lasslett]

Lauri Alanko wrote:
> The problem in the Scheme and ML worlds is that although lots of
> libraries are available, they often need to be separately located and
> installed, and there are often a number of different packages
> providing similar functionality.

So why develop a new language? The links proposal is interesting but your
point Lauri, suggests that the functional languages in existence now are not
the problem. That "standard" libraries, or a lack thereof, are.

So my question is why not address the problem of "official" libraries? For
that matter, why not develop a system like Perl's CPAN?

Is a new language really the answer?

Cheers,
Jeff

[Ulf Wiger]

Donn Cave <do...@u.washington.edu> writes:

> In article <20050207175...@k2.sage.att.com>,
> Garry Hodgson <ga...@sage.att.com> wrote:
>
> > mind you, i'm a big fan of FP. i use erlang and ocaml whenever i can.
> > but it costs me a lot of effort to do so, both in finding what i need and
> > in justifying the decision. if you want to read the vast majority of users
> > who don't already want to use FP, you'll need to make it easy to do so.
> >
> > a while back, python was using the slogan "batteries included" to
> > get this idea across. while y'all are designing the ultimate "take over
> > the world" functional language, please don't forget the batteries.
>
> As important as this is, would you leave it up to the
> language designers, whose expertise in IMAP, HTTP, XML,
> UNIX etc. may not be as notable as their skill with
> computer languages?

One of the reasons why Erlang has been reasonably successful
(about 100,000 downloads/year, excluding Wings3D downloads)
is certainly that the language design was followed up with
a considerable effort to write middleware and domain-specific
libraries. Another reason, I believe, was that Erlang was
used in pilot projects aiming at building real applications.

It's also interesting to see where Erlang has not been that
successful. The lack of good COM, SQL and GUI support has
not been due to intrinsic language deficiencies, but more to
the fact that these things have not been a priority for the
Erlang/OTP design team (nor to its main customers.) Very
few people besides Joe Armstrong will set out to design their
own GUI toolkit in Erlang just because it ought to be possible
to make a beautiful one. Most people will want to have these
things shrink-wrapped and well documented from day 1, so that
they can focus on building their own applications.

I think it's very important to have a few first applications
trying to put the first versions of the language to
practical use. This will mean putting a lot of energy into
writing support libraries early.

I don't think the "build it and they will come" philosophy
will fly. Otherwise, the proposal is very intriguing.

/Uffe
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes

[Vincenzo Ciancia]

Jeff Lasslett wrote:

>
> So my question is why not address the problem of "official" libraries? 
> For that matter, why not develop a system like Perl's CPAN?
>
> Is a new language really the answer?

Well, there are features like pattern matching on xml data, or
interoperation via web services, which could perhaps be better addressed by
a new language definition - see e.g. the reasons behind the xcaml language

http://www.asxcaml.org

However the more I look at alice ml the more I think that it answers to many
of the global computing needs :) Perhaps that could be a good starting
point.

Vincenzo

[Richard C. Cobbe]

Jeff Lasslett <m4d.s...@gmail.com> writes:

> So my question is why not address the problem of "official" libraries?
> For that matter, why not develop a system like Perl's CPAN?

For "official" libraries, you could do much worse than
<http://srfi.schemers.org/>. And, to answer another complaint up-thread, I
know of at least one Scheme implementation that comes with several SRFIs,
so programmers don't have to Google for them.

<blatant plug>

And see <http://planet.plt-scheme.org/> for PLaneT, a CPAN-like system for
PLT Scheme. It's still fairly young and doesn't have many libraries in it,
but the framework is there, and people have been contributing.

It's even got automatic integration with PLT's module system, like CPAN.
If you require a PLaneT module, the system will download and install it as
necessary.

</blatant plug>

Richard

[Jens Axel Søgaard]

Richard C. Cobbe wrote:

> And see <http://planet.plt-scheme.org/> for PLaneT, a CPAN-like system for
> PLT Scheme. It's still fairly young and doesn't have many libraries in it,

Partly because PLT Scheme comes bundled with quite a few libraries.

> but the framework is there, and people have been contributing.

--
Jens Axel Søgaard

[aaronwma...@yahoo.com]

Philip Wadler wrote:
> .....

> * Databases. Kleisli and Mnesia (not to mention SQL and
> XQuery) have demonstrated the value of functional languages as
query
> languages.

> .....

Just had to remark that this is the first time I've seen SQL
recruited as a functional language. Is prolog functional too?
(you mean versus dysfunctional?)

hey, how about xsdb (http://xsdb.sourceforge.net).

Peace -- Aaron Watters

===
To do is to be -- Sartre
To be is to do -- Marx
Do be do be do -- Sinatra

[Joachim Durchholz]

Garry Hodgson wrote:
>
> i hope you are successful. i worry, though, that much of the focus
> in your outline is on the language technology, and not on the ecosystem
> surrounding the language which, i believe, is what will make it "as widely
> used as python" or not. perl, python, java, etc. are not popular primarily
> based on their language design.

If the language design works well for a given type of application, the
types who're doing this kind of application will start building the
ecosystem themselves.

The more important stuff is getting a critical mass of libraries
together so that you can whack up a working application in no time.
(That's what make those "script languages" so successful: sh had all the
Unix application, Perl had regexps which were justification enough at
that time, PHP/Python/younameit have extensive libraries.)

> a while back, python was using the slogan "batteries included" to
> get this idea across. while y'all are designing the ultimate "take over
> the world" functional language, please don't forget the batteries.

Yup, that's the gist. Not just the language is important, early
availability of comprehensive, *working* libraries is crucial.

The libraries need not have perfect design. It's OK if they are just
atom-thin layers on existing C libraries if nothing better is available.

Better yet: make the language include C header files directly. (Or some
automatic translation of them).
I know that's a stinker though - it burdens the language semantics with
C cruft, either directly or in the form of adaptation and transformation
rules (besides, many C constructs have a less than explicit semantics:
"is that #define an integer value, the moral equivalent of an enum, or a
bit sequence?").
Unfortunately, the ability to interface with C is essential nowadays.

Just my 2c.
Jo

[Marcin 'Qrczak' Kowalczyk]

Joachim Durchholz <j...@durchholz.org> writes:

> The libraries need not have perfect design. It's OK if they are
> just atom-thin layers on existing C libraries if nothing better
> is available.

I actually enjoy doing this, and I'm constantly expanding wrapped
libraries for my language.

I keep the original style of the interface, but I'm polishing
technical details so that the library fits the target language,
is integrated with its conventions and protocols, and is safe.
This is sometimes hard and may require lots of work.

> Better yet: make the language include C header files directly.
> (Or some automatic translation of them).

Unfortunately this would be extremely hard. It's impossible to produce
decent interfaces for a high level language from C headers automatically.
Memory allocation issues alone are enough to prevent this.

Currently the method of interfacing my language with C depends on lots
of implementation details of my compiler, especially when I want both
a pleasant result (this means lots of glue code to cover differences
between languages, and living with constraints which allow e.g. to
throw exceptions from C snippets) and low overhead (this means that
much is written on the C side).

I'm leaving the design of more convenient mechanisms for wrapping C
libraries until I implement macros. I don't know yet how they should
look like. The best FFI I've seen is in Haskell, unfortunately it
relies on different language designs (Haskell is statically typed,
glue code written in Haskell is fast).

It's easier to use libraries from high level languages. I've done
bridges between Kogut and Python (quite nice) and between Kogut and
Perl (ugly). Python and Perl libraries can be used directly, without
specialized glue code, and in case of Python they don't even look
strange, despite Python and C being quite different from Kogut.

Since Python people have already wrapped many C libraries, I can use
them via Python without additional work. Small Gtk+ examples work.
I haven't used that for anything serious yet, so there might be some
problems waiting in the corners...

> I know that's a stinker though - it burdens the language semantics
> with C cruft, either directly or in the form of adaptation and
> transformation rules (besides, many C constructs have a less than
> explicit semantics: "is that #define an integer value, the moral
> equivalent of an enum, or a bit sequence?").

I decided to not tie the semantics of my language to C in any way,
instead the glue code must be richer.

My language is dynamically typed, with GC, tail call optimization,
exceptions, green threads, bignums, and Unicode strings. This is as
far from C as possible, except that evaluation rules are traditional
(not lazy, without backtracking, without continuations).

I did care though that types in my language can be represented in C
with minimal overhead, and that they fit the rest of the language
like native types do. Python numbers and sequences support the same
interfaces as native Kogut numbers and sequences.

--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/

[Markus Redeker]

Joachim Durchholz <j...@durchholz.org> writes:

>If the language design works well for a given type of application, the
>types who're doing this kind of application will start building the
>ecosystem themselves.

>The more important stuff is getting a critical mass of libraries
>together so that you can whack up a working application in no time.
>(That's what make those "script languages" so successful: sh had all the
>Unix application, Perl had regexps which were justification enough at
>that time, PHP/Python/younameit have extensive libraries.)

Therefore it probably helps to keep the language focused to a specific kind
of tasks where it is very good -- people will find other uses anyway. Perl's
regular expressions made it good at string processing from the beginning and
useful for system administration and scripting tasks. With Python, I am not
so sure, but it now has a lot of internet-related libraries.

Keeping the language focused will make it a little bit easier to get a
critical mass. At what kind of task are functional languages especially
good, i.e., _much_ better than other languages?

--
Markus Redeker Hamburg, Germany

[Joachim Durchholz]

Marcin 'Qrczak' Kowalczyk wrote:

> Joachim Durchholz <j...@durchholz.org> writes:
>
>>[...] make the language include C header files directly.

>>(Or some automatic translation of them).
>
> Unfortunately this would be extremely hard.

I know. I have done this kind of interfacing, at it was a pain.

> It's impossible to produce
> decent interfaces for a high level language from C headers automatically.
> Memory allocation issues alone are enough to prevent this.

I found pointer and #define interpretation more problematic.

Memory allocation can be reasonably handed through to the caller. It's
(relatively) easy to write a few helper functions that deal with memory
allocation issue, and adding the appropriate wrappers is a one-liner -
tedious but generally accepted.

Pointer interpretation is worse. &foo may be a pointer to a single
object or a pointer to an array of equally-typed objects; a program has
no way to infer that. If it's an array, array size may be defined
according to an almost arbitrary number of ways; what I have seen are:
* A final all-zeroed object
* A count passed in a separate parameter (sometimes the parameter before
the pointer, sometimes the one after, rarely in an arbitrary position)
* (Rare:) A count in the last integer-sized memory location immediately
preceding the first object, i.e. accessible via *(((int *)foo)-1). (This
style was sometimes used on the Amiga, and tied to CPUs that allowed
addressing with negative offsets; since early Intel processors didn't
have an easy way for this addressing style, I have yet to see that style
on a Wintel platform, and I'm not too unhappy with that *g*.)

I already alluded to #define interpretation.

> I did care though that types in my language can be represented in C
> with minimal overhead, and that they fit the rest of the language
> like native types do.

Well, one of the things that make or break a language is its C
interface. Since that Links project specifically aims for being widely
useful, having an easy-to-use C interface is mandatory.

Maybe direct inclusion of C headers isn't the best way to do it. I have
tried various ways, some were really evil, some were so-so - I have yet
to use one that makes C interfaces fun to use (I haven't looked into
NLFFI yet, so I'm currently lacking an important data point).

Regards,
Jo

[Joachim Durchholz]

Markus Redeker wrote:
> Keeping the language focused will make it a little bit easier to get a
> critical mass. At what kind of task are functional languages especially
> good, i.e., _much_ better than other languages?

At "sticking together" all kinds of transformations (a direct
consequence of the prevalence of higher-order functions).

I'm not sure how that translates to a concrete application domain though.

Another point might be referential transparence (somewhat linked to
immutability). While it helps, it doesn't specialize the language in any
way, so this isn't an answer to you question either.

(It's most definitely not "processing with mathematical functions". That
would be taking the term "functional language" far too literally. Though
functional languages happen to excel in this area, but it's not a
generally-interesting application area and hence irrelevant for gaining
wide popularity.)

One thing that FPs could excel at is distributed processing. Immutable
objects are far less error-prone to misinterpretation when they are
distributed over the network; they can be cached with impunity, for
example, and you don't have to distribute changes with ACID semantics.
I see a very real demand here, and from what I have seen (which,
admittedly, isn't very much) Java tends to be dead slow when doing that
systematically (at least the J2EE engine that I saw redefined my
personal definition of "bloat").
Advances in that areay might be unrelated to FP per se, but it's an area
where one could currently recruit a lot of people.
To state it explicitly: code that runs on a foreign VM (or processing
environment) should still reliably adhere to the assertions that were
relevant on the "home VM". This places some very narrow restrictions on
the kind of variance that's allowed between VM implementations, for example.

Regards,
Jo

[Tomasz Zielonka]

Markus Redeker wrote:
> Keeping the language focused will make it a little bit easier to get a
> critical mass. At what kind of task are functional languages especially
> good, i.e., _much_ better than other languages?

In my opinion, the problem with functional languages is that they are
very good at everything. A language like Perl may rock at web scripting
and text processing, but it sucks (IMO) eg. for building compilers,
safety critical applications, etc. So... the areas where it is good
really stand out clearly :)

OK, this wasn't too serious, but I think/feel/see that functional
languages are going in this direction. Change 'very' to 'quite', and
this is true today.

Best regards
Tomasz

--
Szukamy programisty C++ i Haskell'a: http://tinyurl.com/5mw4e

[Donn Cave]

In article <891iuc...@ID-219982.user.uni-berlin.de>,
Markus Redeker <c...@ibp.de> wrote:

I think the point made in the post that started this
sub-thread is that the support libraries make it easier
to get critical mass. Python's virtue is not that it's
specially suited to any particular application, but rather
that it generally works for all kinds of applications.

Actually I think it may be fairly common for applications
to change their stripes in this matter. For example you
might think of "network application" as a distinct category,
but an application that uses for example an LDAP directory
very likely didn't do that from the beginning. And the
libraries provided by Python and Perl for LDAP, for example,
are really I think well suited to this sort of incidental use,
where the provided functionality is not exactly the focus
of a serious application. They're lightweight, but the
availability of this broad selection of libraries allows
you to expediently add an LDAP directory query and move on.
(In this particular case, the library doesn't come with
Python, and you might need to acquire the underlying
OpenLDAP distribution too. So far we're even with Objective
CAML, but the Python version doesn't have a cascading set
of dependencies on other packages and development environments,
so it's actually a lot easier to deal with.)

Anyway, my point is that here it's the application's
ancillary needs that are so helpfully met. For its core
focus, the developer may be willing to invest a lot more
time digging up or implementing functionality, and maybe
less willing to settle for a lightweight solution that
comes with the language environment.

Donn Cave, do...@u.washington.edu

[Joachim Durchholz]

Philip Wadler wrote:
> If we bent our minds to it, could we produce a functional language
> that was as widely used as Python? There is reason to believe that
> functional languages are particularly well suited to building web
> applications.

Dear all,

as the response to the above message in the comp.lang.functional
newsgroup has shown, there's an immense interest in this project.

The announcement also sparked a rather extensive discussion on the
features that such a language should (or should not) have. However, the
discussion suffered from the typical newsgroup syndrome: no consensus,
threads dropping off into silence, etc.

Since I know that WikiWiki webs have a better track record in this
regard, I have set up one at

http://durchholz.org/jo/links/wiki/pmwiki.php

(For those who don't know what a WikiWiki web is: it's a web site where
anybody can edit the pages. Since the pages are versioned, it's easy to
revert accidentally or maliciously defaced pages to the last known good
state.)

I have already added some of my personal pet peeves, but I sincerely
hope that others will contribute as well, with additional proposals or
critiques.

Enjoy!

Jo

[Costin Cozianu]

A modest input:

Could it be the case that somebody reconsiders the issue of manifest
typing versus type inference ?

Here are the main considerations:

- Manifest typing does not have as high of a cost for software engineers
as assumed by language designers.
- Manifest typing provides benefits, especially in conjunction with OO
notation:
MyFancyClass obj= ...
obj. <Ctrl-Space>

This sequence of typing will provide in IDE for C#,C++, Java a friendly
drop down selection list enumerating the methods applicable to obj. It
also provides an economy of expression feature as in
List l= ...
l.iter ( ... )
l.fold_left (... )
versus
l= ...
List.iter ( l, ... )
List.fold_left( l, ... )
The later problem can be aleviated with type classes but then there are
other costs incurred (like the need for wrapping up similar values with
existential types) in order to have truly polymorphic functions or data
structures (like a list of all resource objects (supporting the XA
protocol) associated with a transaction ). My humble observations lead
me to believe that in practice type inference comes packaged with
non-trivial costs.

In particular I wonder if anybody noticed that the OO notation comes
with some definite economy of expression feature: the main (this)
argument is used to disambiguate the name of the function. Since the
argument will already be there, then package (module) names are redundant.

These kinds of costs may be acceptable for a Haskell hacker but for
simple minded engineers that work with Java or C# and a friendly
IDE, the situation seems puzzling.

If given a choice:
- type inference
+ saves you some keystrokes ,
+ some arguably more elegant code (but please no List.iter,
Hastbl.put, etc)
- inferior code assist in IDE (or no IDE at all)
- work arounds (like current existential types in Haskell) in order to
help the type checker
- manifest typing
- a few more keystrokes per identifier
+ good IDEs with code assist
+ no complicated typing (how many Haskell beginners came online asking
why this or that is not type checked ? compare to Java)
the language researcher may prefer type inference, but the software
engineer out in the trenches will likely favor manifest typing.

Admittedly I have found type inference (or alternatively just dynamic
typing) very pleasurable in writing more complex bits of code that
require many identifiers, however in my "put the bread on the table"
kind of programming the use of IDE and Code Assist technology is much
more important. I don't believe type inference addresses those issues
related to partial parsing and code assist in the editor.

Obviously there can be a combination of manifest typing and type
inference that might be just the sweet spot, on the other hand since
nobody designed the perfect language just yet, an easy choice is
manifest typing. And while Java and C# are not the best language designs
out there, arguably it's not because of their manifest typing, on the
other hand one thing is for sure: Java and C# IDEs are the best IDEs out
there by far, and manifest typing helps in this regard.

Just my 2c, of course

Costin Cozianu

[Jacques Garrigue]

Costin Cozianu <c_co...@hotmail.com> writes:

> A modest input:
>
> Could it be the case that somebody reconsiders the issue of manifest
> typing versus type inference ?

[...]

> In particular I wonder if anybody noticed that the OO notation comes
> with some definite economy of expression feature: the main (this)
> argument is used to disambiguate the name of the function. Since the
> argument will already be there, then package (module) names are
> redundant.

This is not related directly to OO, rather overloading.
Some people will tell you that this kind of implicit disambiguation is
most confusing. You have to search for the definition of your object
before you can know what the method is about.
And in real OO this is even worse: the code going to be called is
decided at runtime, so it is very hard to trace mentally the flow of
the program.

Personally I often prefer a few more keystrokes at each function call,
when I know that they will make my program more readable. But it is
true that in some cases they are just clutter.

> If given a choice:
> - type inference
> + saves you some keystrokes ,
> + some arguably more elegant code (but please no List.iter,
> Hastbl.put, etc)
> - inferior code assist in IDE (or no IDE at all)
> - work arounds (like current existential types in Haskell) in order to
> help the type checker
> - manifest typing
> - a few more keystrokes per identifier
> + good IDEs with code assist
> + no complicated typing (how many Haskell beginners came online asking
> why this or that is not type checked ? compare to Java)
> the language researcher may prefer type inference, but the software
> engineer out in the trenches will likely favor manifest typing.

There is a frequent misunderstanding here.
Saying that you are ready to write down some types does not mean that
you don't need type inference. Doing without type inference might be
okay when you don't have parametric polymorphism (i.e. "generics"),
but this is actually much harder when you have them. That's why even
C# has some degree of type inference built in. We are not talking
about a few more keystrokes here, but what might be a few dozen of
keystrokes if you use higher-order functions.

Another aspect is that much more types are explicit in functional
programs than you believe, even without type annotations. For instance
all data constructors are associated with a type. That's why type
inference works well in traditional functional programming.
Admittedly, it doesn't work as well with purely structural types, like
ocaml objects, and for them it's a good idea to write a bit of type
information (I think that most people do so anyway.)

> Admittedly I have found type inference (or alternatively just dynamic
> typing) very pleasurable in writing more complex bits of code that
> require many identifiers, however in my "put the bread on the table"
> kind of programming the use of IDE and Code Assist technology is much
> more important. I don't believe type inference addresses those issues
> related to partial parsing and code assist in the editor.

Making a good IDE is some work. The same amount of work was not
invested in IDEs for functional programming languages. I'm sure there
are plenty of things that could be done for them. I tried to do some
of them in ocamlbrowser (particularly type and code navigation), at a
time when IDEs for Java didn't do very much (my model was rather
smalltalk), but there would be a lot of work to make it a full-fledge
IDE.
The problem of partial parsing doesn't seem related to typing. It is
hard in ocaml, because everything is an expression and the grammar is
highly ambiguous, but hopefully it could be simpler in Haskell.

Also, you certainly don't need the same kind of code assist technology
when programming in a language where code is 5 times smaller. Yet it
could be nice to have the type of your function displayed when you
type its name. Something that is actually simpler in a language
without overloading.

---------------------------------------------------------------------------
Jacques Garrigue Nagoya University garrigue at math.nagoya-u.ac.jp
<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

[Markus Redeker]

Jacques Garrigue <garr...@mailhost.math.nagoya-u.ac.jp> writes:

>Also, you certainly don't need the same kind of code assist technology
>when programming in a language where code is 5 times smaller. Yet it
>could be nice to have the type of your function displayed when you
>type its name. Something that is actually simpler in a language
>without overloading.

The Haskell mode for Emacs does such things to a limited amount: It knows
the types of the Prelude functions and can scan the type declarations that
are explicitly given in the file. They are automatically shown in the status
line. It is quite useful.

[Philip Wadler]

Two updates on Links.

(1) The meeting will be 9.30--17.30 Wednesday 6 April 2005, in the
Conference Suite, School of Informatics, 2 Buccleuch Place. After the
meeting, we will adjourn for a drink in The Links Bar, Bruntsfield. As
before, let me know if you want to attend.

(2) The Links meeting is colocated with ETAPS. There is no requirement
to register for ETAPS to attend Links, but you may wish to do so.
Please note that ETAPS registration fees increase after Monday 7 March.
(Apologies for the late notice, but the venue was confirmed only
recently.)

http://www.etaps05.inf.ed.ac.uk/

Cheers, -- P