Difference between revisions of "SAPL"

From Clean
Jump to navigationJump to search
Line 66: Line 66:
 
If you are brave enough, have a look at the generated SAPL source code. I probably consists of three simple lines only,
 
If you are brave enough, have a look at the generated SAPL source code. I probably consists of three simple lines only,
 
with references to functions located in other modules, e.g. <tt>System.IO</tt>. For proper compilation you need to collect the
 
with references to functions located in other modules, e.g. <tt>System.IO</tt>. For proper compilation you need to collect the
necessary modules from these modules. Precompiled modules can be found in <tt>~/sapl/packages</tt>,  
+
necessary functions from these modules. Precompiled SAPL files can be found in <tt>~/sapl/packages</tt>,  
the necessary system modules in <tt>core/base</tt> and <tt>core/ghc-prim</tt> within that.
+
the base system modules are in <tt>core/base</tt> and <tt>core/ghc-prim</tt> within that.
  
 
== News ==
 
== News ==

Revision as of 19:18, 16 January 2014

SAPL

SAPL is a purely functional, intermediate language and related infrastructure for supporting cross-compilation of lazy functional languages to different target platforms. It currently supports Clean and Haskell/GHC as source languages and provides JavaScript as target platform, however a DART and Java target is under development. SAPL is extensively used in the ITasks project, furthermore various GHC based projects are experimenting with SAPL.

Overview

SAPL infrastructure consists of a few main parts built around the SAPL Language.

Source filters

Source filters convert the source language to the SAPL language. Currently we have source filters for Clean and Haskell/GHC. For Clean, the filter is integrated into the compiler. As for Haskell/GHC, a separate compiler is provided based on the original one. Detailed instructions for their usages can be found at SAPL/Clean and SAPL/GHC, respectively.

SAPL linker

SAPL has hierarchical module support based on directory layout. Prior to the target compilation a linking step is required to collect and combine, based on arbitrary root expressions, the necessary functions recursively from the separate modules into one SAPL file which will be the input of the target compilers.

As the SAPL language is designed for easy parsing, thus the linking is very fast and straightforward compared to the linking of the target languages (e.g. JavaScript) and helps with minimizing the size of the output code.

Flavours

A flavour is a kind of configuration file used by the target compilers. It provides information about how to compile the built-in functions of a given source language to a given target language. It must be in sync with source compiler and source language dependent part of the run-time system. Flavours are provided for all the combinations of source and target languages.

Target compilers

A target compiler transforms SAPL code into a given target language. The compilation must be aided by a flavour for the correct compilation of the built-in functions. The SAPL library supports the development of target languages by providing a lexer and parser for the SAPL language along with language transformation functions (e.g. Topological ordering of let definitions), and other support functions (e.g. strictness propagation, type inference etc). Currently JavaScript is supported as only target language, however DART and Java targets are under development.

Target run-time

Run-time functions are necessary to execute the target code. Some of these are independent of the source language and cope with e.g. lazy evaluation, while some are dependent of the source language and must be in sync with the source filter and the supporting flavour. Some language features must be supported by the run-time system, for the current state of/features supported by the run-times please consult with the appropriate page:

Tutorial (GHC)

As for GHC a carefully adjusted environment must be used for the SAPL compilation (e.g. 32bit compiler must be used, for more explanation please consult to Sapl/GHC). We use [www.vagrantup.com Vagrant] to provide this environment by virtualisation. However, you don't need any knowledge on Vagrant, all you have to do is to install Vagrant in one easy step, check out the following SVN URL

https://svn.cs.ru.nl/repos/clean-sapl/trunk/platforms/GHC/vagrant

and in directory where you checked out type

 $ vagrant up 

followed by

 $ vagrant ssh

and you find yourself using a shell where all the SAPL components are available precompiled. The current directory outside the virtual machine can be accessed at the directory /vagrant.

Now, create a hello.hs with the well knows "Hello, World!" example:

 $ mkdir hello
 $ cd hello
 $ cat > hello.hs
 $ main = putStrLn "Hello, World!"^D

First step, compile it to SAPL:

 $ ghcsapl hello.hs

It creates a Main.sapl, as the file name is the name of the module rather than the name of the original file.

If you are brave enough, have a look at the generated SAPL source code. I probably consists of three simple lines only, with references to functions located in other modules, e.g. System.IO. For proper compilation you need to collect the necessary functions from these modules. Precompiled SAPL files can be found in ~/sapl/packages, the base system modules are in core/base and core/ghc-prim within that.

News

  • January 2 2014: The first draft version of the SAPL wiki is added