eoc unphi produces untestable programs

[deemp]

@maxonfjvipon, @yegor256

Related to #2940

Problem

I normalized a PHI file, then converted it to a normalized EO file and tried to run tests from the normalized EO file. However, tests failed.

eoc version

0.19.0

Files

bytes-tests-minimal-initial.phi:

{
  ⟦
    org ↦ ⟦
      eolang ↦ ⟦
        takes-part-of-bytes ↦ ⟦
          φ ↦ Φ.org.eolang.bytes(
            Δ ⤍ 20-1F-EE-B5-90
          ).slice(
            α0 ↦ Φ.org.eolang.int(
              α0 ↦ Φ.org.eolang.bytes(
                Δ ⤍ 00-00-00-00-00-00-00-01
              )
            ),
            α1 ↦ Φ.org.eolang.int(
              α0 ↦ Φ.org.eolang.bytes(
                Δ ⤍ 00-00-00-00-00-00-00-03
              )
            )
          ).eq(
            α0 ↦ Φ.org.eolang.bytes(
              Δ ⤍ 1F-EE-B5
            )
          )
        ⟧,
        λ ⤍ Package
      ⟧,
      λ ⤍ Package
    ⟧
  ⟧
}

bytes-tests-minimal-normalized.phi:

{ ⟦ org ↦ ⟦ eolang ↦ ⟦ takes-part-of-bytes ↦ ⟦ Δ ⤍ 01- ⟧, λ ⤍ Package ⟧, λ ⤍ Package ⟧ ⟧ }

bytes-tests-minimal-normalized.eo:

+package org.eolang
+tests

# This is the default 64+ symbols comment in front of named abstract object.
[] > takes-part-of-bytes
  01-

Run tests

npx eoc --parser=0.38.0 test

Error

EO objects registered in .eoc/eo-foreign.json
Assembling into .eoc
EO program assembled in .eoc
[ERROR] /home/eyjafjallajokull/Desktop/gh/normalizer/try-unphi/output-eo-programs/normalized/min.eo, line 6: The object has attribute without a name, line=6, pos=2
[ERROR] net.sf.saxon.style.XSLMessage@6f767acb: Errors identified:
  /home/eyjafjallajokull/Desktop/gh/normalizer/try-unphi/output-eo-programs/normalized/min.eo, 6: The object has attribute without a name, line=6, pos=2;
[ERROR] #fatalError(): Processing terminated by xsl:message at line 31 in fail-on-errors.xsl; SystemID: file:///org/eolang/parser/fail-on-errors.xsl; Line#: 31; Column#: 34
[ERROR] Processing terminated by xsl:message at line 31 in fail-on-errors.xsl
[ERROR] Failed to execute goal org.eolang:eo-maven-plugin:0.38.0:verify (default-cli) on project eoc: 'org.eolang.maven.VerifyMojo@47406941' execution failed: java.io.UncheckedIOException: java.io.IOException: java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Failed to transform by net.sf.saxon.jaxp.TransformerImpl: Processing terminated by xsl:message at line 31 in fail-on-errors.xsl; SystemID: file:///org/eolang/parser/fail-on-errors.xsl; Line#: 31; Column#: 34 -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
The command "/home/eyjafjallajokull/Desktop/gh/normalizer/node_modules/eolang/mvnw/mvnw eo:verify -Deo.version=0.38.0 -Deo.tag=0.38.0 --quiet -Deo.sourcesDir=/home/eyjafjallajokull/Desktop/gh/normalizer/try-unphi/output-eo-programs/normalized -Deo.targetDir=/home/eyjafjallajokull/Desktop/gh/normalizer/try-unphi/output-eo-programs/normalized/.eoc -Deo.outputDir=/home/eyjafjallajokull/Desktop/gh/normalizer/try-unphi/output-eo-programs/normalized/.eoc/classes -Deo.generatedDir=/home/eyjafjallajokull/Desktop/gh/normalizer/try-unphi/output-eo-programs/normalized/.eoc/generated-sources -Deo.placed=/home/eyjafjallajokull/Desktop/gh/normalizer/try-unphi/output-eo-programs/normalized/.eoc/eo-placed.csv -Deo.placedFormat=csv --batch-mode --color=never --update-snapshots --fail-fast --strict-checksums" exited with #1 code

[maxonfjvipon]

@deemp only org.eolang.bytes object can have Δ attribute in EO

[github-actions]

@deemp thanks for the report, here is a feedback:

Problems

• Clear Bug Title: The title of the bug report is ambiguous and fails to offer a lucid understanding of the issue. An effective bug title ought to be precise, succinct, and accurately depict the problem.
• Expected and Actual Results: The report lacks a distinct definition of the expected result and its deviation from the actual outcome. Sharing this data can aid developers in swiftly grasping the bug's nature and its departure from the anticipated behavior.
• Prioritization or Severity: The report omits any details regarding the bug's severity or its influence on the software's overall operation. This detail is vital for prioritizing bug resolutions.

I would recommend specifying a clear and succinct bug title that accurately represents the issue at hand.

Please fix the bug report in order it to get resolved faster.
Analyzed with gpt-4

[maxonfjvipon]

@deemp I believe this should work in EO

{
  ⟦
    org ↦ ⟦ 
      eolang ↦ ⟦
        takes-part-of-bytes ↦ Ф.org.eolang.bytes(
          Δ ⤍ 01-
        ), 
        λ ⤍ Package
      ⟧, 
      λ ⤍ Package 
    ⟧
  ⟧ 
}

[deemp]

It should be this "Φ", but otherwise it works.

{
  ⟦
    org ↦ ⟦
      eolang ↦ ⟦
        takes-part-of-bytes ↦ Φ.org.eolang.bytes(
          Δ ⤍ 01-
        ),
        λ ⤍ Package
      ⟧,
      λ ⤍ Package
    ⟧
  ⟧
}

I get this EO and can successfully test it.

+package org.eolang
+tests

Q
.org
.eolang
.bytes > takes-part-of-bytes
  01-

[deemp]

@maxonfjvipon, @yegor256, should we wrap data into Ф.org.eolang.bytes on our side?

According to a discussion (link), we should not.

If you think we should, why?

[maxonfjvipon]

@deemp we decided that we will translate such expression takes-part-of-bytes ↦ ⟦ Δ ⤍ 01- ⟧ to this takes-part-of-bytes ↦ Φ.org.eolang.bytes( Δ ⤍ 01- )

[fizruk]

@maxonfjvipon I have one more case:

Original EO test:

+package org.eolang.io
+tests

# This is the default 64+ symbols comment in front of named abstract object.
[] > prints-string-to-console
  Q
  .org
  .eolang
  .io
  .stdout > @
    Q
    .org
    .eolang
    .string:0
      Q
      .org
      .eolang
      .bytes:0
        48-65-6C-6C-6F-20-77-6F-72-6C-64-0A

Original $\varphi$-expression:

{
  ⟦
    org ↦ ⟦
      eolang ↦ ⟦
        io ↦ ⟦
          prints-string-to-console ↦ ⟦
            φ ↦ Φ.org.eolang.io.stdout(
              α0 ↦ Φ.org.eolang.string(
                α0 ↦ Φ.org.eolang.bytes(
                  Δ ⤍ 48-65-6C-6C-6F-20-77-6F-72-6C-64-0A
                )
              )
            )
          ⟧,
          λ ⤍ Package
        ⟧,
        λ ⤍ Package
      ⟧,
      λ ⤍ Package
    ⟧
  ⟧
}

$\varphi$-expression after normalization (experimental, note the bare atom Lorg_eolang_io_stdout):

{⟦
  org ↦ ⟦
    eolang ↦ ⟦
      io ↦ ⟦
        prints-string-to-console ↦ ⟦
          text ↦ Φ.org.eolang.bytes (Δ ⤍ 48-65-6C-6C-6F-20-77-6F-72-6C-64-0A),
          λ ⤍ Lorg_eolang_io_stdout
        ⟧,
        λ ⤍ Package
      ⟧,
      λ ⤍ Package
    ⟧,
    λ ⤍ Package
  ⟧
⟧}

Resulting EO code after unphi:

+package org.eolang.io
+tests

# This is the default 64+ symbols comment in front of named abstract object.
[] > prints-string-to-console /
  Q
  .org
  .eolang
  .bytes > text
    48-65-6C-6C-6F-20-77-6F-72-6C-64-0A

The last one appears to be incorrect and it does not parse successfully as EO program.

@yegor256 FYI: this is similar to the example in the original proposal for the Normalizer, so I imagine, it should work?

[fizruk]

@maxonfjvipon I think simply removing the backslash (/) is not correct, since the atom Lorg_eolang_io_stdout is then completely lost by eo unphi.

[maxonfjvipon]

@fizruk yes, I was wrong. This backslash is generated by "unphier" but one more symbol ? is missed
It's an interesting case because:

1. only atoms have λ ⤍ ... assets
2. it's not expected that atoms have pre-bound attributes. EO grammar does no support it.

[] > atom /? # right atom

[] > atom /? # wrong atom
  5 > attr

[maxonfjvipon]

@fizruk of course if there's an atom with void attribute:

[text] > stdout /bool

(technically) its text attribute will become bound after application.

[] > stdout /bool
  "Hello" > text

But we don't (and can't) see it at the level of EO. So it's prohibit for atom to have bound attributes at the level of EO grammar

[maxonfjvipon]

@fizruk @deemp we made a new release. Please update eoc to 0.21.0 and use it with --parser=0.38.3 and let's know how it's going

[maxonfjvipon]

@fizruk should be fixed in 0.38.4