Here's the semantic of ENLIST:

1.  ENLIST-at-the-start:

ENLIST at the start of a line denotes that the line is to be
considered to be indented at that location, regardless of where it is
located.  It has no other effect, but acts as an "invisible" symbol.
As a corollary, only the first ever ENLIST on the line is invisible;
succeeding ENLIST's (even ones directly after an ENLIST-at-the-start)
have the ENLIST-inline meaning below.

This is different from GROUP/SPLIT, where multiple
GROUP/SPLIT-at-the-start is the same as one (and zero, for that
matter, except when it's the only item on the line).

Otherwise, ENLIST-at-the-start is the same as SPLIT-at-the-start (it's
an invisible symbol).

2.  ENLIST-inline:

When found inline, ENLIST detects its column location. It then acts as
if ithere were an EOL followed by an indentation to its column
location.

Specifically, to determine the indentation text to insert:

2.1.  Copy the current line's indentation (tabs, spaces, and !) directly.
2.2.  Any non-whitespace character on the current line after the
line's indentation, and before the ":" being considered, is replaced
with a space.

CAVEAT:  Because a "character" may vary between different encodings,
and because different Lisplike's have different capabilities regarding
reading text in different encodings, ONLY ASCII CHARACTERS ARE
CONSIDERED.  If 2.2 above finds a character that is not in the ASCII
domain (0->126) then it throws an error.

This caveat should help in the worst case: when the implementation
lives in a character=byte world, but the programmer is exploiting this
and using the system's native encoding when writing strings (so that
string text and even #| ... |# comments can have encoded non-ASCII
characters that the implementation will pass verbatim to the system).
Except in the case where the encoding uses 0x1B to introduce non-ASCII
characters (IIRC there's an encoding which uses that).

Programmers are thus restricted in that non-ASCII characters cannot be
used before an ENLIST on the same line.  This allows an octet stream
to be read in by different implementations of this spec in exactly the
same way, as long as the encoding used by the writer of the octet
stream is ASCII-compatible.

3.  ENLIST-at-end:

ENLIST-at-end has no semantic defined.  If an ENLIST is at the end of
a line, it is considered either an ENLIST-at-the-start (if it is the
only non-indent non-whitespace on the line) or ENLIST-inline (if there
is text before it).

--

So, transformations:

:
  :
    x

==>

\\
  \\
    x

--


let : : x $ foo bar
    meow x

==>

let : : x $ foo bar
    ^ copy "let ", replace every non-whitespace with space: "    "
    meow x

==>

let
    : : x $ foo bar
    meow x

==>

let
    :
      : x $ foo bar
    meow x

==>

let
    \\
      x $ foo bar ; initial : can be removed here
    meow x

--

define : foo bar
       meow bar

==>

define
       : foo bar
       meow bar

==>

define
       foo bar
       meow bar

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss

Reply via email to