Skip to content

Liberty plan

Jump to bottom Edit New page
ramack edited this page Feb 14, 2013 · 2 revisions

Things to do now

  1. Write the plan
  2. Licence?
    • For the compiler and the tools GPL; nowadays we can choose between three viable alternatives:
      • version 2 only, like the Linux kernel. The most conservative, the more politically-neutral; potentially incompatible with code released under v.2 or later when choosing the “later” option.
      • version 2 or later, like most projects. We can always switch to v3 if necessary
      • version 3 or later; Tybor personally don’t know it enought to judge its usage. Its detractors says it’s too a political license, yet it addresses in a more modern ways things like patents, tivo-ization.

        (Cyril) I’d go for GPLv3. After all what would the compiler do in a TV set?

    • For the libraries MIT-X11 or LGPL. I propose something perl-like (double X11/LGPL) or python like (GPL-compatible, similar to BSD AFAIK).

      (Cyril) OK for X11

      (Paolo 2009-09-15) Wrappers shall be licensed with the same license of the underlying library. AFAIK it is the most sound way to avoid copyright issues; i.e. glib and gtk clusters will be LGPL, libxml2 will be MIT and so on.

      (Cyril 2009-09-15) OK. X11 for our “100% Liberty Eiffel” libraries, matching licence for linked libraries.

  3. Decide on the backend
    • C – for now we will keep the working C backend as main backend, without loosing interest for LLVM and JVM for future development. The inherited JVM backend will be removed.
    • LLVM? The best AFAICS: easy to interact with current tools (SE2.3+gcc), compiles to native, to C,
    • JVM?
    • Native? Not at all, since LLVM gives us two ways to go native for free (“normal” usage and emitting to C).

      (Cyril) OK for LLVM

  4. Decide on the front-end
    • Derived from SmartEiffel’s parser? Its parser shall be fast but it’s a little obscure to me. Many queries has side-effects, there is no evident separation between front-end (parsing, generating an AST) and back-end (C code emitting).
    • Derived from ESE? It would be much cleaner, yet longer. Is it feasible to integrate it with chosen part of SE codebase? I’m thinking about expression, instruction, type_mark, visitor directories

      (Cyril) SmartEiffel’s parser is really faster; but that’s about its only quality. It is deeply tied to the SmartEiffel internals whereas ESE’s is based on a general-purpose parsing library.

  5. Features?
    • Basis: SmartEiffel… Do we need to take anything out?
      Perhaps turning all external calls into something like
      foo (a_label: STRING) is
      external
      alias “a_symbol_name_indipendent_of_actual_plugin_used”
      end
      to make them agnostic regarding which language they interface to.

      (Cyril) OK if the symbol name is structured (i.e. dotted) to allow namespaces

    • Add-ons:
      • convert: this is quite useful; I would add “—convertion-are-warnings” “—convertion-are-errors” flags to the compiler because automatic convertion can have serious impact of perfomance of produced programs (ask me benchmarks on 64bit integers).

        (Cyril) I agree

      • assign?
      • more liberal infix and prefix operators?

        (Cyril) it’s dangerous because the parser cannot distinguish between a free operator and a symbol

        (Paolo) “liberal” means allowing for example Unicode math codes, g_unichar_type (a_char) = G_UNICODE_MATH_SYMBOL (see also this table:http://www.unicode.org/charts/PDF/U2200.pdf ); of course I wasn’t meaning to allow code like «class PERSON ….. feature infix "open"». This way we would get rid of usual rant “why do I have to write my_matrix.multiply(another_matrix).scalar_vector(a_vector) instead of (my_matrix*another_matrix)*a_vector?”; my idea is that the mathematician would have rather written "(my_matrix × another_matrix) ^ a_vector " because scalar and matrix multiplications are not arithmentic multiplication and in fact they actually have different symbols in math. The infix-prefix name rule could be therefore expressed using Unicode classification of characters.

      • inspect on any COMPARABLE not only INTEGERs and STRING

        (Cyril) yes

      • allowing Unicode sourcecode? i.e allowing in INTEGER infix “²”: like Current to write x² instead of x^2

        (Cyril) yes — why not

      • allowing pluggable native types, in a way similar to current SE manifest collection creation, i.e. {MY_NATIVE “a string passed to a MY_NATIVE.initialize feature”}

        (Cyril) yes, oh yes

      • SCOOP?

        (Cyril) I’d like safe multi-threading but I think the model needs to be carefully thought out (the standard SCOOP model has too much syntactic gangrene: separate goes everywhere in the standard library or I missed something)

        (Paolo) Let’s start adding a owner_process field to ANY; attributes AFAIK shall always be accessible by any thread/process, while any command (and mostly probably also any query) shall have an implicit precondition “require owner_process.is_equal(Current.owner_process)”. It’s not separate but it can be a feasible starting point.

      • More control on memory. SE has only two (three) choices:
        1. Its own garbage collector, untouchable by the programmer,
        2. Bohem’s but requires tweaking
        3. No GC at all.
          Ideally the GC could be implemented in Liberty itself, if it provides (attribute) introspection.

          (Cyril) doesn’t LLVM provide standard GC modules?

          (Paolo 2009-09-15) LLVM does not provide a turn-key GC solution, yet it has a complete infrastructure to implement several kind of GC. Read this document for further information; in particular “A semispace collector or building atop malloc are great places to start, and can be implemented with very little code.” may be relevant for us.

      • Introspection for all features, not only attributes; this is quite futurible.

        (Cyril) yes; calling features could be interesting

      • Remove 32-bit assumptions Current SE is meant to be run on 32bit machines or 64bit where “default C int” is 32bit. This does not hold anymore being an LLVM compiler; in fact LLVM currently support 16, 32 and 64 bit architectures . I would not be surprised if someone will add support for 8-bit controllers. I suggest to make that INTEGER’s length shall be “the fittest for any architecture”…. all in all we’ll ultimately have convertions, will we?

        (Cyril) I agree

      • root class constructor may accept a TRAVERSABLE[STRING] as argument
      • “require else” for non-conforming inheritance
      • “class X[E_] inherit E_ end”
      • Generic instanciation
  6. Libraries?
    • SmartEiffel’s? Evolving from it; there are some things I would like to change or add; for example NON_VOID support
    • ESE’s? Cyril will obviously port as much as possible from it.
    • EWLC’s? Tybor will obviously port as much as possible from it.

Things to do first (i.e. to allow bootstrap)

Item Status Comments
Import basic libraries from SmartEiffel & ESE DONE From SmartEiffel we need io, storage, kernel, strings… From ESE we need the parser.
Clean libraries licenses TODO
Build the basic parser and AST structure DONE AST written using ESE’s parser library.
Build the semantics structure DONE Well, mainly. Initialize and check all the types of the system using the AST. Agents are still buggy.
Build an interpreter ONGOING Run the program directly using the semantics structures. useful to debug the semantics structures, and also as preparatory work for both the REPL and the compiler. And of course, very useful in its own right.
Generate LLVM code using the LLVM backend TODO Will use the above semantics structure and visitors
REPL ONGOING Will be based on a “interpreter+debugger” simple combination.
Build the LLVM backend ONGOING Started writing wrappers for the C binding. Investigating whenever current SE allows for direct usage of C++ API
Bootstrap from SmartEiffel TODO When all of the above is done.

Things to do later

Item Status Comments
Use the semantics structure to infer some optimizations TODO Feature inlining, late-binding dynamic type sets, non-Void entities… Will use the semantics visitors
Java support TODO
.NET support TODO
GObject-based libraries support TODO Those support shall be “turn-key” and “good-enough”; it should not require the programmer to write glue code in the majority of cases; it may not be a complete automatic mapping of the foreign language: manual tweaking of not-widely used features may be required.
SCOOP TODO Investigate GCD and 0MQ

Calling Liberty from other languages.

Liberty code shall be easily callable from widespread languages.

  1. interoperability with C, Java and C# should be two-way.
  2. Liberty classes shall be usable by Python or Ruby which are AFAIK clean enought to quickly develop generators of glue code.

Class loader

Provide a class loader at runtime, to allow easier development of application plugins.

Things not to do

  1. Add any feature neither in SmartEiffel nor in ECMA (e.g. nothing ISE specific such as bizarre agent conformance… still not defined in ECMA!)

Packaging

The compiler shall be installable from distribution repositories:

  1. Linux
    1. Ubuntu
    2. Debian
    3. Fedora/RedHat
    4. SuSE
    5. Mandriva
  2. Windows: an installer shall be provided
  3. Other UNIX-like? (including MacOS-X)

All those packages should be the result of normal release workflow.

Architecture

  1. “One shot” compiler, requiring write code – compile – test cycle
  2. Compiling service, which monitors the source codes and tries to keep the project up-to-date?

    (Cyril) yes, that could be useful for debugging. We must look at what LLVM allows

  3. REPL

    (Paolo 2009-09-15) yes, I like it! This way the language will be easy to learn, expecially for children. I’m thinking the way I learned BASIC on a Commodore64 and how scripting languages easily spread, partially because they have a REPL-mode.

Dependencies

Possible approaches:

  1. The few dependencies the better
  2. Let’s use external (C/Java/C#) libraries
  3. Use external libraries when re-writing is not smart.

Let’s say we allow Unicode (UTF8 or UTF16) source code; then the question is: shall we write our own Unicode library?

With option (1) we would develop a Unicode library, (Paolo) Let me say I’m strongly against such an idea. We would re-invent the wheel the millionth time, requiring more time than the age of the universe to finish. Depending on low-level libraries, i.e. Glib would allow to re-use code written by other, to be good citizen of the “logicielle libre” community, climbing on the shoulder of giants. I cited Glib because I know it and it is a GNU library; of course I’m not against any other for of logicielle libre. Exiting the ivory tower means that the white mage could use the spells of gray mages when useful (I hope you recall this somewhat subtle citation). The same applies for many other situations. I would suggest to follow this rule: look for external libraries solving a issue, and see if it “fits” Liberty. In that case wrap it.

(Cyril) I’d be strongly in favour of using external libraries as much as possible. I have enough experience in rewriting libraries to know that it is a dead end. One cannot be at the same time expert in network tweaking, gui interfaces, xml parsing, and who knows what else.
One language to bind them all :-)

Documentation

  • Language validity rules a-la Eiffel The Language
    • esp. type system and rules
Add a custom footer
Add a custom sidebar
Clone this wiki locally