Lambda the Ultimate

[Edit: Previous LtU discussions. I guess I'm hoping to learn if there is anything new, new, new!]

Where might I find a language that infers static types (a la Haskell, SML, O'Caml) and yet also allows for late binding (a la Smalltalk, Lisp). I know some folks have tried to do it for Smalltalk and even for Lisp, but none are particularly 'main stream'. Are there any other obvious things I'm failing to recall?

Ah, the Merd page led me to soft typing! The dates on all the papers in Google hits look old. The only thing that appears to still be kicking is PLT's Mr. Spidey debugger. Has anybody had experience with it, per chance?

Chapel, the Cascade High-Productivity Language:

Chapel strives to improve the programmability of parallel computers in general and the Cascade system in particular, by providing a higher level of expression than current parallel languages do and by improving the separation between algorithmic expression and data structure implementation details.

The design of Chapel is guided by four key areas of language technology [HIPS 2004]:

1. Multithreaded parallel programming in the style of Multilisp, Split-C, or Cilk.
2. Locality-aware programming in the style of HPF and ZPL.
3. Object-oriented programming helps in managing complexity.
4. Generic programming and type-inference simplify the type systems presented to users.

I only saw this mentioned once here, so I thought it was worth posting. Will it solve all the problems?

I was hoping for a few pointers to good information on parsers that can recover from errors and continue to parse the remainder of their input, skipping portions of the text that are not valid in a clean way. Thanks!

After reading a previous thread on debugging I got to thinking about an experience of mine involving debugging a hardware device called a digital filter. This was a big deal involving many people.
We knew for sure that this thing wasn’t going to work from the start and had a step by step plan to debug it at the beginning of the project. Even though this was a hardware project the similarities to what is going on now are too obvious to point out. Digital filters are easily modeled using state and are easily implemented using ordinary OOP software.

Now the key idea is that state systems are really feedback systems. This is very obvious from a hardware point of view because that is the way they are built. I can’t draw a block diagram here so I will try to describe it: Digital filters consist of many patterns of the following type. An input is fed into a subtractor(S) then into a register(R), The output of the register is fed to a multiplier(M) and then fed back to the subtractor(S). The loop R,M,S is the feedback loop. The output is usually the contents of R.

Now from this perspective it was obvious to all of us that in order to debug this thing we had to open up the feedback loops at S and simply go around the circuit and compare the actual values with what should be there for a given input based of a simulation. This is a full proof method and produced a working system after many weeks of tedious work and rewiring.

Here is the problem as I see it. State systems and the state abstraction always involve feedback and the feedback loops may not be obvious. The only full proof and deliberate way to debug such as system is to open up the loops and trace results compared to an open loop simulation. Open loop tests were once common and were often built in.

I am not sure what this means but here is one debugging idea. Suppose we design a system or language to carry a list of its states. And suppose also that we can temporally make those states a constant type (ie not updateable). Now theoretically at least we are in a position to trace through various values based on that state. Another idea might be to log or break whenever a state is updated. I wonder what other readers think about this. This is all fairly obvious but I haven’t seen it myself.

I thought that denizens would be interested in this post by John Gruber about the problems caused by the notion that making Applescript syntax work like English would lead to a friendlier language: http://daringfireball.net/2005/09/englishlikeness_monster

Besides Cobol and Perl are there any other languages where the designers felt that making the syntax resemble English (an evolved rather than designed language with legacy syntactic structures stretching back thousands of years and a history of ambiguous usage) was a good idea? Surely someone must have done some research showing why this usually leads to languages that are harder to work?

This raises some interesting questions about the ways in which language design happens. Should we be paying more attention to the choice of syntax (even though semantics matters I'd claim that in most of the languages used by the vast majority of people the scoping rules and type systems don't wander out of a narrow range of options) and using syntax lists such as this one: http://merd.sourceforge.net/pixel/language-study/syntax-across-languages/ compiled as part of the Merd language project?

It has probably all been done before, but for a number of years I have been attempting to construct a "data" driven programming system.

There is a scrappy website under construction at:
www.ivorysystem.com
or
www.ivoryscript.com
where I am trying to present what has been done so far.

Apart from some useful work done by some staff at Southampton University, it has been something of a solitary exercise. As the system includes a new programming language derivative, this is far from ideal, and I would appreciate any serious peer review and the opportunity to discuss whether or not anything of worth has been achieved.

The website has a .zip archive containing an executable file. I am reasonably sure that it doesn't contain any viruses, but I can't take any responsibility if it becomes infected.

What's better: recursion or iteration? This topic has been discussed to death on LtU:

• Recursion feels quite intuitive
• Iteration and Recursion
• Iteration vs. recursion?
• Why recursing is better than looping
• loops are fundamental, too
• Fold, etc

Olin I-did-it-all-by-myself Shivers weighs in [PDF, 194K]:

In call-by-value functional languages such as ML or Scheme, we typically write loops using tail-recursive function calls. This is actually a terrible way to express program iteration, and it's not hard to see why. As was popularised by Steele, a tail call is essentially a "goto that passes arguments." So writing loops with tail calls is just writing them with gotos. Yet, it has long been accepted in the programming-language community that goto is a low-level and obfuscatory control operator, a position stated by Dijkstra's "Goto considered harmful" letter.

Zonnon offers a new computing model based on active objects with their interaction defined by syntax controlled dialogs.

The Concepts of Zonnon: A language for systems engineering with Modules, Objects and Concurrency



And there's a Zonnon compiler for .Net

(For brevity, hand waving ensues.) A personal mantra is that a language isn't worth using for 'real' development if it doesn't have a serious debugger. From what little I've read up on FP, it seems like there are fewer debuggers and fewer 'quality' ones than, say, in the more procedural camps. Might it prevent folks from seriously getting into FP? I think it does scare me away somewhat!

I'm sure there's plenty I'm not aware of so one question is: what debuggers do exist for Haskell, Clean, ML, etc.? (I have read of debuggers for Haskell, but haven't ever used them - are they truly 'commerical quality'?) O'Caml and Lisp have hum-dingers, no?

The second question I have is: do you even want to use a debugger? Or is there something magical about developing with declarative systems that means you don't, or cannot, use one?

What languages out there that actually have verbose syntax provide good support for the addition of syntactic features? The ability to introduce new special forms in Lisp is awesome... what about the same in a less homogenous language? I understand it would be difficult to open up a language's grammar like that, but is there any work on this, using parsing expression grammars or something of that sort?