[Haskell] (no subject)

[lel416]

Can u still purchase general admission tkts

Sent from my iPhone
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] (no subject)

[Clint Moore]

smime.p7s
Description: S/MIME cryptographic signature
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Clint Moore]

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] (no subject)

[Alexander Kantardjiev]

wow look into this http://www.stenews.net/biz/?read=3610300


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Mark Snyder]

http://isukeworld.com/test/cat13/02efpk.html";> 
http://isukeworld.com/test/cat13/02efpk.html___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Dan Burton]

Haskellers,

I'm pleased to announce the first public release of NetSpec, a little
Network library to simplify networking tasks that involve a fixed number of
connections, using Erlang-esque send and receive primitives.

Check out the docs: http://hackage.haskell.org/package/netspec
And the repo on github (with examples): https://github.com/DanBurton/netspec

--
Dan Burton
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Benjamin L. Russell]

http://www.myvisionview.com/images/scan.php

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Benjamin L. Russell]

http://poorogies.com/wp-content/plugins/scan.php

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Stephanie Weirich]

=
Call for Participation

   ACM SIGPLAN Haskell Symposium 2009

  http://haskell.org/haskell-symposium/2009/

   Edinburgh, Scotland, 3 September 2009
=

 The ACM SIGPLAN Haskell Symposium 2009 will be co-located with the
   2009 International Conference on Functional Programming (ICFP).

   The purpose of the Haskell Symposium is to discuss experiences with
   Haskell and future developments for the language. The scope of the
   symposium includes all aspects of the design, semantics, theory,
   application, implementation, and teaching of Haskell.

Preliminary program:
 * http://haskell.org/haskell-symposium/2009/schedule.html

REGISTRATION IS NOW OPEN:
 * http://www.regmaster.com/conf/icfp2009.html
 * Early registration deadline: July 30, 2009

Local arrangements (including travel and accommodation):
 * http://www.haskell.org/haskellwiki/ICFP_2009_Local_Arrangements
 * Conference reservation/rate deadline: July 20, 2009
 * ICFP09 & Haskell 09 coincides with the final week of the Edinburgh
   Festival, one of the premier arts and cultural festivals in the
   world.  The opportunity to attend the Festival is a plus!  Due to
   the popularity of Edinburgh during the festival period, we
   strongly recommend booking accommodation early.

See you in Edinburgh,

  Stephanie Weirich
  Haskell 2009 Program Chair

=

p.s., don't forget about the ICFP Programming Contest this weekend!!

 * http://www.icfpcontest.org
 * Friday, June 26 to Monday, June 29
 * Organizers: Computer Systems Design Laboratory (University of  
Kansas)


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Oege de Moor]

To: 
Subject: 10 jobs in declarative programming

   TEN DECLARATIVE PROGRAMMING CONSULTANTS SOUGHT


Semmle and LogicBlox are creating a platform for declarative
programming in Datalog, a pure logic programming language.
Semmle is based in Oxford, headed by Oege de Moor;
LogicBlox is based in Atlanta, headed by Molham Aref.

To configure our solution at a number of large corporate
clients in the retail, insurance and software quality
industries, we urgently require 10 full-time staff to 
act as consultants. These consultants will work with 
clients to write custom queries in Datalog, and to create 
user interfaces in a declarative framework.

This is a unique opportunity to change the way enterprise 
software is constructed, and to become part of the revolution
to adopt declarative programming in mainstream applications.

Semmle and LogicBlox offer a vibrant, intellectually
stimulating environment to work on exciting applications of
cutting-edge technology. 

Requirements:
You must be passionate about simplifying the construction
of complex software systems. A good undergraduate degree in 
computer science or related discipline is necessary. Substantial 
programming experience, and familarity with declarative 
programming (both functional and logic) is a must. Some 
travel will be required.

Starting date and renumeration:
The openings are available immediately. The renumeration depends
on experience and qualifications; it is especially competitive 
for recent graduates.

Further information:
To find out more about this opportunity, write to
Oege de Moor (o...@semmle.com) and Molham Aref 
(mol...@logicblox.com).

To apply:
Send a CV and the names of three referees (at least two of
whom must be able to comment on your programming abilities)
to recr...@semmle.com, by June 12.


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Samir Genaim]

   *
   * The Fourth International Workshop *
   * on*
   *   Programming Language Interference and Dependence*
   *   *
   * co-located with LOPSTR'08, PPDP'08 and SAS'08 *
   *   *
   *   15 July, 2008, Valencia, Spain  *
   *   *
   *  Venue: The Technical University of Valencia  *
   *   *
   *  2nd Call for Contributions   *
   *   *
   *   http://www.clip.dia.fi.upm.es/Conferences/PLID08*
   *   *
   *



Important Dates
===

Expression of interest  June 1,  2008
Extended abstract   June 15, 2008
WorkshopJuly 15, 2008



Workshop Description


Interference and  dependence are  closely related concepts,  the first
being the observable phenomenon  connected to the second. Interference
essentially means that behaviour of some parts of a dynamic system may
influence  the behaviour  of other  parts of  the  system.  Dependence
specifies the  relation between the  semantics of sub-components  of a
dynamic system.

Discovering,  measuring and controlling  interference is  essential in
many aspects  of modern computer  science, in particular  in security,
program analysis  and verification, debugging,  systems specification,
model  checking,   program  manipulation,  program   slicing,  reverse
engineering,   data   mining,   distributed  databases   and   systems
biology. Doing  these things  requires theories, models  and semantics
for interference and  dependence, as well as algorithms  and tools for
analysis and reasoning about interference and dependence.

The aim of this workshop is to gather together the community of people
that study  dependence and interference  from the different  points of
view in order  to generate new possible research  directions.  PLID is
devoted to bridging all these communities and assisting work towards a
common goal, providing the appropriate environment for reasoning about
the state of the art in interference and dependence.

Topics of interest include but are not limited to:

 * Security against unwanted interference and dependence
 * Models and theories of program interference
 * Algorithms for reducing or removing interference or for
   ameliorating its effects
 * Theory and foundations of program slicing and related dependence
   analyses
 * Resource declassification theories
 * Semantics of dependence and interference
 * Analyses based on interference and dependence
 * Abstract interpretation for dependence and interference
 * Dependence and interference in specifications
 * Slicing models and specifications
 * Interaction between dependence and refinement



Keynote Speaker
===

Gilles Barthe, IMDEA-software (Madrid, Spain)



Submission
==

The workshop welcomes contributions of  on-going work and ideas in the
field  of dependence and  interference.  Those  who are  interested in
having a  talk at the  workshop and/or discussing issues  related with
these  subjects are  invited to  send your  expression of  interest to
Samir Genaim (samir at clip.dia.fi.upm.es) before June 1st, 2008.

There will  be no  formal publication of  papers.  A web-page  will be
organised  collecting  all   the  workshop  contributions.   Submitted
extended abstracts should be of at most 10 pages LNCS-style and should
be sent before June 15th 2008.



Program Committee
=

David Clark Kings College, London, UK
Sebastian Danicic   University of London, UK
Samir Genaim (chair)Technical University of Madrid, Spain
Roberto Giacobazzi  University of Verona, Italy
Daniele Gorla   University of Roma, Italy
Sebastian Hunt  City University, London, UK
Herbert WiklickyImperial College, London, UK
Steve Zdancewic University of Pennsylvania, USA



Local organization chair


Christophe Joubert  Technical University of Valencia / DSIC
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] (no subject)

[Chris Mears]

"Tomi Owens" <[EMAIL PROTECTED]> writes:

> Hi there. I'm a teacher of Maths and am working my way through the
> Euler Project problems for fun. I have mostly been using Basic, but
> have read up about Haskell and think it looks like a sensible way to
> solve many of the problems.

It certainly is.

> Prelude> let f (a,b) = a * floor (10/b)

>From the floor and the rest of your message, it looks like you want
truncating integer division here.  So, instead of floor and (/), use
div.

let f (a,b) = a * 10 `div` b

With that change the rest of your program should work.

The other replies explain why the interpreter couldn't figure out which
type to use.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] (no subject)

[Brent Yorgey]

On 9/5/07, Tomi Owens <[EMAIL PROTECTED]> wrote:
>
> Hi there. I'm a teacher of Maths and am working my way through the Euler
> Project problems for fun. I have mostly been using Basic, but have read up
> about Haskell and think it looks like a sensible way to solve many of the
> problems.
>
>
I see others have already answered your immediate question; however, I
thought I'd throw in some general comments.  Project Euler is indeed a great
way to learn some Haskell, but you will certainly run into problems with the
numeric types (as you already have).  Haskell is very picky about numeric
types (for good reason!), and until you get used to it, it can be a big pain
and a source of some confusion.  I highly recommend that you read about type
classes, and you may also want to read something like
http://haskell.org/haskellwiki/Converting_numbers.  As someone else already
mentioned, asking questions in the #haskell IRC channel on
irc.freenode.netis also an excellent way to learn things and get past
error messages and
things like this which are probably simple, but you just can't figure out.

Hope this helps,
-Brent
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] (no subject)

[Chaddaï Fouché]

2007/9/5, Tomi Owens <[EMAIL PROTECTED]>:
>  So now I try to apply the function to the list:
>
>  Prelude> map (f) [(a2+b2,a)| a <- [1..4] , b<- [1..4], a2+b2<20, b<=a]
>
>  and I get this result:
>
>  :1:5:
> Ambiguous type variable `t' in the constraints:
>   `Integral t' arising from use of `f' at :1:5
>   `RealFrac t' arising from use of `f' at :1:5
> Probable fix: add a type signature that fixes these type variable(s)
>
>
>  I'm sorry, but I don't quite get how to set the type signature and how it
> will apply to my function...
>

It's because f need a real, not an integer as the second element of
its parameter (since it use (/) in (1/b)), and as it also needs an
integer as it's first, the type checker don't know what the type of a
should be (it can't be both an integer and a floating value at the
same time).
The easiest IMO is to keep a as an integer, but use "fromIntegral" to
convert it to a real in the second part of the tuple :

map f [( a^2+b^2, fromIntegral a) | a <- [1..4] , b<- [1..4], a^2+b^2<20, b<=a]

You would get more help and faster from an IRC channel like
[EMAIL PROTECTED] though.

-- 
Jedaï
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] (no subject)

[Brandon S. Allbery KF8NH]

On Sep 5, 2007, at 21:10 , Tomi Owens wrote:


Prelude> let f (a,b) = a * floor (10/b)
Prelude> f(2,5)
4

This function works just as I want it to.

Now I try creating a list:

Prelude> [(a2+b2,a)| a <- [1..4] , b<- [1..4], a2+b2<20, b<=a]
[(2,1),(5,2),(8,2),(10,3),(13,3),(18,3),(17,4)]

and this works
So now I try to apply the function to the list:

Prelude> map (f) [(a2+b2,a)| a <- [1..4] , b<- [1..4], a2+b2<20, b<=a]

and I get this result:

:1:5:
   Ambiguous type variable `t' in the constraints:
 `Integral t' arising from use of `f' at :1:5
 `RealFrac t' arising from use of `f' at :1:5
   Probable fix: add a type signature that fixes these type variable 
(s)



I'm sorry, but I don't quite get how to set the type signature and  
how it will apply to my function...


The problem here is that (assuming the a\sup{2} etc. are actually  
a^2) the (^) operator expects and returns Integrals, but (/) requires  
a RealFrac.  Thus, the type of your list comprehension is inferred to  
be [(Integer,Integer)] but needs to be RealFrac a => [(Integer,a)]  
(or, more simply, [(Integer,Double)].


  Prelude> let f (a,b) = a * floor (10/b)
  Prelude> :t f
  f :: (RealFrac t1, Integral t) => (t, t1) -> t
  Prelude> let v :: [(Integer,Double)]; v = [(a^2 + b^2,fromIntegral  
a) | a <- [1..4], b <- [1..4], a^2 + b^2 < 20, b <= a]

  Prelude> :t v
  v :: [(Integer, Double)]
  Prelude> map f v
  [20,25,40,30,433329,54,425000]

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Tomi Owens]

Hi there. I'm a teacher of Maths and am working my way through the Euler
Project problems for fun. I have mostly been using Basic, but have read
up about Haskell and think it looks like a sensible way to solve many of
the problems.

OK, so I've downloaded GHCi and am trying to teach myself.

So far I have done this:

  ___ ___ _

 / _ \ /\  /\/ __(_)

/ /_\// /_/ / /  | |  GHC Interactive, version 6.6.1, for Haskell 98.

/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

Loading package base ... linking ... done.

Prelude> let f (a,b) = a * floor (10/b)

Prelude> f(2,5)

4

This function works just as I want it to.

Now I try creating a list:

Prelude> [(a2+b2,a)| a <- [1..4] , b<- [1..4], a2+b2<20, b<=a]

[(2,1),(5,2),(8,2),(10,3),(13,3),(18,3),(17,4)]

and this works

So now I try to apply the function to the list:

Prelude> map (f) [(a2+b2,a)| a <- [1..4] , b<- [1..4], a2+b2<20, b<=a]

and I get this result:

:1:5:

   Ambiguous type variable `t' in the constraints:

 `Integral t' arising from use of `f' at :1:5

 `RealFrac t' arising from use of `f' at :1:5

   Probable fix: add a type signature that fixes these type variable(s)

I'm sorry, but I don't quite get how to set the type signature and how
it will apply to my function...

Thanks,

Tomi


Department for Education, Sport and Culture E Mail
This message is for the named person's use only.  It may contain
confidential, proprietary or legally privileged information.  No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and all 
copies of it from your system, destroy any hard copies of it and notify the 
sender.  You must not, directly or indirectly, use, disclose, distribute, 
print, or copy any part of this message if you are not the intended recipient. 
The Department for Education, Sport and Culture and any of its establishments 
each reserve the right to monitor all e-mail communications through its 
networks. 



Any views expressed in this message are those of the individual sender, except 
where the message states otherwise and the sender is authorised to state them 
to be the views of any such entity. 



The Department for Education, Sport and Culture shall not be liable to the 
recipient or any third party for any loss or damage, however it appears, from 
this e-mail or its content. This includes loss or damage caused by viruses. It 
is the responsibility of the recipient to ensure that the opening of this 
message and its attachments shall not adversely affect systems or data.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Boyko Bantchev]

Hi all!

The List module provides isPrefixOf, isSuffixOf, and --
since
recently -- isInfixOf, to check whether a list is a prefix,
a suffix, or an infix to another list.  Similarly, we have
inits and tails to obtain the prefixes and the suffixes of
a list, but there is no standard function that would return
a list of infixes.  For reasons of symmetry, perhaps it is
worth having a function in List returning, say, a list of
infixes of fixed length, such as e.g.,

infixes n as = map (take n) $ take (length as - n + 1)
(tails as)

Or, instead, there might be included a function that lists
all
infixes lexicographically  (map (tail . inits) . tails)
or perhaps otherwise, e.g. in the order of
increasing/decreasing
lengths.  (In the latter case, the result might be a list of
lists of same-length infixes each.)

What do you think?

Regards,
  Boyko

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Ralf Lammel]

[Foundations of AOP and AO languages have benefitted from the functional 
programming community for a while now. Haskellers, please have a look. Thanks! 
Ralf]

   Call For Papers
 FOAL: Foundations of Aspect-Oriented Languages 2007

A one day workshop affiliated with AOSD 2007 in Vancouver, British Columbia.

Submission Deadline: 23:00 GMT, 10 January 2007
Notification of Acceptance: 2 February 2007
Final Versions of Papers Due:   1 March 2007
Workshop:   13 March 2007

Themes and Goals

FOAL is a forum for research in foundations of aspect-oriented programming 
languages. Areas of interest include but are not limited to:

 * Semantics of aspect-oriented languages
 * Specification and verification for such languages
 * Type systems
 * Static analysis
 * Theory of testing
 * Theory of aspect composition
 * Theory of aspect translation (compilation) and rewriting

The workshop aims to foster work in foundations, including formal studies, 
promote the exchange of ideas, and encourage workers in the semantics and 
formal methods communities to do research in the area of aspect-oriented 
programming languages. All theoretical and foundational studies of this topic 
are welcome.

The goals of FOAL are to:

 * Make progress on the foundations of aspect-oriented programming
   languages.
 * Exchange ideas about semantics and formal methods for
   aspect-oriented programming languages.
 * Foster interest within the programming language theory and types
   communities in aspect-oriented programming languages.
 * Foster interest within the formal methods community in
   aspect-oriented programming and the problems of reasoning about
   aspect-oriented programs.

Workshop Format

The planned workshop format is primarily presentation of papers and group 
discussion. Talks will come in three categories: long (30 minutes plus 15 
minutes of discussion), regular (20 minutes plus 5 minutes of
discussion) and short (7 minutes plus 3 minutes of discussion). The short talks 
will allow for presentations of topics for which results are not yet available, 
perhaps for researchers who are seeking feedback on ideas or seek 
collaborations.

We also plan to ensure sufficient time for discussion of each presentation by 
limiting the overall number of talks.

Submissions

Invitation to the workshop will be based on papers selected by the program 
committee; those wishing to attend but not having a paper to submit should 
contact the organizers directly to see if there is sufficient space in the 
workshop.

FOAL solicits long, regular, and short papers on all areas of formal 
foundations of AOP languages. Submissions will be read by the program committee 
and designated reviewers. Papers will be selected for long, regular, and short 
presentation at the workshop based on their length, scientific merit, 
innovation, readability, and relevance. Papers previously published or already 
being reviewed by another conference are not eligible. Some papers may not be 
selected for presentation, and some may be selected for presentation in shorter 
talks than their paper length would otherwise command. We will limit the length 
of paper presentations and the number of papers presented to make sure that 
there is enough time for discussion.

Papers presented at the workshop will be included in a technical report (from 
Iowa State University). Authors will retain their own copyright to the papers. 
Publication of papers at other venues will thus remain possible. We will also 
investigate having a special issue of a journal for revisions of selected 
papers after the workshop.

Authors should note the following details:

 * Submissions are due no later than 23:00 GMT, 10 January 2007.
   (This is a firm deadline.)
 * Authors must indicate whether they wish to be considered for a
   long, regular, or short presentation.
 * Papers for long presentations must not exceed 10 pages in length;
   those for regular presentations must not exceed 7 pages in length,
   and those for short presentations must not exceed 3 pages in length.
 * Some papers may not be selected for presentation, and some may be
   selected for presentation in shorter talks than requested.
 * We encourage use of the ACM Conference format
    for
   submissions, as this will be required for accepted papers. You
   must add page numbers (which are not part of the standard format)
   to your submissions, to make adding comments easier.
 * Submissions are to be made to the following URL:
   http://continue.cs.brown.edu/servlets/foal07/continue.ss

We will notify the corresponding author of papers that are selected for 
presentation at the workshop by 2 February 2006. Early registration for AOSD 
(you must register for AOSD to attend the workshop) is 9 F

[Haskell] (no subject)

[John C. Peterson]

From: John Peterson <[EMAIL PROTECTED]>
To: haskell@haskell.org
Subject: Blown disk on haskell.org

Sorry for the downtime - haskell.org lost a disk today.  Everything is
back to normal (I hope).  If you have software installed there, we
upgraded to a new OS.  Hope this doesn't break anything!

   John
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Duncan Coutts]

Gtk2Hs - A Haskell GUI library based on the Gtk+ GUI Toolkit.
 
Version 0.9.7.1 is now available from:
 
http://gtk2hs.sourceforge.net/

This release is only needed for Windows users. If you have version 0.9.7
working there is no need to upgrade.

Source and binary packages are available for Windows.
There are binary packages for Gtk+ 2.4.x and 2.6.x. The binary packages require
GHC 6.2.2.

You may wish to use Gtk+ 2.6 since it follows the Windows native look
and themes whereas Gtk+ 2.4 did not.

Installation on Windows is fairly straightforward. There is an installer
for Gtk+ on Windows and installing Gtk2Hs just involves unzipping and
running a batch file. Instructions are here:
http://gtk2hs.sourceforge.net/archives/2005/02/17/installing-on-windows/

For future Gtk2Hs releases we hope to provide an MSI installer to make
it even easier.

Changes since 0.9.7: 
  * build fixes for Windows
  * almost all modules now carry LGPL 2.1 license
  * a couple of extra functions are now bound

Other changes and news since the last release announcement:
  * there is an introductory article by Kenneth Hoste in the first
issue of The Monad.Reader:
  http://www.haskell.org/hawiki/TheMonadReader_2fIssueOne
  * a complete website redesign
  * many new screenshots: 
  http://sourceforge.net/project/screenshots.php?group_id=49207
  * packages of version 0.9.7 are available for Gentoo and FreeBSD

Please report all problems to [EMAIL PROTECTED] .
Contributions and feedback are also most welcome.

Duncan
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] (no subject)

[Javier García-Vivó Albors]

Hi.
I'm trying to use the hs-plugins with ghci for Windows. Do you know how to do
it? I've tried several ways to install the and I haven't managed it. Thanks for
your help


This message was sent using IMP, the Internet Messaging Program.

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: Module Initialisation? (was Re: [Haskell] (no subject))

[Remi Turk]

On Sun, Oct 17, 2004 at 07:20:28PM +0100, Ben Rudiak-Gould wrote:
> Remi Turk wrote:
> 
> > On Sun, Oct 17, 2004 at 05:11:02PM +0100, Ben Rudiak-Gould wrote:
> >
> >> I don't think there's any problem with
> >>
> >> type MVar = STMVar RealWorld
> >>
> >> newMVar :: a -> ST s (STMVar s a)
> >> withMVar :: STMVar s a -> (a -> ST s b) -> ST s b ...
> >>
> >> For that matter it seems like we could (should?) have
> >>
> >> forkST :: ST s () -> ST s (STThreadId s) forkIO = forkST
> >
> > But what semantics would they have? It cannot be the normal
> > concurrency as AFAIK runST is supposed to be deterministic.
> 
> Okay, so I'm being silly. Forget forkST then. But STMVar is still okay, 
> isn't it? The only MVars you could use in a state thread would be those 

I won't ever remind you of your being silly if you tell me about
the current state of your implicit-(parameter|return)-IO story ;)

STMVar does indeed still seem okay, except that I have no idea if
it actually makes any sense outside of IO.
(That is: newSTMVar x = unsafeIOToST (newMVar x) seems a bit
pointless and might be the actual way it needs to be implemented.
Has a vague feeling of being silly too now...)

By the way, I'm still in favour of `type IO a = ST RealWorld a':
It just seems wrong to either "let's just make it IO" or having
to sprinkle stToIO's around...

> you'd created in the same state thread, and without forkST they can't be 
> accessed in a nondeterministic way. Their presence is pointless, true, 
> but at least not unsafe.
> 
> It does seem a bit of a hack, but it still seems preferable to the other 
> alternatives currently on the table (namely unrestricted IO, a new 
> SafeIO, or unsafeIOToST.newMVar).
> 
> -- Ben

I'm waiting to be convinced either way ;)

Groetjes,
Remi

-- 
Nobody can be exactly like me. Even I have trouble doing it.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Module Initialisation? (was Re: [Haskell] (no subject))

[Ben Rudiak-Gould]

Remi Turk wrote:
 On Sun, Oct 17, 2004 at 05:11:02PM +0100, Ben Rudiak-Gould wrote:
> I don't think there's any problem with
>
> type MVar = STMVar RealWorld
>
> newMVar :: a -> ST s (STMVar s a)
>> withMVar :: STMVar s a -> (a -> ST s b) -> ST s b ...
>
> For that matter it seems like we could (should?) have
>
> forkST :: ST s () -> ST s (STThreadId s) forkIO = forkST
 But what semantics would they have? It cannot be the normal
 concurrency as AFAIK runST is supposed to be deterministic.
Okay, so I'm being silly. Forget forkST then. But STMVar is still okay, 
isn't it? The only MVars you could use in a state thread would be those 
you'd created in the same state thread, and without forkST they can't be 
accessed in a nondeterministic way. Their presence is pointless, true, 
but at least not unsafe.

It does seem a bit of a hack, but it still seems preferable to the other 
alternatives currently on the table (namely unrestricted IO, a new 
SafeIO, or unsafeIOToST.newMVar).

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

Re: Module Initialisation? (was Re: [Haskell] (no subject))

[Adrian Hey]

On Sunday 17 Oct 2004 4:45 am, Wolfgang Thaller wrote:
> Adrian Hey wrote:
> > I'm puzzled about this idea of "module init action" in a declarative
> > language. Perhaps, if it's desirable to have some module initialisation
> > applied to a module if anything from it is used, the way to do this
> > would
> > be to have a reserved identifier specially for the purpose, like
> > "main", but at the module level. (Though this idea still seems a
> > bit strange to me).
>
> I don't see what's so strange about that.

What's strange about it IMHO is that at the moment the mere presence of
some definition in a module has no effect on actual programs. What counts
is whether or not defined thing is actually connected to the top
level main via some chain of explicit (I.E. named) dependency. This
is a property I would like to preserve. If I've understood the proposal
correctly, we'd lose this.

> At least, it's not any
> stranger than on-demand execution of IO actions in a pure functional
> language. And the toplevel "<-" is definitely a natural syntax for
> that.

True, but maybe this isn't neccessary, and even if it is, performing the
IO creation acts only if the created thing is actually used by a
program still seems the lesser of two evils to me. Of course "used"
could mean one of at least two different things..
 1- The compiler does some kind of dependency analysis and mops up
all referenced "things which must be created" into some kind of
pre-main action.
 2- Things which must be created are just compiled into some kind of
thunk which gets reduced (post-main), if and when it is actually
required by a running program.

Option 1 seems like quite a difficult thing to implement, but does
have the advantage that well defined semantics could be given to
arbitrary IO operations. It also has the disadvantage that a some
of these may be redundant (just because something is referenced
doesn't imply that is will actually be used in any given program
run).

Option 2 seems easier to implement and is nice and lazy, but
suffers from semantic ambiguity if arbitrary IO operations
are allowed (encouraged). But do we need to do this? I'm
begining think maybe we don't. The only reason it seems like
we do is because currently the only way of creating IORefs
and wotnot is via the IO monad, but this need not be so IMO.

> You're taking away a feature I want to use.

Sorry, I didn't mean to deprive you of something you would find useful.
But maybe it should be considered as a separate issue. It's not clear to
me how the compiler (or Joe programmer for that matter) would determine
and/or control which modules initialisation actions would be executed or
not, if there's no obvious "connection" to the top level main.

> 1) Initialising global IORefs is a good thing, no matter when it's
> actually done.

Yes, the hypothetical SafeIO monad allows you to do this (what you can't
do is read or write IORefs).

> 2) Being able to initialize things at program startup is a good thing,
> even if they're not explicitly referred to.

Well here is where we disagree I think. Not that I think this is a bad
thing as such, but the rules that determine which modules init actions
do or don't get invoked seem quite unclear to me if there's no requirement
that they are referenced from "main", directly or indirectly.

But maybe you could clarify what you have in mind?

Regards
--
Adrian Hey

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

Re: Module Initialisation? (was Re: [Haskell] (no subject))

[Remi Turk]

On Sun, Oct 17, 2004 at 05:11:02PM +0100, Ben Rudiak-Gould wrote:
> Remi Turk wrote:
> 
> >It definitely sounds nice, but is it actually possible to generalize e.g. 
> >MVar from "RealWorld" to "forall s" or are we always going to have to say:
> >
> >v <- unsafeIOToST (newMVar / newChan ... )
> > 
> >
> I hadn't thought of that, but I don't think there's any problem with
> 
>type MVar = STMVar RealWorld
> 
>newMVar  :: a -> ST s (STMVar s a)
>withMVar :: STMVar s a -> (a -> ST s b) -> ST s b
>...
> 
> For that matter it seems like we could (should?) have
> 
>forkST :: ST s () -> ST s (STThreadId s)
>forkIO = forkST
> 
> and so on.
> 
> -- Ben

But what semantics would they have?
It cannot be the normal concurrency as
AFAIK runST is supposed to be deterministic.

Groetjes,
Remi

-- 
Nobody can be exactly like me. Even I have trouble doing it.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Module Initialisation? (was Re: [Haskell] (no subject))

[Ben Rudiak-Gould]

Remi Turk wrote:
It definitely sounds nice, but is it actually possible to generalize e.g. MVar from "RealWorld" 
to "forall s" or are we always going to have to say:
v <- unsafeIOToST (newMVar / newChan ... )
 

I hadn't thought of that, but I don't think there's any problem with
   type MVar = STMVar RealWorld
   newMVar  :: a -> ST s (STMVar s a)
   withMVar :: STMVar s a -> (a -> ST s b) -> ST s b
   ...
For that matter it seems like we could (should?) have
   forkST :: ST s () -> ST s (STThreadId s)
   forkIO = forkST
and so on.
-- Ben
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Module Initialisation? (was Re: [Haskell] (no subject))

[Remi Turk]

On Sun, Oct 17, 2004 at 01:53:22PM +0100, Ben Rudiak-Gould wrote:
[snip]
> >> Since a lot of the concerns expressed about this seem to centre
> >> around possible abuse of arbitrary IO operations in these top level
> >> constructions, maybe the problem could be addressed by insisting
> >> that a restricted monad was used, call it SafeIO say.
> 
> How about (forall s. ST s)?
> 
> We can require module init actions to have a type (forall s. ST s a) 
> instead of IO a. The compiler or RTS wraps the actions with stToIO 
> (which is a safe function) before executing them.
> 
> Benefits:
> 
>* It's just as easy as before to allocate global refs (and global 
> mutable arrays).
>* It's still possible to perform arbitrary IO actions (e.g. FFI 
> calls), but you have to wrap them in unsafeIOToST -- a good thing since 
> they really are unsafe. unsafeIOToST is much safer than unsafePerformIO 
> when used in this way.
> 
> Problems:
> 
>* stToIO (newSTRef 'x') doesn't have type IO (IORef Char).
> 
> This problem can be solved by adopting a reform that I've wanted for a 
> long time anyway: make IO, IORef, etc. aliases for (ST RealWorld), 
> (STRef RealWorld), etc. instead of completely different types. Then 
> stToIO is the identity function and we only need a single set of 
> state-thread functions instead of the parallel IO and ST equivalents 
> that we have currently.

It definitely sounds nice, but is it actually possible to
generalize e.g. MVar from "RealWorld" to "forall s" or are we
always going to have to say:

v <- unsafeIOToST (newMVar / newChan ... )

GHC's definition:
data MVar a = MVar (MVar# RealWorld a)


-- 
Nobody can be exactly like me. Even I have trouble doing it.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: Module Initialisation? (was Re: [Haskell] (no subject))

[Ben Rudiak-Gould]

Wolfgang Thaller wrote:
 Adrian Hey wrote:
> I'm puzzled about this idea of "module init action" in a
> declarative language. Perhaps, if it's desirable to have some
> module initialisation applied to a module if anything from it is
> used, the way to do this would be to have a reserved identifier
> specially for the purpose, like "main", but at the module level.
> (Though this idea still seems a bit strange to me).
 I don't see what's so strange about that.
I think his point is that some module init actions are run while others 
aren't, and it's not entirely clear how the distinction should be made. 
Currently it's possible to think of import declarations as simply 
bringing names into scope, but in the presence of module init actions 
import declarations have side effects.

In many languages you can refer to a function in another module by its 
fully qualified name even if that module hasn't been explicitly 
imported. This is a nice feature and I'd like to see it added to 
Haskell, but there's a tension between it and the module-init-action 
feature as currently specified: we would have to look through the whole 
program source for fully-qualified names in order to figure out which 
module actions will be run.

There would be no semantic problem if all module actions were always 
run, but this is impossible because it would have to include modules not 
installed on the user's machine, as well as modules that haven't even 
been written yet.

There is also no semantic problem if only "safe" actions like newIORef 
are used, but the current proposal provides no static guarantee of this.

In any case, I have an idea of how to solve this problem -- see below.
> Since a lot of the concerns expressed about this seem to centre
> around possible abuse of arbitrary IO operations in these top level
> constructions, maybe the problem could be addressed by insisting
> that a restricted monad was used, call it SafeIO say.
How about (forall s. ST s)?
We can require module init actions to have a type (forall s. ST s a) 
instead of IO a. The compiler or RTS wraps the actions with stToIO 
(which is a safe function) before executing them.

Benefits:
   * It's just as easy as before to allocate global refs (and global 
mutable arrays).
   * It's still possible to perform arbitrary IO actions (e.g. FFI 
calls), but you have to wrap them in unsafeIOToST -- a good thing since 
they really are unsafe. unsafeIOToST is much safer than unsafePerformIO 
when used in this way.

Problems:
   * stToIO (newSTRef 'x') doesn't have type IO (IORef Char).
This problem can be solved by adopting a reform that I've wanted for a 
long time anyway: make IO, IORef, etc. aliases for (ST RealWorld), 
(STRef RealWorld), etc. instead of completely different types. Then 
stToIO is the identity function and we only need a single set of 
state-thread functions instead of the parallel IO and ST equivalents 
that we have currently.

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

Re: Module Initialisation? (was Re: [Haskell] (no subject))

[Wolfgang Thaller]

Adrian Hey wrote:
I'm puzzled about this idea of "module init action" in a declarative
language. Perhaps, if it's desirable to have some module initialisation
applied to a module if anything from it is used, the way to do this 
would
be to have a reserved identifier specially for the purpose, like
"main", but at the module level. (Though this idea still seems a
bit strange to me).
I don't see what's so strange about that. At least, it's not any 
stranger than on-demand execution of IO actions in a pure functional 
language. And the toplevel "<-" is definitely a natural syntax for 
that.

I've interpreted this correctly this means that someAction will always
get executed, whether or not foo (or anything dependent on foo) is used
elsewhere? This seems like a bad thing to me.
It's a feature. I'd actually _want_ to use that one independently.
It may be harmless enough
if all it does is create a few IORefs which are then promptly garbage
collected, but in some situations it could involve quite complex
and expensive initialisation operations on foreign libraries
(for example).
Well if you want those IO operations to be lazily interleaved with the 
rest of the program (or not executed at all), you can use

valueToBeInitedLazily <- unsafeInterleaveIO $ do
blah
... which explicitly says what you are doing that might be slightly 
unsafe.

Since a lot of the concerns expressed about this seem to centre
around possible abuse of arbitrary IO operations in these top
level constructions, maybe the problem could be addressed by
insisting that a restricted monad was used, call it SafeIO say.
You're taking away a feature I want to use.
1) Initialising global IORefs is a good thing, no matter when it's 
actually done.
2) Being able to initialize things at program startup is a good thing, 
even if they're
not explicitly referred to.
3) Lazy, on-demand initialization of things is a good thing, if you 
know what you're doing.
4) Lazy, on-demand initialization of things (with potential side 
effects) is a bad thing, if you don't know what you're doing.

If we define toplevel IO bindings to be just like the unsafePerformIO 
hack, we get 1,3 and 4 (and 4 is actually a bad thing).
If we define toplevel IO bindings as mdo-style module initialisation, 
we get 1 and 2 directly, and 3 with an obvious use of 
unsafeInterleaveIO. We don't get 4, because obviously, when you use 
unsafeInterleaveIO, you're already claiming to know what you're doing.

Also note that if useless initialization of IORefs ever becomes a 
problem, we can still use lots of nasty hacks inside the compiler to 
optimize for those common functions. But I don't think we'll ever have 
to do this.

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

Module Initialisation? (was Re: [Haskell] (no subject))

[Adrian Hey]

On Thursday 14 Oct 2004 10:18 am, Simon Marlow wrote:
> On 13 October 2004 16:17, Wolfgang Thaller wrote:
> > We could get away with "desugaring" them to some very "unsafe" non-IO-
> > bindings and having the "module init action" do something evil to
> > make the IO happen in the right order... should be possible to make
> > that look exactly like mdo from the outside.
> > We'll end up using the unsafePerformIO hack inside the implementation
> > again, so that people end up with two IORefs instead of one, but that
> > should be cheap enough:
> >
> > foo <- someAction
> >
> > ... could be transformed into ...
> >
> > foo_var = unsafePerformIO $ newIORef (throw NonTermination)
> > foo_action = someAction >>= writeIORef foo_var
> > foo = unsafePerformIO $ readIORef foo
> >
> > ... with the appropriate NOINLINEs.
> > The module init action would then make sure that foo_action gets
> > invoked.
>
> Yes, we could do that.  The fact that we're using NOCSE/NOINLINE
> internally still seems very fragile, though.  Oh well, perhaps we have
> to live with that if we don't want the pain of a special binding type
> throughout the compiler.

I'm puzzled about this idea of "module init action" in a declarative
language. Perhaps, if it's desirable to have some module initialisation
applied to a module if anything from it is used, the way to do this would
be to have a reserved identifier specially for the purpose, like
"main", but at the module level. (Though this idea still seems a
bit strange to me).

Also, I'm still not convinced that mdo is something I want emulated
anyway, (well not if it means doing something like the above). If
I've interpreted this correctly this means that someAction will always
get executed, whether or not foo (or anything dependent on foo) is used
elsewhere? This seems like a bad thing to me. It may be harmless enough
if all it does is create a few IORefs which are then promptly garbage
collected, but in some situations it could involve quite complex
and expensive initialisation operations on foreign libraries
(for example).

Since a lot of the concerns expressed about this seem to centre
around possible abuse of arbitrary IO operations in these top
level constructions, maybe the problem could be addressed by
insisting that a restricted monad was used, call it SafeIO say.

So we'd have something like this:
initIORef :: a -> SafeIO (IORef a)
initMVar  :: a -> SafeIO (MVar a)
initEmptyMVar :: SafeIO (MVar a)
liftSafeIO:: SafeIO a -> IO a

The idea being that from within SafeIO you couldn't read or modify IORefs
or do any other IO operation, all you could do is create new ones (or
incorporate existing ones into the data structure). Wouldn't this + mdo
suffice for the safe construction and initialisation of complex mutable data
structures (which is probably all people want most of the time)?

I guess you'd still need a get out occasionally, especially for FFI..
flakyLiftIO :: IO a -> SafeIO a
:-)

So at the top level you'd probably have..

myThing :: Thing
myThing <- safeNewThing

safeNewThing :: SafeIO Thing
safeNewThing = mdo ...

newThing :: IO Thing
newThing = liftSafeIO safeNewThing

Now that all seems so simple, I'm certain I must have overlooked
something :-(

Regards
--
Adrian Hey

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

RE: [Haskell] (no subject)

[Simon Marlow]

On 13 October 2004 16:17, Wolfgang Thaller wrote:

> We could get away with "desugaring" them to some very "unsafe" non-IO-
> bindings and having the "module init action" do something evil to
> make the IO happen in the right order... should be possible to make
> that look exactly like mdo from the outside.
> We'll end up using the unsafePerformIO hack inside the implementation
> again, so that people end up with two IORefs instead of one, but that
> should be cheap enough:
> 
> foo <- someAction
> 
> ... could be transformed into ...
> 
> foo_var = unsafePerformIO $ newIORef (throw NonTermination)
> foo_action = someAction >>= writeIORef foo_var
> foo = unsafePerformIO $ readIORef foo
> 
> ... with the appropriate NOINLINEs.
> The module init action would then make sure that foo_action gets
> invoked. 

Yes, we could do that.  The fact that we're using NOCSE/NOINLINE
internally still seems very fragile, though.  Oh well, perhaps we have
to live with that if we don't want the pain of a special binding type
throughout the compiler.

Cheers,
Simon

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

[Haskell] (no subject)

[Wolfgang Thaller]

> b) Some predetermined order, with semantics like mdo:

Hmm, I just realized that this also means we can execute moduke 
intialisation code that returns no result using:
_ <- do ...

I like that, I desperately need that for my Objective-C binding...
So the extension with the specified order actually allows one to do more 
things than the unsafePerformIO hack. I wouldn't care about specifying the 
order otherwise. If the default order is wrong, people can still use 
unsafeInterleaveIO.

> GHC already has an initialisation procedure for each module in the
> program which could be adapted to run the initialisation-time IO
> actions, with a little effort.

Hmm, doesn't the initialisation procedure run before the Stg machine is 
properly set up? I guess all the GHC init code could do is to register IO 
actions to be executed later (but before main is run). We probably want 
all the GHC module init procedures to be run before we execute any IO 
actions.

> I'm more worried about what other changes we have to make to the
> compiler: if we can avoid having to flag top-level bindings as
> monadic/non-monadic all the way through the compiler, then we could
> avoid a pervasive change to the compiler.  At the moment I can't see an 
> obvious way to do that.

We could get away with "desugaring" them to some very "unsafe" non-IO-
bindings and having the "module init action" do something evil to make the 
IO happen in the right order... should be possible to make that look 
exactly like mdo from the outside.
We'll end up using the unsafePerformIO hack inside the implementation 
again, so that people end up with two IORefs instead of one, but that 
should be cheap enough:

foo <- someAction

... could be transformed into ...

foo_var = unsafePerformIO $ newIORef (throw NonTermination)
foo_action = someAction >>= writeIORef foo_var
foo = unsafePerformIO $ readIORef foo

... with the appropriate NOINLINEs.
The module init action would then make sure that foo_action gets invoked.

So we'd only need to annotate modules with a list of init actions and 
extend the RTS appropriately for that...


Cheers,

Wolfgang

-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++

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

[Haskell] (no subject)

[Alfonso]

Hello dear haskellers:

 

My name is Alfonso Meléndez I work in Computer
Science in  a Colombian
 University.

Right now, I am developing an application for
discrete mathematics and I need to comunicate Java with Haskell, 

more precisely  I use Java for the interface of the
application and from here  I need to call several  Haskell Functions.

In Haskell.org  there are two libraries  ( Java Bridge
and JNI) that communicate Haskell with Java (but not viceversa).

 

Is there and easy and direct way to do this job?

 

Thank you!!!

 

 

 

Alfonso  Meléndez

Dirección de Proyectos

Facultad de Ingeniería de Sistemas

Escuela Col de Ingeniería

Tels: 676266,6763888, Ext: 224,  371 

Cel:  (315) 8938216

 





This e-mail message has been scanned for Viruses and Content and cleared by 
NetIQ MailMarshal 




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