[Haskell] Haskell 2013 call for PANEL DISCUSSIONS
=== ACM SIGPLAN HASKELL SYMPOSIUM 2013 CALL FOR PANEL DISCUSSIONS Boston, MA, USA, 23-24 September 2013, directly before ICFP http://www.haskell.org/haskell-symposium/2013/ haskell2...@easychair.org === The ACM SIGPLAN Haskell Symposium 2013 will be colocated with the 2013 International Conference on Functional Programming (ICFP) in Boston, MA, USA. The Haskell Symposium seeks to present original research on Haskell, to discuss practical experience and future development of the language, as well as to promote other forms of denotative programming. This year, the symposium will include a new category of panel discussions, which will subsume past "Future of Haskell" discussions. We solicit proposals for panel discussions, submitted by a moderator who proposes to bring together specific panelists who have agreed to address a specific pressing issue in the Haskell community. The proposals should summarize the panelist positions that would be discussed. The proposals should explain (and will be judged on) whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical or social. Please contact the program chair with any questions about the relevance of a proposal. Submission Details: === The submission deadline Fri 28th June 2013, anywhere on earth. "Panel Proposals" should be marked as such with those words in the title at time of submission. Submitted proposals should be in portable document format (PDF), at most 2 pages formatted using the ACM SIGPLAN style guidelines (http://www.acm.org/sigs/sigplan/authorInformation.htm). The text should be in a 9-point font in two columns. Submission is via EasyChair: https://www.easychair.org/conferences/?conf=haskell2013 Accepted panel proposals will be posted on the symposium web page, but not formally published in the proceedings. Travel Support: === Student attendees with accepted proposals can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page (http://www.sigplan.org/PAC.htm). Programme Committee: * Andreas Abel, Ludwig-Maximilians-Universität München * Lennart Augustsson, Standard Chartered Bank * Jean-Philippe Bernardy, Chalmers University of Technology * Olaf Chitil, University of Kent * Neil Ghani, University of Strathclyde * Hans-Wolfgang Loidl, Heriot-Watt University * Ian Lynagh, Well-Typed LLP * David Mazières, Stanford University * Akimasa Morihata, Tohoku University * Takayuki Muranushi, Kyoto University * Alberto Pardo, Universidad de la República * Norman Ramsey, Tufts University * Neil Sculthorpe, University of Kansas * Chung-chieh Shan (chair), Indiana University * Christina Unger, Universität Bielefeld * Dana N. Xu, INRIA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell 2013 call for submissions
n: Fri 14th June 2013, anywhere on earth (prior abstract submission unnecessary) * Panel submission : Fri 28th June 2013, anywhere on earth (prior abstract submission unnecessary) * Author notification: Thu 11th July 2013 * Final papers due : Thu 25th July 2013 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines (http://www.acm.org/sigs/sigplan/authorInformation.htm). The text should be in a 9-point 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 and panel proposals are limited to 2-page abstracts, in the same ACM format as papers. "Functional Pearls", "Experience Reports", "Demo Proposals", and "Panel 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. Submission is via EasyChair: https://www.easychair.org/conferences/?conf=haskell2013 Programme Committee: * Andreas Abel, Ludwig-Maximilians-Universität München * Lennart Augustsson, Standard Chartered Bank * Jean-Philippe Bernardy, Chalmers University of Technology * Olaf Chitil, University of Kent * Neil Ghani, University of Strathclyde * Hans-Wolfgang Loidl, Heriot-Watt University * Ian Lynagh, Well-Typed LLP * David Mazières, Stanford University * Akimasa Morihata, Tohoku University * Takayuki Muranushi, Kyoto University * Keiko Nakata, Tallinn University of Technology * Alberto Pardo, Universidad de la República * Norman Ramsey, Tufts University * Neil Sculthorpe, University of Kansas * Chung-chieh Shan (chair), Indiana University * Christina Unger, Universität Bielefeld * Dana N. Xu, INRIA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Extended deadline; IFIP sponsorship: IFIP Working Conference on Domain-Specific Languages
IFIP Working Conference on Domain-Specific Languages (DSL) 6-8 September 2011, Bordeaux, France http://dsl2011.bordeaux.inria.fr/ CALL FOR PAPERS (EXTENDED DEADLINE; IFIP SPONSORSHIP) Domain-specific languages have long been a popular way to shorten the distance from ideas to products in software engineering. On one hand, the interface of a DSL lets domain experts express high-level concepts succinctly in familiar notation, such as grammars for text or scripts for animation, and often provides guarantees and tools that take advantage of the specifics of the domain to help write and maintain these particular programs. On the other hand, the implementation of a DSL can automate many tasks traditionally performed by a few experts to turn a specification into an executable, thus making this expertise available widely. Overall, a DSL thus mediates a collaboration between its users and implementers that results in software that is more usable, more portable, more reliable, and more understandable. These benefits of DSLs have been delivered in domains old and new, such as signal processing, data mining, and Web scripting. Widely known examples of DSLs include Matlab, Verilog, SQL, LINQ, HTML, OpenGL, Macromedia Director, Mathematica, Maple, AutoLisp/AutoCAD, XSLT, RPM, Make, lex/yacc, LaTeX, PostScript, and Excel. Despite these successes, the adoption of DSLs have been stunted by the lack of general tools and principles for developing, compiling, and verifying domain-specific programs. General support for building and using DSLs is thus urgently needed. Languages that straddle the line between the domain-specific and the general-purpose, such as Perl, Tcl/Tk, and JavaScript, suggest that such support be based on modern notions of language design and software engineering. The goal of this conference, following the last one in 2009, is to explore how present and future DSLs can fruitfully draw from and potentially enrich these notions. We seek research papers on the theory and practice of DSLs, including but not limited to the following topics. * Foundations, including semantics, formal methods, type theory, and complexity theory * Language design, including concrete syntax, semantics, and types * Software engineering, including domain analysis, software design, and round-trip engineering * Modularity and composability of DSLs * Software processes, including metrics for software and language evaluation * Implementation, including parsing, compiling, program generation, program analysis, transformation, optimization, and parallelization * Reverse engineering, re-engineering, design discovery, automated refactoring * Hardware/software codesign * Programming environments and tools, including visual languages, debuggers, testing, and verification * Teaching DSLs and the use of DSLs in teaching * Case studies in any domain, especially the general lessons they provide for DSL design and implementation The conference will include a visit to the city of Bordeaux, a tour and tasting at the wine museum and cellar, and a banquet at La Belle Époque. INSTRUCTIONS FOR AUTHORS Papers will be judged on the depth of their insight and the extent to which they translate specific experience into general lessons for software engineers and DSL designers and implementers. Where appropriate, papers should refer to actual languages, tools, and techniques, provide pointers to full definitions, proofs, and implementations, and include empirical results. Proceedings will be published in Electronic Proceedings in Theoretical Computer Science (http://info.eptcs.org/). Submissions and final manuscripts should be at most 25 pages in EPTCS format. IMPORTANT DATES * 2011-04-25: Abstracts due (extended deadline) * 2011-05-02: Submissions due (extended deadline) * 2011-06-10: Authors notified of decisions * 2011-07-11: Final manuscripts due * 2011-09-05: Distilled tutorials * 2011-09-06/2011-09-08: Main conference PROGRAM COMMITTEE * Emilie Balland (INRIA) * Olaf Chitil (University of Kent) * Zoé Drey (LaBRI) * Nate Foster (Cornell University) * Mayer Goldberg (Ben-Gurion University) * Shan Shan Huang (LogicBlox) * Sam Kamin (University of Illinois at Urbana-Champaign) * Jerzy Karczmarczuk (University of Caen) * Jan Midtgaard (Aarhus University) * Keiko Nakata (Tallinn University of Technology) * Klaus Ostermann (University of Marburg) * Jeremy Siek (University of Colorado at Boulder) * Tony Sloane (Macquarie University) * Josef Svenningsson (Chalmers University of Technology) * Paul Tarau (University of North Texas) * Dana N. Xu (INRIA) ORGANIZERS Local chair:Emilie Balland (INRIA) Program chairs: Olivier Danvy (Aarhus University), Chung-chieh Shan (Rutgers University) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] NASSLLI 2010 call for course and workshop proposals
NASSLLI 2010 North American Summer School in Logic, Language and Information 2010 June 21-26, Indiana University CALL for COURSE and WORKSHOP PROPOSALS The fourth NASSLLI (after previous editions at Stanford University, Indiana University, and UCLA) will return to Bloomington, Indiana, June 21-25, 2010. The summer school, loosely modeled on the long-running ESSLLI series in Europe, will consist of a number of courses and workshops, selected on the basis of the proposals. By default, courses and workshops meet for 90 or 120 minutes on each of five days. Proposals are invited that present interdisciplinary work between the areas of logic, linguistics, computer science, cognitive science, philosophy and artificial intelligence, though work in just one area is within the scope of the summer school if it can be applied in other fields. Examples of possible topics (adapting from previous NASSLLI courses) would include e.g. logics for communication, computational semantics, game theory (for logic, language and/or computation), dynamic semantics, modal logics, linear logic, machine learning techniques, statistical language models, and automated theorem proving. We encourage potential course or workshop contributors to check out previous programs at: http://www.linguistics.ucla.edu/nasslli04/program.html http://www.stanford.edu/group/nasslli/ http://www.indiana.edu/~nasslli/2003/program.html Courses and workshops should aim to be accessible to an interdisciplinary, graduate level audience. Courses may certainly focus on a single area, but lecturers should then include introductory background, try to avoid specialized notation that cannot be applied more widely, and spend time on the question of how the topic is relevant to other fields. A workshop can be more accessible if its program is bracketed by broader-audience talks that introduce and summarize the week's presentations. Associated Workshops/Conferences: In addition to courses and workshops taking place during the main NASSLLI five day session, Indiana University welcomes proposals for 1-3 day workshops or conferences hosted on campus immediately before or after the summer school, thus on the weekends of June 18-20 and June 27-29 2010. Previous such associated meetings have included a Mathematics of Language conference and Theoretical Aspects of Reasoning About Knowledge (TARK). Submission Details: Submissions should be by email, and should indicate 1) person(s) and affiliation 2) type of event (course or workshop; main session or weekend workshop/conference) 3) an outline of the course up to 500 words 4) an indication of whether special equipment is needed to teach that course (beamer, computer ...) 5) a statement about the instructor's experience in teaching in interdisciplinary settings 6) expected costs (whether you want to be paid hotel and/or travel, and descriptions of funding in hand or for which you will apply) Financial Details: A course may be taught by one or two persons. Conference fees are waived for all instructors. However, we are only able to pay for the full travel and expenses of one instructor per course. If two persons are lecturing, they may share a lump sum paid for both. We must also stress that while proposals from all over the world are welcomed, the Summer School can in general guarantee only toreimburse travel costs for travel from destinations within North America to Bloomington, although exceptions can be made depending on the financial situation. Furthermore, we encourage all lecturers to fund their own travel if this is feasible, since this will allow us to use our available funding for student scholarships. Workshops are more complicated financially than courses, and a proposal for a workshop should include a plan to obtain some outside funding for the speakers. Notifications of Interest: To give us an idea about the number of submissions, we would like you to email us, ideally within two weeks, in case you are interested in submitting a proposal. This will not commit you to actually submit one (and not emailing in advance does not preclude you from submitting a full proposal). Schedule: Jun 18 on, 2009 - unofficial notifications of intention to submit; Sep 15,2009 - Deadline for submissions; Nov 1, 2009 - Course/workshop proposers notified of p.c. decisions; Nov 15,2009 - Official announcement of program; May 15,2009 - Material for courses available for printing; Jun 21,2010 - Start of NASSLLI 2010 courses. Program Committee: David Beaver (committee chair), UT Austin Thony Gillies, Rutgers University John Horty, University of Maryland Sandra Kuebler, Indiana University Eric Pacuit, Stanford University Chris Potts, Stanford University Dan Roth, University of Illinois, Urbana/Champaign Chung-Chieh Shan, Rutgers University Matthias Scheutz, Indiana University Standing NASSLLI Steering Committee: David Beaver, UT Austin Larry Moss (committee chair
[Haskell] Re: scoped type variables
Norman Ramsey wrote in article <20090316154743.12f45104...@lakeland.eecs.harvard.edu> in gmane.comp.lang.haskell.general: > ... > In any case, I hope this question is orthogonal to the problem of > permitting a type declaration as a 'decl' in a where clause and not a > mere lonely 'topdecl'. Is anybody else keen to have this ability? Yes, and I'd like to say "let type ... = ... in" and/or "where type ... = ..." inside type expressions as well. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Who would have thought LISP would come back to life. Steve Bourne, in an interview about Bourne Shell. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: No fun with phantom types
Michael Marte <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > *FD> :type let x = (1::Int) in x #+ x #+ x > let x = (1::Int) in x #+ x #+ x :: (MakeAExp (AExp s) s1) => AExp s1 > > It appears to me that ghci generates two phantom types s and s1 and fails to > unify them. Because you may define other MakeAExp instances elsewhere, ghc can't unify s and s1. For example, if you were to define instance MakeAExp (FDVar s) [s] ... instance MakeAExp (AExp [s]) s ... then s could be [s1] in your type! You can probably add functional dependencies to fix this problem, but I would suggest that you get rid of MakeAExp altogether. Just give (#+) and its friends the type "AExp s -> AExp s -> AExp s", with no type-class constraint. You need to explicitly inject FDVar into AExp, but most of the time you probably just need to handle AExp values without caring that they are constructed with Variable. You also need to inject Int into AExp, unless you simply make "instance Num (AExp s)". -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Lemonade was a popular drink and it still is. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Image manipulation
Dan Piponi <[EMAIL PROTECTED]> wrote: > On 10/29/07, [EMAIL PROTECTED] wrote: > > I must say that I don't see much use of laziness here. > Laziness plays a big role in real world image processing. vips/nip2 is one nice instantiation of this idea. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig I want to propose an operating system that will substantially reduce the time required to get a problem solved... The only way quick response can be provided at bearable cost is by time-sharing. That is, the computer must attend to other customers while one customer is reacting to some output.McCarthy,1959. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: type class instance selection & search
If only for those watching from home, here are some references. jeff p <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > >Better yet, > > how about LambdaProlog ( > > http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), > > which generalizes from Horn clauses to (higher-order) hereditary Harrop > > formulas, including (restricted but powerful) universals, implication, and > > existentials? > Having hereditary Harrop formulas at the type level would be cool. It > would also probably require type level lambdas. On that note: Trifonov, Valery. 2003. Simulating quantified class constraints. In Proceedings of the 2003 Haskell workshop, 98-102. New York: ACM Press. http://flint.cs.yale.edu/trifonov/papers/sqcc.pdf http://flint.cs.yale.edu/trifonov/papers/sqcc.ps.gz > There was a recent discussion about type level lambdas in Haskell > which ended with the observations that 1) it would mess up unification > (i.e. make it undecidable and/or too hard) to have explicit type level > lambdas; and 2) they are already implicitly there (this was pointed > out by Oleg) since one can define a type level application and type > level functions. I think 1) is a bit of a cop-out since you could > always restrict to pattern unification (L-lamda unification) which is > decidable and has MGUs. On that note: Neubauer, Matthias, and Peter Thiemann. 2002. Type classes with more higher-order polymorphism. In ICFP '02: Proceedings of the ACM international conference on functional programming. New York: ACM Press. http://www.informatik.uni-freiburg.de/~neubauer/papers/icfp02.pdf http://www.informatik.uni-freiburg.de/~neubauer/papers/icfp02.ps.gz -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig "Injustice is happening now; suffering is happening now. We have choices to make now. To insist on absolute certainty before starting to apply ethics to life decisions is a way of choosing to be amoral." -Richard Stallman ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: type class instance selection & search
Conal Elliott <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > I keep running into situations in which I want more powerful search in > selecting type class instances. I agree that it's quite useful for instance search to backtrack, if not desirable in all cases. Proof search is program search, after all. Of course, allowing undecidable instances, we can build backtracking into instance search ourselves by representing the state of a backtracking machine as a type. http://okmij.org/ftp/Haskell/poly2.txt -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig And if thou gaze into the abyss, the abyss...actually finds you pretty creepy. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Infinite, open, statically constrained HLists
[EMAIL PROTECTED] wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > We show a presentation of heterogeneous sequences that admits infinite > sequences and permits post-hoc addition of new elements, even to an > already infinite sequence. We can also assert static constraints, > e.g., the sequence must be made of non-decreasing Peano numerals. Our > sequences permit all the common operations such as `head', `tail', > `cons', `map', `take' and `fold'. It is a type error to attempt to > take `head' of an empty sequence. Any finite sequence is > inter-convertible with the HCons-based HList. I understand this technique as switching (at the type level) from a nested tuple to a function from natural numbers. If that's correct, would it also be possible to switch to a lazy list at the type level? That is, one would revise the HList library to always "force"/"evaluate" an HList type before matching it against HNil or HCons. class Force thunk result | thunk -> result where ... A new and possibly infinite HList would be defined by defunctionalizing type-level thunks. Existing HLists would continue to work because we can define "instance Force (HCons a b) (HCons a b)". Just a thought... -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Batman don't...but Kathmandu! ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Discrete event simulation
Paul Johnson <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in
gmane.comp.lang.haskell.general:
> I want to do some fairly straightforward discrete event simulation.
> Tasks do side effects, probably in the ST monad. Every so often the
> current task calls "delay n" where n is a number of seconds. This puts
> the task back on a list of schedulable processes that is ordered by
> time, and then takes the head of the list and starts executing it.
>
> Part of this will be some kind of synchronisation primitive. I don't
> much care what it is, but somewhere I need a way to make a process wait
> until something happens rather than just a constant time.
You'd be interested in Jan Christiansen and Frank Huch's ICFP 2004
paper, where they build a replacement IO monad to debug concurrent
programs. Abstract: "This paper presents an approach to searching for
deadlocks in Concurrent Haskell programs. The search is based on a
redefinition of the IO monad which allows the reversal of Concurrent
Haskells concurrency primitives. Hence, it is possible to implement
this search by a backtracking algorithm checking all possible schedules
of the system. It is integrated in the Concurrent Haskell Debugger
(CHD), and automatically searches for deadlocks in the background while
debugging. The tool is easy to use and the small modifications of the
source program are done by a preprocessor. In the tool we use iterative
deepening as search strategy which quickly detects deadlocks close to
the actual system configuration and utilizes idle time during debugging
at the best."
Ignoring non-integral delays and synchronisation primitives for the
moment, your problem is equivalent to breadth-first search (on top of
mutable state). Kiselyov, myself, Friedman, and Sabry's functional
pearl in ICFP 2005 shows how to build breadth-first search as a monad
transformer (which can be applied to a state monad).
> I think I want to use something like
>type Task r s a = ContT r (ST s) a
Indeed continuations need to be involved, in one way or another. The
key is that the answer type ("r" above) has to recursively mention
the type of tasks, because a suspended task is a function from a
resumption signal to a resumed task. This basic idea is behind the
last programming example in Filinski's POPL 1999 paper ("a simple
resumption-based semantics of concurrency allows us to directly simulate
a shared-state program across all possible dynamic interleavings of
execution threads"). See also Ganz, Friedman, and Wand's ICFP 1999
paper (and references therein), and Kiselyov's simulation of dynamic
delimited-control operators in terms of static ones (Indiana CS TR 611).
--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Can't sleep, clown will eat me.
---
"Unlike you I get Windows shoved down my throat at work."
Ooh, that's a pane in the neck.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Announcing Djinn, new version 2004-12-13
Lennart Augustsson <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > There is a new version of Djinn available, with two notable > new features: Haskell data types can be defined and the > found functions are sorted (heuristically) to present the > best one first. Hello, I wonder why the only Church numerals Djinn found were 0 and 1? Djinn> :set +m Djinn> num ? (a -> a) -> (a -> a) num :: (a -> a) -> a -> a num x1 x2 = x1 x2 -- or num _ x2 = x2 Very cool, in any case. Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Medicine makes people ill, mathematics makes them sad, and theology makes them sinful. -- Martin Luther (1483-1546) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Monads vs. continuations
Gregory Woodhouse <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > Okay, this seems sensible enough. Loosely speaking, I see this code > as getting a line, checking to see if it's empty. If it is, it just > quits (returning the "empty" value). Otherwise, it prints line, and > invokes itself through a *new* do statement. That seems awfully like > using a continuation to track the input stream as part of the > environment. But it seems obvious to me that here is something I'm > not understanding here. I think of the do as providing an appropriate > continuation (one in which the line just read is gone) to pass to the > next call. Given your understanding of continuations, it may be more appropriate for you to think in terms of not "do" but the underlying combinations of "return" and ">>=" that "do" is syntactic sugar for. It may also help to consider monads other than IO, for example the input and output monads described in Section 7.3 of Philip Wadler's article "Comprehending Monads". I suspect that your understanding described in the paragraph above is essentially correct. You can also find more information on the relation between continuations and monads in: - Section 7.4 of "Combinations Monads", - Andrzej Filinski's articles "Representing Monads" and "Representing Layered Monads", and his dissertation "Controlling Effects", - Philip Wadler's article "Monads and Composable Continuations", - Section 3.2 of Philip Wadler's article "How to Declare an Imperative". -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2005-11-06 Against Exploiting the Environment in War http://tinyurl.com/adhg9 2005-11-20 Universal Children's Day http://www.un.org/depts/dhl/children_day/ 2005-11-25 Elimination of Violence Against Women http://tinyurl.com/drd57 2005-11-25 Buy Nothing Day http://www.buynothingday.co.uk/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Writing large n-dim un-boxed array of Int32 quickly?
Rene de Visser <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > To do this I need to cast my 5 dimensional array to a 1 dimensional > array? Does this work? i.e. how do I know that GHC uses a flat array > representation for multidemsional arrays (rather than a nested model > using pointers). You know that the array type you are using uses a flat representation because -it- doesn't know what index type you are using. IOUArray must be polymorphic over the index type (the first argument to the type constructor IOUArray), so it can't do anything with the indices that the Ix type class doesn't tell it how to do. The Ix type class doesn't tell IOUArray how many dimensions you have. But you may also want to look into StorableArray. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2005-11-06 Against Exploiting the Environment in War http://tinyurl.com/adhg9 2005-11-20 Universal Children's Day http://www.un.org/depts/dhl/children_day/ 2005-11-25 Elimination of Violence Against Women http://tinyurl.com/drd57 2005-11-25 Buy Nothing Day http://www.buynothingday.co.uk/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: manipulating untyped lambda-calculus in Haskell
Vivian McPhail <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > It seems that I must be missing something? Is there a more elegant > way of doing this? Check out the "generalized algebraic data types" feature (GADT, one of its many names), now available in GHC. One classical example of its use is to write type-safe interpreters similar to your NL parser. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Science operates according to a law of conservation of difficulty. The simplest questions have the hardest answers; to get an easier answer, you need to ask a more complicated question. -- George Musser. Color Madness. Oddball maps can require more than four colors. Sci. Am., January 2003. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Typing in haskell and mathematics
Jeremy Gibbons <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > But in FP, of course, functions are first class citizens. So one may get > ambiguities on account of it being reasonable to treat a particular > function either as "program" or as "data" - with conflicting outcomes... > Suppose one wants to streamline notation, so > that instead of having to write > (f . g) $ x > one can write > f @ g @ x > Here, "@" means either composition or application according to context. It > is supposed to be associative, so it isn't the same as normal Haskell $; > in particular, > f @ g > is valid and represents the composition of f and g. Indeed, I've been thinking about such a notation, but one that explicitly specifies whether to treat a function as "program" or "data". Variables like "f" always denote data to start with; such data can be thought of as a program that maps unit to a function. Data can be turned into a program by unquoting it with "," (usually I write "@" for unquotation but you use it for composition already). (Conversely, a program can be turned into data by enclosing it in a pair of quotation brackets "[]", a la Joy; unquotation cancels quotation by the reduction step ,[X] => X.) Now (f . g) $ x in Haskell notation is written ,f @ ,g @ x We also distinguish between ,thrice @ thrice and ,thrice @ ,thrice An advantage of this notation is that it exposes the symmetry between call-by-value and call-by-name evaluation: right-to-left evaluation here corresponds to call-by-value, argument-first evaluation; left-to-right evaluation here corresponds to call-by-name evaluation. I could go on and on about this. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig War crimes will be prosecuted. War criminals will be punished. And it will be no defense to say, "I was just following orders."' George W. Bush, address to the nation, 2003-03-17 http://www.whitehouse.gov/news/releases/2003/03/20030317-7.html ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Parameterized Show
George Russell <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > > Ken Shan's paper, the above and the following messages > > http://www.haskell.org/pipermail/haskell/2004-September/014515.html > > argue that Haskell already has the full power of Standard ML's > > structures and functors (and not only generative but applicative > > functors as well). > So does a Turing machine for that matter. The fact that you can translate > Standard ML's functors into rather cumbersome Haskell proves nothing. A quick note on this point: the translation I present in that paper preserves type abstraction, in the sense that you won't be able to distinguish between an encoded complex number stored as Cartesian coordinates and an encoded complex number stored as polar coordinates. Or so I claim (; just to get across the intuitive difference between a translation into Turing machine code and my translation into System F-omega. But more importantly, I don't think the outcome of the translation is necessarily "rather cumbersome Haskell". Mark Jones's tutorial "Functional Programming with Overloading and Higher-Order Polymorphism" shows many elegant programming examples that would be written in ML with functors, and whose higher-kinded types fall within the range of (in other words, are explained by) my translation. As you suggest, we should try to bridge Haskell's high-power type and type-class system with ML's module system, quite possibly to mutual benefit, but dynamic scoping may not be part of the bridge. For example, perhaps what you are getting at is some kind of "import" or "open" mechanism to select a type-class instance, but of course I am unclear on the details. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig A Bush re-election would galvanise the opposition http://guardian.co.uk/print/0,3858,5054048-114515,00.html Nato is a threat to Europe and must be disbanded http://guardian.co.uk/print/0,3858,5057388-111202,00.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Applicative translucent functors in Haskell
On 2004-09-08T19:46:55+0200, Tomasz Zielonka wrote:
> On Wed, Sep 08, 2004 at 04:27:23PM +0100, Simon Peyton-Jones wrote:
> > The ML orthodoxy says that it's essential to give sharing constraints by
> > name, not by position. If every module must be parameterised by every
> > type it may wish to share, modules might get a tremendous number of type
> > parameters, and matching them by position isn't robust. I think that
> > would be the primary criticism from a programming point of view. I have
> > no experience of how difficult this would turn out to be in practice.
> How about named fields in type constructors? Something like Haskell's
> records but at type level. Seems like a fun extension ;)
Proponents of ML-style module systems emphasize the advantage
of "sharing by specification" (or "fibration") over "sharing by
construction" (or "parameterization") (MacQueen 1986; Pierce 2000;
Harper and Pierce 2003). As Simon Peyton-Jones noted, in the context
of our translations of ML-style modules into System F-omega and
Haskell, sharing by specification gives type-equality constraints by
name, whereas sharing by construction gives type-equality constraints
by position. Harper and Pierce (2003; Pierce 2000) give examples of
modular programming where the latter approach can lead to an exponential
number of parameters, which are clumsy to deal with at best. It has
been often suggested that records at the type level be introduced to
address this issue (Jones 1995, 1996; Shao 1999a,b; Shan 2004; Tomasz
Zielonka in this discussion thread).
In this message, we (Oleg Kiselyov and Chung-chieh Shan) translate
Harper and Pierce's example into Haskell, using only the most common
Haskell extensions to give type-equality constraints by name and avoid
an exponential blowup. This exercise suggests that, while type-level
records may be convenient to have in Haskell, they may not be strictly
necessary to express sharing by specification. As shown below, we
can indeed refer to type parameters "by name", taking advantage of
the ability of a Haskell compiler to unify type expressions and bind
type variables. Our technique may be generalizable to encode all
sharing by specification. We hope this message helps clarify the
difference between the two sharing styles, and relate the ML and Haskell
orthodoxies.
First, let us demonstrate the exponential explosion of type variables.
We again will be using OCaml and Haskell in parallel, to make our
Haskell translation of module expression clearer. Later we shall
show how we prevent the exponential explosion in Ocaml -- and how
to translate that solution to Haskell. Again this message is a
doubly-literal code: both in OCaml and Haskell. It can be loaded in
GHCi or Hugs -98 as it is. To get the OCaml code, please filter the
text of the message with "sed -n -e '/^}/ s/^} //p'"
> {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-}
> module FNs where
(The final solution arrived at by the end of this message does not
require -fallow-undecidable-instances above.)
Let us consider a module of the following interface (a signature, in
ML speak):
} module type FN = sig
} type a
} type b
} val app : a -> b
} end
This is the interface of a regular function. It can be thought of
as a compiler stage or network protocol stack that translates one
intermediate language or representation (type a) into another (type b).
Here are two sample modules of that signature:
} module TIF = struct
} type a = int
} type b = float
} let app x = float_of_int x
} end
}
} module TFI = struct
} type a = float
} type b = int
} let app x = truncate x + 1
} end
In our Haskell translation, a signature corresponds to a type class,
and an implementation (a structure, aka module) to an instance:
> class NFN a b where
> napp:: a -> b
>
> instance NFN Integer Float where
> napp x = fromInteger x
>
> instance NFN Float Integer where
> napp x = truncate x + 1
Let us write a module that represents a composition appr . appl of
two FN-functions: appl: al->bl and appr: ar->br. In order for the
composition to be well-formed, the result type of appl must be the
argument type of appr: bl = ar (which we will call the intermediate
type t). Let us further suppose that we wish to make this intermediate
type explicit (e.g., for inspection, to resolve overloading, to invoke
the two intermediate functions separately, etc). Thus we arrive at the
following interface:
} module type NFN1 = sig
} type a1
} type t
} type b1
} val app1 : a1 -> b1
} end
Or, in Haskell
> class NFN1 a t b where
> napp1:: t -> a -> b
Note that the type of the intermediate result is really needed in
Haskell, to resolve the overloading and properly select the instance.
The composition of two modul
Re: [Haskell] Applicative translucent functors in Haskell
On 2004-09-08T16:27:23+0100, Simon Peyton-Jones wrote: > You might want to show it to Derek Dreyer and other ML module experts. I'm trying; I'm trying. (: > The ML orthodoxy says that it's essential to give sharing constraints by > name, not by position. If every module must be parameterised by every > type it may wish to share, modules might get a tremendous number of type > parameters, and matching them by position isn't robust. I think that > would be the primary criticism from a programming point of view. I have > no experience of how difficult this would turn out to be in practice. On 2004-09-08T19:46:55+0200, Tomasz Zielonka wrote: > How about named fields in type constructors? Something like Haskell's > records but at type level. Seems like a fun extension ;) I do believe that the potential exponential blowup in expressing sharing constraints is an issue that needs to be addressed in practice, and that named fields in type constructors (in other words, record kinds) would be the main part of the solution. Section 5.1 of my paper (http://www.eecs.harvard.edu/~ccshan/xlate/) has some discussion and pseudocode. Comments are greatly appreciated of course! Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig "[Programming] Languages shape the way we think, or don't." -- Eric Naggum 2004-09-21 International Day of Peace http://www.un.org/events/peaceday/ Rich Zitola for Massachusetts State Senate (Worcester and Middlesex District) http://www.vote-zitola.org/ signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Initialisation without unsafePerformIO
On 2004-06-04T13:56:34-0400, Abraham Egnor wrote: > I don't see how this technique can be at all safe: > > instance ReflectStorable s => Reflect (Stable s a) a where > reflect = unsafePerformIO $ > do a <- deRefStablePtr p >freeStablePtr p >return (const a) > where p = reflectStorable (undefined :: s p) > > reify :: a -> (forall s. Reflect s a => s -> w) -> w > reify (a :: a) k = unsafePerformIO $ > do p <- newStablePtr a >reifyStorable p (\(_ :: s p) -> k' (undefined :: Stable s a)) > where k' (s :: s) = (reflect :: s -> a) `seq` return (k s) > > The above means that a StablePtr will be allocated once per reify and > destroyed once per reflect; I don't see how the code can guarantee > that there will be only one reflect per reify. In fact, it seems > quite likely that there will be far more reflects than reifys. But (in a typical Haskell implementation) the action supplied as an argument to unsafePerformIO is only performed once. The result is memoized for future use. In particular, "reflect" only calls "freeStablePtr" the first time it is invoked; thereafter it simply produces the function "const a" that was computed the first time. You can easily verify for yourself that "deRefStablePtr" is called exactly once per "newStablePtr", regardless of whether the reified value is looked up once, multiple times, or not at all. (The "not at all" case is dealt with by the "seq".) In any case, if you don't trust this explanation, then you can use the preceding pieces of code in Section 4. The memory leak that this code eliminates only exists for non-serializable data types, and only significant if your program generates and discards many sets of non-serializable parameters outside the IO monad over its lifetime. Oleg + Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig I HATE SIGNATURES. AND I HATE MYSELF FOR USING THEM. signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Initialisation without unsafePerformIO
On 2004-06-04T03:35:25-0700, John Meacham wrote: > Yeah, such an extension would need to ensure initializers are > monomorphic. another advantage of a special syntax rather than > unsafePerformIO. A next thing to worry about is the order of initialization, especially when mutually recursive imports are involved. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig unsafePerformIO is NOT Haskell! signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Initialisation without unsafePerformIO
On 2004-06-01T18:06:36+0200, George Russell wrote: > The most common use of unsafePerformIO, for me at least, is initialisation. > There *surely* must be a better way of doing this, but I haven't really > seen much discussion of the topic. Here is my back-of-the-envelope > suggestion for a new interface, can anyone do better? Oleg and I summarize the existing solutions to the configuration problem in Section 2 of our draft paper at http://www.eecs.harvard.edu/~ccshan/prepose/ We then propose a new solution. Implicit configuration -- or, type classes reflect the value of types The _configuration problem_ is to propagate run-time preferences throughout a program, allowing multiple concurrent configuration sets to coexist safely under staticly guaranteed separation. This problem is common in all software systems, but particularly acute in Haskell, where currently the most popular solution relies on unsafe operations and compiler pragmas. We solve the configuration problem in Haskell using only widely implemented and stable language features like the type class system. In our approach, a term expression can refer to run-time configuration parameters just as it refers to compile-time constants in global scope. Besides supporting such intuitive term notation, our solution also helps improve the program's performance by transparently dispatching to specialized code at run-time. We can propagate any type of configuration data -- numbers, strings, IO actions, polymorphic functions, closures, and abstract data types. The enabling technique behind our solution is to propagate values via types (literally), with the help of polymorphic recursion and higher-ranked polymorphism. The technique essentially emulates local type-class instance declarations. Configuration parameters are propagated throughout the code implicitly as part of type inference rather than explicitly by the programmer. We are thinking of submitting this paper to the Haskell workshop. Any comments would be appreciated, especially before Friday. (: Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2004-06-05: World Environment Day http://www.unep.org/wed/2004/ 1 000 000 Europeans demand the exit of nuclear power www.atomstopp.at/1million/ signature.asc Description: Digital signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] return?
On 2004-04-29T18:27:32-0500, [EMAIL PROTECTED] wrote:
> While writing monad programs, I sometimes want to do a return as it is in
> imperative program. i.e.,
> do{return 1; return 2} is same as return 1
Hello,
You can build an error monad transformer along the lines of the
Control.Monad.Error module, in particular the ErrorT data type there
(but without the Error class). You can then replace "return" above with
"throwError" for your error monad transformer.
Ken
--
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
BBC News: Universities face week of protest
http://news.bbc.co.uk/1/hi/education/3508209.stm
pgp0.pgp
Description: PGP signature
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
