feat(#3343): Allow Partial XMIR Printing

[volodya-lombrozo]

In this PR I added Xmir.Simplified that can print partial XMIR documents to EO.

Closes: #3343.
History:

• feat(How to print a small part of XMIR to EO? #3343): add Simplified printer to XMIR
• feat(How to print a small part of XMIR to EO? #3343): fix all qulice suggestions

---

PR-Codex overview

The PR introduces a new Simplified class in Xmir for partial XMIR printing. It includes tests and XSLT transformations for simplified EO printing.

Detailed summary

• Added Simplified class for partial XMIR printing in Xmir
• Implemented tests for Simplified and Default classes
• Added XSLT transformation for simplified EO printing

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[volodya-lombrozo]

@maxonfjvipon Could you review that changes, please?

[volodya-lombrozo]

@yegor256 Could you take a look, please?

[volodya-lombrozo]

@yegor256 friendly reminder

[volodya-lombrozo]

@yegor256 friendly reminder

[yegor256]

@volodya-lombrozo the intent is not clear. Would be great to add some explanation to the Javadoc.

[volodya-lombrozo]

@yegor256 Could you take a look one more time, please?

[volodya-lombrozo]

@yegor256 reminder

[yegor256]

@volodya-lombrozo even though the idea looks simple and straight-forward, I'm not convinced. If you use only a single <o> object, you loose meta information (like +alias), which is important for a EO program. If we let users do this, we lose the ability to check the correctness of their EO programs. This looks like a temporary hack, but not a "standard" approach, which we should ship together with other EO-related tools, I believe.

[volodya-lombrozo]

@yegor256 I constantly face this problem when I need to print a single eo object instead of printing the entire eo program. (It is the third time already.) For me, it's a big deal and a constant pain in the... neck. Maybe we can create another interface or a separate implementation for printing? But in this case, it will be "object printing," not "eo printing." The difference lies in a separate interface and a completely different purpose.

[volodya-lombrozo]

@yegor256 It's rather important changes that blocks other issues

[volodya-lombrozo]

@yegor256 reminder

[yegor256]

@volodya-lombrozo why can't you use a normal printing? Because you want to minimize the size of the XMIR, getting rid of the header part?

[volodya-lombrozo]

@yegor256 yes. When you need to print ~100 different objects and test them, the task of "wrapping" each case with boilerplate code becomes tedious.

[volodya-lombrozo]

@yegor256 Reminder

[yegor256]

@volodya-lombrozo the problem is this: if we allow printing just a part of XMIR, we loose some meta information and, what is more important, loose the ability to provide such information in the future. It's similar to allowing Java compiler to compile just a method of a class, not the entire class. Even though it's technically possible (in some cases), such a partial compiler would be a very strange feature, don't you think?

[volodya-lombrozo]

@yegor256 Of course, regarding compilers, I agree — It would definitely be a strange feature indeed. Is phi-printing the compilation process?

Wiki:

The name "compiler" is primarily used for programs that translate source code from a high-level programming language to a low-level programming language

I thought it is the representation of the same xmir on the same level. Am I right? At least the "printing" suggests that it is just a rewriting. In other words, we just have a different representation, and we don't compile anything, do we? So, if we have this representation, why can't we have another one that would only help?

I consider this feature as an alternative "short view" on some parts of xmir. Of course this "short" representation doesn't have to be used further in any compilation pipelines. So, it's exactly why I suggested to use different interface for this class:

Maybe we can create another interface or a separate implementation for printing? But in this case, it will be "object printing," not "eo printing." The difference lies in a separate interface and a completely different purpose.

As for this:

if we allow printing just a part of XMIR, we loose some meta information and, what is more important, loose the ability to provide such information in the future.

Why do we need this information in the future? The only purpose for this partial printing is testing, no more.

[yegor256]

@volodya-lombrozo the printing may expect the entire XMIR document to be available in order to print EO. If we allow printing of just a part of the XMIR, we introduce some other assumptions, which may not be in line with the previous one. Thus, we will have to maintain them both, not always understanding what to do if they conflict. For example, this pseudo XMIR:

<xmir>
  <meta>abc</meta>
  <objects>
    <o id=1/>
  </objects>
</xmir>

It prints to (using both the info from the <meta> and the <o> elements):

OBJ 1/abc

You introduce just-one-object printer, which will produce (for example):

OBJ 1/foo

Here, you will have to replace abc with foo, because you don't have <meta> available.

Now, we have two EO outputs for the same input. How they correlate? Hard to say. How to maintain this correlation? Hard to say.

[volodya-lombrozo]

@yegor256 Sorry, maybe I don't clearly understand you. If you're asking about the correlation between 'object' and 'file' printing (how to update both of these xslt transformations), then it's a separate question, but I'm sure we can solve this easily in the code.

As for this:

we introduce some other assumptions, which may not be in line with the previous ones
I didn't clearly understand which assumptions you mean.

<o id=1/>

will give me

OBJ 1

Why this?

OBJ 1/foo

Moreover, it's a problem of 'object' printing: how to retrieve some missing elements. As I've already said many times, 'object' printing is suitable only for testing, so we can't rely on it in pipelines or make any assumptions based on it.

[yegor256]

@volodya-lombrozo the <o> element is not the only place where the information about a particular object is stored. Some information may be in other places of the XMIR document. This is what I mean.

[volodya-lombrozo]

@volodya-lombrozo the <o> element is not the only place where the information about a particular object is stored. Some information may be in other places of the XMIR document. This is what I mean.

@yegor256 Yes, I understood that. When we print only a single object without a header - we use only the information we have, of course. I believe it's fine in the context of testing.

[yegor256]

@volodya-lombrozo yes, for testing it's fine, in your own project, where you understand the context and the risks. But shipping this functionality to everybody would be a mistake, I believe.

[volodya-lombrozo]

@volodya-lombrozo If I move this changes to my own project:

1. I won't be able to use it across several projects. Even for now I need to use this functionality in two separate repositories.
2. It will be hard to keep consistency between "program" printing and "object" printing - when they are located at one place - it's much easier to "inherit" some functionality. For example "program" printing might use "object" printing script and vice versa.

[yegor256]

@volodya-lombrozo why can't you print this:

<xmir>
<objects>
<o base=".plus">
  <o base="int" data="bytes">00 00 00 00 00 00 00 01</o>
  <o base="int" data="bytes">00 00 00 00 00 00 00 02</o>
</o>
</objects>
</xmir>

instead of:

<o base=".plus">
  <o base="int" data="bytes">00 00 00 00 00 00 00 01</o>
  <o base="int" data="bytes">00 00 00 00 00 00 00 02</o>
</o>

It's a question of these "extra" four lines?

[volodya-lombrozo]

@yegor256 Let's imagine I have 100 java objects that can create only some parts of the entire program. For example Plus.java can create the following xmir.

<o base=".plus">
  <o base="int" data="bytes">00 00 00 00 00 00 00 01</o>
  <o base="int" data="bytes">00 00 00 00 00 00 00 02</o>
</o>

It doesn't know anything about the entire xmir structure. Just this. So, if I need to test this class, I need to "wrap" it with extra lines. Also I have to do it for all the rest 99 classes. It's tedious. Of course, I can write wrappers, matchers and so on, but I will have the same problems which I have already mentioned.

[yegor256]

@volodya-lombrozo yes, you need to wrap them, but you don't do this manually, do you? You create unit tests, which wrap them and then print. Or I misunderstand the scenario?

[volodya-lombrozo]

@yegor256 Sometimes I need to do it manually, like here:

new Xmir.Default(
    new XMLDocument(
        new Xembler(
            new Directives().add("program").add("objects")
            .append(
                new DecompilerMachine(Collections.singletonMap("output", output))
                .decompile(pack.instructions())
            )
            .up().up()
        ).xmlQuietly()
    )
).toEO()

[volodya-lombrozo]

@yegor256 Reminder

[volodya-lombrozo]

@yegor256 Friendly reminder

[volodya-lombrozo]

Since there are many concerns about this functionality, I close this PR