Fork us on GitHub Follow us on Facebook Follow us on Twitter

Changes between Version 19 and Version 20 of Sysel


Ignore:
Timestamp:
2010-05-20T19:04:53Z (11 years ago)
Author:
Jiri Svoboda
Comment:

Introductory word, code organization

Legend:

Unmodified
Added
Removed
Modified
  • Sysel

    v19 v20  
    77
    88Note that Sysel syntax is not finalized. Some important language features are missing at the moment (especially visibility control and packaging) so the examples presented will need to change when these are implemented.
     9
     10This article currently serves several purposes. First as a memo, not to forget ideas and elaborations. Second as a temporary source of information for anyone who wants to learn about Sysel (and plans for it). Third by sharing the plans to allow discussion and brainstorming.
    911
    1012== Roadmap ==
     
    4345 * generic type constraints
    4446 * method and operator overloading
    45  * packaging
     47 * code organization (packages and modules)
    4648
    4749== Ideas for Sysel ==
     50
     51Notes on features which are almost certain to appear in Sysel in one way another.
     52
     53=== Code organization ===
     54
     55Sysel shall employ ''packages'' and ''modules''. Together, these two constructs provide full information about organization of the codebase and allow for a certain degree of freedom in how finely the code is partitioned,
     56
     57==== Packages ====
     58
     59Packages provide two main features: a namespace and visibility controls. Packages thus provide a greater level of isolation than mere classes and allow safe composition of code developed by different (uncoordinated) teams. Packages can have a well defined API/ABI and can be delivered in compiled form via libraries. Each package has a name which must be fully qualified.
     60
     61Within a package all symbol references only need to be qualified relative to the package. To reference symbols outside of the current package they must be ither imported or the reference must be fully qualified. (TODO: Should we enforce explicit import of all symbols?) Symbols can only be imported individually or in a qualified manner. This ensures that there can be no collisions of symbols from different namespaces (which need not be under the control of the same entity). When importing symbols the symbols being imported must be specified using their fully qualified names.
     62
     63==== Modules ====
     64
     65Modules provide a complementary and finer-grained means of decomposition. Usually each source file corresponds to exactly one module. For each module we define its (unqualified) name and fully qualified name of the package it belongs to (which 'anchors' it in the code base). Conversely, each package specifies all modules it consists of. Thus for each module we can determine which package it belongs to and for each package we can determine all modules (and thus all symbols) it consists of.
     66
     67Thus modules allow the source code to be broken into separate files and at the same time tie it together in a formal manner. When building a package or program, there is thus no need to specify all its source files informally in a makefile. It is sufficient to point the compiler to directories where it should look for source files and tell it which package we want built.
     68
     69Modules do not represent a namespace. Any symbols defined or imported in one module will be accessible (unqualified) in any other module within the same package. Names of global symbols in all modules of a package thus must be coordinated. Note that due to object-oriented nature of the language there are usually not very many global symbols defined per module.
     70
     71Definitions of classes can be split across multiple modules (but not packages). Thus large classes can be split accross multiple source files.
    4872
    4973=== Dynamic linking ===