User loginNavigation |
LtU ForumD3: Thinking with JoinsD3 is a popular HTML5 visualization framework. While similar to other JS frameworks in its exposure of CSS/SVG, its enter()/exit() abstraction is an elegant leap for structuring code. Check out Mike Bostock's short and direct explanation Thinking with Joins:
I particularly appreciated the practicality of this model for designing animated transitions. You can also check out the beautiful gallery of examples. By lmeyerov at 2012-05-24 03:33 | LtU Forum | login or register to post comments | other blogs | 448 reads
Languages with 'unique' programsHas there been any PL research into languages where every semantically distinct program has exactly one representation in the source language? In other words, a language where for any given set of inputs, any change in the source text will create a program that for the same set of input produces a different set of outputs than the original program. Basically taking Python's "there should be one-- and preferably only one --obvious way to do it" philosophy to its logical extreme. I'm interested in how limiting this is on what you can express, since for any two equivalent algorithms only one of them could be written in the language. Is there an established technical term for this I can Google? Languages & NichesHi there, I've been reading LtU for a while now, but I finally took the plunge and registered. I'm mostly self-taught and I can appreciate the quote by Dominic Fox on the Policies page. Hopefully, at worst I'm a newbie and not a wannabe. Anyways, I'm working on designing my own language, and I've actually settled most of the design choices, even started writing up parts of the compiler front-end. Before I finally start setting things in stone though, I wanted to step back and make sure I'm not missing anything. I think it's interesting that the past few stories have been more about the "pragmatics" (if I can sneak in a linguistics term) of languages: adoption, tool-support, an active community. I found the comments to the story on R really interesting especially starting here. I think Dennis Ritchie's advice on not expecting to become a superstar is apt too, but I figure if I'm going to put a lot into this project, shoot for the moon, right? When it comes to adoption though, I think Peter Gabriel's "Worse is Better" makes sense. Needs either arise or remain that other languages don't fill. It's almost evolutionary, where a new niche opens up and the first language into it, even if it's far from perfect, gets the opportunity and support to adapt. I've read a lot of opinions that handling concurrency well is the current big hurdle to clear, but I've also read a few logical arguments that concurrency is a hyped issue. I'm far from the most experienced or smartest about this so I was wondering if anyone, based on their own research or work, had a different opinion on what the great, unfilled niche is. My own impression is that a toolchain and primitives that help simplify parallelism over data and air-tight security are actually stronger needs (like E?), but I could see concurrency being valuable for real-time systems. Obviously, I'm going to make the language as complete as possible, but there's a point past which you just burn yourself out. If there are any articles or papers I should check out, I'd really appreciate it. Besides that, I hope this isn't too long or off topic, and I look forward to being part of the site. Predicates, ghost predicates and higher order predicatesThis short article describes how predicates are handled in Modern Eiffel. In a similar manner as with functions(described in Functions ... ), predicates can be ghost predicates and/or higher order predicates. By hbrandl at 2012-05-17 19:27 | LtU Forum | login or register to post comments | other blogs | 601 reads
Encoding System Fw in predicative dependent type theorySystem Fω appears impredicative, but I'm wondering if there is an easy way to embed it into predicative dependent type theory by inferring bounds on universes. Also, if anyone can provide an example of a System Fω term that would be rejected by Coq's typical ambiguity resolver, that would be helpful to me. Any references or thought are appreciated. [ANN] Call for Speakers - FP Days 2012 - Cambridge, October 25-26thFP Days is a practically-focussed event for people working with or interested in learning Functional Programming. We're looking for enthusiastic speakers to share their practical experiences of Functional Programming. Accepted speakers pay no conference fees. You don't have to be a big name and we encourage and support first-time speakers willing to share their experiences. CALL FOR SPEAKERS - SUBMISSION DEADLINE JULY 6TH We are seeking high-quality session proposals covering any aspect of functional programming. Hands-on sessions, experience reports, tutorials, panels and other interactive sessions are particularly encouraged although more theoretical sessions are also welcome. In addition to free entry for the conference, being a speaker gives you a unique opportunity to present your viewpoint to our audience and get feedback. MAKING A PROPOSAL Making a session proposal isn't difficult. All we require is some basic information on the session you plan to run - enough to judge that it would be of value to our participants. Please visit http://www.fpdays.net/fpdays2012/index.php for more information. By Mark Dalgarno at 2012-05-13 19:32 | LtU Forum | login or register to post comments | other blogs | 384 reads
Reducers - A Library and Model for Collection ProcessingRich Hickey's post on Reducers - A Library and Model for Collection Processing By adopting an alternative view of collections as reducible, rather than seqable things, we can get a complementary set of fundamental operations that tradeoff laziness for parallelism, while retaining the same high-level, functional programming model. Because the two models retain the same shape, we can easily choose whichever is appropriate for the task at hand. Proofs as programsMany software developers are turned away from verification techniques because providing proofs for algorithms seems something horrible and pureley theoretical to them. A newcomer to a proof assistant like Coq or Isabelle needs at least two weeks to be able to prove some simple theorems. And it is difficult to realize that proving has something to do with programming. In order to provide software verification for the masses a different approach is necessary. If one gains more experience with proofs one realizes that writing a proof is not very different from writing a program. Currently I try to exploit the technique of writing a proof like a program. This led to the notion of proof procedures. With proof procedures there is no need to issue proof commands to some proof engine to manipulate the state of the engine. One just writes assertions (i.e. boolean expressions) in a step by step logical manner. A proof look like a procedure. The article Proofs made easy with proof procedures describes the basic approach. On the Naturalness of SoftwareA paper in ICSE 2012 by Abram Hindle, Earl Barr, Zhendong Su, Mark Gabel, and Prem Devanbu. Abstract:
More a visionary paper, but seems to be the best work I've seen so far on how to apply ML to programming. Feather: A Heapless Functional Programming LanguageHi all! I'm busy designing my third language (or, redesigning the first, depending on how you look at it). I changed Feather to be a heapless functional programming language. Primarily, this means there is no need for a garbage collector. Programs for embedded devices that have real-time constraints stand to benefit the most from this. With any luck, we could get a subset to compile to some GPUs. Here's the design as it is. Note that I use underscores for tabs whitespace due to forum restrictions -
Feather’s lack of heap is accomplished by extending the end frame pointer for previous stack frames whose return slot uses the data of the successive frames that the end frame pointer is extended over. This elides the need for any type of garbage collection. The cost is that a bunch of dead ‘popped’ variables also get extended over, but this shouldn’t be a big problem in practice when using the techniques described next. Feather can also return closures, but that means the end frame pointer must be extended over the closed-over values, so they must be used with caution. Non-consable return values are placed at the beginning of the next stack frame and the previous end frame pointer is extended over it. Consable return values like lists and maps are treated with more care. When a consable value is to be returned, 8 to 32 slots are allocated at the beginning of the new stack frame, and any conses that take place on the consable return value are placed in one of those slots. (In fact, there may need to be a way to specify what the beginning slot count should be for a given function call.) Further, any conses on those conses will also be placed in one of those slots. If the return slots are finally filled, then n * 4 new slots are allocated past the last stack variable for further use, and so on. An analyzer could be hooked in at run-time to track the average and max allocations needed at each call site to eliminate most needs to do secondary (and so on) allocations for consable return values. There may also be a special cons that allows temporary conses to be used on consable return value that are _not_ placed in the return slots. If one of these accidentally makes it into the returned cons structure, it will be wasteful due to extending the return frame end pointer over that stack variable - but will not be terminal to the program. With these technique, I think a minimum amount of space will be wasted on dead varables, but we'll have to see for sure. Tail-call optimizations should be possible with this set up. There will almost certainly be some restrictions on language's expressiveness due to the heaplessness, but we'll discover and work around those as we go along. For example, I'm not sure if monads will be implementable without a heap, but the syntax is there in case we can. Some syntax - /* multi-line comment /* nests */*/ // function definition syntax uses powerful mix-fixity and repetition specification // function signatures (map)________// partial application. Same as (x, y) ~> x map y () // unit double 5 (x, y) ~> x * x - y // recommended indentation // sequential expression // choice expression // simple match // multi-match // match chain // restricted match (makes inferred function type more specific when using a match) // monad comprehension // functional types ---- Error handling - Uses a system similar to scheme's Condition system. ---- Literal numbers are Int by default - ---- Function type arrows – ---- Uses of semi-colon - ---- Miscellaneous rules - So anyways, I'll keep designing this until I get a chance to start implementing it. I've already implemented a pure functional programming language with F# (see AmlProject at SourceForge), so I've got enough confidence to start on this one. I'm thinking I'll use LLVM to build the compiler. Hopefully this language will finally allow us to program stuff like games for embedded devices and console in a functional style. |
Browse archivesActive forum topics |