headers
Ganesh Sittampalam | 24 Jan 2006 02:20
Picon
Gravatar

Re: forwarded message on the importance of libraries

On Mon, 23 Jan 2006, Isaac Jones wrote:

> Garry Hodgson writes:
>
> "Isaac Jones" <isaac.jones@...> wrote:
>
>>     Haskell' will be a conservative refinement of Haskell 98. It will
>>     be the work of this committee to adopt a set of language
>>     extensions and modifications and to standardize *a new set of
>>     libraries.* [emphasis mine]
>
> excellent.  just please please please don't give short shrift to the 
> libraries, as this is what will make or break any effort to make haskell 
> more useful to the development community at large.

I entirely agree that Haskell in general needs a large set of libraries. 
However, whether it should have a large set of *standardised* libraries is 
more questionable. In particular, standardised libraries can't be changed 
very easily.

What's the general feeling on this? The only mention of this issue on trac 
seems to be "define criteria for including libraries", so I guess noone is 
quite sure yet :-)

> excellent.  play close attention to the "out of the box" experience.
> if i can install it, run the examples, maybe have some useful
> command among them, i'm far more likely to invest the effort
> to go further.

We can have a large set of libraries distributed with every implementation
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sam Goldman | 24 Jan 2006 09:27
Favicon

Re: forwarded message on the importance of libraries

Hi--

> On Mon, 23 Jan 2006, Isaac Jones wrote:
> 
>> Garry Hodgson writes:
>>
>> "Isaac Jones" <isaac.jones@...> wrote:
>>
>>>     Haskell' will be a conservative refinement of Haskell 98. It will
>>>     be the work of this committee to adopt a set of language
>>>     extensions and modifications and to standardize *a new set of
>>>     libraries.* [emphasis mine]
>>
>> excellent.  just please please please don't give short shrift to the 
>> libraries, as this is what will make or break any effort to make 
>> haskell more useful to the development community at large.
> 
> I entirely agree that Haskell in general needs a large set of libraries.

Yes! What libraries do people want that haven't been done? I wouldn't 
mind doing some boring coding tasks in Haskell to pass the time.

> However, whether it should have a large set of *standardised* libraries 
> is more questionable. In particular, standardised libraries can't be 
> changed very easily.
> 
> What's the general feeling on this? The only mention of this issue on 
> trac seems to be "define criteria for including libraries", so I guess 
> noone is quite sure yet :-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Niklas Broberg | 24 Jan 2006 09:31
Picon
Gravatar

Re: Polymorphic record update

On 1/23/06, Henrik Nilsson <nhn@...> wrote:

[snip lots of good stuff]

This suggestion would go a long way to alleviate the burden of
boiler-plate coding. It is a conservative extension, and it is
intuitive at that. Indeed I believe I have written code with the
suggested update mechanism many times without thinking on the type
mismatch (and been beaten on my fingers by the compiler of course).
:-)

> But we'd rather not have to write such functions by hand, just as
> we'd rather not write update functions by hand. Maybe the record
> update syntax could be extended so that the function that gets
> generated behind the scenes only includes constructors that
> does NOT mention a particular field. For example, the field
> name(s) that must not occur could be prefixed by "~" which suggests
> negation in some settings. It does not have this connotation in Haskell,
> but at least "~" is already a special symbol. We could then write:
>
>     foo :: T a -> T Int
>     foo x <at> (C1 {}) = x {f1 = 1}
>     foo x <at> (C2 {}) = x {f1 = 2}
>     foo x         = x {~f1}
>
> Now the code for "foo" only has to be changed if new constructors
> having a field "f1" are added.
>
> Of course, it should be possible to combine this with the normal
> record update syntax. E.g.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dinko Tenev | 24 Jan 2006 09:53
Picon

Re: more flexible partial application

I created a feature request for this while GHC was still on SF, it has
propagated to trac and can be seen here:

http://hackage.haskell.org/trac/ghc/ticket/315

Cheers,
Dinko

On 1/23/06, Sebastian Sylvan <sebastian.sylvan <at> gmail.com> wrote:
> Are there any subtle reasons for why something like the following
> couldn't be allowed?
>
>
> > foo x y z w = ...
> > bar x w = foo x _ _ w
>
> I.e. a more flexible version of partial application. This would be
> translated too
>
> > bar x w = \y z -> foo x y z w
>
> I.e a function which takes the "_" parameters in the same order they
> were encountered in the function application.
>
> Some other languages allow this, such as Nemerle. Quite handy.
>
> /S
>
> --
> Sebastian Sylvan
(Continue reading)

Permalink | Reply | 3 comments |
headers
Manuel M T Chakravarty | 25 Jan 2006 03:41
Picon
Picon
Favicon
Gravatar

Re: more flexible partial application

lennart@... wrote:
> In my opinion, it's a useful feature, but I'm not
> convinced it's useful enough to add to Haskell.

I agree.  

BTW, IIRC the language Hope+ had a similar feature.  I think it was
question marks that identified left out parameters in Hope+.

Manuel

> Quoting Sebastian Sylvan <sebastian.sylvan@...>:
> 
> > Are there any subtle reasons for why something like the following
> > couldn't be allowed?
> >
> >
> >> foo x y z w = ...
> >> bar x w = foo x _ _ w
> >
> > I.e. a more flexible version of partial application. This would be
> > translated too
> >
> >> bar x w = \y z -> foo x y z w
> >
> > I.e a function which takes the "_" parameters in the same order they
> > were encountered in the function application.
> >
> > Some other languages allow this, such as Nemerle. Quite handy.
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeffrey Yasskin | 25 Jan 2006 04:51
Picon
Favicon

Re: more flexible partial application

I think it's a neat feature, but:

Using _ seems to conflict with a Jhc extension in which "Using
underscore in an expression expands to bottom with an error message
giving the current file and line number."
http://repetae.net/john/computer/jhc/jhc.html

Scheme has a similar feature called (cut) documented at
http://srfi.schemers.org/srfi-26/srfi-26.html. I haven't read the
SRFI, but it would make sense to incorporate their experience in any
new feature for Haskell.

Jeffrey Yasskin

On 1/24/06, Dinko Tenev <dinko.tenev@...> wrote:
> I created a feature request for this while GHC was still on SF, it has
> propagated to trac and can be seen here:
>
> http://hackage.haskell.org/trac/ghc/ticket/315
>
> Cheers,
> Dinko
>
>
> On 1/23/06, Sebastian Sylvan <sebastian.sylvan@...> wrote:
> > Are there any subtle reasons for why something like the following
> > couldn't be allowed?
> >
> >
> > > foo x y z w = ...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Johannes Waldmann | 25 Jan 2006 09:37
Picon
Favicon

what's the goal of haskell-prime?

Dear all, in the "mission statement" I read

>   We will strive to only include tried-and-true language features,

but the current discussion seems to have a wider focus,
i. e. it is more of a wish list. Indeed I think that this is a good
idea (ask (future) Haskell users what they want)
but it might not be the original goal of the Haskell-Prime effort.

On the other hand, design-by-committee (or by wiki, call it what you
want) has its problems. Just for our enjoyment, here are two quotes
from Stroustrup: Design and Evolution of C++ (1994) (ch. 12.6, p. 269f):

* ... Tom Cargill got a lot of applause for the .. suggestion
that anyone who proposed a new feature for C++ should also propose
an old feature of similar complexity that should be removed...

* Jim Waldo .. followed up with a further idea: Proposers of new
features should be required to donate a kidney. That would make people
think hard before proposing, and even people without any sense
would propose at most two extensions.

I like to stress that when discussing an extension, we should
strive to clearly state the problem that it tries to solve,
and we should check carefully what solutions are already known
(within Haskell, or within other languages/libraries).

Best regards,
--

-- 
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
(Continue reading)

Permalink | Reply | 11 comments |
headers
Johannes Waldmann | 25 Jan 2006 09:53
Picon
Favicon

Existential types: want better syntactic support (autoboxing?)

It is standard practice to hide implementation details,
in particular, not publishing the type of an object,
but just the interfaces that its type implements. We can do this
with existential types but the notation feels clumsy. See my message
http://www.haskell.org//pipermail/haskell-cafe/2005-June/010516.html
--

-- 
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Permalink | Reply | 20 comments |
headers
Johannes Waldmann | 25 Jan 2006 10:14
Picon
Favicon

module system/namespaces: separate with/use, allow local "use"

With the module system, we should make a distinction between declaring

(1) that we want to use a module
(2) how to bring the module's names into scope

E. g. in Ada, there is "with" and "use", and "use" can be local,
see also http://www.dcs.gla.ac.uk/mail-www/haskell/msg00991.html
(Similar thing is "using namespace" in C++) (in Java, "import" does
really mean "use", since everything is "withed", but that "use" then has
to be global - presumably for the same reason that Ada-with must be
at the start of the module: for maintenance, dependence on
other modules should be clearly visible).

I think the current Haskell definition (import .. qualified .. hiding)
is kludgy. Especially "hiding": that sounds similar in spirit to
a subroutine call  of the kind "call function f but don't execute its
fourth statement".

(PS: now it's enough kidneys from me)
--

-- 
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Permalink | Reply | 1 comment |
headers
jur | 25 Jan 2006 11:01
Picon

Re: what's the goal of haskell-prime?


On Jan 25, 2006, at 9:37 AM, Johannes Waldmann wrote:

> Dear all, in the "mission statement" I read
>
>>   We will strive to only include tried-and-true language features,
>
> but the current discussion seems to have a wider focus,
> i. e. it is more of a wish list. Indeed I think that this is a good
> idea (ask (future) Haskell users what they want)
> but it might not be the original goal of the Haskell-Prime effort.

Hello,

I have been on this mailing list since yesterday, so maybe this
has been addressed before.

My first question is: who are the future users of Haskell?

For instance: is this group homogenuous enough to define a single  
standard,
or would it  be advisable to define various layers in the language.
A compiler may then choose to support up to and including a number of  
layers.
I can imagine a compiler for students to learn functional programming  
with
to have seriously different demands from the compiler used by  
researchers
to do programming language research. I am usually not happy with the  
fact that
(Continue reading)

Permalink | Reply | 10 comments |

Gmane