Difference between revisions of "SAPL"

From Clean
Jump to navigationJump to search
Line 8: Line 8:
 
== Overview ==
 
== Overview ==
  
−
Compiling Clean or Haskell to JavaScript consists of three easy steps. First, you need to compile
+
SAPL infrastructure consists of a few main parts built around the [[SAPL Language]].
−
the necessary source code modules to the SAPL language. The execution of this step depends on the source language you would like to use.
+
# '''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.
−
Instructions for Clean and Haskell/GHC can be found at [[SAPL/Clean]] and [[SAPL/GHC]], respectively.
 
  
−
=== Linking ===
+
# '''SAPL linker'''. It collects and combine, starting with some root expressions, the necessary functions recursively
−
 
+
into one SAPL file. This helps with minimizing the size of the output code.
−
The second step is to collect and combine, starting with some root expressions, the necessary functions recursively
 
−
into one SAPL file. Engaging on this linking step helps with reducing the final code size as much as possible.
 
−
The linking is done using the <tt>sl</tt> command. A simple example for its usage is as follows:
 
−
 
 
−
<pre>
 
−
sl --include-dir=build --expr=Main.main out.sapl
 
−
</pre>
 
−
 
 
−
It links for the <tt>main</tt> function in the module called <tt>Main</tt> and collects all the necessary functions into the <tt>out.sapl</tt> file.
 
−
The module search path is the <tt>build</tt> directory in the current directory. Multiple root expressions and include directories can be provided. For the other command line arguments please type
 
−
 
 
−
<pre>
 
−
sl --help
 
−
</pre>
 
−
 
 
−
=== Final compilation ===
 
−
 
 
−
The result of the <tt>sl</tt> command can be compiled to JavaScript using the <tt>sapl2js</tt> command.
 
−
The following example compiles <tt>out.sapl</tt> to JavaScript and places the result in the file <tt>out.js</tt>.
 
−
 
 
−
<pre>
 
−
sapl2js -f clean -o out.js out.sapl
 
−
</pre>
 
−
 
 
−
Please note the usage of the <tt>-f</tt> command line argument. The target code depends on the source language as different languages
 
−
use different ''primitive/built-in functions''. Thus, during the final compilation step, the compiler must be aware of the primitive
 
−
functions contained by the SAPL source code.  
 
−
 
 
−
This information is provided by the so called '''flavor''' file to the final compiler. The file has an extension of ".f" and it describes
 
−
how to compile the primitive functions of a given source language to a given target language. As currently we have two source languages and one target platform, two flavor files are provided: one for the compilation of Clean to JavaScript (clean.f) and one
 
−
for compilation of Haskell/GHC to JavaScript (ghc.f).
 
−
The compiler looks up the flavor file in the following directories in the given order:
 
 
   
 
   
−
# in the current directory
+
# '''Flavours'''. A flavour is a kind of configuration file used by the target compilers. It provides information about
−
# in the directory which contains the executable of the compiler (bindir)
+
how to compile the built-in functions of a given source language to a given target language.
−
# bindir/../lib/sapl/
 
−
# bindir/../lib/
 
−
 
 
−
For further command line arguments please type
 
−
 
 
−
<pre>
 
−
sapl2js --help
 
−
</pre>
 
−
 
 
−
=== Micro optimizations ===
 
−
 
 
−
As an optional step, we recommend to use [https://developers.google.com/closure/compiler/ Closure Compiler]
 
−
for micro optimizations of the generated JavaScript code. It can speed up the generated JavaScript code by up to 10-20 percents.
 
−
You can use a following command:
 
−
 
 
−
<pre>
 
−
java -jar closure-compiler.jar --js_output_file out.js in.js
 
−
</pre>
 
−
 
 
−
=== Execution ===
 
  
−
For the execution of the final script you need to cope with the SAPL run-time engine.
+
# '''Target compilers'''. A target compiler transforms SAPL code into a given target language. The compilation must be aided by
−
It consists of the actual run-time functions and the implementation of the primitive functions.
+
a flavour for the correct compilation of the built-in functions.  
−
This latter depends on the source language, thus, you need (partly) different run-time
 
−
for different source languages.
 
  
−
Template HTML as well as the necessary JavaScript files for GHC and Clean can be found at
+
# '''Target run-time'''. Run-time functions are necessary to execute the target code. Some of these are independent of the source language
−
[https://svn.cs.ru.nl/repos/clean-sapl/trunk/platforms/GHC/run-time GHC run-time]
+
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
−
and at [https://svn.cs.ru.nl/repos/clean-sapl/trunk/platforms/Clean/run-time Clean run-time]. You also need to borrow the common
+
the supporting flavour.
−
part of the RTS from [https://svn.cs.ru.nl/repos/clean-sapl/trunk/platforms/Common/run-time Common RTS].
 
  
 
== Getting started ==
 
== Getting started ==

Revision as of 17:08, 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 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.

  1. 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.
  1. SAPL linker. It collects and combine, starting with some root expressions, the necessary functions recursively

into one SAPL file. This helps with minimizing the size of the output code.

  1. 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.

  1. 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.

  1. 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.

Getting started

So far, no official version of the SAPL compiler infrastructure is released. The current development version can be checked out from https://svn.cs.ru.nl/repos/clean-sapl. Build instructions can be found at SAPL/Build

GHC

Clean

Tutorial (GHC)

Before you engage in following this tutorial, please make sure you successfully installed the SAPL system as it is written at SAPL/Build.

TODO

News

  • January 2 2014: The first draft version of the SAPL wiki is added
Retrieved from "https://wiki.clean.cs.ru.nl/index.php?title=SAPL&oldid=1148"