My photo

Mildred's Website

My avatar

GoogleTalk, Jabber, XMPP address:

GPG Public Key
(Fingerprint 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B)

Category: dev

Articles from 6 to 15

Wed 28 Nov 2012, 02:49 PM by Mildred Ki'Lya comp dev en lisaac lysaac

The overlooked problem

Let me explain the reason why I think Lisaac is broken and why I stopped working on it. The fundamental concept behind it is completely broken, and i never could solve the problem. First, let me explain a few things about Lisaac:

  • It is statically typed (like Eiffel)
  • It is prototype based (like Self)

It may not seem like it but those two things are mutually exclusive, unless something is done to reconcile the two. Being statically typed means you know the type (or a parent of the real type) at compile-time. Being prototype based means that the type can change completely.

Imagine you have a CUCUMBER that inherit VEGETABLE. If at some point during run-time, the cucumber inherit SOFTWARE (yes, cucumber is the name of a software as well) you have a problem. Yet, this is not the problem I want to talk about.

Lisaac solve this problem because you can only assign a child type as a parent. In the following object:

 Section Header
   + name := CUCUMBER;
 Section Inherit
   + parent :VEGETABLE := ...;

So, you're forbidden to assign a SOFTWARE in the parent slot because SOFTWARE is not a child of VEGETABLE. But, you're allowed to assign a GREEN_VEGETABLE. So not it becomes:

 Section Header
   + name := CUCUMBER;
 Section Inherit

Now, let's say you send a message to your cucumber, and through the magic of inheritance, you end up in a slot of the parent. That is, you are executing code that is located in GREEN_VEGETABLE. Then, you have a problem.

 Section Header
   + name := GREEN_VEGETABLE;
 Section Public
   // inherited from VEGETABLE
   - do_something <- paint_it_green;
 Section Private
   // specific to GREEN_VEGETABLE
   - paint_it_green <- ( "green".println; );

In the code above, if you are executing the do_something slot and have SELF = CUCUMBER, you can't possibly call the paint_it_green slot because it does not exist in CUCUMBER, and the Lisaac compiler will refuse to compile your code. To explain it another way, the type of Self is not compatible with GREEN_VEGETABLE, and this is a problem for this is the code we are executing. You can't easily solve this problem.

In the Self language, if you had a similar situation, it would work because it is not statically typed. It would have failed to find paint_in_green in the cucumber and called the parent, which would have been a green vegetable. Somehow, the type of the cucumber would have changed at runtime, which is incompatible with a type system that can only compute types at compile time (and have them immutable at run time).

So, I stopped working on Lisaac

I tried to start up a new project, Lysaac, but got confronted to the same problem once the compiler was mature enough to start getting into inheritance. So I stopped again. Life getting in the way didn't help.

A new hope

I tried to look into virtual machines, convincing myself that compiled languages couldn't possibly answer such need to dynamic things in the language. I looked at Self for the first time. I tried to build a virtual machine that was fully concurrent. I looked at the Go language because I know that it has nice concurrent primitives ... and I found illumination.

The Go language feels like a dynamic language, but it is compiled. I always wondered how it could implement duck typing, and I found out. I also realized that the difference between a virtual machine with a JIT compiler, and a runtime for a compiled language that included a compiler was very narrow. Basically, nothing prevents any language from being compiled instead of being JIT compiled. You just have to include a compiler in the standard library.

Ironically, that what Common Lisp is doing.

A new language

I like how Go implements interfaces, and I want to do the same. In this new language, an object is composed of :

  • an opaque work (pointer sized)
  • a pointer to an interface

An interface is a collection of pointers to functions. There is always a pointer for the fallback implementation and a pointer for the case operation (to case an object to a new interface).

I want to use a smalltalk/Io type syntax. So the following will represent an object with one variable and one slot:

 obj := {
   var := obj slot;
   slot <- { ... };

The data word of obj would be a pointer to a struct containing the variable "var" The interface of obj would be:

  • a function pointer for the fallback implementation that throws an error
  • a function pointer for the "cast" operation
  • a function pointer for the "slot" slot

I haven't figured out yet how to pass parameters to functions and return objects. This kind of things will require to comply to predefined interfaces (we need a way to tell which object type is returned by a slot for example). Interfaces would probably be defined at compile time and available as constants in code at run time (to be given as parameter to the cast slot).

If I want to be able to compile on the fly the code, I need to include the LLVM library. So I need to implement the language in a language that is compiled using LLVM (so bootstraping will be easier).

Thu 13 Sep 2012, 03:30 PM by Mildred Ki'Lya comp dev en idea wwwgen

I started writing wwwgen: a website generator that uses redo for its dependency tracking. Unfortunately, I might not have taken the correct approach to the problem. I reuse the webgen concepts, and that might be a bad idea.

Specifically, webgen (and my first version of wwwgen) are bottom-up systems (you take the sources and build everything they can generate). The problem is that redo itself is top-down (you take the target and build it, building sources as they are needed), and I tried to make the two match. It's very difficult, and impossible to do with a clean design.

What I'd like to have is a simple wwwgen binary that generates a HTML file from a source file. Let's imagine how it could work:

  • If the source file is a simple page with no templates, just generate the HTML and this is it

  • If the source file is a simple page with a template, redo-ifchange the template source and build the HTML combining the two

  • If the source file is an index, we have a problem because multiple outputs are generated. Redo doesn't support this case and we must find a way to make it work.

So, we have a problem here ...

Now, we have another problem. Specifically, my source file is called and I want my output file to be title/index.html. In webgen, this is implemented by a configuration in telling it to build in title/index.html.

There is a solution to solve both problems at once. the wwwgen command creates an archive (the formats needs to be defined, it could be tar, or different yaml documents in the same file for example). Then, the build process would be:

 find src -name "*.src" \
   | sed 's/src$/gen/' \
   | xargs -d '\n' redo-ifchange
 find src -name "*.gen" \
   | xargs -d '\n' wwwgen unpack

 redo-ifchange "$2.src"
 wwwgen --redo-dependencies -o "$3" generate "$2.src"

wwwgen generate would parse the source file and generate an archive, that will be unpacked later by wwwgen unpack. Let's see how it can work:

  • The source file can choose where it unpacks, relatively to the directory where the source file is

  • If the source file is an index, it will redo-ifchange the other source files for the index and redo-ifchange the template, generate multiple pages packed together.

  • If the source file is a tag tree (a special source that doesn't output anything on its own but create index files dynamically), then it parses every child to find a canonical list of tags and the paths they refer to. Then, it creates the index files. Unfortunately, those index files will never be compiled until next build.

How an we improve the design to be able to create source files dynamically.

There are different views to the problem:

  • pages, index and tags should all generate all the output files they are related to. It means that index files should be able to generate pages, and tags should be able to generate indexes and pages.

  • pages should generate the output file, index should generate pages and feeds and tags should generate index.

  • mixed solution (the one described): pages generate output file, index should generate the output files as well and tags generates index.

How can we generate source files on the fly:

  • have a predefined compilation order: first tags, then index and lastly feeds and pages.

  • rebuild everything until no more source files are generated. We might build unnecessary things.

I prefer the second solution which is more flexible, but we need a way to avoid building things twice. For example, it's not necessary to build a page if on the next phase the page source is going to be regenerated.

Very simply, the generated page can contain a link to the index source file that generated it, and when generating the page, redo-ifchange is run on the index file.

Next question: what if a tag is deleted. The corresponding index page is going to stay around until the next clean. The tag page should keep around a list of index files it generated and delete them when a tag is no longer detected. And deleting the index should not be done using rm because the index will need to delete the pages it generated. The best solution would be to integrate to redo to detect these files.

The build scripts now are:

 srclist="$(find src -name "*.src")"
 while [ "$oldsrclist" != "$srclist" ]; do
   echo "$srclist" \
     | sed 's/src$/gen/' \
     | xargs -d '\n' redo-ifchange
   srclist="$(find src -name "*.src")"

 find src -name "*.gen" \
   | xargs -d '\n' wwwgen unpack

 redo-ifchange "$2.src"
 wwwgen --redo-dependencies -o "$3" generate "$2.src"

Thu 02 Aug 2012, 11:15 AM by Mildred Ki'Lya comp dev en git

I was looking at Git, and which features may land in the next few releases, and I found the following things:

Git-SVN will be completely redesigned

If you worked with git-svn, you probably know that the git-svn workflow has nothing to do with git. Basically, you just have the svn history and have to use git-svn to push the changes back to the subversion repository. You can't use git-push and that's really annoying.

Recently, the git-remote-helpers feature was added. It allows git to interact with any kind of remote url, using a specific git-remote-* command. For example, you can already use mercurial this way (according to git-remote-hg):

Git allows pluggable remote repository protocols via helper scripts. If you have a script named "git-remote-XXX" then git will use it to interact with remote repositories whose URLs are of the form XXX::some-url-here. So you can imagine what a script named git-remote-hg will do.

Yes, this script provides a remote repository implementation that communicates with mercurial. Install it and you can do:

$ git clone hg::
$ cd some-mercurial-repo
$ # hackety hackety hack
$ git commit -a
$ git push

The plan is to do the same with subversion. You could just do:

 $ git clone svn::

Branches might be tricky to implement, they might not be there. But you will get what's already in git-svn but with a way better UI. And far more possibilities for the future.

Here is the summary from the GSoc page:

The submodule system of git is very powerful, yet not that easy to work with. This proposed work will strengthen the submodule system even more and improve the user experience when working with submodules.

Git repository:

Midterm evaluation: passed

Progress report / status:

  • [GSoC 11] submodule improvements at git mailing list
  • [GSoC 11 submodule] Status update at git mailing list
  • [RFC PATCH] Move git-dir for submodules at git mailing list

Submodules will be improved a lot

I wish it was already there. From the wiki page, the improvements will be:

As Dscho put it, submodules are the “neglected ugly duckling” of git. Time to change that …

Issues still to be tackled in this repo:

  • Let am, bisect, checkout, checkout-index, cherry-pick, merge, pull, read-tree, rebase, reset & stash work recursively on submodules (in progress)
  • Teach grep the --recursive option
  • Add means to specify which submodules shall be populated on clone
  • Showing that a submodule has a HEAD not on any branch in “git status”
  • gitk: Add popup menu for submodules to see the detailed history of changes
  • Teach “git prune” the “--recurse-submodules” option (and maybe honour the same default and options “git fetch” uses)
  • Better support for displaying merge conflicts of submodules
  • git gui: Add submodule menu for adding and fetching submodules
  • git status should call “git diff --submodule --ignore-submodules=dirty” instead of “git submodule summary” for providing a submodule summary when configured to do so.
  • Add an “always-tip” mode
  • Other commands that could benefit from a “--recurse-submodules” option: archive, branch, clean, commit, revert, tag.
  • In the long run should be converted to a rather simple wrapper script around core git functionality as more and more of that is implemented in the git core.

Submodule related bugs to fix

  • Cherry picking across submodule creation fails even if the cherry pick doesn’t touch any file in the submodules path
  • git submodule add doesn’t record the url in .git/config when the submodule path doesn’t exist.
  • git rebase --continue won’t work if the commit only contains submodule changes.

Issues already solved and merged into Junio’s Repo:

  • Since git 1.6.6:
    New --submodule option to “git diff” (many thanks to Dscho for writing the core part!)
    Display of submodule summaries instead of plain hashes in git gui and gitk
  • Since git 1.7.0:
    “git status” and “git diff*” show submodules with untracked or modified files in their work tree as “dirty”
    git gui: New popup menu for submodule diffs
  • Since git 1.7.1:
    Show the reason why working directories of submodules are dirty (untracked content and/or modified content) in superproject
  • Since git 1.7.2:
    Add parameters to the “--ignore-submodules” option for “git diff” and “git status” to control when a submodule is considered dirty
  • Since git 1.7.3:
    Add the “ignore” config option for the default behaviour of “git diff” and “git status”. Both .git/config and .gitmodules are parsed for this option, the value set in .git/config. will override that from .gitmodules
    Add a global config option to control when a submodule is considered dirty (written by Dscho)
    Better support for merging of submodules (thanks to Heiko Voigt for writing that)
  • Since git 1.7.4:
    Recursive fetching of submodules can be enabled via command line option or configuration.
  • Since git 1.7.5:
    fetch runs recursively on submodules by default when new commits have been recorded for them in the superproject
  • Since git 1.7.7:
    git push learned the --recurse-submodules=check option which errors out when trying to push a superproject commit where the submodule changes are not pushed (part of Frederik Gustafsson’s 2011 GSoC project)
  • Since git 1.7.8:
    The “update” option learned the value “none” which disables “submodule init” and “submodule update”
    The git directory of a newly cloned submodule is stored in the .git directory of the superproject, the submodules work tree contains only a gitfile. This is the first step towards recursive checkout, as it enables us to remove a submodule directory (part of Frederik Gustafsson’s 2011 GSoC project)

And the GSoC page:

The submodule system of git is very powerful, yet not that easy to work with. This proposed work will strengthen the submodule system even more and improve the user experience when working with submodules.

Git repository:

Midterm evaluation: passed

Progress report / status:

  • [GSoC 11] submodule improvements at git mailing list
  • [GSoC 11 submodule] Status update at git mailing list
  • [RFC PATCH] Move git-dir for submodules at git mailing list

Thu 21 Jun 2012, 03:08 PM by Mildred Ki'Lya dev en website

Hi everyone, I just developed a new way to update my blog. I am just using my mailer (which is currently Thunderbird for a lack of a better alternative). As you may know, I already manage my own server. I have a nginx web server and my website is just plain old static pages generated from markdown using my own version of webgen.

My code is available at two locations:

I just developed a few scripts which does the following:

  • hooked in /etc/aliases, receive e-mail from a special e-mail address. Put this mail in an inbox directory on the server
  • another daemon (a shell script run by daemontools actually) run as the www-data user is monitoring the inbox using inotifywait. When a mail comes, or every 60 seconds, it process the mail using a ruby script that convert the mail to a markdown page, and run webgen on the website. It also commit and push the changes.

And that's all.

The one thing I couldn't automate is the creation of the private key to push the changes back to the git server.

All the code is there. I just don't know if I have a public URl for these repos :)

Wed 19 Oct 2011, 10:21 AM by Mildred Ki'Lya comp dev en privacy web

What is this all about: web privacy. We are tracked everywhere, and i'd like to help if possible. So, let's design a web browser that for once respects your privacy.

Main features:

  • Each website has its own cookie jar, its own cache and its own HTML5 local storage
  • History related css attributes are disabled
  • External plugins are only enabled on demand
  • Support for Tor/I2P is enabled by default
  • You have complete control over who receives what information
  • Let's you control in the settings if you want to allow referrers or not.
  • The contextual menu let's you open links anonymously (no referrer, anonymous session)

The browser is bundled with a particular UI that let you control everything during your browsing session. it is non intrusive and makes the best choice by default. I am thinking of a notification bar that shows at the bottom. I noticed that this place is not intrusive when I realized that the search bar in Firefox was most of the time open, even if most of the time I didn't use it.

First, let's define a session:

  • A session can be used my more than one domain at the same time.
  • A session is associated to a specific cache storage
  • A session is associated to a specific HTML5 storage
  • A session is associated to a specific cookie jar
  • A session acn be closed. When it is closed, session cookies are deleted from the session
  • A session can be reopened. All long lasting cookies, cache, HTML5 storage and such is then used again.
  • A session can be anonymous. In such a case, the session is deleted completely when it is closed.
  • A session is associated to none, one or more domains. These domains are the domains the end user can see in the address bar, not the sub items in the page.

Sessions are like Firefox profiles. If you iopen a new session, it's like you opened a new Firefox profile you just created. Because people will never create a different Firefox profile for each site.

If we want to protect privacy, when a link is opened, a new session should be created each time. To make it usable to browse web sites, it is made possible to share sessions in specific cases. Let's define the cases where it might be intelligent to share a profile:

  • You click a link or submit a form and expect to still be logged-in in the site you are viewing. You don't care if you follow a link to an external page.

    User Interface: If the link matches one of the domains of the session, then keep the session. No UI. If the user wanted a new session, the "Open anonymously" entry in the context menu exists. A button on the toolbar might be available to enter a state where we always want to open links anonymously.

    If the link points to another domain, then open the link in a new session unless "Open in the same session" was specified in the context menu. The UI contains:

    We Protected your privacy by separating <domain of the new site> from
    the site you were visiting previously (<domain of the previous site>).
    Choices: [ (1) Create a new anonymous session          | ▼ ]
             | (2) Continue session from <previous domain> |
             | (3) Use a previous session for <new domain> |
             | (4) Use session from bookmark "<name>"      |

    The first choice is considered the default and the page is loaded with it. If the user chooses a new option, then the page is reloaded.

    If the user chooses (2), the page is reloaded with the previous session and the user will be asked if "Do you want <old domain> and <new domain> to have access to the same private information about you?". Answers are Yes, No and Always. If the answer is Always, then in the configuration, the two domains are considered one and the same.

    The choice (3) will use the most recent session for the new domain. It might be a session currently in use or a session in the history.

    There are as many (4) options as there are bookmarks for the new domain. If different bookmarks share a single session, only one bookmark is shown. This choice will load the session from the bookmark.

    If (3) and (4) are the same sessions, and there is only one bookmark (4), then the (4) option is left out.

  • You use a bookmark and expect to continue the session you had for this bookmark (webmails)

    The session is simpely stored in the bookmark. When saving a bookmark, there is an option to store the session with it or not.

    [X] Do not save any personal information with this bookmark
  • You open a new URL and you might want reuse a session that was opened for this URL.

    The User Interface allows you to restore the session:

    We protected your privacy by not sending any personal information to
    <domain>. If you want <domain> to receive private information, please
    Choices: [ Do not send private information     | ▼ ]
             | Use a previous session for <domain> |
             | Use session from bookmark "<name>"  |

If you can see other use cases, please comment on that.

From these use cases, I can infer three kind of sessions:

  • Live sessions, currently in use
  • Saved sessions, associated to a bookmark
  • Closed sessions in the past, accessible using history. Collected after a too long time.

Now, how to implement that? I was thinking of QtWebKit as I already worked with Qt and it's easy to work with.

  • We have a main widget: QWebView. We want to change the session when a new page is loaded. So we hook up with the signal loadStarted.
  • We prevent history related CSS rules by implementing QWebHistoryInterface, more specifically, we store the history necessary to implement QWebHistoryInterface in the session.
  • We change the cache by implementing QAbstractNetworkCache and setting it using view->page()->networkAccessManager()->setCache(...)
  • We change the cookie jar by implementing QNetworkCookieJar and setting it using view->page()->networkAccessManager()->setCookieJar(...)
  • Change the local storage path using a directory dedicated for the session and using view->page()->settings()->setLocalStoragePath(QString)

After all that, we'll have to inspect the resulting browser to determine if there are still areas where we fail at protecting privacy.

Mon 09 May 2011, 02:40 PM comp dev en


  • What is HMP: It is a messaging protocol destined to replace e-mails.

  • Why replace e-mails: Because it is full of spam and unmaintainable. This alternative is lighter and easier to implement than a full SMTP server with SPAM management.

  • Why use HTTP: I'm not fan of putting everything over HTTP but it has its advantages:

    • It has a security layer (HTTPS)
    • It is (relatively) simple and implemented everywhere
    • It manages content-types and different types of requests
    • It is extensible
    • It goes easily through proxys and NATs
    • It allows multiplexing many different resources on the same server

    In the long run, perhaps we should move away from HTTP as:

    • It is too associated with the web
    • It doesn't allow initiative from the server.

    WebSockets could be a good alternative one day.

  • How do I get my messages: Not specified, although you could possibly authenticate using a standard HTTP method to the same resource as your address and issue a GET command.

  • Does this allows a web implementation: Yes, it will need to be further specified but if the server detects a browser request (without the HMP headers) on the resource, it could issue a web-page with a form.

  • Is the message format specified: no, it needs to be. I plan on using JSON.

  • Do you plan an implementation: Yes, using probably node.js or Lua.

  • What prompted this: The Tor network doesn't have any standard messaging system. I don't believe SMTP is suited for that.

  • Why write this spec, you have no code to back this up: because I like writing specs, and it's a way for me to remind me to write the code, and to tell me how I should write it. I might not get the time to write this as soon as I want.

What is a hmp address




Translation to HTTPS resources

A HMP address can directly be translated to an HTTPS resource. The standard scheme translates to:


Message sending overview

To send a message from to, the sequence is:

  • Connection to

    [1] POST
    [1] HMP-Pingback: 235
    [1] HMP-From:
    [1] Content: message-content
  • opens a connection to

    [2] GET
    [2] HMP-Pingback: 235
    [2] HMP-Method: MD5
  • responds to

    [2] HMP-Hash: ef0167eca19bb2d4c8dfe4c3803cc204
    [2] Status: 200
  • responds to the original sender

    [1] Status: 200

Headers to the POST request

The POST request is the request used to post a message. It contains two specific headers:

  • HMP-From: The address the message is sent from

  • HMP-Pingback: A sequence number that uniquely identifies the message for the sender. it needs not be unique, as long as at ont point in time, there are only one message corresponding to this ID.

Particular status codes:

  • 200 in case of success

  • 403 in case the From address could not be authenticated

From address authentication, pingpack

In order to avoid SPAM, the sender must be authenticated when the message is sent. For this reason, before accepting or rejecting the request, the server must initiate a pingback procedure to the sender.

First, the From address is converted to an HTTPS resource and a GET connection is initiated. The specific request-headers are:

  • HMP-Pingback: the pingback sequence number from the previous request

  • HMP-Method: method for verifying the originating message. The only specified method is "MD5"

MD5 Method

In case the message is recognized, the from server responds with the following header:

  • HMP-Hash: MD5 hash of the content of the message identified by the pingback identifier

The status code can be:

  • 200 in case the message was recognized

  • 404 in case the message was not found

If the MD5 sum corresponds to the message received and a success code was given, the from is verified and the message can be sent.

Mon 02 May 2011, 12:04 PM comp dev en lisaac lysaac

This is great: Here is the source files:


Section Header

  + name := Reference CSTRING;

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


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:


@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 ?

Fri 29 Apr 2011, 09:56 AM comp dev lisaac lysaac

Look at this:

Section Header

  + name := Singleton NULL;

Section Public

  - is_null :BOOLEAN <- FALSE;

Section Header

  + name := Singleton NULL;

Section Inherit

  - parent :OBJECT := OBJECT;

Section Public

  - is_null :BOOLEAN <- TRUE;

Section Header

  + name := UNION;

Section Inherit

  - parent :OBJECT := OBJECT;

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;

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;

Section Header

  + name := USE;

Section Public

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

Fri 29 Apr 2011, 09:52 AM comp dev en lisaac lysaac

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.

Fri 29 Apr 2011, 09:40 AM comp dev en lisaac lysaac

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.