Lambda the Ultimate

AutoTest is a testing too for Eiffel akin to QuickCheck for Haskell, which automates testing of code based on contract based specifications of functions. While AutoTest is still in development, it is also more ambitious than QuickCheck, seeking to provide a single push-button approach to testing with multiple pluggable strategies for generating test data. A recent talk discusses in more detail some of the more advanced aspects of where AutoTest is going. Most importantly AutoTest has proved to be practical, having already found a number of bugs in Eiffel's base libraries!

Tom 2.4 was released today, and contains many improvements. In particular, it is possible to generate with the Gom tool unmutable typed tree data structures with invariants, such as ordered lists, duplicate removal or even distributivity of balanced trees.
Also the new reflexive strategies allow self modifying and dynamic strategies in Java, and the easy use of strategic programming in a Java environment. This allows for instance the easy development of a Just in Time compiler for those strategies, using bytecode rewriting.

Quoting the announce:

Tom 2.4 announcement
--------------------

It is our great privilege and pleasure to announce the availability of
Tom version 2.4.

This release continues our work on the integration of pattern matching
and rule based programming facilities into C and Java.

Tom is a pattern matching compiler developed at INRIA. It is
particularly well-suited for programming various transformations on
trees/terms and XML based documents. Its design follows our research on
the efficient compilation of rule based languages (e.g. ELAN, developed
at INRIA-Loria).

Many applications have been developed in Tom. Among them, let us mention:
- the Tom compiler itself
- languages semantics, interpreters and program transformation tools
- a Just In Time strategy compiler using dynamic Java bytecode
transformation
- a generator of canonical abstract syntax trees (Gom)
- a proof assistant for supernatural deduction
- a compiler algorithm for anti-pattern matching and disunification

Tom is a complex compiler which adds powerful constructs to C and Java:
non linear syntactic matching, associative matching with neutral element
(a.k.a. list-matching), XML based pattern matching, string matching, and
equational rewriting.
This offers the possibility to analyze and transform any kind of
data-structure. Tom can be used for large scale developments and
applications. It comes with documentation, programming, and debugging
support.

This new release contains many improvements and new features:
- Anti-Patterns:
Tom now supports not only pattern matching, but also anti-pattern
matching. For example, the pattern (_*,!a(),_*) denotes a list
which contains at least one element different from a(). In a similar
way, !(_*,a(),_*) denotes a list which does not contain any a().

- Reflexive Strategies:
A strategy is now a term that can be matched like any other term.
This allows to dynamically build or transform a strategy at runtime.

- Congruence Strategies:
Gom generates new elementary congruence and constructions
strategies. This allows for instance to define the Map operation in
a easy way: map(s) = _conc(s)

- Java Bytecode:
A support for Java bytecode analysis and transformation is available
in the runtime library. This allows class loading, bytecode analysis
and transformation in an algebraic framework.
Using the strategy language, the control flow graph can be explored
and visualized using dot.

- Eclipse Plugin:
It is back for Eclipse version 3.2.
It also supports Gom and all new functionalities.

Tom is available, in open source (GPL/BSD License), from the web page:

http://tom.loria.fr

Best regards,
Tom development team

We've stopped to take a look at how Hecl handles procedures and their arguments. Since Hecl is a command-based language that takes a lot from Tcl, one obvious thing to borrow would call-by-name:

set i 10
incr i
puts "i is now $i (11)"

Currently, though, it does call-by-reference for destructive commands like 'incr':

set i 10
incr $i
puts "i is now $i (11)"

Part of the thought behind this choice is that I want a consistent mental model for users, who I do not anticipate being programming language wonks, but rather those who would like to utilize Hecl to script applications for their cell phones, perhaps on a level on par with your average PHP user. In a language like PHP, variables always have a $ attached to them, which makes it easy for users to recognize that "that's a variable". I have a suspicion that Tcl's strategy of using foo here and $foo there may be confusing to new users, who must recall which one to use in which place.

Furthermore, I am curious what references or lack thereof do to people's conceptual models of a language - having two variables point at the same thing. For instance PHP gives you the & operator to create a reference, C gives you pointers, Ruby and Python let you assign one thing to another and, in some cases, modify the thing pointed at by both variables. This also has me wondering what Scheme/Python/Ruby style pass by value with some kinds of values being modifiable is like for newer users... whether that makes sense or is confusing to have some kinds of things that can be changed, and others that can't.

I'm currently searching for research and information on the topic, but in the meanwhile, what do you think?

I was thinking the other day it'd be interesting if C++ supported something like the following:

template<modifier T>
class A : public SomeClass {
public:
    void GuarunteedMethod();
    void AlwaysThereMethod();

T:
    void DependsOnUser();
    void MayNotBePublic();
};

template<modifier T>
class B : T SomeClass {
};

Then somewhere in code using the templates:

A<public> X; // Object that has public DependsOnUser()
A<private> X; // Object that doesn't

B<public> X; // publically inherits from SomeClass
B<protected> X; // protectedly inherits from SomeClass

You can get the same effect in today's C++ as in A by splitting up the class more or in B's case by having dummy intermediary classes.

A class has two different types I think, that which it presents to calling code, public interface, and that which it provides to extending code, protected interface (you could argue there's a third, the types that it presents to itself but that's not really an observer relationship). So in the sense that it changes the resulting type, the above C++ extension is consistent with the notion of templates as type factories.

This got me thinking about what exactly the relationship between access modifiers and a class's type is. I'm not sure whether or not you could say that access modifiers change the type of member functions. Access modifiers do impose a compile time limit on who can use the function, which sounds related to types, but usually we only think of the type of a function to be it's return type + parameter types.

Maybe I'm just caught up in the wording and access modifiers can be thought of as simply defining complex scopes, but it seems different to me from the concept of scope because it's not that the symbols aren't visible, it's that they're disallowed.

Thoughts? :)

I'm looking for a java compiler (source code) that is easy to understand and extend. Performance or full coverage of the language are not really relevant, as long as it's robust and realistic. Source code should be in ML or Java. Are there any canonical compiler for that kind of things?

Thanks.

This looks very interesting:

http://homepage.mac.com/luke_e/Menu8.html

(Luke also posted an announcement to the Haskell mailing list)

I haven't seen any posts about this yet, so I thought I'd point it out: ICFP 06 is over, and there are lots of interesting articles.

E.g. from the Scheme Workshop:

• HOAS: [Barzilay] using higher-order syntax for normal code (not just macros)
• "From Variadic Functions to Variadic Relations: A miniKanren Perspective": [Byrd, Friedman]:
  discusses pseudo-variadic functions
• Termite Scheme [Germain, Feeley, Monnier]: Erlang-style processes in Scheme (the latest version)
• Incremental compiler construction [Ghuloum]
• "SHard: a Scheme to Hardware Compiler" [Saint-Mleux, Feeley, David]: compiling Scheme to FPGAs
• and more..

I was amazed to see the article concerning the C implemented Apache versus the Erlang implemented Yaws and immediately went looking for how Erlang emulated its processes. What I could not find after reading "Making reliable distributed systems in the presence of software errors", and "The development of Erlang" was what was making the magic happen. What is this high level of concurrency attributed to; bytecode instructions, abstractions built upon continuations, erlang-style trampolines, what?

I would like to learn more about concurrency in general (and more specifically, its implementation), even to the point of playing around with these new ideas in Common Lisp and Scheme. I have reviewed CL-MUPROC, Termite, and Distel; and so far Distel seems to be the most interesting due to its lack of need for any underlying thread or process implemenation.

Can anyone provide me some insight, whether explaination as to how Erlang makes process magic or Lisp equivalents, or reference readings to learn more about the subject.

Thank you for your time,

Mark Stahl

References:
Apache vs. Yaws
Making reliable distributed systems in the presence of software errors
The development of Erlang
CL-MUPROC
Termite
Distel

This is a repost from my blog at Artima.com. In this forum, I am sure that I would have an interesting and differing point of view from those posted at Artima.

I've started work on a rather ambitious book called Fundamentals of Programming which will be intended as a programming book for people starting at the very beginning. I thought I would invite some feedback about my proposed structure.

I plan on breaking the book up into the following sections, with the primary example language for that section.

1. Programming Basics - Cat
2. Pointers and Memory Addressing - C++
3. Object Oriented Programming - Java
4. Functional Programming - Scheme
5. Mixed Paradigm Programming - Scala
6. Software Design - Cross Language

The language I associated with each section would be by no means exclusive. I would introduce that particular language, familiarize the user with it, and use it for the bulk of the examples.

One reason for using multiple languages is that I want beginners to be exposed to a wide breadth of languages, and ways of thinking. I want people to feel they are getting their money's worth by becoming familiar with several different major languages.

The usage of the Cat language is risky, since no one has heard of it. However, I really like the idea of starting a lesson on programming using the example of postfix calculators. This leads naturally to an interpreted stack based language.

The choice of Scala, is potentially contentious because Scala isn't as mature as Haskell or OCaml. However Scala is chock full of support for advanced programming techniques, it is type safe, and it has a sane syntax.

The final section would introduce the concept of using the appropriate language(s) for the job. As such I would be sure to mention languages like: Perl, PHP, Python, Assembly, TCL, and others.

The order of these sections are not intended as hard and fast rules. I am hoping to design the book such that entire sections can be skipped or moved. For example, Pointers and Memory Addressing can be placed at the end, or left out entirely. Another possibility is that Functional Programming can be placed before Object Oriented Programming.

What languages would you use, and how would you structure your ideal programming text? Do you already have a favourite introductory text that can't be improved on?

If we SSA transform our program and _then_ perform type inference (glossing over issues like if we get always infer somethings type), do we get strong static dynamic typing?

e.g.:

a = 1
b = a + 1
a = "hello"
printLine a
.
.
.
a0 = 1
b0 = a0 + 1
a1 = "hello"
printLine a1 

Of course there are scenarios like:

if condition then a = 1
else a = "Hello"
end if

But I believe that these scenarios can be overcome. My question is then, is this impossible for any reason?