Should libtextstyle have "style domains"? [Was: Re: Libtextstyle in Jitter and Poke: sub-package mode and CSS installation]

[Luca Saiu]

Hello.

On 2019-10-30 at 19:44 +0100, Jose E. Marchesi wrote:

> Ok, let's settle on some terminology:
> - What [Luca calls] "VM code" is what [José calls] "PVM disassembly"
> - What [Luca calls] "disassembly" is what [José calls] "native disassembly"
>
> In PVM disassembly, I am using custom printers for several things,
> particularly PVM values, which can be arrays, structs, closures and the
> like.  These values use the same classes than the ones used at the REPL
> to print values.

Agreed, and that is a typical case: every program using a Jittery VM
will have its own high-level entities, usually unrelated to Jitter.  And
what is important here at the boundary between Jitter and an application
using it is essentially the shape of data: it will be Poke data for the
Poke VM, Lisp data for a Lisp VM, ML data for an ML VM.

The Jittery side needs to handle a subset of the high-level entities of
the application, which the application knows how to handle already; plus
its own, Jittery entities.

> For the native disassembly, there yeah I agree, I don't care about
> styling that :)

Native-code disassembly is apparently easier because it does not cross
this boundary: it is all on one side.  But see below.

> Still, I would like to get my poke_ostream thru an argument in the
> custom printer, instead of having to rely on a global variable.

Absolutely.  Having global state here feels wrong, for a stream which is
potentially based on a different underlying descriptor every time; right
now you are always printing to the standard output, but that could
change.

>     Of course in the good printer API the FILE * argument will be replaced
>     by something more abstract -- but not a libtextstyle stream, because
>     libtextstyle might be unavailable or disabled.  It will be something
>     abstract.
>     
>     And still, even if the printer received a libtextstyle stream as a
>     parameter, that would not be helpful to you: my output style is for
>     printing Jittery VM routines, while yours is for printing Poke's data.
>     So they would be two different, incompatible streams.
>     The literal printer should only see yours.
>
> Just give me a void* pointer in the custom printers, and I will be
> happy, I think... :)

Here I disagree.

The Jitter library could use an initial stream provided by you, and them
pass it back to your literal printer at every call; but it would still
be a complicated thing that you would have to manage by hand, with your
libtextstyle wrapper.  And I, on the Jitter side, would have to do the
same with a stream of the same nature, having the same underlying
descriptor, but a different style: it would *not* be the same
libtextstyle stream.  Everything would need to be flushed at the time of
the style switch -- in an automatic, invisible way on the Jitter side,
but manually on the printer side if Jitter does not know about your
application-specific stream abstraction.

This above is one objection, but I believe not the important one.


Looking at Poke's code and then at the libtextstyle documentation I
noticed how style_file_prepare is not reentrant: it sets defaults *for
the application*.  I believe that to be the central issue.

Gettext handles the problem correctly, I believe, by providing for a
different text domain for each library, which will be different from the
text domain of the applications using them: libraries and programs
linked to them will have different strings with different translations.
In the same way I suppose that a library should have its own "style
domain", distinct from the "style domain" of a program linking to it.

(Notice that we may even have "classical" reentrancy problems, related
to threads: it is perfectly conceivable that multiple threads want to
print at the same time, using different styles; that would work, I
believe, as long as every stream is initialized correctly with its own
default and its own parameters.)

I am not even sure whether Jitter is a particularly perverse case; the
only unusual feature, in this respect, is that different languages, with
different styles, are nested within one another.  For the rest the
interoperability problem with libtextstyle does not feel different from
the one with gettext.

Does this make sense, Bruno and José?  I may well be overlooking some
easier solution.

Thanks for your insights,

-- 
Luca Saiu
* My personal web site:  http://ageinghacker.net
* GNU epsilon:           http://www.gnu.org/software/epsilon
* Jitter:                http://ageinghacker.net/projects/jitter

I support everyone's freedom of mocking any opinion or belief, no
matter how deeply held, with open disrespect and the same unrelented
enthusiasm of a toddler who has just learned the word "poo".

signature.asc
Description: PGP signature