Lambda the Ultimate

Andrei Alexandrescu describes (PDF) how to get safe functional programming in the otherwise imperative language D.

vs., say, monads.

This question has been bugging me for a while: whats the standard practice of handling comments during parsing? Ignore them or annotate the parsetree? My first thought is to simply let the lexer discard comments. But if the goal is to reproduce the source of the program via a pretty printer or some such, the comments need to come a long for the ride?

What leads me to this line of inquiry is: If I'm a client purchasing a parser should I expect my $20,000 C++ parser (for example, I've read C++ parsers are expensive) to preserve comments?

I've been working on a library to wrap WPF dependency properties with signals so that data binding is easier to do in WPF when using C#:

http://www.codeplex.com/wpfsignals.

Dependency properties by themselves are like signals (time-varying values) but don't support direct transformation (i.e., map) or composition like signals do. Instead, you have to define verbose value converters and jump through a lot of hoops. To solve this problem, the WPF signal library creates a signal-like wrapper around dependency properties so they can support direct transformation and composition; e.g., we can directly express relationships like:

rectangle().top().bind = canvas.height() - rectangle.height()

meaning that the rectangle is stuck to the bottom of the canvas, even as the size of the canvas or rectangle changes.

This is currently a source code release only. SignalLib is a Visual Studio 2008 .NET 3.5 project, and an example application (in the SignalExample project) is provided to help introduce the library. Feedback is appreciated.

I'm going to be doing some traveling in the near future where I won't have my laptop available, but I'd still like to be able to play around with programming a bit. I have an MP3 player running the opensource firmware rockbox, and thought I could develop a plugin for it that would be a programming environment that would let me still code some toy programs relatively quickly despite the player only having 6 buttons.

This presents some unique challenges. Ideas so far:

-Keep naming things to a minimum (since typing variable names by selecting letters from a grid would be really burdensome). I'm thinking of just having a 'new variable' option that would give a variable with an autogenerated name (e.g. 'A1'), with the option to edit the name if things start to become too unreadable.

-Programs are state machines. Press a button to make a state (also having autogenerated names, e.g. 'S1'). Each state has a set of button handlers and a particular screen graphic associated with it. Not necessarily scalable to large programs, but should be sufficient for small ones. This way switching what buttons should do and switching what's on screen involves just picking a state from a list.

-Builtin functions to draw a grid of squares, iterate over all of them by row or by column, and the ability to associate state with each square. Squares will automatically have at least one character variable associated with them, and the value stored in it will be drawn inside the square.

I think this would be enough to implement some simple board games like othello, and some toy programs like say a binary clock. But I'm curious if anyone else has ideas or has worked in a similar environment, say trying to make a programming IDE for a cell phone or other limited input device.

I know this question might have been asked before, but I haven't found any satisfactory answer as of yet. Is C++ effective as a language for scientific computing? How easy it is to create GUIs from simple command line programs in C++ compared to python? In python, I think TK can be used, but what are the steps to go about to do that in C++? And, in terms of speed, where does C++ stand compared to Numpy? I know that C would be faster, but what about C++?

Simple question. What is the latest research into doing the sort of tasks usually done in C/C++ with something else? I'll list three areas I think are important.

1) Ability to interface directly with hardware (i.e. can you write an OS in it)
2) Ability to create compiled binaries and both static and shared libraries
3) Modern features like garbage collection that don't slow the whole thing down to a crawl

I'm aware of OCaml, which seems to fulfill at least #2 and #3 and I know about the House project in Haskell. The latter seems not to have been worked on in about 2 years though. I also know about the D language which seems like a better C++ but not a real departure from what's been going on for 30+ years. More generally, is any significant research into radical new OS concepts going on and what sort of languages are they using?

Lately I've been wondering about a trend in software development: We seem to be grappling not so much with algorithm specification, but rather with the organization of large systems developed by large teams. As such, documentation and testing become almost as relevant as the source code itself. I was wondering whether there were any good languages for writing (1) source code, (2) documentation, and (3) unit tests all in the same location, and in an elegant way?

I'm thinking something like this:

(define (factorial n)
  (returns "the mathematical factorial of n.")
  (if (> n 0)
    (* n (factorial (- n 1)))
    1)
  (such-that
    (and (= (factorial 0) 1)
         (= (factorial 5) 120))))

And it would translate into (1) a function that computed the factorial, (2) a unit test for that function, and (3) this documentation (or something similar):

Factorial (n): Returns the mathematical factorial of n.

Examples: Factorial (0) = 1 (passed), Factorial (5) = 120 (passed).

My initial thought is that it would have to be some sort of Lisp-type macro system, but that's just a guess. Any thoughts would be appreciated.

I've been wrapping a C++ library of mine using Python and have been finding it all quite challenging. One complexity is that I'm using SWIG and my wrappers use objects that are themselves written in C++ and wrapped using SIP and something else too (I think it's called Dart). Apparently all wrapped Python objects are not truly the same in their meta-data and you need to screw around with different ways to extract the pointer to the original C/C++ objects. Anyway, I was wondering what language people thought was the easiest to construct wrappers around compiled (presumably C/C++) code in. I'll consider any paradigm, functional, imperative, OO/non-OO, whatever.

I'm designing (and hopefully implementing) a new programming language. Now, I've taken a bit of language-design advice I once heard from a wise old professor, which is: "Never add an entirely new feature to an entirely new language." Instead, I'm consolidating older, thoroughly-tested ideas whose time has come into a language suited for a domain that has yet to see such features.

The vision? An advanced, almost-type-safe imperative language with functional and object-oriented features for kernel and base-library level systems programming. The goal in creating this? To bring the convenience of high-level language features to low-level programming.

The very foundation of the language is:

1) Lexical scoping.
2) Imperative block structure based on statements.
3) A strong type system with a single exceptional case of code marked "unsafe" (because when writing a kernel you either allow unsafe code somewhere, or develop a type system that could probably win a Turing award).

The features I'm putting in are:

1) Module/unit files. See: Delphi, Python.
2) Lambda functions and full lexical closures. Every function treated as data comes with a closure by default, even when it has no closed-over lexical variables. When a function lacks such variables, the compiler can optimize out their storage, but the type system must treat them as the same! Tail-recursion optimization will be mandatory.
3) Exception handling as seen in Java, C++, Delphi, Python and practically every other modern language. Not having it is downright silly, especially when a clever compiler can allocate an exception object on the stack, thus allowing even the heap allocator to safely throw exceptions.
4) Templates, as almost directly stolen from D. Only types can be passed to templates.
5) Object orientation based on generic functions and specializing multi-methods. However, there won't be pre or post methods, and each class can only inherit from one other class (thus VASTLY simplifying inheritance-related problems). Generic functions and specializing methods are used to provide dynamic method dispatch.
6) The unification of tuples, structures, and classes. A class is merely a structure that can inherit from another class, have methods specialized on it, and have multiple scopes (private, public, protected, et al). A structure is merely a tuple with named members. I see no reason that I can't declare a tuple type in which only some members have names, and leave the language to provide indexes for all, then declare a new tuple type that inherits from the first, and finally specialize a generic function on that latter type.
7) Dynamic arrays, stolen right from Delphi. I will also include static arrays just for the convenience of allocating a known number of items off the stack when heap space often runs scarce at the lowest level.
8) Typed reference values. These function like pointers in that their implementation identifies an address in memory, but to the programmer they can either contain the NULL value or reference a known object whose address was obtained via a take-the-address operator. Objects (as in instances of classes) will be referred to by references only. I'm actually quite on-edge about this one as it will introduce the possibility of dangling references. The level of safety provided by an utterly pointer-less language would be nice, but so would not copying huge amounts of data to pass an object into a function.
9) Blocks of code marked unsafe in which pointers, pointer arithmetic, inline assembly and re-interpretive type casting all become legal. These should only be used for ultra-low-level functions such as writing to device registers, and a perfectly-formed unsafe block will make the compiler emit a warning unless the programmer also marks it assumed safe.
10) Let blocks for variable declaration. Sod just declaring a new variable out of the blue, we should be marking where our variables go into and out of scope.

Features left out as deliberate design decisions are:
1) Type inference. It requires writing an inconveniently extensive type system and disallowing either references or mutable variables.
2) Garbage collection. You guys will hate me for this (because everyone and everything has garbage collection nowadays), but when writing an operating system or a device driver one can't find themselves left at the mercy of a GC, either for performance or safety reasons. For these domains you need a language with such a small runtime-library you can write it in 3 pages of code, or none at all.
3) Looping constructs. In the presence of tail-recursion optimization and templates, they simply aren't needed. Let people write functional code!
4) Concurrency. Once again, you simply don't assume certain language features at the lowest level.
5) Implicit type conversions. The only working implicit conversion will be the assignment of an integer to a floating-point variable.
6) Operator overloading. It makes parsing that much harder.

Now, the things I need your advice about are:
1) Syntax. Should I stick with C-like syntax for familiarity, switch to a Lispy s-expression syntax for metaprogramming capabilities, or use some completely other syntax I haven't thought of?
2) The references. Is not copying data really worth aliasing bugs?
3) Any advice on the implementation of generic-function dispatch, particularly in the case where methods might only become known at link time? I've got a system that will work fairly well already, but it only works when the programmer can only specialize on a generic function in the same module that declares and implements that generic function. Still, assuming that, it can do some work to type-check and ambiguity-check the generic-function call at compile time, resulting in only a small list of the type-safe possible dispatches to be looked up at runtime.
4) Do you think I've completely missed something?

I've got a textbook on compilation techniques and I'm raring to go at this, so please write in any ideas or criticisms you might have. Except about the mandate of garbage collection. I refuse to have my thread scheduler pause for a GC, though I feel quite happy about having one for writing desktop applications.

Chris Oakasaki has a blog post about teaching functional programming using Ada. He says

Why, with excellent functional programming languages like Haskell or ML easily available, would I choose to do a functional programming project in Ada? (I CAN STILL HEAR YOU LAUGHING!) Partly because we use Ada in some courses at our institution, and I wanted a library that could help in teaching recursion to novices. But, honestly, mostly I just wanted to see if it could be done

The idea of crossing paradigms has been around awhile. SICP rather famously introduces object orientation by building it on top of Scheme.

What do you think about teaching or learning paradigm A in a language strongly oriented towards paradigm B? What's gained? What's lost?