Emojicode Documentation 1.0 beta 2


What Is a Package?

Emojicode divides code into packages. A package is a unit of code that can consist of one or more Emojicode source code files. All packages have a name associated with them and all code belongs to a package.

If you tell the compiler to compile a file this file implicitly becomes the main file for a package called _. So remember, all code you write belongs to a package.

The objective of packages is to provide an easy way of reusing code as well as allowing the programmer to divide programs into logical units.

Each package has its own set of namespaces. If you define or import types in one package, these types will not be available in other packages without explicitly exporting and importing them.


Make sure youโ€™re familiar with Emojicodeโ€™s namespaces.

Importing Other Packages

As you probably already know, you can import packages. The syntax to do this is:

package-import โŸถ ๐Ÿ“ฆ package-name type-emoji
package-name โŸถ variable

If such a statement occurs to the compiler, the compiler will search the its package search paths for a package with the provided name package-name and will try to import it. To learn more about the package search paths, please see Appendix: The Emojicode Compiler.

If you import a package, all types that were exported from the imported package are made available in the importing package. The types will be added to the provided namespace. If this would cause a naming collision, the compiler will emit an error.

The example below imports the files package into the default namespace ๐Ÿ . The progam then uses the class ๐Ÿ“„ which was imported from the files package.

๐Ÿ“ฆ files ๐Ÿ 

๐Ÿ ๐Ÿ‡
  ๐Ÿบ๐Ÿ†•๐Ÿ“„โ–ถ๏ธ๐Ÿ“œ ๐Ÿ”คnovel.txt๐Ÿ”คโ—๏ธ โžก๏ธ readFile

Any package can load other packages as long as this doesnโ€™t lead to a circular dependency. The compiler will detect circular dependencies and abort the compilation.

The s package is implicitly imported into the default namespace ๐Ÿ  of every package.

Writing an Importable Package

Exporting Types

A package always has a main file, which is the file you pass to the compiler. This file can then include other files using ๐Ÿ“œ.

By default, all types defined within a package are internal and not exported. If you want to export a type defined in your package you must attribute it with ๐ŸŒ.

Keep in mind that types donโ€™t actually belong to a namespace. When exporting a type, the namespace is irrelevant.

For instance, the main file of a cat simulator could look like this:

๐ŸŒ ๐Ÿ‡ ๐Ÿฑ ๐Ÿ‡
  ๐Ÿ†• ๐Ÿ‡๐Ÿ‰

  โ—๏ธ ๐ŸŽ™ ๐Ÿ‡
    ๐Ÿ˜€ ๐Ÿ”คMeow๐Ÿ”คโ—๏ธ

Compiling the Package

We can now tell the compiler to compile the cat simulator package:

emojicodec -p catsimulator main.emojic

If you run this command, the compiler will not create an executable binary, but an archive (named libcatsimulator.a in our example) and an interface file called ๐Ÿ›. The interface file describes your package in a special subset of Emojicode. When the compiler tries to import a package it looks for this interface file to determine the interfaces of the package. It is crucial that you not modify this file in any way. Note that the file may also be called interface.emojii but no such file can coexist with a ๐Ÿ› file in a package.

If we place these two files inside a directory named catsimulator we have a package ready for distribution!

Let us test our new package by writing this short program test.emojic:

๐Ÿ“ฆ catsimulator ๐Ÿ 

๐Ÿ ๐Ÿ‡
  ๐Ÿ†•๐Ÿฑโ—๏ธ โžก๏ธ cat

Our directory structure looks like this now:

โ”œโ”€โ”€ packages
โ”‚   โ””โ”€โ”€ catsimulator
โ”‚       โ”œโ”€โ”€ ๐Ÿ›
โ”‚       โ””โ”€โ”€ libcatsimulator.a
โ””โ”€โ”€ test.emojic

Finally, we compile test.emojic

emojicodec test.emojic

and give it a shot:


The ๐Ÿ Block in Packages

You can include a ๐Ÿ block in every package. Only the ๐Ÿ block of the package from which you ask the compiler to create an executable will be executed. This, for example, means that if you import a package that provides a ๐Ÿ block it will not be exeucted. If you compile that package to an executable then, of course, the ๐Ÿ block will be executed.

Linking with Non-Emojicode Code

You can also implement methods and initializers in another language.

To do this, you must specify a name for the method or initializer instead of a function body. For example:

โ—๏ธ ๐Ÿ”ก โžก๏ธ ๐Ÿฌ๐Ÿ”ก ๐Ÿ“ป ๐Ÿ”คsDataAsString๐Ÿ”ค
external-link-name โŸถ ๐Ÿ“ป string-literal

You can then implement the function in e.g. C++. Then compile these implementations to object files as well and pack them into the package archive. Itโ€™s important that the implementations conform to the C calling convention.

Learn more about implementing functins in C++ in this guide.

Emojicode packages are complied to static archives. If your package depends on a shared library this means that the Emojicode Compiler, when linking the binary, must be aware of this dependency.

You can list shared libraries that must be linked as link hints at document level:

link-hints โŸถ ๐Ÿ”— link-hints-list ๐Ÿ”—
link-hints-list โŸถ string-literal | link-hints-list

This example is taken from the allegro package:

๐Ÿ“œ ๐Ÿ”คdisplay.emojic๐Ÿ”ค
๐Ÿ“œ ๐Ÿ”คapp.emojic๐Ÿ”ค

โ† Previous Next Up: โ€œThreadsโ€ โ†’
Something not quite right? Improve this page