Ssl takeaways
layout: post
title: “S/SL Takeaways”
—
S/SL
S/SL means Syntax Semantic Language. (See References).
S/SL is described as a minimal syntax for parsing.
Parsing has been subsumed by Parser Combinators and PEG.
Yet, S/SL still contains a hidden gem.
Takeaways
- link functions1.
Link Functions
Link functions are unimplemented functions.
Link functions are not implemented in S/SL, but are implemented in the base language (I call this a Toolbox Language).
Dataless Language
In S/SL, there is no data.
There are only handles2 to data.
One can declare the existence of data and can move it around, but one cannot specify the implementation of the data in S/SL.
Typeless Language
S/SL has no built-in types3.
In S/SL, you can declare handles2 to types, but you cannot specify how the types are implemented.
Inputs
Inputs are declared as handles.
Outputs
Outputs are declared as handles.
Errors
Errors are declared as handles.
Restricted API To/From Link Functions
S/SL functions can take 0 or 1 parameters (only).
S/SL functions can return 0 or 1 return values.
Datalessness In Other PLs
It is possible to create data handles in other PLs, but most PLs tend to encourage description of the implementations.
For example, int, float, array, list, etc. are examples of data implementations.
S/SL enforces non-implementation of details
Typelessness in Other PLs
It is possible to create hierarchies of abstract types in other PLs, but this usually tends (psychologically) towards accidental complexity.
S/SL enforces the use of type handles.
Input in Other PLs
S/SL’s simple handles enforce simple description of inputs.
Output in Other PLs
S/SL’s simple handles enforce simple description of outputs.
Error in Other PLs
S/SL’s simple handles enforce simple description of errors.
Many current PLs implement error handling using throw, resulting in backtraces of uninteresting details (e.g. essentially the same as core dumps).
Error handles could be used to invoke throw, or, better, could be used to provide useful debugging error messages.
Encouraging Behavior vs Possible Behavior
There seems to be a fine line between PLs that encourage certain paradigms vs. making those behaviors possible.
For example, it is possible to write CPS in assembly code, but few programmers bother to do so.
Lifting concepts to make them visible, vs. eliding other concepts, is an important aspect of PL design.
S/SL’s use of handles makes the Architectural concepts of a progam visible, while eliding implementation.