First LLVM-made binary

A small step for a humble programmer, a huge leap for Liberty project 

(Me - right now)

 LLVM wrappers begin to be functional; please have a look at LLVM example directory and lauch make; after a while you will find:

• llvm_example : the executable made by SmartEiffel (we are using latest version from subversion repository)
• example.bc:   LLVM bitcode, produced by llvm_example
• example.s:    ASCII assembler program text, compile from bytecode by llc - the LLVM static compiler
• example:      an ELF relocatable, made by as, usually the GNU assembler

A lot of works remains to be done in LLVM, I expect to work out several idea on actual implementation of peculiar technical details of the Eiffel runtime during the wrapping of the rest of LLVM.

I would say that since Eiffel choice not to have namespaces we shall have no name-mangling problems.

We need bindings not wrappers...

Interfaces to foreign libraries have been traditionally called bindings or wrappers. I never cared too much about eventual differences in meaning, I used to use them as synonims; now I'm beginning to realize that they have different meaning.
Let's speak in Eiffel or C/C++: a WRAPPER is a tiny reference (i.e. unexpanded) object containing a pointer to the unde lying data structure, think about it as a glorified REFERENCE[POINTER]; a binding - in my humble opinion - shall be a way to directly use the actual data structure as an Eiffel object, turning that pointer into the actual reference used on the Eiffel side.
Needless to say this double layer - WRAPPER and wrappee, referred thorught "feature handle: POINTER" pratically means to manually manage memory inside each effective wrapper coupling it with deferred classes that implements memory policies like EIFFEL_OWNED, C_OWNED, GLOBALLY_CACHED, MIXED_MEMORY_HANDLING, or REFERENCE_COUNTED.
This is how wrapping has always been done in Eiffel, either in Eiffel (in EWLC or EWG) or with C glue code (elj).
To bootstrap Liberty we still need them and we will still need them a lot after Liberty will be ready.
My proposal is to allow better integration with foreign languages or object-models, like C-with-Gobject or C++.
Surely both models do not perfectly map Eiffel's object way; we still will need to instruct Liberty on how to handle those datatypes generated by foreign code,
SmartEiffe started to develop external types, something  that eventually bring us "real bindings".
We need "only" to allow the developer of a binding to provide object_size, generator and generator_type.
Those will be interfaced the object-model facility of the foreign language, for example with C++ Run Time Type Identification, the C++ typeid operator and its std:type_info object; Gobject also offers a comfortable type system that will fit.
Obviously there will be mismatches, peculiarities and headaches but it can be done. Other languages have done it, we can also.
There will a cost. The cost is "diverging" farther from ECMA; I read the standard a couple of months ago and I wasn't satistied by what I read about integration with other languages. I had the impression they don't care that much about integration. What I found there was a language that already diverged from what we learned to love as Eiffel.
We standed still, they walked away. We shall find and walk our trail. Perhaps different, perhaps useful for a later merge.
Let's keep writing wrappers and not binding to bootstrap.

Syntax OK

Good news to finish 2009!

The commit f95add1fdaaf39f956fec89500590282fbcbc11d marks an end to syntax errors. The whole Liberty library and tools code is correctly parsed.

Now to testing and fixing the semantics tree generation...

SCOOP

Read the wiki and tell me what you think.

Inline agents should be closures

Compare the current SmartEiffel inline agent definition:

local
   i: INTEGER
do
   agent (h: INTEGER) is
      do
         std_output.put_line(h.out)
      end (i)
      .call([])
end

with a real closure:

local
   i: INTEGER
do
   agent is
      do
         std_output.put_line(i.out)
      end
      .call([])
end

What do you think?

A couple of proposals

Adding "ref: REFERENCE[like Current]" in ANY
This would to allow to easily write a manifest COLLECTION[ANY] holding non-expanded objects and references to expanded like INTEGER or REAL.
The usage would to write code like
   formatter: STRING_PRINTER is once create Result.make(std_output) end
   do_stuff is
   do
      formatter.put_message("Cluster @(1): @(2) classes, @(2)%% non-deferred",<<"a_cluster_name", 1000.ref, 0.25.ref>>)
    end
I'm conscious this would allow for printf-like features that mimick variadic functions, a potential way toward spaghetti-code; current alternative is formatter.put_message("Cluster @(1): @(2) classes, @(2)%% non-deferred",<<"a_cluster_name", 1000.out, 0.25.out>>) that allocates two temporary strings, nullifing/thwarting one of the main reason to use a STRING_PRINTER: avoiding creation of temporary, shortly-lived strings.

Adding ROPE string and eventually a TWINE.

Sometime ago I started a little hack named LINKED_STRING, a string implemented as a linked list of strings; the idea was to make concatenation efficient, ideally an O(1) operation; then I discovered that (quite obviously) other people had the same idea. Ropes are usually not implemented using lists as in my draft. I'm still thinkering about it.

Let's turn towards the future

Yes, SmartEiffel is dead.

SmartEiffel has brought great things such as the first working implementation of non-conforming inheritance as well as well defined (should I say, just defined) conformance rules for agents.

SmartEiffel lost its steam, in my opinion, because:

1. The code base is too complex. There is no way to understand it if you are not helped by the core team.
2. The core team does not welcome any patch from the outside. It discouraged people to participate and since the users of a compiler are also technical people, users were lost.
3. Everybody knew that the core team had a private list where every decision was taken. Not free.
4. Some members of the core team had ideas that were not approved by the big boss. Too many no-no and core members got weary.
   
5. The head of the core team seems to have mysteriously disappeared. The team lost all motivation.

Here comes Liberty: SmartEiffel down from its ivory tower.

I want Liberty to be:

1. A striking example of good Eiffel code. That certainly means powerful, but above all simple and understandable.
2. Released with batteries (and with simple technical means to add more batteries!)
   
3. Interoperable with most mainstream languages (C, Java, .NET...)
4. Available on most platforms.
5. Really free, as in free speech.