Changes between Version 8 and Version 9 of PIL


Ignore:
Timestamp:
10/04/24 13:35:48 (20 months ago)
Author:
siegel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • PIL

    v8 v9  
    22
    33== Basic Properties
    4 * PIL programs are target of translators from C, Fortran, MPI/OpenMP/etc. They can also be written by humans.
    5 * PIL should be a high-level language like CIVL-C.
    6 * PIL programs can be easily translated to PFG.
    7 * PIL must also have a totally well-defined semantics and syntax.
    8 * PIL programs can have nested funtion definitions.
    9 * PIL programs can use preprocessor directives like in C
    10 * There are no automatic conversions.  All must be done by explicit casts.
    11 * `$input`/`$output` variables in global scope (like CIVL-C)
    12 * Identifiers are like in C, e.g.,  `x`, `f10`, ...
    13 * Keywords, functions, etc. not in C start with `$` (like CIVL-C)
    14 * Libraries: similar to C, `#include <stdlib.h>`, but these name PIL libraries and there are additional PIL libraries
    15 * PIL programs can be divided into multiple files (translation units)
    16  *  One TU can refer to a variable, function, type, in another TU.
    17  * the variable just needs to be declared somewhere in the TU
    18  * the function just needs a prototype somewhere in the TU
    19  * the use of "static" in a variable decl or function def makes it private to that TU (so two can have same name)
    20  * no need for "extern"
    21  * at most one of the TUs declaring the variable can have an initializer
    22  * at most one of the TUs can have a definition for a function
    23 * Program order:
    24  * a program is a sequence of variable, function, and type definitions.
    25  * the order is totally irrelevant.
    26  * a variable can be used anywhere it is in scope
    27  * a function can be called anywhere it is in scope
     41. PIL programs are target of translators from C, Fortran, MPI/OpenMP/etc. They can also be written by humans.
     51. PIL should be a high-level language like CIVL-C.
     61. PIL programs can be easily translated to PFG.
     71. PIL must also have a totally well-defined semantics and syntax.
     81. PIL programs can have nested funtion definitions.
     91. PIL programs can use preprocessor directives like in C
     101. There are no automatic conversions.  All must be done by explicit casts.
     111. `$input`/`$output` variables in global scope (like CIVL-C)
     121. Identifiers are like in C, e.g.,  `x`, `f10`, ...
     131. Keywords, functions, etc. not in C start with `$` (like CIVL-C)
     141. Libraries: similar to C, `#include <stdlib.h>`, but these name PIL libraries and there are additional PIL libraries
     151. PIL programs can be divided into multiple files (translation units)
     16 1.  One TU can refer to a variable, function, type, in another TU.
     17 1. the variable just needs to be declared somewhere in the TU
     18 1. the function just needs a prototype somewhere in the TU
     19 1. the use of "static" in a variable decl or function def makes it private to that TU (so two can have same name)
     20 1. no need for "extern"
     21 1. at most one of the TUs declaring the variable can have an initializer
     22 1. at most one of the TUs can have a definition for a function
     231. Program order:
     24 1. a program is a sequence of variable, function, and type definitions.
     25 1. the order is totally irrelevant.
     26 1. a variable can be used anywhere it is in scope
     27 1. a function can be called anywhere it is in scope
    2828
    2929== Types
    … …  
    7575Procedure definitions can be nested.   It is an error to call a procedure `f` when `f` is not in scope.  (This is similar to Gnu C.)   In other words, if the call takes place in dyscope d, then the definition of `f` must be in d's static scope, or in the parent of d's static scope, or its parent, etc.
    7676
    77 A procedure definition can be templated:
    78 {{{     
    79        <T1,T2,...> <procedure def>
    80 }}}   
    81 This defines one procedure for each assignment of types to the Ti.
    82 
    8377There is a second way to specify a procedure, using a lambda expression, which is described below.
    8478     
    … …  
    9690}}}
    9791where `expr` is a side-effect-free expression of type `R` and can refer to any variables in scope.
     92
     93=== Misc.
     94
     95Both procedure and logic function definitions can be templated, e.g.,
     96{{{     
     97       <T1,T2> int f($map<T1,T2> f, T1 x) { ... }
     98       <T1,T2> $logic int g($map<T1,T2> f, T1 x) { ... }
     99}}}   
     100This defines one procedure for each assignment of types to the `Ti`.
     101
     102Both kinds of functions can be declared without providing definitions, indicating that the definition can be found in a different translation unit:
     103{{{
     104  int f(int x);
     105  $logic int g(int x);
     106}}}
    98107
    99108=== Lambda expressions
    … …  
    115124The type of this expression is `R(T1, ..., Tn)`.   The resulting value of this is type is a procedure which can be called or assigned to a variable, etc., just like any other procedure value.
    116125
    117 Note that the definition can only use the specified variables.  Evaluating this expression yields a closure, which is a pair consisting of a dyscope and the body of the procedure.   The dyscope has variables `vj`, which are initialized by evaluating the `initj` when the lambda expression is evaluated.  The body of the procedure may read and write to the `vj`.  That dyscope will live as long as the procedure is around.  Hence a function may return a closure and that closure may still be called at any time, anywhere in the program, regardless of whether the original lambda expression is in scope.
     126Note that the definition can only use the specified variables.  Evaluating this expression yields a closure, which is a pair consisting of a dyscope and the body of the procedure.   The dyscope has variables `vj`, which are initialized by evaluating the `initj` when the lambda expression is evaluated.  The body of the procedure may read and write to the `vj`.  That dyscope has no parent and will live as long as the procedure is around.  Hence a function may return a closure and that closure may still be called at any time, anywhere in the program, regardless of whether the original lambda expression is in scope.
     127
     128When a procedure closure is called, a new dyscope is created whose parent dyscope is the dyscope of the closure.  In the new dyscope, the formal parameters are assigned the actual values and procedure is executed in that scope.  When it returns, the new dyscope is removed.
    118129
    119130A lambda expression that specifies a logic function has the form