Haskell Weekly News: Issue 213

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

PhD studentship in Nottingham (closing date 10th February)

Dear all,

I am currently advertising a PhD Studentship in Functional
Programming at the University of Nottingham in the UK:

   http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI1088

The closing date is *** Friday 10th February 2012 ***.   If
you would like to apply, please follow the instructions in
the advert, rather than clicking on "apply online".

Many thanks,

Graham Hutton

--  
Prof Graham Hutton
Functional Programming Lab
School of Computer Science
University of Nottingham, UK
http://www.cs.nott.ac.uk/~gmh

This message and any attachment are intended solely for the addressee and may contain confidential
information. If you have received this message in error, please send it back to me, and immediately delete
it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any
views or opinions expressed by the author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

ANNOUNCE: GHC version 7.4.1

   =============================================================
    The (Interactive) Glasgow Haskell Compiler -- version 7.4.1
   =============================================================

The GHC Team is pleased to announce a new major release of GHC, 7.4.1.

Here are some of the highlights of the 7.4 branch since 7.2 and 7.0:

  * The Num class no longer has Eq or Show superclasses.

  * There is a new feature Safe Haskell (-XSafe, -XTrustworthy, -XUnsafe).
    The design has changed since 7.2.

  * There is a new feature kind polymorphism (-XPolyKinds).
    A side-effect of this is that, when the extension is not enabled, in
    certain circumstances kinds are now defaulted to * rather than being
    inferred.

  * There is a new feature constraint kinds (-XConstraintKinds).

  * It is now possible to give any sort of declaration at the ghci prompt.
    For example, you can now declare datatypes within ghci.

  * The profiling and hpc implementations have been merged and overhauled.
    Visible changes include renaming of profiling flags, and a new
    semantics for the cost-centre stacks (which should in most cases
    result in more useful and intuitive profiles). The +RTS -xc flag now
    also gives a stack trace.

  * It is now possible to write compiler plugins.

  * DPH support has been significantly improved.

  * There is now preliminary support for registerised compilation using
    LLVM on the ARM platform.

Full release notes are here:

  http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html

How to get it
~~~~~~~~~~~~~

The easy way is to go to the web page, which should be self-explanatory:

        http://www.haskell.org/ghc/

We supply binary builds in the native package format for many
platforms, and the source distribution is available from the same
place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.

Background
~~~~~~~~~~

Haskell is a standard lazy functional programming language.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).

On-line GHC-related resources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Relevant URLs on the World-Wide Web:

GHC home page              http://www.haskell.org/ghc/
GHC developers' home page  http://hackage.haskell.org/trac/ghc/
Haskell home page          http://www.haskell.org/

Supported Platforms
~~~~~~~~~~~~~~~~~~~

The list of platforms we support, and the people responsible for them,
is here:

   http://hackage.haskell.org/trac/ghc/wiki/Contributors

Ports to other platforms are possible with varying degrees of
difficulty.  The Building Guide describes how to go about porting to a
new platform:

    http://hackage.haskell.org/trac/ghc/wiki/Building

Developers
~~~~~~~~~~

We welcome new contributors.  Instructions on accessing our source
code repository, and getting started with hacking on GHC, are
available from the GHC's developer's site run by Trac:

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

Mailing lists
~~~~~~~~~~~~~

We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

    http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
    http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

    http://www.haskell.org/mailman/listinfo/

Some GHC developers hang out on #haskell on IRC, too:

    http://www.haskell.org/haskellwiki/IRC_channel

Please report bugs using our bug tracking system.  Instructions on
reporting bugs can be found here:

    http://www.haskell.org/ghc/reportabug

CFP TFPIE 2012

CALL FOR PAPERS/PRESENTATIONS TFPIE 2012
International Workshop on Trends in Functional Programming in Education 2012
June 11 2012
University of St Andrews, Scotland
http://www.cs.ru.nl/P.Achten/TFPIE_2012/TFPIE_2012_home.html

The first International Workshop on Trends in Functional Programming
in Education, TFPIE 2012, will be co-located with TFP 2012 at the
University of St Andrews in Scotland. The goal of TFPIE is to gather
researchers, professors, teachers, and all professionals that use or
are interested in the use of functional programming in education.
TFPIE aims to be a venue where novel ideas, classroom-tested ideas,
and work in progress on the use of functional programming in education
are discussed. The one-day workshop will foster a spirit of open
discussion by having a review process for publication after the
workshop.

The program chairs of TFPIE 2012 will screen submissions to ensure
that all presentations are within scope and are of interest to
participants. Potential presenters are invited to submit an extended
abstract (4-6 pages) or an article (up to 16 pages). The authors of
all accepted presentations will have their preprints and their slides
made available on the workshop's website/wiki. Any visitors to the
TFPIE 2012 website/wiki will be able to add comments. This includes
presenters who may respond to comments and questions as well as
provide pointers to improvements and follow-up work. After the
workshop, the program committee will review, using prevailing academic
standards, the articles accepted for presentation to select the best
for publication in Electronic Proceedings in Theoretical Computer
Science (EPTCS). Articles rejected for presentation and all extended
abstracts will not be formally reviewed by the PC.

TOPICS OF INTEREST

TFPIE 2012 welcomes submissions describing practical techniques used
in the classroom, tools used and/or developed, and any creative use of
functional programming (FP) to aid education in or outside Computer
Science. Topics of interest include, but are not limited to:

FP and beginning CS students
FP in Artificial Intelligence
FP in Robotics
FP and Music
Advanced FP for undergraduates
FP in graduate education
Engaging students in research using FP
FP in Programming Languages
FP in the high school curriculum
FP as a stepping stone to other CS topics
FP and Philosophy

If you are not sure if your work is appropriate for TFPIE 2012, please
contact the PC chairs by e-mail at: tfpie2012 <at> cs.ru.nl .

Program Committee

Peter Achten, Radboud University Nijmegen
Jost Berthold, University of Copenhagen
Marc Feeley, University of Montreal
Ralf Hinze, University of Oxford
Shriram Krishnamurthi, Brown University
Michel Mauny, ENSTA Paris Tech
James McKinna, UK
Marco T. Morazan, Seton Hall University
Rinus Plasmeijer, Radboud University Nijmegen
Simon Thompson, University of Kent

Important Dates

May 20        submission of abstract or article
May 25        notification of acceptance
June 11       TFPIE
July 6        submission of formal paper
September 10  notification of acceptance
October 1     camera-ready paper

Venue

The University of St Andrews is Scotland's first university and the
third oldest in the English-speaking world, founded in 1413. Over six
centuries it has established a reputation as one of Europe's leading
and most distinctive centers for teaching and research. St Andrews is
situated on the east coast of Fife, Scotland, UK. The town is
approximately 50 miles north-east of Edinburgh, 14 miles south-east of
Dundee, 78 miles south of Aberdeen, and 82 miles east of Glasgow
making it easily accessible by any means of transportation. Help on
traveling to St Andrews can be found at:
http://www.st-andrews.ac.uk/visiting/GettingtoStAndrews/ .

Questions?

If you have any questions, do not hesitate to contact us at:
tfpie2012 <at> cs.ru.nl .

--

-- 

Cheers,

Marco

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4

Both packages now have much-improved support for non-UTF8 paths on
POSIX systems. There are no significant changes to Windows support in
this release.

system-filepath 0.4.5:
Hackage: http://hackage.haskell.org/package/system-filepath-0.4.5
API reference: https://john-millikin.com/software/haskell-filesystem/reference/system-filepath/0.4.5/

system-fileio 0.3.4:
Hackage: http://hackage.haskell.org/package/system-fileio-0.3.4
API reference: https://john-millikin.com/software/haskell-filesystem/reference/system-fileio/0.3.4/Filesystem/

-----

In GHC  7.2 and later, file path handling in the platform libraries
was changed to treat all paths as text (encoded according to locale).
This does not work well on POSIX systems, because POSIX paths are byte
sequences. There is no guarantee that any particular path will be
valid in the user's locale encoding.

system-filepath and system-fileio were modified to partially support
this new behavior, but because the underlying libraries were unable to
represent certain paths, they were still "broken" when built with GHC
7.2+. The changes in this release mean that they are now fully
compatible (to the best of my knowledge) with GHC 7.2 and 7.4.

Important changes:

* system-filepath has been converted from GHC's escaping rules to its
own, more compatible rules. This lets it support file paths that
cannot be represented in GHC 7.2's escape format.

* The POSIX layer of system-fileio has been completely rewritten to
use the FFI, rather than System.Directory. This allows it to work with
arbitrary POSIX paths, including those that GHC itself cannot handle.
The Windows layer still uses System.Directory, since it seems to work
properly.

* The POSIX implementation of createTree will no longer recurse into
directory symlinks that it does not have permission to remove. This is
a change in behavior from the directory package's implementation. See
http://www.haskell.org/pipermail/haskell-cafe/2012-January/098911.html
for details and the reasoning behind the change. Since Windows does
not support symlinks, I have not modified the Windows implementation
(which uses removeDirectoryRecursive).

Re: [Haskell-cafe] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4

John Millikin wrote:
> In GHC  7.2 and later, file path handling in the platform libraries
> was changed to treat all paths as text (encoded according to locale).
> This does not work well on POSIX systems, because POSIX paths are byte
> sequences. There is no guarantee that any particular path will be
> valid in the user's locale encoding.

I've been dealing with this change too, but my current understanding
is that GHC's handling of encoding for FilePath is documented to allow
"arbitrary undecodable bytes to be round-tripped through it".

As long as FilePaths are read using this file system encoding, any
FilePath should be usable even if it does not match the user's encoding.

For FFI, anything that deals with a FilePath should use this
withFilePath, which GHC contains but doesn't export(?), rather than the
old withCString or withCAString:

import GHC.IO.Encoding (getFileSystemEncoding)
import GHC.Foreign as GHC

withFilePath :: FilePath -> (CString -> IO a) -> IO a
withFilePath fp f = getFileSystemEncoding >>= \enc -> GHC.withCString enc fp f

Code that reads or writes a FilePath to a Handle (including even to
stdout!) must take care to set the right encoding too:

fileEncoding :: Handle -> IO ()
fileEncoding h = hSetEncoding h =<< getFileSystemEncoding

> * system-filepath has been converted from GHC's escaping rules to its
> own, more compatible rules. This lets it support file paths that
> cannot be represented in GHC 7.2's escape format.

I'm dobutful about adding yet another encoding to the mix. Things are
complicated enough already! And in my tests, GHC 7.4's FilePath encoding
does allow arbitrary bytes in FilePaths.

BTW, GHC now also has RawFilePath. Parts of System.Directory could be
usefully written to support that data type too. For example, the parent
directory can be determined. Other things are more difficult to do with
RawFilepath.

--

-- 
see shy jo

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell-cafe] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4

On Sun, Feb 5, 2012 at 18:49, Joey Hess <joey <at> kitenet.net> wrote:
> John Millikin wrote:
>> In GHC  7.2 and later, file path handling in the platform libraries
>> was changed to treat all paths as text (encoded according to locale).
>> This does not work well on POSIX systems, because POSIX paths are byte
>> sequences. There is no guarantee that any particular path will be
>> valid in the user's locale encoding.
>
> I've been dealing with this change too, but my current understanding
> is that GHC's handling of encoding for FilePath is documented to allow
> "arbitrary undecodable bytes to be round-tripped through it".
>
> As long as FilePaths are read using this file system encoding, any
> FilePath should be usable even if it does not match the user's encoding.

That was my understanding also, then QuickCheck found a
counter-example. It turns out that there are cases where a valid path
cannot be roundtripped in the GHC 7.2 encoding.

--------------------------------------------------------------------------
$ ~/ghc-7.0.4/bin/ghci
Prelude> writeFile ".txt" "test"
Prelude> readFile ".txt"
"test"
Prelude>

$ ~/ghc-7.2.1/bin/ghci
Prelude> import System.Directory
Prelude System.Directory> getDirectoryContents "."
["\61347.txt","\61347.txt","..","."]
Prelude System.Directory> readFile "\61347.txt"
*** Exception: .txt: openFile: does not exist (No such file or directory)
Prelude System.Directory>
--------------------------------------------------------------------------

The issue is that  [238,189,178] decodes to 0xEF72, which is within
the 0xEF00-0xEFFF range that GHC uses to represent un-decodable bytes.

> For FFI, anything that deals with a FilePath should use this
> withFilePath, which GHC contains but doesn't export(?), rather than the
> old withCString or withCAString:
>
> import GHC.IO.Encoding (getFileSystemEncoding)
> import GHC.Foreign as GHC
>
> withFilePath :: FilePath -> (CString -> IO a) -> IO a
> withFilePath fp f = getFileSystemEncoding >>= \enc -> GHC.withCString enc fp f

If code uses either withFilePort or withCString, then the filenames
written will depend on the user's locale. This is wrong. Filenames are
either non-encoded text strings (Windows), UTF8 (OSX), or arbitrary
bytes (non-OSX POSIX). They must not change depending on the locale.

> Code that reads or writes a FilePath to a Handle (including even to
> stdout!) must take care to set the right encoding too:
>
> fileEncoding :: Handle -> IO ()
> fileEncoding h = hSetEncoding h =<< getFileSystemEncoding

This is also wrong. A "file path" cannot be written to a handle with
any hope of correct behavior. If it's to be displayed to the user, a
path should be converted to text first, then displayed.

>> * system-filepath has been converted from GHC's escaping rules to its
>> own, more compatible rules. This lets it support file paths that
>> cannot be represented in GHC 7.2's escape format.
>
> I'm dobutful about adding yet another encoding to the mix. Things are
> complicated enough already! And in my tests, GHC 7.4's FilePath encoding
> does allow arbitrary bytes in FilePaths.

Unlike the GHC encoding, this encoding is entirely internal, and
should not change the API's behavior.

> BTW, GHC now also has RawFilePath. Parts of System.Directory could be
> usefully written to support that data type too. For example, the parent
> directory can be determined. Other things are more difficult to do with
> RawFilepath.

This is new in 7.4, and won't be backported, right? I tried compiling
the new "unix" package in 7.2 to get proper file path support, but it
failed with an error about some new language extension.

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell-cafe] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4

John Millikin wrote:
> That was my understanding also, then QuickCheck found a
> counter-example. It turns out that there are cases where a valid path
> cannot be roundtripped in the GHC 7.2 encoding.

> The issue is that  [238,189,178] decodes to 0xEF72, which is within
> the 0xEF00-0xEFFF range that GHC uses to represent un-decodable bytes.

How did you deal with this in system-filepath?

While no code points in the Supplementary Special-purpose Plane are currently
assigned (http://www.unicode.org/roadmaps/ssp/), it is worrying that it's used,
especially if filenames in a non-unicode encoding could be interpreted as
containing characters really within this plane. I wonder why maxBound :: Char
was not increased, and the addtional space after `\1114111' used for the
un-decodable bytes?

> > For FFI, anything that deals with a FilePath should use this
> > withFilePath, which GHC contains but doesn't export(?), rather than the
> > old withCString or withCAString:
> >
> > import GHC.IO.Encoding (getFileSystemEncoding)
> > import GHC.Foreign as GHC
> >
> > withFilePath :: FilePath -> (CString -> IO a) -> IO a
> > withFilePath fp f = getFileSystemEncoding >>= \enc -> GHC.withCString enc fp f
> 
> If code uses either withFilePort or withCString, then the filenames
                      withFilePath?
> written will depend on the user's locale. This is wrong. Filenames are
> either non-encoded text strings (Windows), UTF8 (OSX), or arbitrary
> bytes (non-OSX POSIX). They must not change depending on the locale.

This is exactly how GHC 7.4 handles them. For example:

openDirStream :: FilePath -> IO DirStream
openDirStream name =
  withFilePath name $ \s -> do
    dirp <- throwErrnoPathIfNullRetry "openDirStream" name $ c_opendir s
    return (DirStream dirp)

removeLink :: FilePath -> IO ()
removeLink name =
  withFilePath name $ \s ->
  throwErrnoPathIfMinus1_ "removeLink" name (c_unlink s)

I do not see any locale-dependant behavior in the filename bytes read/written.

> > Code that reads or writes a FilePath to a Handle (including even to
> > stdout!) must take care to set the right encoding too:
> >
> > fileEncoding :: Handle -> IO ()
> > fileEncoding h = hSetEncoding h =<< getFileSystemEncoding
> 
> This is also wrong. A "file path" cannot be written to a handle with
> any hope of correct behavior. If it's to be displayed to the user, a
> path should be converted to text first, then displayed.

Sure it can. See find(1). Its output can be read as FilePaths once the
Handle is set up as above.

If you prefer your program not crash with an encoding error when an
arbitrary FilePath is putStr, but instead perhaps output bytes that are
not valid in the current encoding, that's also a valid choice. You might
be writing a program, like find, that again needs to output any possible
FilePath including badly encoded ones.

Filesystem.Path.CurrentOS.toText is a nice option if you want validly
encoded output though. Thanks for that!

> This is new in 7.4, and won't be backported, right? I tried compiling
> the new "unix" package in 7.2 to get proper file path support, but it
> failed with an error about some new language extension.

The RawFilePath is just a ByteString, so your existing converters for that
in system-filepath might work.

--

-- 
see shy jo

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell-cafe] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4

On Sun, Feb 05, 2012 at 07:17:32PM -0800, John Millikin wrote:
> 
> That was my understanding also, then QuickCheck found a
> counter-example. It turns out that there are cases where a valid path
> cannot be roundtripped in the GHC 7.2 encoding.

This is fixed in GHC 7.4.1.

Thanks
Ian

Re: [Haskell-cafe] ANNOUNCE: system-filepath 0.4.5 and system-fileio 0.3.4

On 06/02/2012 20:32, Ian Lynagh wrote:
> On Sun, Feb 05, 2012 at 07:17:32PM -0800, John Millikin wrote:
>>
>> That was my understanding also, then QuickCheck found a
>> counter-example. It turns out that there are cases where a valid path
>> cannot be roundtripped in the GHC 7.2 encoding.
>
> This is fixed in GHC 7.4.1.

I think we forgot to mention it in the release notes.  Rountripping of 
FilePath is now fully supported.  The commit in question is this:

commit 7e59b6d50ec4a4400e8730bfd8cfc471c1873702
Author: Max Bolingbroke <batterseapower <at> hotmail.com>
Date:   Fri Nov 18 17:45:34 2011 +0000

     Go back to using private-use characters in roundtripping

Which was the result of a long discussion on the glasgow-haskell-users 
mailing list:

 
http://www.haskell.org/pipermail/glasgow-haskell-users/2011-November/021115.html

Separately the unix package added support for undecoded FilePaths 
(RawFilePath), but unfortunately at the same time we started using a new 
extension in GHC 7.4.1 (CApiFFI), which we decided not to document 
because it was still experimental:

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

In retrospect we should have documented this.  It's not like we don't 
normally dump a load of experimental features on our users and then 
change them later 

Cheers,
	Simon