Lambda the Ultimate

We remember all too well a recent discussion on LtU in which the OP complained about PLs to be too low level. If I understood correctly the authors goal was a language which is essentially data-driven and has no notion of control flow. The control-flow should somehow emerge from the "need" of data.

After a while this idea started to work in my mind and I remembered reading some papers in the late '90s about the "chemical reaction metaphor" in computing which has some resemblence. I'm not sure if the work of Banatre et al about the Gamma formalism was ever mentioned on LtU so I refer to some papers about Gamma and related topics I found on the Web.

The chemical reaction metaphor
Structured Gamma
Autonomic Computing
Higher Order Chemisty
Parallel Computing
AspectGamma

The title says it all. Asynchronious messages are a very nice solution when you're sending a command (send it and forget it, as opposed to twice the time required waiting for a response). But what about querying for information? In this case you're forced to fake synchronious messanging by maintaining information about your request (either in a hashmap, or in a message itself). Of course continuations are also a nice solution for faking synchronious messages.

It's pretty easy to see how message passing and special scheduling are great paradigms for the type of problems that Erlang was designed to solve. Not so easy for asynchronious messages, though. Can anyone comment on why Erlang designers went with asynchronious messanging? Is it because it's a more general feature and synchronious messages can be implemented on top of them?

This is a continuation of this discussion. The main points for soft typing are as follows.

• Compile time type checks. Soft typing can catch the same amount of provable errors at compile time as static typing.
• Automatic downcasts. Downcasts are done automatically assuming the program passes type checking. The main argument for explicit casts is that it provides the programmer with more information, but this is a misnomer. One does not have to write down information for it to be shown to him, so long as said information is inferrable. Note: whether or not you believe OCaml doesn't have casting is irrelevant, simply assume that, when I refer to casting, I also mean situations in which it's emulated.
• Unimposing. Unless a piece of code is provably incorrect at compile time, the compiler can insert runtime checks.
  

An simple test that is a good predictor of whether a new student with no programming background will pass a progamming course. The test categorises students into three bins - Students that:

• are consistent (those that answer questions according to an internal mental model)
• are inconsistent
• answer no questions (blank)

There is a good correlation between the consistent answerers and their final exam pass rate:

	Consistent(A1)	Inconsistent/Blank (A1)
Pass	21	8
Fail	6	26

The paper The camel has two humps and the homepage of one of the authors have more information. Links found from Hack the planet.

The paper (and the reasoning) seem wishy-washy to me - but the correlation is impressive.

If their premise is correct, I wonder if similar tests could be constructed to help sieve for functional programmers, engineers, or any other logical tasks?

I'm curious if anyone has thought about or know of any languages that are aimed towards solving the parallel class hierarchy problem. If you're unfamiliar it's a term GoF uses a lot -- it refers to when you delegate out part of the responsibilities of a class to another class, so you end up with class hierarchies like:

A -> B
  -> C

AWindow -> BWindow
        -> CWindow

ARenderer -> BRenderer
          -> CRenderer

In this trivial example nested classes can help improve the encapsulation but parallel classes still always have a sloppy feeling to me.

More generally, does the public/protected/private scheme make parallel class hiearchies inevitable? Does AOP handle this problem somehow?

I'm going to write myself a small functional language just for fun. I've previously written an interpreter in Haskell for LC but now I want to try going the route of modern (popular, whatever) languages such as Python or Ruby. So exactly how are those languages implemented?

• Do they generate byte code for a virtual machine?
• Does the virtual machine handle garbage collection?
• What virtual machine would be good to target if I need to implement typical things such tail call optimizations and closures?
• Is parsers/lexers for modern languages handwritten or do they use something like Flex/Bison?
• Is it easier to write an interpreter in C or to generate byte code?

Encoding Information Flow in Haskell by Peng Li and Steve Zdancewic.

This paper presents an embedded security sublanguage for enforcing information-flow policies in the standard Haskell programming language. The sublanguage provides useful information-flow control mechanisms including dynamic secirity lattices, run-time code privileges and declassification, without modifying the base language. This design avoids the redundant work of producing new languages, lowers the threshold for adopting security-typed languages, and also provides great flexibility and modularity for using security-policy frameworks.

The embedded security sublanguage is designed using a sstandard combinator interface called arrows. Computations constructed in the sublanguage have static and explicit control-flow components, making it possible to implement information-flow control using static-analysis techniques at run time, while providing strong security guarantees. This paper presents a concrete Haskell implementation and an example application demonstrating the proposed techniques.

Very interesting use of arrows. EDSL in Haskell with privilege informations encoded in the type, & more; fun!

[Edit: corrected link]

I don't have the time to check this myself, but since more than one member mentioned this item is probably either spam or worse (a virus etc.), I unpublished the item for the moment. If LtU members think the item was legitmate, let me know by replying to this message.

Hi Folks,

I've been following LtU for some time and although I do not understand much of what is on topic here, I've always find some insights I could use on my own projects.

The field of CS that I've always liked best is programming language implementation, but not being in a CS course anymore makes hard for me to get directions on what books to read and stuff like that.

I have the dragon book but the portuguese transaltion is simply horrible to the point that it actually confuses you instead of teaching you.

I'd like if possible that the fine folks here could point me to some good book and maybe point me to some simple interpreter/compiler available on the net, some that can be understood by someone that is starting.

I can undestand C, Scheme, Lisp, Python, much of my work today is done in Runtime Revolution which is a xTalk language inspired by Apple HyperCard, so I'd like some day to be able to implement my own little xTalk interpreter for scripting unix-like systems and for fun. I am very fond of YellowTABs Zeta and of Haiku operating system, I think a little easy to use scripting language would be a nice addition... xTalks are very easy to use, but since, no one is going to implement it, I decided to learn the steps so that I could do it myself.

Any help, clue, ISBN and advise is greatly appreciated.

Cheers
Andre Garzia

I've been doing a lot of OpenGL coding in C++ for my work, and it occurred to me that C++ is a much better language for making DSLs than I first thought. C macros (yes, I know, *shudder*), templates and inline functions, and operator overloading offer a pretty good degree of flexibility. But not all is well. From the C++ FAQ, http://www.parashift.com/c++-faq-lite/operator-overloading.html:

[13.7] Can I create a operator** for "to-the-power-of" operations?

Nope.

The names of, precedence of, associativity of, and arity of operators is fixed by the language. There is no operator** in C++, so you cannot create one for a class type.

If you're in doubt, consider that x ** y is the same as x * (*y) (in other words, the compiler assumes y is a pointer). Besides, operator overloading is just syntactic sugar for function calls. Although this particular syntactic sugar can be very sweet, it doesn't add anything fundamental. I suggest you overload pow(base,exponent) (a double precision version is in ).

By the way, operator^ can work for to-the-power-of, except it has the wrong precedence and associativity.

So maybe C++ is not that great for DSLs :) My immediate thought was, how does common lisp handle this, seeing as its macro facility is often referenced as being an excellent tool for DSLs, but then I realized that its prefix notation + s-expressions prevents associativity and precedence from ever being an issue. The order of evaluation is always explicit.

How do languages that don't use lisp's syntax handle this? Are there any that let you hand define the associativity and precedence? The latter seems like a particularly hard problem because different areas of the code could define their own unique operators, etc.

Another limitation not mentioned in the FAQ entry is that you can only overload operators when at least 1 of the operands is a user defined type. So you can't change how primitive and standard library types interact at all.