headers
JP Bernardy | 1 Jun 2004 17:24
Picon
Favicon

RE: Tree Wars, IntMap strikes back.


> > Ok, so that means that I should merge in the last
> > change by Daan (and in IntSet too)?
> 
> I wasn't using that patch for my measurements.

So, I've ran the test myself, and came with these
results:

before patch:
0.4684287
0.1547765
0.5245203

9.13862e-2
3.74943e-2
4.36934e-2

after patch:
0.4657292
0.1477775
0.5206209

9.1786005e-2
2.6795901e-2  
4.40933e-2

Lookup (2nd number) is much faster, so I apply the
patch; and adapt it to IntSet as well.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Isaac Jones | 1 Jun 2004 20:49

new Library Infrastructure spec.

(followups to libraries <at> haskell.org)

Hail Haskellers! 

A commonly-identified obstacle to the spread of Haskell libraries is
that there is no standard way

   a) for authors to package a library or other tool for distribution
      to others

   b) for customers to install such a package

Platforms vary.  Haskell compilers vary.  Packages have
dependencies. Etc.

Isaac Jones has coordinated an effort to address this problem.  We've
had a lot of discussion between him and (at least some of) the folk
involved in the GHC, Hugs, and nhc implementations.  This discussion
has led to a new concrete proposed specification[1].  Here it is:
http://www.haskell.org/libraryInfrastructure/proposal

See also the project home page:
http://www.haskell.org/libraryInfrastructure/

We would welcome your feedback, either as a potential library or tool
author, or as a potential consumer, or both.  The specification isn't
complete in every detail, but it seems better to post it before
investing in details that may be rendered void by subsequent
discussion.
(Continue reading)

Permalink | Reply | 0 comments |
headers
S. Alexander Jacobson | 2 Jun 2004 00:26

Re: new Library Infrastructure spec.

I like the simplicity but would also like the spec
to make it easy for me to guarantee that that I
don't end up running/installing malware.

I think Haskell's typesystem and purity should
make it relatively easy to make sure that:

1. installation has no sideeffects beyond
   making a module available for import

2. import has no sideeffects beyond making
   functions in a module available

3. the installer and perhaps end-user is notified
   if functions in a module/package use
   unsafeperformIO or some equivalent and perhaps
   what IO functions the IO monad code actually
   does use (if any).

I don't want to have to trust a random downloaded
Setup.lhs (I don't want to have to read/understand
its source) and I suspect it is easy enough to
make sure that I don't have to.

-Alex-

PS I know that other languages require that lib
users trust lib authors and have been succesful
nonetheless, but I don't think we have to impost
that requirement.  Combined with quickcheck and
(Continue reading)

Permalink | Reply | 1 comment |
headers
Isaac Jones | 2 Jun 2004 04:32

Re: new Library Infrastructure spec.

"S. Alexander Jacobson" <haskell <at> alexjacobson.com> writes:

> I like the simplicity but would also like the spec
> to make it easy for me to guarantee that that I
> don't end up running/installing malware.
>
> I think Haskell's typesystem and purity should
> make it relatively easy to make sure that:

We actually talked about exactly this idea (thanks to Ross) last
month.  I understand what you're looking for here, but I don't think
you'll be able to get any extra security without unduly limiting the
system...

> 1. installation has no sideeffects beyond
>    making a module available for import

What about packages that install binary tools or data files?  I don't
want to limit the system to just libraries for the sake of this
security feature.

> 2. import has no sideeffects beyond making
>    functions in a module available

This is already true (besides some stuff with type classes, of
course).

> 3. the installer and perhaps end-user is notified
>    if functions in a module/package use
>    unsafeperformIO or some equivalent and perhaps
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Peyton-Jones | 2 Jun 2004 09:49
Picon
Favicon
Gravatar

RE: new Library Infrastructure spec.

| > I like the simplicity but would also like the spec
| > to make it easy for me to guarantee that that I
| > don't end up running/installing malware.
| >
| > I think Haskell's typesystem and purity should
| > make it relatively easy to make sure that:

I don't think so, alas.  The IO monad lets you do *anything*, and of
course Setup.lhs runs in the IO monad, else it would not be able to move
files or run a compiler. 

So I'm not optimistic.  Perhaps a package whose Setup.lhs did nothing
but import Distribution.Simple (which you perhaps trust) would be more
trustworthy than a big pile of goop.

But remember that you are installing a library that you will later
(presumably) run, and that might be bad too.

I'm not optimistic here. 

Simon
Permalink | Reply | 11 comments |
headers
Keith Wansbrough | 2 Jun 2004 12:19
Picon
Picon
Favicon

Re: new Library Infrastructure spec.

> We would welcome your feedback, either as a potential library or tool
> author, or as a potential consumer, or both.  The specification isn't
> complete in every detail, but it seems better to post it before
> investing in details that may be rendered void by subsequent
> discussion.

This looks great!  A few comments:

1. In the document, Angela uses `#! runhugs' or `#! runghc' at the top
   of her Setup.lhs.  But Joe is running an nhc install.  Angela can't
   know which compiler Joe is using, and so she shouldn't have to
   specify at the top of Setup.lhs.  I propose that she write `#!
   runhs' instead, and the compiler writers all provide a `runhs'
   script (or symlink) as appropriate.

2. In section 4.1, the syntax for pkg.desc is discussed.  I think the
   simplest and least surprising syntax to use would be the RFC-2822
   email message header syntax (specifically sections 2.2 and 2.2.3).
   That is, each field is first written as

     <fieldname> ":" <fieldbody>

   ; then long lines may be "folded" by breaking them anywhere
   <whitespace> is allowed, by inserting <newline><whitespace>.

   To read this format back, first "unfold" by replacing all
   <newline><whitespace> pairs with <whitespace>; then expect
   <fieldname> ":" at the start of each line, with the remainder being
   <fieldbody>.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Marlow | 2 Jun 2004 12:31
Picon
Favicon

RE: new Library Infrastructure spec.

On 02 June 2004 11:20, Keith Wansbrough wrote:

>> We would welcome your feedback, either as a potential library or tool
>> author, or as a potential consumer, or both.  The specification isn't
>> complete in every detail, but it seems better to post it before
>> investing in details that may be rendered void by subsequent
>> discussion.
> 
> This looks great!  A few comments:
> 
> 1. In the document, Angela uses `#! runhugs' or `#! runghc' at the top
>    of her Setup.lhs.  But Joe is running an nhc install.  Angela can't
>    know which compiler Joe is using, and so she shouldn't have to
>    specify at the top of Setup.lhs.  I propose that she write `#!
>    runhs' instead, and the compiler writers all provide a `runhs'
>    script (or symlink) as appropriate.

Probably better than a symlink is to have a 'runhaskell' program that
dynamically looks for a compiler to run, based on an order of
preference.  Then runhaskell can be distributed separately, and there's
no retargetting of symlinks required when compilers are installed or
uninstalled.  This is like the runghc I wrote recently: it searches for
a ghc binary in the path, so that I don't have to wire in the path to
ghc when runghc is built.

> 2. In section 4.1, the syntax for pkg.desc is discussed.  I think the
>    simplest and least surprising syntax to use would be the RFC-2822
>    email message header syntax (specifically sections 2.2 and 2.2.3).
>    That is, each field is first written as
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Graham Klyne | 2 Jun 2004 14:47

Re: new Library Infrastructure spec.

At 14:49 01/06/04 -0400, Isaac Jones wrote:
>We hope this will be an important spec, and will be with us for a long
>time.  So now's the time to look at it.  Send feedback to
>libraries <at> haskell.org.

Here are my comments (mostly nits) on:
   http://www.haskell.org/libraryInfrastructure/proposal/libraryInfrastructure.pdf

...

General:

After a first reading, I find myself a little confused about the module 
naming invariant (sect 2.2), and subsequent comments about prefixes (e.g. 
4.2.1, 4.2.3).  I think that the term "prefix" is used exclusively to refer 
to file location, but the name suggests something "deeper" is 
intended.  I'm also (mildly) concerned that the invariant might create 
problems for distributing and installing large libraries (cf. the problem 
noted in section 3.1.2).

While appreciating the desire noted in 2.2 for avoidance of complexity, I 
can't help wondering if there's a "minimal" approach to qualifying module 
names that would allow module version-mixing in a program.  I'm thinking of 
something like a "hidden" qualification of each module name that is derived 
from the particular source of the module (location, hash of content, or 
something else).  Then, different versions of a module might be made 
visible to different source files without prohibiting multiple versions 
appearing in a program.  The details of such differentiation would be 
entirely compiler dependent, so I think the design space is not unduly 
prejudiced.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Keith Wansbrough | 2 Jun 2004 17:02
Picon
Picon
Favicon

Re: new Library Infrastructure spec.

> I think SimonM's suggestion of an RFC2822-like syntax is reasonable, but it 

[my suggestion, not SimonM's!]

> would probably be better to not simply cite RFC2822, since some 

I agree, we should give an explicit definition.  I don't think it's 
likely to be very complicated.

> complications might arise.  An alternative might be XML, which would be a 
> more "modern" choice.

Ugh! No! Please! No!  No reason to do this - remember, this file is 
written by Angela Author, who has just written a Haskell module or two, 
and doesn't have a handly XML structured editor to hand.  She just 
wants to fire up her text editor and write three lines.

> Some nits to look out for with RFC2822 format are:
> + Internationalization and non-ASCII characters

We should specify either Latin-1 or Unicode/UTF-8.  The latter, I guess.

> + Case (in)sensitivity of header field names

Insensitive would follow the Principle of Least Surprise.

> + No support for structured information (text string values only).
> + No facility for grouping information
> + Comments in some header field values
(Continue reading)

Permalink | Reply | 1 comment |
headers
S. Alexander Jacobson | 2 Jun 2004 20:22

RE: new Library Infrastructure spec.

On Wed, 2 Jun 2004, Simon Peyton-Jones wrote:
> But remember that you are installing a library that you will later
> (presumably) run, and that might be bad too.

We have two different issues here: the safety of
*running* a library and the safety of *installing*
a library.

Obviously, if I run a lib in the IO monad without
a sandbox, I am totally at risk of whatever the
code does (but see below)

However, if I run a library outside the IO Monad
(and I can be certain that the lib does not call
unsafeperformIO) then I have a high level of
confidence in the safety of running the code. And,
if that lib also comes with quickcheck/hunit/proof
code, then I can have a really high level of
confidence in using the code almost immediately.

Isaac Jones observed that unless you and the other
compiler authors say that it is easy/possible to
make it safe to *run* libraries, there is no point
in trying to make it safe to *install* them. So,
the questions on the table for you is whether
there is an easy way of guaranteeing that non IO
Monad code does not do unsafeperformIO.

If ensuring safety of non IO Monad code IS
possible, it may be worth thinking about making
(Continue reading)

Permalink | Reply | 10 comments |

Gmane