SylComp - Simply your language   

  Someday all compilers will be made this way ... meanwhile ...
 enjoy being here helping to build the future.

Live Compilation

In the context of the Sylcomp Project (buiding of a compiler for the Syl programming language), we are talking here about what we call "live" compilation. Syl applications will be divided into modules. The division will be at the programmer's discretion, but typically a "module" will be a part of the application which is not essential to its execution, but which contains functionality which may be useful. For example, an application dealing mainly with local files (eg an accounting program) may have an Internet search "module", a module which will only be used rarely by the user. For speed and good memory management, the programmer can choose to divide his application into two modules. One containing all the functionalities of the application and the other containing Internet search. This last module would not be loaded when the application is launched but only if necessary, if the user requests it.

In SylIDE, the SylComp IDE, the programmer will be allowed, for each application, to work in three modes (application modes): "development", "test" and "real". In development mode ", there will (one day) be three possible compilation modes for a "module":

  • static compilation (obj and / or lib)
  • dynamic compilation (dll)
  • "live" compilation (Syl memory modules)

    The idea of "dll" is excellent for a healthy memory management. In terms of end using of an application, as a general rule, the use of "dll" is good (except for very specific low level applications). At the "memory-space" level, the extra memory need caused by the use of "dlls" is only felt when the user uses all of the "modules", which is generally NOT the case, otherwise the programmer would simply not have chosen this division into modules. At the "speed" level, the discussion is similar. As generally an application containing only the functionalities used takes up much less space in memory, at the end, the use of dlls is only a plus.

    The reason why dlls are not used more often is mainly due to the fact that this causes additional worries for the programmer. However, the problem is in large part due to the current IDEs which do not do their "part": Syl intends to solve this problem (in large part) making the use of dlls almost transparent to the programmer.

    After all, programmers are application developers and they go out of their way to make things easier for their users. Are not a compiltauer and an IDE "applications". The programmers who use them are they not "users". By what magic would applications intended for programmers be freed from the obligation to make their task easier?

    Sorry, that was a bit of an ad for the Syl Philosophy.

    DLLs reside in files on the disk, but once in memory they contain executable code (just like exe), callable on demand.

    more to come ...