Index

Lysaac: on en parle pas mais ça avance

Tue, 10 Apr 2012 16:57:20 +0200

Lysaac c'est ma réimplémentation du compilateur lisaac. Jusqu'a présent, il n'y avait pas grand chose, mais dernièrement, il y a eu des commits intéressants:

les variables fonctionnent
- avec des valeurs par défaut
- on peut les lire
- et y écrire
on a aussi des BLOCKs, mais sans upvalues

Ça ne paye peut être pas de mine, mais en fait, l'infrastructure du compilo est presque complète.

Prochaines avancées: héritage et affichage des erreurs

Et peut être après: des améliorations de syntaxe (appels de slot à paramètres et bien plus tard: opérateurs). Pour le moment, je me concentre sur les choses basiques.

Si vous voulez jouer, vous pouvez. Si vous avez une erreur inattendue, créez un scénario d'utilisation et donnez le moi (préférablement sous forme de fichier .feature).

Lysaac: not talking about it but it goes forward

Tue, 10 Apr 2012 16:57:20 +0200

Lysaac is my reimplementation of the lisaac compiler. Until now, it wasn't very interesting to look at, but recently, I pushed a few interesting commits:

you now have variables
- the default value is initialized correctly
- the read works
- the write works
you also have BLOCKs (sorry, no upvalues for now)

This may looks like nothing, but under the hood, the infrastructure is almost completely there.

Next thing to come: inheritance and error reporting.

Then perhaps, syntax improvements like keyword messages and later: operators. For now, I want the basic functionnality working well.

If you want to play with it, you can. If you get an error, create a use-case and propose it as a new feature. Please use as a model the .feature files.

Lysaac now compiles Hello World!

Tue, 10 Apr 2012 16:57:20 +0200

This is great: Here is the source files:

c/cstring.li

Section Header

  + name := Reference CSTRING;

  - role := String; // const char*
  - type := Integer 8;

c/main.li

Section Header

  + name := MAIN;

Section Public

  - puts str:CSTRING <- External `puts`;

  - main <-
  (
    puts "Hello World";
  );

You type lysaac compile c >c.bc and you get the following LLVM assembly code:

c.bc

@0 = private constant [12 x i8] c"Hello World\00"


declare void @puts (i8*)

define void @main () {
  %1 = getelementptr [12 x i8]* @0, i32 0, i32 0
  tail call void @puts(i8* %1)
  ret void
}

And you can execute it using the standard LLVM tools:

$ llvm-as < c.bc | lli
Hello World
$

Isn't that great ?

Union types and null

Tue, 10 Apr 2012 16:57:20 +0200

Look at this:

object.li

Section Header

  + name := Singleton NULL;

Section Public

  - is_null :BOOLEAN <- FALSE;

null.li

Section Header

  + name := Singleton NULL;

Section Inherit

  - parent :OBJECT := OBJECT;

Section Public

  - is_null :BOOLEAN <- TRUE;

union.li

Section Header

  + name := UNION;

Section Inherit

  - parent :OBJECT := OBJECT;

union.1.li

Section Header

  + name := Expanded UNION(E);

  - import := E;

Section Inherit

  - parent :UNION := UNION;

Section Public

  + element:E;
  - set_element e:E <- (element := e;);

  - when o:T do blc:{o:T;} <-
  (
    (o = E).if {
      blc.value element;
    };
  );

  - from_e e:E :SELF <-
  ( + res :SELF;
    res := clone;
    res.set_element e;
    res
  );

union.2.li

Section Header

  + name := Expanded UNION(E, F...);

Section Inherit

  + parent_e :UNION(E);
  + parent_next :UNION(F...);

Section Public

  - when o:T do blc:{o:T;} <-
  (
    (o = E).if {
      parent_e.when o do blc;
    } else {
      parent_next.when o do blc;
    };
  );

use.li

Section Header

  + name := USE;

Section Public

  - accept_object_or_null obj:UNION(USE,NULL) <-
  (
    obj
    .when NULL do { o:NULL;
      ? { o.is_null };
    }
    .when USE do { o:USE;
      ? { o.is_null.not };
    };
  );

Stack environments

Tue, 10 Apr 2012 16:57:20 +0200

Stack environment would be an argument passed implicitely to every function in the code. It would contain global policy. In particular the MEMORY object that lets you allocate memory. If you want to change the allocation policy, you just have to change the current environment, and all functions you call will use the new policy.

We could allow user defined objects like that, not just system objects.

We could also manage errors that way. An error flag could be stored in the environment. Set by the calee and tested by the caller.

Lysaac annotations

Tue, 10 Apr 2012 16:57:20 +0200

Because I'm using an open world assumption, I need the compiler to generate annotations on units it compiles, so when it sees them again, it knows what it does (or does not) internally.

I was looking at a LLVM video this morning (VMKit precisely) and the person talked about an interesting optimization. What if we could allocate objects in stack instead of the heap. This would save time when creating the object. Then we wouldn't be tempted to avoid creating new objects for fear of memory leaks (there is not garbage collector in lisaac currently) and performance penalty.

This is the same thing as aliased variables in Ada.

An object can be allocated on the stack if:

it is not returned by the function.
it is not stored on the heap by the function.
it is not used in a called function that would store a pointer to this object on the heap.

So, when the compiler compiles a cluster, it has to generate an annotation file containing for each argument in each code slot whether the argument is guaranteed to remain on the stack or if it might be stored on the heap. If an argument is guaranteed to stay on the stack, we can allocate it on the stack. When the function will return, the only instances would be located in the current stack frame.

Lysaac compilation model and inline prototypes

Tue, 10 Apr 2012 16:57:20 +0200

In Lysaac, I choose to follow the open world assumption, like the majority of programming languages out there, instead of the closed world assumption. There are two main reasons:

First, I don't strive at creating an optimizing compiler, not yet at least. Closed world is useful for that, but I don't need it.
Second, open world assumption increases the complexity a lot. The Lisaac compiler uses an exponential algorithm, and will always hit a limit with big projects. With an open world, you can partition the complexity.

Because I still believe in global compilation, I decided that my compilation unit would be the cluster instead of the prototype. That is, I'll compile a cluster completely in one object file. That makes it possible to optimize things like private prototypes.

This leaves a big performance problem for BOOLEANs in particular. BOOLEAN, TRUE and FALSE are prototypes in the standard library, and having an open world assumption would require pasing to the if then slot function pointers. I can't realisticly do that.

So, These prototypes could be marked as Inline. They are separated from their cluster and gets compiled in every cluster that uses them. The syntax could be quite simple:

Section Header

  + name := Inline TRUE;

But, because each cluster is then free to compile it as it wants, there is a problem of interoperability. How can you be sure that the TRUE in your cluster is compiled the same way as in the neighbooring cluster you are using. As it is, you can't pass TRUE object around clusters. Very annoying.

The solution would be to encode them and decode them manually. You could have:

Section Header

  + name := Inline TRUE;

Section Feature

  - inline_size :INTEGER := 0;

Take a more interesting example:

Section Header

  + name := Inline Expanded BIT;

  - size := 1;

Section Feature

  - inline_size :INTEGER := 1;
  - encode p:POINTER <-
  (
    p.to_native_array_of BIT.put bit to 0;
  );
  - decode p:POINTER <-
  (
    data := p.to_native_array_of BIT.item 0;
  );

This needs to be refined.

Additionally, .cli files could also contain the Inline keyword. In that case, the cluster it reference will be compiled with the current cluster. That could be useful for private clusters.

Lysaac and clusters

Tue, 10 Apr 2012 16:57:20 +0200

If you noticed, I started my own Lisaac compiler, called Lysaac and I want to make it a little bit different from Lisaac. I'll try to keep compatibility, but for few things, I might take a different direction.

One of these things is the way prototypes are found.

In Lisaac, you have a complete set of prototypes and when you look for a prototype, it is looked everywhere. This is not desirable. Imagine you are writing a library that requires the prototype FOO. Currently, if FOO is not present in the library, instead of issuing an error, the compiler would take the FOO prototype in the application that use the library. Meaning that the library is effectvely using a pieve of the application code.

I want to take the SmartEiffel approach and separate the source code in few clusters. A cluster is a collection of prototypes. And the prototypes in a cluster can only use the prototype of the same cluster or the prototypes of imported clusters. This solve the above dependancy problem.

A cluster is a directory that contain prototypes in .li files and subdirectories. If a subdirectory do not contain .li files, the sub-subdirectories are not recursively searched. A cluster can import another cluster using a cluster file ending with .cli.

An example of .cli file is as follows:

Section Header

  - name := Cluster LIBFOO;

  - path := ("libfoo-3.14", "../libfoo");

The search paths can be:

relative to the .cli file if it starts with .
relative to LYSAAC_PATH directories otherwise

LISAAC_PATH defaults to $XDG_DATA_HOME/lysaac/lib:/usr/local/share/lysaac/lib:/usr/share/lysaac/lib.

The search paths would then be for this example:

$XDG_DATA_HOME/lysaac/lib/libfoo-3.14
/usr/local/share/lysaac/lib/libfoo-3.14
/usr/share/lysaac/lib/libfoo-3.14
../libfoo

The parser for these files is being written. Then you can see the complete hierarchy of the project:

$ lysaac src
◆ Root Cluster
│ Cluster in: src
├─◆ LIB (src/lib.cli)
│ │ Cluster in: lib
│ ├─◆ STDLIB (lib/stdlib.cli)
│ │ │ Cluster in: /home/mildred/.local/share/lysaac/lib/stdlib
│ │ ├─◇ STRING (...)
│ │ ├─◇ ABSTRACT_STRING (...)
│ │ ╰─◇ ...
│ ├─◇ LIBC (lib/libc.li)
│ ╰─◇ CSTRING (lib/cstring.li)
├─◇ PARSER (src/parser.li)
├─◇ CLUSTER_ITEM (src/cluster_item.li)
├─◇ ITM_STYLE (src/itm_style.li)
├─◇ LYSAAC (src/lysaac.li)
├─◇ ITM_AFFECT (src/itm_affect.li)
├─◇ ANY (src/any.li)
├─◇ PARSER_CLI (src/parser_cli.li)
╰─◇ CLUSTER (src/cluster.li)

Now, each item in a cluster can be public or private. Public items are available to the users of the clusters whereas private items are restricted to members of the same cluster. To declare a private item, just say:

Section Header

  + name := Private PROTOTYPE;

Section Header

  - name := Private Cluster LIBTOTO;

If you want to declare a whole bunch of prototypes private to your cluster, just include them in a private cluster. To do so, you'll need the following files:

cluster/my_private_prototypes.cli:

Section Header

  - name := Private Cluster MY_PRIVATE_PROTOTYPES;

  - path := "./deps/my_private_prototypes";
  // makes the cluster relative to the .cli file
  // use a deps additional directory to avoid the current cluster to
  // look into deps/my_private_prototypes. deps should not contain any
  // files, just subdirectories.

cluster/deps/my_private_prototypes/private_proto.li:

Section Header

  + name := Public Prototype PRIVATE_PROTO;

PIPE(E)

Tue, 10 Apr 2012 16:57:20 +0200

Inspired from ruby #Array:

Section Header

  + name := PIPE(E);

Section Private

  + blc :{;BOOLEAN,E};

Section Public

  - create blc_:{;BOOLEAN,E} :SELF <-
  (
    blc := blc_;
    Self
  );

  - read :(BOOLEAN,E) <- blc.value

  - map blc:{E;X} :PIPE(X) <-
  ( // Upvalue Self
    PIPE(X).clone.make {
      + have_e :BOOLEAN;
      + e :E;
      (have_e, e) := Self.read;
      have_e.if {
        e := blc.value e;
      };
      have_e, e
    }
  );

  - select blc:{E;BOOLEAN} :PIPE(E) <-
  ( // Upvalue Self
    PIPE(E).clone.make {
      + have_e :BOOLEAN;
      + e :E;
      (have_e, e) := Self.read;
      have_e.if {
        blc.value e.if_false {
          have_e := FALSE;
        };
      };
      have_e, e
    }
  );

  - flatten_1 :PIPE(X) <-
  ( // Upvalue Self, buffer
    + buffer :PIPE(X);
    PIPE(X).clone.make {
      + have_e, have_x :BOOLEAN;
      + e :E;
      + x :X;
      buffer.is_null.if_false {
        (have_e, e) := buffer.read;
        have_e.if_false {
          buffer := NULL;
        };
      };
      buffer.is_null.if {
        (have_e, e) := Self.read;
        have_e.if {
          (buffer ?= e).is_null.if_false {
            (have_x, x) := buffer.read
            // TODO: cas où have_e = FALSE (buffer est vide)
          };
        };
      };
      have_x, x
    }
  );

  - to_array_of_e :ARRAY(E) <-
  ( + result :ARRAY(E);
    + have_e :BOOLEAN;
    + e :E;
    {(have_e, e) := read;
    have_e
    }.while_do {
      result.add_last e;
    };
    result
  );

TODO:

Upvalue
Syntax improvement (block input variables is too verbose)
More typing of parameter types, particurlarly as return values (map return unknown type X)
var := bool.if {val1} else {val2}
NULL.is_null -> TRUE

Section Interface

Tue, 10 Apr 2012 16:57:20 +0200

I had an idea about inheritance, comming from Eiffel and my today's work in Ada Object Oriented Programming in embedded software. I am working on a software that is going to be embedded in an ADIRU (Air Data Inertial Reference Unit) in the final assembly line (not on air). This software is about implementing a protocol to let the test operator test the connections in the aircraft.

Embedded software means memory constraints. Basically, that means I can only allocate new objects when the application is starting up. When the application is running (with a scheduler), it is no longer possible to create new objects. This is bad for me because I just want to create different objects at runtime that have a different behaviour. The objects all have the same size in byte, the same data. There is just a function that is inherited.

Next, I thought of Eiffel ...

And then about what is inheritance. I can think of two aspects of inheritance:

Behaviour inheritance: you just want the same behaviour as your parent. This is the Section Insert
Interface inheritance: you just want the polymorphism

When you think about it, the two aspects complements each other. The traditional inheritance is just the combinaison of the two. So I thought that could be a great idea to separate them. Bundeling them together would just help programmers mistakenly inherit for an object, even if they obly want polymorphism or behavior inheritance alone.

There is another trap: extend an object that you already inherited. You might add some features/methods/slots that you don't necessarily want in herited prototypes. You end up cluttering the inherited objects a lot. So I thought that a good rule would be to forbid the inheritance from an implementation and force inheritance from interfaces.

And, how to do that nicely in Lisaac?

With the new Section Interface

The Section Interface would define an interface for the current prototype. It would contain slots and their contracts that are going to be inherited. Slots not defined here will not be available for inheritance. And if there is no Section Interface, no inheritance will be possible.

In short terms, it means that if you use the Strict version of the prototype (or if the compiler can infer you are doing so), you can use the slots in the Section Public. Else, you are limited to the Section Interface.

Cool things with interfaces

Just as in eiffel, if you have two slots that conflicts when inherited like in the following code:

Section Header

  + name := BAG(T);

Section Interface

  - count :INTEGER;
  - lower :INTEGER;
  - upper :INTEGER;

  - owner :PERSON;

Section Header

  + name := SHOP;

Section Inherit

  - tomatos :BAG(TOMATOS);
  - eggs    :BAG(EGGS);

Section Interface

  //
  // You can rename the slots:
  //

  - tomatos_count <- tomatos.count;
  - tomatos_lower <- tomatos.lower;
  - tomatos_upper <- tomatos.upper;

  - eggs_count <- eggs.count;
  - eggs_lower <- eggs.lower;
  - eggs_upper <- eggs.upper;

  //
  // Or reimplement them:
  // (if there is a conflict, it should be present in the interface tell the
  //  compiler that you thought of reimplementing it.)
  //

  - owner :PERSON;

Section Public

  - owner :PERSON <-
  (
    ? { eggs.person = tomatos.person };
    tomatos.owner
  );

This will tell the compiler that when the SHOP transforms into a BAG(TOMATOS) through polymorphism, it should use the tomatos_count instead of count. This will also tell that the owner of both the tomatos and eggs is the same and implemented in SHOP.

How to inherit?

For behaviour inheritance:

Section Insert

  - parent1 :Expanded P1;
  - parent2 :P2 := P2;
  + parent3 :Expanded P3;
  + parent4 :P4 := P4;

For interface inheritance (the two forms are equivalent)

Section Inherit

  - parent1 :Interface P1;
  + parent2 :Interface P2;

For both (if there is no default values for forms 2 and 4 the compiler should issue a warning):

Section Inherit

  - parent1 :Expanded P1;
  - parent2 :P2 := P2;
  + parent3 :Expanded P3;
  + parent4 :P4 := P4;