User loginNavigation |
FunctionalComputational Semantics with Functional Programming
The manuscript of the book Computational Semantics with Functional Programming by Jan van Eijck and Christina Unger, as well as related software, is available online.
The introductory chapters are probably going to be unnecessary for LtU readers, but once things get going there is a lot to learn here if you are interested in formal semantics of natural language, especially in the Montague-style. And if this doesn't ring a bell - just search for "continutation" in the manuscript, and be prepared to meet old friends (you know who you are) in a new context. If the contributing editors will neglect their duties, LtU will wither and die. Hint, hint. Delimited Control in OCaml, Abstractly and Concretely, System DescriptionDelimited Control in OCaml, Abstractly and Concretely, System Description
Oleg was kind enough to send me an e-mail letting me know of this paper's existence (it appears not yet to be linked from the "Computation" page under which it is stored) and to include me in the acknowledgements. Since the paper in its current form has been accepted for publication, he indicated that it can be made more widely available, so here it is. In typical Oleg fashion, it offers insights at both the theoretical and implementation levels. By Paul Snively at 2010-01-25 17:27 | Cross language runtimes | Functional | Implementation | Semantics | Type Theory | 3 comments | other blogs | 8532 reads
Syntactic Proofs of Compositional Compiler CorrectnessSyntactic Proofs of Compositional Compiler Correctness
A submitted draft of another paper from Adam, continuing to expand LambdaTamer's reach. By Paul Snively at 2010-01-09 17:10 | Functional | Implementation | Lambda Calculus | Semantics | Type Theory | 4 comments | other blogs | 8934 reads
A Verified Compiler for an Impure Functional LanguageA Verified Compiler for an Impure Functional Language
Further work on/with LambdaTamer for certified compiler development. By Paul Snively at 2010-01-09 17:03 | Functional | Implementation | Lambda Calculus | Semantics | Type Theory | 4 comments | other blogs | 9714 reads
Certified Programming With Dependent Types Goes BetaCertified Programming With Dependent Types From the introduction:
This is the best Coq tutorial that I know of, partially for being comprehensive, and partially for taking a very different tack than most with Adam's emphasis on proof automation using Coq's Ltac tactic language. It provides an invaluable education toward understanding what's going on either in LambdaTamer or Ynot, both of which are important projects in their own rights. Please note that Adam is explicitly requesting feedback on this work. By Paul Snively at 2010-01-09 16:56 | Functional | Lambda Calculus | Logic/Declarative | Misc Books | Semantics | Teaching & Learning | Type Theory | 6 comments | other blogs | 10894 reads
John Hughes on Erlang and HaskellJohn Hughes talks about his experience with Erlang vs. Haskell in an InfoQ Interview. While the discussions about strict vs lazy, pure vs side effecting, and dynamic vs static typing are interesting he raises a good question for the LtU crowd at the end:
So, LtU, where is the next order of magnitude coming from? Causal Commutative Arrows and Their OptimizationCausal Commutative Arrows and Their Optimization, Hai Liu. Eric Cheng. Paul Hudak. ICFP 2009.
One way of understanding what is going on in this paper is that in terms of dataflow programming, FRP programs correspond to programs with single-entry, single-exit dataflow graphs. This means that none of the internal dataflow nodes in an FRP program are actually necessary -- you can coalesce all those nodes into a single node while preserving the observable behavior. (They briefly touch on this point when they mention that synchronous languages try to compile to "single loop code".) What's very slick is that they have a nice normal form procedure that (a) is defined entirely in terms of their high-level language, and (b) always yields code corresponding to the the coalesced dataflow graph. It's an elegant demonstration of the power of equational reasoning. SequenceL - declarative computation on nonscalarsI recently came across the language SequenceL, which it seems NASA is using in some of its human spaceflight programs. SequenceL is described as a high-level language for declarative computation on nonscalars. One of the key features of the language appears to be the avoidance of the need to explicitly specify recursive or iterative operations. For example, given the function definition Search(scalar Target, tuple [Subscript, Word]) = Subscript when Word = Target which applies to tuples, the programmer can apply the function directly to lists of tuples without any need to specify how that application will be performed, e.g. search(fox,[[1,dog],[2,cat],[3,fox],[4,parrot]]) → 3 search(rabbit,[[1,dog],[2,cat],[3,fox],[4,parrot]]) → [] The language designers (Daniel Cooke and J. Nelson Rushton) claim that this kind of thing leads to more concise and readable code, and a more direct representation of a specification. Unfortunately, the SequenceL website appears to be inaccessible at the moment. However, Daniel Cooke's site includes links to a number of papers and talks that describe SequenceL. In particular, the paper Normalize, Transpose, and Distribute: An Automatic Approach for Handling Nonscalars provides a detailed description of the "Consume-Simplify-Produce/Normalize-Transpose" approach that is embodied by SequenceL. There's also an overview of SequenceL available through CiteSeer. By Allan McInnes at 2009-10-11 21:34 | Functional | Logic/Declarative | 13 comments | other blogs | 12263 reads
A Type-theoretic Foundation for Programming with Higher-order Abstract Syntax and First-class Substitutions
A Type-theoretic Foundation for Programming with Higher-order Abstract Syntax and First-class Substitutions by Brigitte Pientka, appeared in POPL 08.
Higher-order abstract syntax (HOAS) is a simple, powerful technique for implementing object languages, since it directly supports common and tricky routines dealing with variables, such as capture-avoiding substitution and renaming. This is achieved by representing binders in the object-language via binders in the meta-language. However, enriching functional programming languages with direct support for HOAS has been a major challenge, because recursion over HOAS encodings requires one to traverse - abstractions and necessitates programming with open objects.Its been a while since I posted, but this paper appears that it may be of interest to some members of this community. It looks interesting to me, but I just wish I understood all the terminology. I don't know what "open objects" are, and why they are a problem. I don't understand what HOAS is. I don't even know what binders are. The list goes on. I surely can't be the only person who is interested, but feels that this is just out of their grasp. I bet that I probably could understand these things with a minimum of explanation, given I have experience implementing languages. If anyone is interested in rephrasing the abstract in more basic terms, I would be very appreciative. [Edit: corrected spelling of Brigitte Pientka. My apologies.] By cdiggins at 2009-10-03 18:51 | Functional | Semantics | Theory | 26 comments | other blogs | 18290 reads
Parallel Performance Tuning for Haskell
Parallel Performance Tuning for Haskell. Don Jones Jr., Simon Marlow, and Satnam Singh.
Parallel Haskell programming has entered the mainstream with support now included in GHC for multiple parallel programming models, along with multicore execution support in the runtime. However, tuning programs for parallelism is still something of a black art. Without much in the way of feedback provided by the runtime system, it is a matter of trial and error combined with experience to achieve good parallel speedups. This paper describes an early prototype of a parallel profiling system for multicore programming with GHC. The system comprises three parts: fast event tracing in the runtime, a Haskell library for reading the resulting trace files, and a number of tools built on this library for presenting the information to the programmer. We focus on one tool in particular, a graphical timeline browser called ThreadScope. The paper illustrates the use of ThreadScope through a number of case studies, and describes some useful methodologies for parallelizing Haskell programs.
By Ehud Lamm at 2009-09-03 22:03 | Functional | Parallel/Distributed | 5 comments | other blogs | 12258 reads
|
Browse archives
Active forum topics |
Recent comments
23 weeks 2 days ago
23 weeks 2 days ago
23 weeks 2 days ago
45 weeks 4 days ago
49 weeks 6 days ago
51 weeks 3 days ago
51 weeks 3 days ago
1 year 2 weeks ago
1 year 6 weeks ago
1 year 6 weeks ago