Re: Arguments before or after command?

[Jeff Kingston]

To answer two emails from Cedric Sodhi:

> What doesn't quite seem to fit in with Lout being a clean, consistent
> language is how arguments are passed to @Commands . By which logic do
> commands take arguments { Before } @TheCommand or @TheCommand { And
then
> the Argument } or even
>  
> @TheCommand { And then } { multiple } { Arguments } ?
> 
> Sadly, this reminds me a bit of the problems I had with Groff and
> especially LaTeX, where sometimes, there appears to be no rule for how
> commands are called. Could you shed a bit of light onto that? For
> example, why are not all commands constructed according to one syntax
> where @TheCommand {Is followed by one object of {possibly subgrouped}
> arguments} ?

These choices are offered to make various syntaxes possible.  There is
no rule, but there are conventions.  For example, when you write

   x sup 2

you are using left and right parameters; when you write

   @Section
       @Title { Another section }
       @Tag { another }
   @Begin
      ...
   @End @Section

you are using named parameters for the optional things, and a body
parameter for the content of the section.  I consider both examples
to be convenient and intuitive.  The example above of @TheCommand
is legal Lout but it does not pass three parameters to @TheCommand.

> Further, it appears there appears to be a distinction as to "named
> arguments", which appear to be those in a syntax like
> 
> @ACommand @ANamedArgument { ValueOfArgument }
> 
> Which raises the question how to prevent clashes between the names of
> "named arguments" and normal commands (for they same to share one
> namespace). This seems to defy the principle of (named) arguments
living
> in the scope of the function, rather than the embedding scope (to
allow
> defining functions regardless of the environment in which those are
> called).

They share a namespace at the point after @ACommand (or after a named
parameter after @ACommand) but not elsewhere.  This gives rise to a
syntactic (but not semantic) ambiguity at those points.  In the example
you give, @ANamedArgument is considered to invoke a named parameter if
a symbol immediately precedes it (@ACommand in this case), and that
symbol has a named parameter called @ANamedArgument, and not to invoke
a named parameter if not.

Thus, there is no violation of the principle you mention, of functions
being definable independently of the environment.  However it does
mean that named parameters can shadow other symbols at a limited
number of points.
 
> Even further, why do we sometimes have @Something ... @EndSomething
> (e.g. List) and sometimes @Something @Begin ... @End @Something
> (e.g. Section)?

Because, owing to fundamental deficiencies in the design of Lout, you
can't make a sequence of things by invoking a single symbol.  Rather,
you need to invoke two (e.g. @List and @EndList).  On the other hand,
you can make most things by invoking a single symbol (e.g. @Section).

> And even further, why do certain commands require their arguments to
be
> enclosed in braces? Naively, one would think that xyz and { xyz } are
> the same thing (where in the latter the braces are redundant}, but
many
> arguments fail if their (one and only) arguments are not enclosed in
> braces, for example
> 
> @SysInclude math
> 
> fails.

I'm not sure why I required braces following @SysInclude, it was a
long time ago and I can't think of any particular reason now.  There
are more telling examples of this, however:  the braces following
named parameters, and the braces that must enclose body parameters
but not right parameters.  These are required because without them
it is not clear how the various objects are to be grouped together,
which is a problem when you are opening and closing scopes, as you
are with named parameters and body parameters but not with left and
right parameters.

Those interested in these issues might like to contribute to the
syntax of Lout's successor, Nonpareil, or rather the "Nonpareil text
format" in which documents are to be expressed.  Lists will be
definable using a single symbol in Nonpareil, and I've already
decided that opening scopes in actual parameters is not a good idea,
despite having some conveniences.  So most of the inconsistencies
are doomed to destruction, but I can't see anything better than

   @ACommand @ANamedArgument { ValueOfArgument }

for optional parameters, despite its syntactic (not semantic) ambiguity.
If someone can improve on this, while giving users something concise
and intuitive, that would be a big positive step.  I'm trying to limit
myself to three special characters, "\", "{", and "}", with "\" being
what Nonpareil will use instead of "@".

Jeff