User loginNavigation |
archivesFringeDC Formal Meeting March 22nd at 1PM- Haskell Spectacular: XMonad, Zippers and More!FringeDC is a group in Washington DC interested in Fringe Programming Languages (Lisp, Haskell, Erlang, Prolog, etc.) www.lisperati.com/fringedc.html Our next meeting features Brent Yorgey, who is well known in the Haskell community and a contributor to XMonad. For those who don't know, XMonad (a purely functional windows manager) is often lauded (well, by me at least, but others as well :-) as a masterpiece in software engineering. It cleanly marries elegant functional programming code with the ugliest of uglies, the X Windows system. Brent will be giving an intro to Haskell and explain the nuts of bolts of extending XMonad. As an opener, Philip Fominykh will be giving an opening presentation on Zippers, an exotic purely functional data structure popular among Haskellers! The Meeting is will be held on Saturday, March 22nd. It is hosted by Clark&Parsia, a developer of OWL/Semantic Web reasoning software in downtown DC. After the presentation, we'll grab some food nearby and talk programming languages. Address: -Conrad Barski, M.D. (cell 202 436 1388) P.S. We're looking for someone to make a video of the meeting for the interwebs- Bring your camera if you want to help. By drcode at 2008-03-15 14:12 | LtU Forum | login or register to post comments | other blogs | 4378 reads
Higher-Order Programming without Closures?The connections between higher-order functions and closures have been discussed here before, and clearly closures make higher-order programming more expressive. However, closures can sometimes make reasoning about space use and efficiency more difficult, as they penalize all higher-order function call sites (absent whole-program compilation). I wonder if anyone has explored the space of languages with higher-order functions, but without closures. By this I mean that all functions-as-values are restricted to carry no environment, thus reducing them to C-like function pointers. We can add closures back using modules: module type Fun = sig type ('a,'b) t val new: ('a -> 'b) -> ('a,'b) t val apply: ('a,'b) t -> 'a -> 'b end So it's clear from function signatures whether an operation accept a Fun or accepts a function pointer. The space use and efficiency trade-offs are thus quite clear. I don't have a good intuition as to how painful this might be to program with however. Eliminating closures clearly decreases expressiveness, but if we keep an expressive ML-like syntax with type inference, we haven't quite devolved to Java-like verbosity. Have any languages taken this or a similar route? |
Browse archivesActive forum topics |
Recent comments
22 weeks 1 day ago
22 weeks 2 days ago
22 weeks 2 days ago
44 weeks 3 days ago
48 weeks 5 days ago
50 weeks 2 days ago
50 weeks 2 days ago
1 year 6 days ago
1 year 5 weeks ago
1 year 5 weeks ago