[Haskell] Call for Contributions -- HC&A Report (November 2004 edition)

[Andres Loeh]

Dear Haskellers,

another six months have passed, and another change of editor has
occurred. Half a year usually also is plenty of time for several
productive changes and news to occur within the Haskell community,
and therefore it is time for you to start writing: please
contribute to the forthcoming seventh edition of the

  
  Haskell Communities & Activities Report  
http://www.haskell.org/communities/

Submission deadline: 29 October 2004

  (please send your contributions to [EMAIL PROTECTED], in 
plain ASCII or LaTeX format)
  

The Haskell Communities & Activities Report is a bi-annual overview
of the state of Haskell as well as Haskell-related projects over
the last, and possibly the upcoming 6 months. If you have only
recently been exposed to Haskell, it might be a good idea to browse
the May 2004 edition -- you will find interesting topics
described as well as several starting points and links that may
provide answers to many questions.

The plan is to collect contributions until roughly the end of
October, then start to compile them into a coherent report which
will appear during November. As always, this is a great opportunity
to update your webpages, make new releases, announce of even start
new projects, or to point at some developments you want every
Haskeller to see!

As the purpose of the report is to collect recent or current
activities, we encourage you to update all existing summaries
and reports. We will drop any topics that have not had any
activity for the past year, i.e., since November 2003, but we
would very much prefer you to present an updated description
of the topic. Of course, new entries are more than welcome.
Reports should generally be kept brief and informative, ranging 
from a few sentences to a few hundred words, to keep the whole
report reasonably sized.

Looking forward to your contributions,

Andres (current editor)

--- topics

New suggestions for current hot topics, activities, projects, etc.
are welcome - especially with names and addresses of potential
contacts, but here is a non-exclusive list of likely topics
(see also http://www.haskell.org/communities/topics.html ):

General Haskell developments; Haskell implementations; Haskell  
  extensions; Standardization and documentation; Haskell tutorials,
  howtos and wikis; Organisation of Haskell tool and library
  development; Haskell-related projects and publications; new
  research, fancy tools, long-awaited libraries, cool applications;

Feedback from specialist mailing lists to the Haskell community
  as a whole; Haskell announcements;  all (recent) things Haskell

Announcements: if you've announced anything new on the Haskell
  list over the last six months, you'll want to make sure that is
  reflected in this edition!

Project pings: if you're maintaining a Haskell tool or library or 
  somesuch, you'll want to let everyone know that it is still alive 
  and actively maintained, even if there have been no new additions,
  but all the more if there have been new developments.

Tutorials: if you've fought with some previously undocumented 
  corner of Haskell, and have been kind enough to write down how you
  did manage to build that graphical user interface, or if you've 
  written a tutorial about some useful programming techniques, 
  this is your opportunity to spread the word (short, topic-specific,  
  and hands-on tutorials that only show how to achieve a certain   
  practical task would do a lot to make things easier for new
  Haskellers - please write some!)

Applications: if you've been working quietly, using Haskell for  
  some interesting project or application (commercial or otherwise),
  you might want to let others know about what you're using Haskell
  for, and about your experiences using the existing tools and   
  libraries; are you using Haskell on your job?

  An interesting thread about using Haskell and more generally functional 
  programming for non-Haskell things seems to recur with reasonable
  frequency - why not write a sentence or two about your use of Haskell 
  for our report?

Feedback: if you're on one of the many specialist Haskell mailing
  lists, you'll want to report on whatever progress has been made 
  there (GUI API discussions, library organisation, etc.)


If you're unsure whether a contact for your area of work has come   
forward yet, have a look at the report's potential topics page, or 
get in touch with me.  I have contacted last time's contributors,  
hoping they will volunteer to provide updates of their reports, and
will update the contacts on the topics page fairly regularly.  But 
where you don't yet see contacts listed for your own subject of
interest, you are very welcome to volunteer, or to remind yo

RE: [Haskell] threading mutable state through callbacks

[Simon Marlow]

On 08 October 2004 19:18, Sven Panne wrote:

> Jules Bean wrote:
>> [...] Unfortunately, it's not going to work. It's not going to work
>> because some of the procedures take callbacks, and the callbacks are
>> values of type IO (). I can see two solutions to this:
>> 
>> a) revert to using an IORef [...]
>> b) write the callbacks as values of type StateT Env IO () [...]
> 
> or
> 
> c) Give up any hope of clean semantics and simply use a common hack
> like: 
> 
>{-# NOINLINE myGlobalVar #-}
>myGlobalVar :: IORef Int
>myGlobalVar = unsafePerformIO (newIORef 0)
> 
> My GLUT binding does it happily, as does GHC itself, [snip]

I'd like to add that while the implementation might be a little unsafe,
there's no problem in principle with the semantics of top-level IORefs.
We could add such a thing as a GHC extension, but it would be nice if it
were an instance of a more general-purpose extension.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] elementary tracing for Haskell

[Philip Wadler]

Are there any tools for beginning programmers that give traces of 
Haskell programs?  I want something like the following.  Given the 
defintion

sum [] = 0
sum (x:xs) = x + sum xs
typing
sum [1,2,3]
should yield this trace
sum [1,2,3]
1 + sum [2,3]
1 + 2 + sum [3]
1 + 2 + 3 + sum []
1 + 2 + 3 + 0
1 + 2 + 3
1 + 5
6
I know there are advanced tools like Hat, but (unless I'm missing 
something) they don't yield anything as naive as the above, and it's 
naive users I'm trying to help here.  -- P

PS.  Google search on "Haskell trace" yields lots on Hat, plus the 
following.

The Mystery of Brigadier General Harry L. Haskell
... we have developed a short biography of General Haskell and been 
able to trace the
 locations where he lived, and, possibly, how the medal came into my 
family. ...
 family.phelpsinc.com/branches/haskell/ - 28k - Cached - Similar pages

Philip Wadler, Professor of Theoretical Computer Science
School of Informatics, University of Edinburgh
JCMB, Mayfield Road, Edinburgh EH9 3JZ SCOTLAND
+44 131 650 5174 http://homepages.inf.ed.ac.uk/wadler/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] CFP: TFP04 Symp on Trends in Functional Programming

[Hans-Wolfgang Loidl]

[ The registration page for TFP04 is now open: registration deadline is Nov 1;
  Deadline for paper submissions is Nov 15th.
  Apologies for repeated copies of this message -- HWL ]



  CALL FOR PAPERS

 TFP 2004
Fifth Symposium on
 Trends in Functional Programming

  November 25-26th 2004,
  Ludwig-Maximilians University, Munich, Germany

 http://www.tcs.ifi.lmu.de/~hwloidl/TFP04


The Symposium on Trends in Functional Programming is an international forum
for  researchers with interests  in all  aspects of  functional programming
languages.  It  succeeds TFP03  in  Edinburgh  and  continues the  Scottish
Functional  Programming  Workshop series  from  1999-2002.   Papers on  all
aspects  of  functional  programming  are welcomed,  be  they  theoretical,
implementation-oriented, or  experience papers.  The venue for  this year's
symposium will be Ludwig-Maximilians University in central Munich.


WORKSHOP TOPICS


Papers on any aspect of functional programming are welcomed. Papers on
the following subject areas are particularly welcome:

* design and implementation of functional or declarative languages;
* rich type systems, including type systems for expressing side-effects,
  resource bounds, or other safety properties;
* linear type systems, soft type systems, typeful programming;
* formal aspects of functional programming, semantics, reasoning,
  verification;
* inductive or co-inductive techniques, proof nets;
* mobile-code functional programming languages;
* parallel programming with functional languages, cost models for
  functional programs;
* functional aspects of imperative programming, functional bytecode;
* interoperability with imperative programming languages, calling
  imperative from functional or vice versa;
* type inference algorithms, type error repair, deep types;
* strongly-typed imperative languages with inference;
* optimisation techniques, implementation techniques, and performance 
  measurements;
* experience papers: applications of functional programming or
  functional programming in education.


PROCEEDINGS


As  with the previous  instances of  TFP and  SFP, we  intend to  publish a
high-quality subset of contributions  in the Intellect Trends in Functional
Programming  series. All  speakers attending  the workshop  are  invited to
submit a paper  for the draft proceedings. Revised  papers will be refereed
after  the   symposium  according   to  normal  conference   standards  for
publication by Intellect. This implies (among other things) that:

* the paper should be written in English
* the paper is well written
* the topic of the paper should be stated clearly
* the approach to solve the problem should be outlined clearly
* a detailed discussion of the solution has to be given
* the solution is compared with relevant related work
* there is an abstract, introduction and conclusion.
* the conclusion should summarise the problem, the solution, and how
  this solves the problem.
* papers must not exceed 16 pages.
* the paper should conform to the TFP format
  
* the paper should be submitted as a PostScript or a PDF file using the paper 
  submission page 
  in case of problems with the on-line submission process, send the paper by email
  to the programme chair, Hans-Wolfgang Loidl <[EMAIL PROTECTED]>


DATES


Nov 1st 2004: Registration deadline
Nov 15th 2004:Submission for draft proceedings
Nov 25-26th 2004: Symposium at Ludwig-Maximilians University, Munich
Dec 20th 2004:Submission for referees process
Jan 31st 2005:Notification of acceptance/rejection


PREVIOUS WORKSHOPS


The previous instance  of TFP was held in Edinburgh  2003 and continues the
Scottish Functional  Programming Workshop series with  previous meetings at
Stirling (2001), St.  Andrews (2000),  and Stirling (1999).  The TFP series
  strives to combine  an active  workshop environment
for  presenting latest  research, with  a formal  post-symposium refereeing
process   and  the   publication   of  a   high-profile  proceedings   (see
).  For a review
of past TFP  proceedings, see the July 2003 issue  of the JFP 13(4):823-824
at.Sponsorship   funding
available to us will be used to reduce registration rates for PhD students,
who present proof of affiliation in advance of the symposium.


PROGRAM COMMITTEE

  * Stephen Gilmore, University of Edinburgh
  * Gaetan Hains, Universite d'Orleans
  * Kevin Hammond, University of St Andrews
  * John Hughe

Re: [Haskell] -allow-extension-for-bottom

[Keith Wansbrough]

> Dear Haskell implementors,
> 
> Consider the compilation flag  -allow-extension-for-bottom
> 
> which changes the language meaning so that allows to ignore
> the bottom value. For example, the programs
> 
>(1)   (\ x -> (if p x then  foo (g x)  else  foo (h x)) )
> and
>(2)   (\ x -> foo ((if p x then  g x  else  h x)) )
> 
> become equivalent, and many program transformations become 
> possible.

Is it not the case that with -allow-extension-for-bottom all programs
are equivalent to

  error "Finished"

and hence not just 1000 times faster but infinitely faster
(asymptotically)?

Seriously, I can see that something like this might be of interest,
but the details are not trivial.  For a start, you'd want to allow
refinements only - from _|_ to non-_|_ - rather than in both
directions, to disallow the above transformation.  But then you'd have
to deal with refinement relations rather than equivalences everywhere
in the theory, losing symmetry and making things more complicated.

--KW 8-)

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] -allow-extension-for-bottom

[Serge D. Mechveliani]

Dear Haskell implementors,

Consider the compilation flag  -allow-extension-for-bottom

which changes the language meaning so that allows to ignore
the bottom value. For example, the programs

   (1)   (\ x -> (if p x then  foo (g x)  else  foo (h x)) )
and
   (2)   (\ x -> foo ((if p x then  g x  else  h x)) )

become equivalent, and many program transformations become 
possible.
I suspect that after compiling and running of a program under
-allow-extension-for-bottom  the user will discover many helpful
information about the original program.
For example, under  -allow-extension-for-bottom  it may run 1000 
times faster, and then, the user finds out what to change to have 
a 1000 times speed-up for the original program for the standard 
Haskell. 

Thus, in my particular practical example, it is evident to me that 
it is better to specify (2). But many similar effects are hard to 
find out without compiling under  -allow-extension-for-bottom.

Maybe, the compiler could issue the warnings like, say,

  "Consider factoring `if' in ...   This may improve ... "
?

Copy, please, the answer to  [EMAIL PROTECTED],

-
Serge Mechveliani
[EMAIL PROTECTED]
 



___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: factoring `if'

[Wolfgang Jeltsch]

Serge D. Mechveliani wrote:
> [...]

> People note that in my example of
>
> > > (1)   (\ x -> (if p x then  foo (g x)  else  foo (h x)) ...)
> > >
> > > (2)   (\ x -> foo  ((if p x then  g x  else  h x)) )
>
> p x  may be _|_, and this makes (1) not equivalent to (2).

Yes.  I think, the point is that laziness does not only have something to do
with execution behavior but also with the meaning of expressions as soon as
_|_ values are considered.

> Serge Mechveliani

Wolfgang

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: factoring `if'

[Serge D. Mechveliani]

Thanks for the help!

People note that in my example of 

> > (1)   (\ x -> (if p x then  foo (g x)  else  foo (h x)) ...)
> > 
> > (2)   (\ x -> foo  ((if p x then  g x  else  h x)) )

p x  may be _|_, and this makes (1) not equivalent to (2).

-
Serge Mechveliani
[EMAIL PROTECTED]


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] factoring `if'

[Jeremy Gibbons]

On Mon, 11 Oct 2004, Serge D. Mechveliani wrote:

> How do you think, is the program (1) equivalent to (2)
> in the meaning of Haskell-98 ?

Not at all. If foo is non-strict and p partial, (2) may yield a result
where (1) would not. You identify the possibility yourself: (2) is lazier.

> (1)   (\ x -> (if p x then  foo (g x)  else  foo (h x))
>   where
>   p ... g ... h ... foo ...
>   )
>
> (2)   (\ x -> foo  ((if p x then  g x  else  h x)
> where
> p ... g ... h ... foo ...
>)
>   )
>
> If it is equivalent, then does it make sense for a compiler to
> convert (1) to (2):  to separate a common `factor' of the if-branches
> ?
> The reason for this may be, for example, that the result printing
> of  (f x)  is more `lazy' in (2) than in (1):
> the part of  foo  may print immediately and  (g x) or (h x)  may print
> long after.
> This is a difference in behavior, it does not effect the computation
> meaning.
>
> I have a large program which is easily written in the style of (1),
> (and in many places it sets `case' instead of `if').
> Annoyingly, it prints out in a not a lazy manner.
> It can be rewritten in the form of (2), but with effort, and it will
> look less plain.
> So, maybe, this is a business of a compiler?

[EMAIL PROTECTED]
  Oxford University Computing Laboratory,TEL: +44 1865 283508
  Wolfson Building, Parks Road,  FAX: +44 1865 273839
  Oxford OX1 3QD, UK.
  URL: http://www.comlab.ox.ac.uk/oucl/people/jeremy.gibbons.html

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] factoring `if'

[Colin Runciman]

Serge,
How do you think, is the program (1) equivalent to (2) 
in the meaning of Haskell-98 ?

(1)   (\ x -> (if p x then  foo (g x)  else  foo (h x))
 where
 p ... g ... h ... foo ...
 )
(2)   (\ x -> foo  ((if p x then  g x  else  h x)
   where
   p ... g ... h ... foo ...
  )
 )
 

Both examples are illegal -- there are no where-expressions in Haskell, 
only where-equations. 

Ignoring the local definition part, however, the answer is no.  Lifting 
foo out of the branches of the conditional is only valid if foo is strict.

Colin R

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] factoring `if'

[Serge D. Mechveliani]

Dear Haskell implementors,

How do you think, is the program (1) equivalent to (2) 
in the meaning of Haskell-98 ?

(1)   (\ x -> (if p x then  foo (g x)  else  foo (h x))
  where
  p ... g ... h ... foo ...
  )

(2)   (\ x -> foo  ((if p x then  g x  else  h x)
where
p ... g ... h ... foo ...
   )
  )

If it is equivalent, then does it make sense for a compiler to 
convert (1) to (2):  to separate a common `factor' of the if-branches
?
The reason for this may be, for example, that the result printing
of  (f x)  is more `lazy' in (2) than in (1):
the part of  foo  may print immediately and  (g x) or (h x)  may print
long after.
This is a difference in behavior, it does not effect the computation
meaning.

I have a large program which is easily written in the style of (1),
(and in many places it sets `case' instead of `if').  
Annoyingly, it prints out in a not a lazy manner.
It can be rewritten in the form of (2), but with effort, and it will
look less plain.
So, maybe, this is a business of a compiler?

Copy, please, the possible answer to  [EMAIL PROTECTED]

-
Serge Mechveliani
[EMAIL PROTECTED]
 
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: elementary tracing for Haskell

[Colin Runciman]

Phil,
Are there any tools for beginning programmers that give traces of 
Haskell programs?  I want something like the following.  Given the 
defintion

sum [] = 0
sum (x:xs) = x + sum xs
typing
sum [1,2,3]
should yield this trace
sum [1,2,3]
1 + sum [2,3]
1 + 2 + sum [3]
1 + 2 + 3 + sum []
1 + 2 + 3 + 0
1 + 2 + 3
1 + 5
6
I know there are advanced tools like Hat, but (unless I'm missing 
something) they don't yield anything as naive as the above, and it's 
naive users I'm trying to help here.  -- P
There is a Hat tool called hat-anim that can do this kind of thing.  It 
was developed by Tom Davie as a student project.  It is not part of the 
current "official release" of Hat but is included in the CVS version.  
Tom is now a PhD student at Canterbury ([EMAIL PROTECTED]), supervised by 
Olaf Chitil ([EMAIL PROTECTED]).

Regards
Colin R
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell