Re: Punctuation spacing

[Ludovic Courtès]

Hi,

address@hidden (Jeff Kingston) writes:

>> BTW, I couldn't find the explanation for the special-meaning `//' that
>> must follow address@hidden', address@hidden', etc.  Is it documented 
>> somewhere?
>
> In the Expert's Guide under concatenation.

Hmm, I would have thought that this initial `//' had a special meaning,
i.e., different from regular concatenation.  I'll look at it into more
details...

> As you say, (2) is not achievable, but (3) and (4) have a problem too.
> Let's suppose that somehow, by (3) or (4) or otherwise, we have been
> able to explain to Lout that in certain languages, certain punctuation
> characters have to trigger certain modifications, like extra space.
> We still aren't out of the woods, because we then have the problem
> of making sure that the right language is in force at every point.
> Consider the case where some text contains an equation which itself
> contains some text.  We would need to switch to language "equation"
> as we enter the equation, to turn off the modifications, and switch
> back to whatever language we were in before as we enter the included
> text.  But by that time we have forgotten what that prior language was.

I don't see how this is different from address@hidden', address@hidden', 
address@hidden',
etc.:

  Helvetica @Font {
    Courier @Font {
      Times @Font {
        Some text.
      }
    }
  }

This is similar in spirit to what Common Lisp and Scheme refer to as
"dynamic variables", "fluids" or "parameter objects" [0].  In Lout,
these things are implemented as part of the style of an object which is
itself inherited from the enclosing object.  Wouldn't it be possible to
treat punctuation spacing similarly?

The text-enclosing equation issue you mention is indeed trickier.  There
could be a special setting that turns off punctuation spacing, for
instance `none @PunctuationSpacing { ... }'.  But then, as you said,
text appearing within equation would inherit this property, which we
don't want (ideally).

On the other hand, do people really insert text (i.e., sentences) within
address@hidden'?  I would guess that is not a common situation and that 
requiring
the user to explicitly invoke address@hidden' to deal with such
situations would be reasonable requirement.  In any case, note that the
`none @PunctuationSpacing' setting would just make Lout behave as it
does now.

Are there other similar situations where this would be a problem?

> I would go for your suggestion (1).  At places where the definitions
> are not wanted, people will have to enclose the affected punctuation
> characters in double quotes.  When the right solution (explained in my
> previous mail) is beyond Lout's limits, you have to compromise.

You said:

  [I]n an ideal system you would take a paragraph of literal text and
  apply a language-specific formatting algorithm to it.  This way you
  don't need a whole new description language, just a general-purpose
  programming language.

Well, the general-purpose language that is used to do this in Lout is
C.  Of course, it would be nicer if it were written in (an extended
version of) Lout as well.  But given the current situation, adding a
special primitive (thus implemented in C) does not seem so distant from
the "right solution".  ;-)

Thanks for your help,
Ludovic.


[0] For instance: http://srfi.schemers.org/srfi-39/srfi-39.html