Re: [Haskell] Guidelines for respectful communication
> On 7 Dec 2018, at 6:47 pm, Jonathan Lange wrote: > > In particular, her suggestion about pairing guidelines for respectful > communications with guidelines for what to do when things break down is an > excellent one, and has worked well in other communities to help those on the > fringes of a community feel welcome and able to contribute. I’ll also back this up. Over the last couple of years I’ve been involved in 3 separate communities which have struggled with many of the same issues. The way I see it, guidelines for Respectful Communication are statements of the desired end goal, but they don’t provide much insight as to the root causes of the problems, or how to address them. At the risk of trivialising the issue, one could reduce many such statements to “Can everyone please stop shouting and be nice to each other.” (CEPSSaBNTEO) Here are two templates for problems that I’ve seen over and over, and not necessarily in this community. The names used are placeholders. 1) Alice has become very interested in a particular technical issue and wants to change the direction of Project X to address it. Alice has contributed to Project X on and off, but did not start it and is not currently leading it. The main developer is Bob who agrees that the issue exists, but is focused on other things right now, and isn’t motivated to have a long discussion about something he sees as a minor detail. Alice continues to post on a public list about the issue, until Bob becomes exasperated and replies with something like “yes, but I don’t care about that right now”. Alice thinks the comment is directed at her personally, posts a hurt reply, then Charlie, Debbie, and Edward chime in about whether or not that was an appropriate communication. There is a thread on Reddit with 50 comments from people that Alice and Bob have never heard of. Both Alice and Bob are demotivated by the whole experience, and future potential contributors to Project X stumble across the Reddit post and decide they don’t want to get involved anymore. 2) Charlie and Debbie have been building System Y for the last 10 years as a side project, which over time has grown to be a key part of the public infrastructure. Both Charlie and Debbie are well known and respected by the community, but don’t always have time to fix bugs promptly. System Y also has some long standing issues that everyone grumbles about, but also know how to work around. Edward works for Company Z, which has recently formed to do consulting in this area. Company Z has publicly stated that they will invest 2 million dollars improving the public infrastructure, and plan to build a replacement for System Y. Some think that Edward is trying to take over System Y as a marketing exercise, others think System Y should have been replaced long ago, others think that Edward should just start funding Charlie and Debbie's work on System Y full time, instead of trying to build a new system from scratch. Charlie and Debbie are overwhelmed with all the emails and have less and less time to actually fix bugs in System Y. Next, Harold, who has been watching from the sidelines, posts a long tirade about all the reasons that Company Z is a terrible company doing the wrong things for the wrong reasons. Charlie barely knows Harold, but posts a small comment agreeing with the general sentiment. Edward sees the comment and promises himself that there is no way the ungrateful System Y people are ever getting any of his money. Two years later both System-Y and Company Z’s SystemY-Prime are in common use, do basically the same thing, and everyone grumbles about both. The root problems here are differences in motivation, miscommunication, and the Internet Amplification Effect (IAE). Harsh posts in public forums are a surface effect that feeds back and exacerbates the underlying problems. People like Harold who stoke the flames don’t tend to read the Respectful Communication guidelines, and everyone always feels justified in their own opinions. There is published work on dealing with conflicts in online communities [1], but I don’t pretend to be an expert. Perhaps an interested party could start a wiki page with statements of the form “If you feel like X is happening then consider doing Y.” This might also help people that are not naturally good at understanding the thoughts and motivations of other people, and work better when such advice is written down. Peace, Ben. [1] Managing Conflicts in Open Source Communities Ruben Van Wendel De Joode, 2004. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] CFP: Haskell Symposium Regular Track Final Call
= ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2015 Vancouver, Canada, 3-4 September 2015, directly after ICFP http://www.haskell.org/haskell-symposium/2015 = Reminder that the Haskell Symposium Regular Track abstract deadline is this: Tuesday 19th of May, with full papers due this: Friday 22nd of May. Authors that have *already submitted to the early track*, have until 5th of June to resubmit an improved version of those papers. Deadlines stated are valid anywhere on earth. (the HotCRP submission site states them in US EDT, but don't fret) See the website for further details http://www.haskell.org/haskell-symposium/2015 = ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] Haskell 2015: 2nd Call for Papers
columns. The length is restricted
to 12 pages, except for "Experience Report" papers, which are
restricted to 6 pages. Papers need not fill the page limit -- for
example, a Functional Pearl may be much shorter than 12 pages.
Each paper submission must adhere to SIGPLAN's republication policy,
as explained on the web.
Demo proposals are limited to 2-page abstracts, in the same ACM
format as papers.
"Functional Pearls", "Experience Reports", and "Demo Proposals"
should be marked as such with those words in the title at time of
submission.
The paper submission deadline and length limitations are firm.
There will be no extensions, and papers violating the length
limitations will be summarily rejected.
A link to the paper submission system will appear on the
Haskell Symposium web site closer to the submission deadline.
Submission Timetable:
=
Early TrackRegular Track System Demos
--- ---
13th March Paper Submission
1st MayNotification
19th May Abstract Submission
22nd May Paper Submission
5th June ResubmissionDemo Submission
26th June Notification Notification Notification
19th July Final papers due Final papers due
Deadlines stated are valid anywhere on earth.
In this iteration of the Haskell Symposium we are trialling a
two-track submission process, so that some papers can gain early
feedback. Papers can be submitted to the early track on 13th March.
On 1st May, strong papers are accepted outright, and the others will
be given their reviews and invited to resubmit. On 5th June early
track papers may be resubmitted, and are sent back to the same
reviewers. The Haskell Symposium regular track operates as in
previous years. Papers accepted via the early and regular tracks are
considered of equal value and will not be distinguished in the
proceedings.
Although all papers may be submitted to the early track, authors of
functional pearls and experience reports are particularly encouraged
to use this mechanism. The success of these papers depends heavily
on the way they are presented, and submitting early will give the
program committee a chance to provide feedback and help draw out
the key ideas.
Program Committee:
===
Mathieu Boespflug- Tweag I/O
Edwin Brady - University of St Andrews
Atze Dijkstra- Utrecht University
Tom DuBuisson- Galois
Torsten Grust- University of Tuebingen
Patrik Jansson - Chalmers University of Technology
Patricia Johann - Appalachian State University
Oleg Kiselyov- Tohoku University
Edward Kmett - McGraw Hill Financial
Neelakantan Krishnaswami - University of Birmingham
Ben Lippmeier (chair)- Vertigo Technology
Hai (Paul) Liu - Intel Labs
Garrett Morris - University of Edinburgh
Dominic Orchard - Imperial College London
Matt Roberts - Macquarie University
Tim Sheard - Portland State University
Joel Svensson- Indiana University
Edsko de Vries - Well Typed
=___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] CFP: Haskell Symposium 2015
font in two columns. The length is restricted to 12 pages, except for "Experience Report" papers, which are restricted to 6 pages. Papers need not fill the page limit -- for example, a Functional Pearl may be much shorter than 12 pages. Each paper submission must adhere to SIGPLAN's republication policy, as explained on the web. Demo proposals are limited to 2-page abstracts, in the same ACM format as papers. "Functional Pearls", "Experience Reports", and "Demo Proposals" should be marked as such with those words in the title at time of submission. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. A link to the paper submission system will appear on the Haskell Symposium web site closer to the submission deadline. Submission Timetable: = Early TrackRegular Track System Demos --- --- 13th March Paper Submission 1st MayNotification 19th May Abstract Submission 22nd May Paper Submission 5th June ResubmissionDemo Submission 26th June Notification Notification Notification 19th July Final papers due Final papers due Deadlines stated are valid anywhere on earth. In this iteration of the Haskell Symposium we are trialling a two-track submission process, so that some papers can gain early feedback. Papers can be submitted to the early track on 13th March. On 1st May, strong papers are accepted outright, and the others will be given their reviews and invited to resubmit. On 5th June early track papers may be resubmitted, and are sent back to the same reviewers. The Haskell Symposium regular track operates as in previous years. Papers accepted via the early and regular tracks are considered of equal value and will not be distinguished in the proceedings. Although all papers may be submitted to the early track, authors of functional pearls and experience reports are particularly encouraged to use this mechanism. The success of these papers depends heavily on the way they are presented, and submitting early will give the program committee a chance to provide feedback and help draw out the key ideas. Program Committee: === Mathieu Boespflug- Tweag I/O Edwin Brady - University of St Andrews Atze Dijkstra- Utrecht University Tom DuBuisson- Galois Torsten Grust- University of Tuebingen Patrik Jansson - Chalmers University of Technology Patricia Johann - Appalachian State University Oleg Kiselyov- Tohoku University Edward Kmett - McGraw Hill Financial Neelakantan Krishnaswami - University of Birmingham Ben Lippmeier (chair)- Vertigo Technology Hai (Paul) Liu - Intel Labs Garrett Morris - University of Edinburgh Dominic Orchard - Imperial College London Matt Roberts - Macquarie University Tim Sheard - Portland State University Joel Svensson- Indiana University Edsko de Vries - Well Typed = ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell Symposium Experience Report Advice Page
Dear Haskell Hackers, I have started an advice page for people that plan to submit experience reports to the upcoming Haskell Symposium, based on my experience as a PC member last year: http://www.haskell.org/haskellwiki/HaskellSymposium/ExperienceReports Haskell Symposium experience report acceptance rates are typically lower than for full papers, and it would be good to improve this. Please add any comments, links or insights you may have to the above page. If you are planning to submit an experience report... then also read the page! :-) Ben. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: Disciplined Disciple Compiler (DDC) 0.3.1
The Disciplined Disciple Compiler Strike Force is pleased to announce the release of DDC 0.3.1. DDC is a research compiler used to investigate program transformation in the presence of computational effects. This is a development release. There is enough implemented to experiment with the core language, but not enough to write real programs. New Features * Compilation via C and LLVM for first-order programs. * Cross-module inlining. * An effect-aware rewrite rule framework. * Generation of LLVM aliasing and constancy meta-data. * More program transformations: Beta (substitute), Bubble (move type-casts), Elaborate (add witnesses), Flatten (eliminate nested bindings), Forward (let-floating), Namify (add names), Prune (dead-code elimination), Snip (eliminate nested applications). People ~~ The following people contributed to DDC since the last release: Tran Ma- LLVM aliasing and constancy meta-data. Amos Robinson - Rewrite rule system and program transforms. Erik de Castro Lopo- Build framework. Ben Lippmeier - Code generators, framework, program transforms. Full release notes: http://code.ouroborus.net/ddc/ddc-stable/RELEASE Further reading: http://disciple.ouroborus.net/ For the impatient: cabal update; cabal install ddc-tools ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] The end of an era, and the dawn of a new one
On 06/12/2012, at 3:56 , Simon Peyton-Jones wrote: > Particularly valuable are offers to take responsibility for a > particular area (eg the LLVM code generator, or the FFI). I'm > hoping that this sea change will prove to be quite empowering, > with GHC becoming more and more a community project, more > resilient with fewer single points of failure. The LLVM project has recently come to the same point. The codebase has become too large for Chris Lattner to keep track of it all, so they've moved to a formal "Code Ownership" model. People own particular directories of the code base, and the code owners are expected to review patches for those directories. The GHC project doesn't have a formal patch review process, I think because the people with commit access on d.h.o generally know who owns what. Up until last week I think it was "SPJ owns the type checker and simplifier, and SM owns everything else." :-) At this stage, I think it would help if we followed the LLVM approach of having a formal CODE_OWNERS file in the root path of the repo explicitly listing the code owners. That way GHC HQ knows what's covered and what still needs a maintainer. The LLVM version is here [1]. Code owners would: 1) Be the go-to person when other developers have questions about that code. 2) Fix bugs in it that no-one else has claimed. 3) Generally keep the code tidy, documented and well-maintained. Simon: do you want a CODE_OWNERS file? If so then I can start it. I think it's better to have it directly in the repo than on the wiki, that way no-one that works on the code can miss it. I suppose I'm the default owner of the register allocators and non-LLVM native code generators. Ben. [1] http://llvm.org/viewvc/llvm-project/llvm/trunk/CODE_OWNERS.TXT?view=markup ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Disciple Core Interpreter 0.2.1
The Disciplined Disciple Compiler (DDC) is being stripped down, cleaned and rebuilt with 100% less known bugs and unfortunate holes. The first pieces are now ready for human consumption, namely a new core language and interpreter for it. There is a tutorial including Hackage links here: http://disciple.ouroborus.net/wiki/Tutorial/Core Read more about the project on the wiki: http://disciple.ouroborus.net/ Cheers, Ben. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell Implementors Workshop talk proposals due this Friday!
Call for Talks ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2011 Tokyo, Japan, September 23rd, 2011 The workshop will be held in conjunction with ICFP 2011 http://www.icfpconference.org/icfp2011/ Important dates Proposal Deadline: 22nd July 2011 Notification:8th August2011 Workshop: 23rd September 2011 The Haskell Implementors' Workshop is to be held alongside ICFP 2011 this year in Tokyo, Japan. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. This relatively new workshop reflects the growth of the user community: there is a clear need for a well-supported tool chain for the development, distribution, deployment, and configuration of Haskell software. The aim is for this workshop to give the people involved with building the infrastructure behind this ecosystem an opportunity to bat around ideas, share experiences, and ask for feedback from fellow experts. We intend the workshop to have an informal and interactive feel, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience - It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2011. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop we hope to study the underlying technology. We want to bring together anyone interested in the nitty gritty details necessary to turn a text file into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and Tools for development or deployment Talks - At this stage we would like to invite proposals from potential speakers for a relatively short talk. We are aiming for 20 min talks with 10 mins for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 200 words to b...@cse.unsw.edu.au We will also have a lightning talks session which will be organised on the day. These talks will be 2-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers -- * Rebekah Leslie (Portland State University) * Ben Lippmeier - co-chair (University of New South Wales) * Andres Loeh (Well-Typed LLP) * Oleg Lobachev(University of Marburg) * Neil Mitchell - co-chair (Standard Chartered) * Dimitrios Vytiniotis (Microsoft Research) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell Implementors Workshop 2011, Second CFT
Call for Talks ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2011 Tokyo, Japan, September 23rd, 2011 The workshop will be held in conjunction with ICFP 2011 http://www.icfpconference.org/icfp2011/ Important dates Proposal Deadline: 22nd July 2011 Notification:8th August2011 Workshop: 23rd September 2011 The Haskell Implementors' Workshop is to be held alongside ICFP 2011 this year in Tokyo, Japan. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. This relatively new workshop reflects the growth of the user community: there is a clear need for a well-supported tool chain for the development, distribution, deployment, and configuration of Haskell software. The aim is for this workshop to give the people involved with building the infrastructure behind this ecosystem an opportunity to bat around ideas, share experiences, and ask for feedback from fellow experts. We intend the workshop to have an informal and interactive feel, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience - It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2011. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop we hope to study the underlying technology. We want to bring together anyone interested in the nitty gritty details necessary to turn a text file into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and Tools for development or deployment Talks - At this stage we would like to invite proposals from potential speakers for a relatively short talk. We are aiming for 20 min talks with 10 mins for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 200 words to b...@cse.unsw.edu.au We will also have a lightning talks session which will be organised on the day. These talks will be 2-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers -- * Rebekah Leslie (Portland State University) * Ben Lippmeier - co-chair (University of New South Wales) * Andres Loeh (Well-Typed LLP) * Oleg Lobachev(University of Marburg) * Neil Mitchell - co-chair (Standard Chartered) * Dimitrios Vytiniotis (Microsoft Research) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CFT -- Haskell Implementors' Workshop 2011
Call for Talks ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2011 Tokyo, Japan, September 23rd, 2011 The workshop will be held in conjunction with ICFP 2011 http://www.icfpconference.org/icfp2011/ Important dates Proposal Deadline: 22nd July 2011 Notification:8th August2011 Workshop: 23rd September 2011 The Haskell Implementors' Workshop is to be held alongside ICFP 2011 this year in Tokyo, Japan. There will be no proceedings; it is an informal gathering of people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure. This relatively new workshop reflects the growth of the user community: there is a clear need for a well-supported tool chain for the development, distribution, deployment, and configuration of Haskell software. The aim is for this workshop to give the people involved with building the infrastructure behind this ecosystem an opportunity to bat around ideas, share experiences, and ask for feedback from fellow experts. We intend the workshop to have an informal and interactive feel, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience - It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2011. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop we hope to study the underlying technology. We want to bring together anyone interested in the nitty gritty details necessary to turn a text file into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and Tools for development or deployment Talks - At this stage we would like to invite proposals from potential speakers for a relatively short talk. We are aiming for 20 min talks with 10 mins for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 200 words to b...@cse.unsw.edu.au We will also have a lightning talks session which will be organised on the day. These talks will be 2-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers -- * Rebekah Leslie (Portland State University) * Ben Lippmeier - co-chair (University of New South Wales) * Andres Loeh (Well-Typed LLP) * Oleg Lobachev(University of Marburg) * Neil Mitchell - co-chair (Standard Chartered) * Dimitrios Vytiniotis (Microsoft Research) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] New blog on Disciple/DDC development
The blog is at: http://disciple-devel.blogspot.com/ more about the project here: http://trac.haskell.org/ddc/ Ben. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: gloss-1.0.0.2: Painless 2D vector graphics, animations and simulations.
Gloss hides the pain of drawing simple vector graphics behind a nice data type and a few display functions. Gloss uses OpenGL and GLUT under the hood, but you won't have to worry about any of that. Get something cool on the screen in under 10 minutes. A simple animated example is: import Graphics.Gloss main = animateInWindow "My Window" (200, 200) (10, 10) white $ \time -> Rotate (time * 100) $ Color red $ Line [(0, 0), (100, 100)] "animateInWindow" first takes the name, size, position and background color of the window. The final argument is a function from the time (in seconds) from when the program started, to a picture. Once the window is open you can pan around, zoom and rotate the animation using the mouse. Pictures of more detailed examples are at: http://trac.haskell.org/gloss/ Try it out now with: cabal update cabal install gloss cabal install gloss-examples gloss-styrene then right-click drag to rotate the box.. Ben. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: The Disciplined Disciple Compiler - alpha 1
Hi All, I'm pleased to announce the initial alpha release of the Disciplined Disciple Compiler (DDC). Disciple is an explicitly lazy dialect of Haskell which includes: - first class destructive update of arbitrary data. - computational effects without the need for state monads. - type directed field projections. All this and more through the magic of effect typing. More information (and download!) available from: http://www.haskell.org/haskellwiki/DDC or http://code.google.com/p/disciple DDC: more than lambdas. Onward! Ben. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Mixing monadic and non-monadic functions
Frederik Eaton wrote:
I want the type system to be able to do "automatic lifting" of monads,
i.e., since [] is a monad, I should be able to write the following:
[1,2]+[3,4]
and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}".
print ("a: " ++ readLn ++ "\nb: " ++ readLn)
two lines are read and then printed. Does anybody for a moment
question what order the lines should be read in?
Frederik,
To do "automatic lifting" you need to do a (higher-order) effect
analysis, then make sure the compiler doesn't rearrange applications
which have conflicting effects.
One way of preventing the compiler from rearranging effects is to thread
though a dummy variable - like a "World token", ala the IO monad - which
makes the order of operations explicit as an extra data dependency, then
compile the resulting code.
Another way is to use the effect information to lift the applications
into a hierarchy of monads which represent how effectful the application
is, then compile the monadic code directly. There's a paper by Andrew
Tolmach called "Optimizing ML using a hierarchy of monadic types", which
does exactly this.
Tolmach's approach worked ok, but there were some problems with higher
order functions.. ie with map :: (a -E> b) -> [a] -E> [b] where E is
some effect, you have to assume a worst case effect for the first
argument - so any expression using map can't be moved around by the
compiler - eg for the full laziniess transform.
Another way would be just to annotate every application with the effects
it has, then have the compiler check these before it tries to rearrange
anything - and have an extra rule that you can't suspend an application
which has visible effects.
I am working on a compiler for my PhD project which takes this third
option. I've got the effect analysis working, but I had to resort to a
graph based type inference method - which is something that wouldn't be
easilly added to something like GHC.
Onward!
Ben.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Who brought the monad to us?
Wolfgang, I thing that Eugenio Moggi was the first to combine monads from category theory with the lambda calculus. Check out: Computational Lambda Calculus and Monads, Eugenio Moggi, 1988 http://www.disi.unige.it/person/MoggiE/ It's citeseer page is at: http://citeseer.ist.psu.edu/275817.html Ben. Wolfgang Jeltsch wrote: Hello, is it right to say that Philip Wadler was the one who invented monadic I/O or were there others who did so together with Wadler? I need this for my thesis. :-) Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Strictness question
Gary Morris wrote: ioexptmod :: Integer -> Integer -> Integer -> Int -> IO Integer ioexptmod base expt n keySize = return $! exptmod base expt n keySize My hope was that the use of $! would force it to compute the exponentiation while I was timing -- and the average times are around 30K clock cycles, suggesting that it's doing the work, but I was wondering if it was possible that I was missing something. An expression like (f $! x) is only ever going to force x to whnf (weak head normal form). To gloss over details: it'll reduce x far enough so it knows that it's an Integer, but it won't nessesarally compute that integers value. If you want to ensure that something is actually computed in a lazy language, you need to do something with the result that *absolutely* needs a completely constructed object.. Printing to screen is a prime candidate, the system can't print something unless it's evaluated it. Those 30K clocks suggest it's doing _some_ work. I wouldn't start making bets on what that work actually consists of though.. BTW: Haskell would have to be my absolutely last choice for experimenting with timing attacks against RSA.. Let's just say that I admire your courage! :) Ben. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Implicit parallel functional programming
I thought the "lazy functional languages are great for implicit parallelism" thing died out some time ago - at least as far as running the programs on conventional hardware is concerned. Designing an algorithm that breaks apart a "sequential" lazy program into parallel chunks of the appropriate size is **HARD** (with double asterixes). The time and space behavior of a lazy program is complex enough for the _programmer_ to reason about, let alone an automated analysis - which has no knowledge of what the program is actually trying to do. I think a more likely approach lies in the direction of the so called "parallel strategies". If you haven't already, I would strongly suggest reading: Algorithm + Strategy = Parallelism, 1998, PW Trinder, et al. You can get this paper from Simon Peyton Jones's homepage. Also, at the end of Hans Wolfgang-Loidl's thesis he develops a granularity analysis for a Haskell subset - one of the first steps in any kind of implicit parallelism. It's a pretty good effort, but at the end of it all it still relies on a pre-existing table of information about recursive functions. I think that these kind of analyses tend suffer from uncomputability problems more than most. If you've still got your heart set on implicit parallelism, then there's a (very slow) simulator you might want to poke around with. I wrote it based around Clem Baker-Finch's "Abstract machine for parallel lazy evaluation", which supports fully speculative implicit parallelism. There's a link to it on my homepage at http://cs.anu.edu.au/people/Ben.Lippmeier Keean Schupke wrote: I have to say I disagree... I feel Haskell is highly suited to implicit parallel execution... The key to "implicit" parallelisation is that it is implicit - not explicit, so the programmer should feel like they are programming a sequential language. If we can assume little memory access penalties for threads running on other CPUs (shared cache model), it seems to be a matter of putting locks on the right structures, and allowing any worker-thread to take the next function ready to run from the scheduler. Keean. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Strange "let"
Ha!, What you've done is redefine the (+) function.. try 10 + 30 and see what you get. Your local definition shadows the "real" (+) function defined in the prelude. let a + b = 3 is equivalent to let (+) a b = 3 ... Jinwoo Lee wrote: Hi, I'm a Haskell newbie. I was trying several things with GHCi and found out that the expression "let a + b = 3" does not generate any errors. Prelude> let a + b = 3 Prelude> a :1: Variable not in scope: `a' Prelude> b :1: Variable not in scope: `b' Prelude> What does "let a + b = 3" mean in this case? I also tries with GHC compiler using the code below, but it generates no error. main :: IO () main = do let a + b = 3 putStrLn "Hello" Could somebody answer this? Jinwoo ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Licensing problem, caused by static linking on windows
Kevin,
The problem is that on Windows, GHC statically links the program with
the libgmp library, which has an LGPL license. The LGPL license says
that we can distribute the executable under our own terms, [...]
You could write a C wrapper around a run-time loaded library. Cygwin
supports dlopen() and friends so it might even be portable. You would
statically link the wrapper code so GHC has the symbols it needs, but
the actual functionality would remain in the original .dll / .so.
Though, if you've used lots of functions from libgmp it might be a
hassle to write the wrappers.
Ben.
[untested example code]
Wrapper.hs
foreign import ccall someFunction_Wrapper :: Int -> Int
Wrapper.c
int (*someFunction_WrapperSym)(int);
int someFunction_Wrapper (int x)
{
return someFunction_WrapperSym (x);
}
void initWrapper ()
{
void* handle = dlopen("where/is/libgmp.so", RTLD_NOW);
someFunction_WrapperSym = dlsym (handle, "someFunction");
}
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
