- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] semantics
by kevin＠froglingo.com 09 Feb '11

09 Feb '11

On Tue, Feb 8, 2011 at 07:55 pm, Conal Elliott <conal(a)conal.net> wrote: Here's my personal denotational answer to question 2: I think of a type as denoting a collection of (mathematical) values. If an expression e has type T, then the meaning (value) of e is a member of the collection denoted by T. This simple principle, which is fundamental to how I think of functional programming, has consequences in library design, which I've discussed at http://conal.net/blog/posts/notions-of-purity-in-haskell/ . When we consider a class of partial recursive functions as the type T, then what are the expressions (such as e in your statement above) for T? It seems that the type definition missed operations. For example, if a and b are two variables declared as integers, then we would not know how to calculate a + b if the type integers didn't include the plus operator. Defining a type as a set of values and a set of operations on the values is perfectly fine mathematically. But in the context of programming languages, a type seems to need its syntax anyhow in addition to be a set of values and a set of operations on the values. For example the type definition in C: typedef mydata { int a; char c; } The definition itself is the syntax while we may view the infinite many records {<0, 'a'>, <2, 'a'>, ..., <0, 'b>, ....} as its semantics (or the semantics was called a type earlier).

2 1

Re: [Haskell-cafe] semantics
by kevin＠froglingo.com 09 Feb '11

09 Feb '11

On Tue, Feb 8, 2011 at 2:01 PM, Alexander Solla <alex.solla(a)gmail.com> wrote: > It is hard to come up with a single operational semantic for types, because they do so many different things, and there is a semantic for each interpretation. G. Hillebrand, P. C. Kanellakis (in paper "Functional Database Query Languages as Typed Lambda Calculi of Fixed Order" and others) encoded tuples, lists, tables, the relational algebra, complex objects, and others in typed lambda calculus. The different things (I guess we can call them types here) were able to be compared with the uniformed (opeartional) semantics.

1 0

semantics
by Patrick Browne 09 Feb '11

09 Feb '11

Consider the following definitions: 1. Denotational semantics can be considered as relation between syntax and mathematical objects (the meaning of the syntax). 2. Operational semantics can be considered as set of rules for performing computation. Question 1 Applying these definitions in a Haskell context can I say that the lambda calculus provides both the operational and denotational semantics for Haskell programs at value level for definition and evaluations. Question 2 Does it make sense to use these definitions at type level? If so, what exactly do they represent? Thanks, Pat This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie

3 2

Unrecognized function symbols in .prof
by Lee Pike 08 Feb '11

08 Feb '11

Hi, I am profiling a Haskell program using GHC, and after executing the program with +RTS -p, I get a .prof file that lists the cost centers of the program. Some of the cost centers listed are for function symbols that do not exist in the given module. For example, I have in my .prof file: COST CENTRE MODULE %time %alloc ==_a2MT Foo 19.8 0.0 ==_a2R8 Foo 17.8 0.0 ==_a2Bg Bar 13.7 0.0 .... .... It appears these are generated symbols; how do I find out what those function symbols correspond to? (In this case, my assumption is that these symbols refer to instances of the Eq class, but I'm not sure.) [I couldn't find anything about this in the GHC online documentation or via Googling, but sorry if I missed it.] Thanks, Lee

4 4

ACM SIGPLAN Workshop on ML
by Chung-chieh Shan 08 Feb '11

08 Feb '11

ACM SIGPLAN Workshop on ML Sunday, 18 September 2011, Tokyo, Japan (co-located with ICFP) http://conway.rutgers.edu/ml2011/ CALL FOR CONTENT The ML family of programming languages includes dialects known as Standard ML, Objective Caml, and F#. These languages have inspired a large amount of computer-science research, both practical and theoretical. This workshop aims to provide a forum for discussion and research on ML and related technology (higher-order, typed, or strict languages). The format of ML 2011 will continue the return in 2010 to a more informal model: a workshop with presentations selected from submitted abstracts. Presenters will be invited to submit working notes, source code, and extended papers for distribution to the attendees, but the workshop will not publish proceedings, so any contributions may be submitted for publication elsewhere. We hope that this format will encourage the presentation of exciting (if unpolished) research and deliver a lively workshop atmosphere. SCOPE We seek research presentations on topics related to ML, including but not limited to * applications: case studies, experience reports, pearls, etc. * extensions: higher forms of polymorphism, generic programming, objects, concurrency, distribution and mobility, semi-structured data handling, etc. * type systems: inference, effects, overloading, modules, contracts, specifications and assertions, dynamic typing, error reporting, etc. * implementation: compilers, interpreters, type checkers, partial evaluators, runtime systems, garbage collectors, etc. * environments: libraries, tools, editors, debuggers, cross-language interoperability, functional data structures, etc. * semantics: operational, denotational, program equivalence, parametricity, mechanization, etc. Research presentations should describe new ideas, experimental results, significant advances in ML-related projects, or informed positions regarding proposals for next-generation ML-style languages. We especially encourage presentations that describe work in progress, that outline a future research agenda, or that encourage lively discussion. In addition to research presentations, we seek both Status Reports and Demos that emphasize the practical application of ML research and technology. Status Reports: Status reports are intended as a way of informing others in the ML community about the status of ML-related research or implementation projects, as well as communicating insights gained from such projects. Status reports need not present original research, but should deliver new information. In the abstract submission, describe the project and the specific technical content to be presented. Demos: Live demonstrations or tutorials should show new developments, interesting prototypes, or work in progress, in the form of tools, libraries, or applications built on or related to ML. In the abstract submission, describe the demo and its technical content, and be sure to include the demo's title, authors, collaborators, references, and acknowledgments. (Please note that you will need to provide all the hardware and software required for your demo; the workshop organizers are only able to provide a projector.) Each presentation should take 20-25 minutes, except demos, which should take 10-15 minutes. The exact time will be decided based on the number of accepted submissions. We plan to make videos of the presentations available on ACM Digital Library. SUBMISSION INSTRUCTIONS Email submissions to ccshan AT cs.rutgers.edu. Submissions should be at most two pages, in PDF format, and printable on US Letter or A4 sized paper. Persons for whom this poses a hardship should contact the program chair. Submissions longer than a half a page should include a one-paragraph synopsis suitable for inclusion in the workshop program. IMPORTANT DATES * 2011-06-17: Submission * 2011-07-22: Notification * 2011-09-18: Workshop PROGRAM COMMITTEE Amal Ahmed (Indiana University) Andrew Tolmach (Portland State University) Anil Madhavapeddy (University of Cambridge) Chung-chieh Shan (chair) (Rutgers University) Joshua Dunfield (Max Planck Institute for Software Systems) Julia Lawall (University of Copenhagen) Keisuke Nakano (University of Electro-Communications) Martin Elsman (SimCorp) Walid Taha (Halmstad University) STEERING COMMITTEE Eijiro Sumii (chair) (Tohoku University) Andreas Rossberg (Google) Jacques Garrigue (Nagoya University) Matthew Fluet (Rochester Institute of Technology) Robert Harper (Carnegie Mellon University) Yaron Minsky (Jane Street)

1 0

Second call for submissions: Monad.Reader special poetry and fiction edition
by Brent Yorgey 08 Feb '11

08 Feb '11

Ten days until the submission deadline. "Nein": what I won't take for an answer. Eighth to eighteenth February, Seven thousand minutes twice, Sick's he who can't write aught. Five submissions now; Four more, at least? Three'd be fair To no- One. http://themonadreader.wordpress.com/2011/01/19/call-for-copy-special-poetry…

1 0

File position
by Permjacov Evgeniy 08 Feb '11

08 Feb '11

Is there any way to get current position from System.IO.Handle as Integer? If no, what other <b> windows/unix portable</b> IO function set of file io with this functionality you can suggest? keeping track of current position by hand is not an option, sorry. I'm thinking about c's low-level functions such as open, read, write, but there is no such functions in windows and I do not know if libc from haskell platform provides emulation. If it does, I'll use lowlevel c functions brainfree.

2 1

Re: [Haskell-cafe] Byte Histogram
by John Lato 08 Feb '11

08 Feb '11

From: Johan Tibell <johan.tibell(a)gmail.com> > > > > > (The OOP people, of course, just don't bother trying. They use typecasts > > everywhere...) > > > > Do associated types solve this? Or are there still problems? > > Duncan showed me a definition using associated types, which I have > unfortunately forgotten. > Yes, associated types (or fundeps) solve this problem. This problem of container types is one of the motivating examples behind both extensions. I think the real problem we have with container classes has a lot more to do with what we would use them for. That is, Haskell already has Monoid, Foldable and Traversable. These three (especially Foldable) cover nearly everything OOP programmers would expect out of generic container operations. What's missing are classes for specific data types. That is, a Map/Dict interface, a Queue interface, and a Heap interface (probably others too, but these are the first that come to mind). But the standard Data.Map and List (for a queue) seem good enough for most people, so there seems to be a lot of inertia to overcome for these to be popular. John

3 5

Froglingo – a functional programming language
by kevin＠froglingo.com 08 Feb '11

08 Feb '11

Hi, I have recently finished a paper about Froglingo, a programming language designed to make it easier to write data-intensive business applications. It is a monolith consolidating programming, database/file management, data exchange, web server, and access control. What makes Froglingo unique is a sub language that is the first known as semantically equivalent to a class of TOTAL recursive functions. Froglingo shares with Haskell a declarative approach to programming, and strong mathematical foundations, so I thought that people on this list might find it of some interest. You can find the paper at: http://www.froglingo.com/FroglingoPL.pdf. If you have any thoughts about it, I’d love to hear from you. Thank you for your attention. Kevin

1 0

ICFP 2011: Second Call for Papers
by Wouter Swierstra 08 Feb '11

08 Feb '11

===================================================================== Second Call for Papers ICFP 2011: International Conference on Functional Programming Tokyo, Japan, Monday 19 -- Wednesday 21 September 2011 http://www.icfpconference.org/icfp2011 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Titles, abstracts & keywords due: Thursday 17 March 2011 at 14:00 UTC Submissions due: Thursday 24 March 2011 at 14:00 UTC Author response: Tuesday & Wednesday 17-18 May Notification: Monday 30 May 2011 Final copy due: Friday 01 July 2011 Conference: Monday-Wednesday 19-21 September 2011 Scope ~~~~~ ICFP 2011 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Particular topics of interest include * Language Design: type systems; concurrency and distribution; modules; components and composition; metaprogramming; relations to imperative, object-oriented, or logic programming; interoperability * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; mathematical logic; monads; continuations; delimited continuations; global, delimited, or local effects * Transformation and Analysis: abstract interpretation; partial evaluation; program transformation; program calculation; program proofs; normalization by evaluation * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security; education * Functional Pearls: elegant, instructive, and fun essays on functional programming * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * By 17 March 2011, 14:00 UTC, submit a title, an abstract of at most 300 words, and keywords. * By 24 March 2011, 14:00 UTC, submit a full paper of at most 12 pages (6 pages for a Functional Pearl and for an Experience Report), including bibliography and figures. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.acm.org/sigplan/republicationpolicy.htm In addition, authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no rewiewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations will be videotaped and released online if the presenter consents by signing an additional permission form at the time of the presentation. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. If this requirement is a hardship, make contact with the program chair at least one week before the deadline. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available from SIGPLAN at http://www.acm.org/sigs/sigplan/authorInformation.htm Submission: Submissions will be accepted electronically at a URL to be named later. Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 48-hour period, starting at 14:00 UTC on Tuesday 17 May 2010, to read reviews and respond to them. Special Journal Issue: There will be a special issue of the Journal of Functional Programming with papers from ICFP 2011. The program committee will invite the authors of select accepted papers to submit a journal version to this issue. Conference Chairs: Manuel M T Chakravarty, University of New South Wales, Australia Zhenjiang Hu, National Institute of Informatics (NII), Japan Program Chair: Olivier Danvy, Aarhus University, Denmark Program Committee: Kenichi Asai, Ochanomizu University, Japan Josh Berdine, Microsoft Research, UK Adam Chlipala, Harvard University, USA William Cook, University of Texas at Austin, USA Maribel Fernandez, King's College London, UK Ronald Garcia, Carnegie Mellon University, USA Neal Glew, Intel Labs, USA Jacques Garrigue, Nagoya University, Japan Suresh Jagannathan, Purdue University, USA Sam Lindley, University of Edinburgh, UK Frank Pfenning, Carnegie Mellon University, USA Paola Quaglia, University of Trento, Italy Alexis Saurin, University of Paris VII, France Mike Spivey, Oxford University, UK Kristian Stoevring, University of Copenhagen, Denmark Doaitse Swierstra, Utrecht University, The Netherlands David Van Horn, Northeastern University, USA Rene Vestergaard, JAIST, Japan Edwin Westbrook, Rice University, USA

1 0