607 update eo to 0.49.1

[deemp]

• Closes Update eo to 0.49.1 #607

[deemp]

@yegor256, for some reason, the pipeline fails

https://github.com/objectionary/eo-phi-normalizer/actions/runs/12360133696/job/34494382837#step:12:288

Environment:

eolang version: 0.28.0

eo submodule version: 0.49.1

Commands:

cat org/eolang/bool-tests.eo

+package org.eolang
+tests

# No comments.
[] > compares-two-bools
  Q
  .org
  .eolang
  .true
  .eq > @
    Q
    .org
    .eolang
    .true:0

# No comments.
[] > compares-two-different-types
  Q
  .org
  .eolang
  .true
  .eq
    42:0
  .not > @

# No comments.
[] > compares-bool-to-bytes
  Q
  .org
  .eolang
  .true
  .eq
    01-:0
  .and > @
    Q
    .org
    .eolang
    .false
    .eq:0
      00-:0

# No comments.
[] > compares-bool-to-string
  Q
  .org
  .eolang
  .true
  .eq
    "\u0001":0
  .and > @
    Q
    .org
    .eolang
    .false
    .eq:0
      "\u0000":0

# No comments.
[] > compares-bool-to-bytes-reverse
  01-
  .as-bytes
  .eq
    Q
    .org
    .eolang
    .true:0
  .and > @
    00-
    .as-bytes
    .eq:0
      Q
      .org
      .eolang
      .false:0

eoc --parser 0.49.1 --home-tag 0.49.1 test

EO objects registered in .eoc/eo-foreign.json
EO program assembled in .eoc
[ERROR] In 61 XMIR files, we found 168 warnings
[ERROR] Failed to execute goal org.eolang:eo-maven-plugin:0.49.1:lint (default-cli) on project eoc: 'LintMojo' execution failed: java.lang.IllegalStateException: In 61 XMIR files, we found 168 warnings -> [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:lint -Deo.version=0.49.1 -Deo.tag=0.49.1 --quiet -Deo.sourcesDir=/home/eyjafjallajokull/Desktop/gh/normalizer/tmp/upgrade -Deo.targetDir=/home/eyjafjallajokull/Desktop/gh/normalizer/tmp/upgrade/.eoc -Deo.outputDir=/home/eyjafjallajokull/Desktop/gh/normalizer/tmp/upgrade/.eoc/classes -Deo.generatedDir=/home/eyjafjallajokull/Desktop/gh/normalizer/tmp/upgrade/.eoc/generated-sources -Deo.placed=/home/eyjafjallajokull/Desktop/gh/normalizer/tmp/upgrade/.eoc/eo-placed.csv -Deo.placedFormat=csv -Deo.failOnWarning=true --batch-mode --color=never --update-snapshots --fail-fast --strict-checksums" exited with #1 code

[yegor256]

@deemp use --easy option for eoc

[deemp]

@fizruk, the pipeline fails because the syntax sugar as mentioned in #603 hasn't yet been implemented.

https://github.com/objectionary/eo-phi-normalizer/actions/runs/12367097278/job/34514834809?pr=617#step:12:514

UPD: I'm trying to implement this sugar.

[deemp]

@yegor256, should Φ̇.true.eq(Φ̇.true) be desugared as Φ.org.eolang.true.eq(α0 ↦ Φ.org.eolang.true)?

[yegor256]

@deemp yes, exactly

[deemp]

• I've implemented Work with desugared objects where appropriate #639

@fizruk, dataization of the celsius example produces bytes for some reason.

cat tmp/foo.phi

{⟦
    c ↦ Φ.org.eolang.number(
        as-bytes ↦ Φ̇.bytes(Δ ⤍ 40-39-00-00-00-00-00-00)
    ), // 25.0
    φ ↦ ξ.c.times(x ↦ ⟦ Δ ⤍ 3F-FC-CC-CC-CC-CC-CC-CD ⟧)  // 1.8
            .plus(x ↦ ⟦ Δ ⤍ 40-40-00-00-00-00-00-00 ⟧), // 32.0
⟧}

eo-phi-normalizer dataize --recursive -d eo-phi-normalizer/data/0.41.2/org/eolang/number.phi -d eo-phi-normalizer/data/0.41.2/org/eolang/bytes.phi tmp/foo.phi

40-53-40-00-00-00-00-00

[deemp]

@fizruk, @yegor256, I tried to implement the syntactic sugar for such expressions

⟦ number(as-bytes) ↦ ⟦ ... ⟧ ⟧

but then got shift-reduce conflicts.

I had the following definitions in the Syntax.cf.

Label.      Attribute ::= LabelId ;
...
AttrSugar.  Attribute ::= LabelId "(" [LabelId] ")";

I think when parser encounters number it doesn't know whether it should reduce it to an Attribute or shift and put ( on the parser stack.

@yegor256, can you temporarily support a special syntax for such sugar?

Example:

⟦ ~number(as-bytes) ↦ ⟦ ... ⟧ ⟧

Then, I can avoid conflicts by using:

AttrSugar.  Attribute ::= "~" LabelId "(" [LabelId] ")";

[yegor256]

@deemp I'm not sure I understand what's the source of the shift-reduce conflict:

I think when parser encounters number it doesn't know whether it should reduce it to an Attribute or shift and put "(" on the parser stack.

This text is not clear for me. Can you elaborate a bit further?

[yegor256]

@deemp BTW, this EBNF we use to parse phi expressions, maybe will help: https://camo.githubusercontent.com/77e1ebd2a73dbe1889a630de643778e76b81b406bf1bdae75be8f833ac67f791/68747470733a2f2f7777772e656f6c616e672e6f72672f65626e662f5068692e706e67

[deemp]

This text is not clear for me. Can you elaborate a bit further?

@yegor256, you use ANTLR which generates top-down (LL) parsers. We use BNFC which generates bottom-up (LR) parsers. We use BNFC for convenience.

A GLR parser could try multiple options.

1. Parse number from ⟦ number(as-bytes) ↦ ⟦ ... ⟧ ⟧ as a LabelId (reduce).
2. Parse number, then parse (as-bytes) from ⟦ number(as-bytes) ↦ ⟦ ... ⟧ ⟧ (shift), then combine them into AttrSugar.

However, currently, BNFC-generated parser (using the --glr flag) don't typecheck.

Hence, we have to use a LR parser which can't try multiple options and thus gets a shift/reduce conflict.

@fizruk, please correct me if I'm wrong.

I see the following options:

• (Simple) (Temporarily) Make the $\varphi$-calculus syntax unambiguous for a LR parser (see my suggestion about the syntax 607 update eo to 0.49.1 #617 (comment)).
• (Hard) Use happy and alex to generate parsers more flexibly and probably get a working GLR parser.
• (Hard) Rewrite the parser using a parser combinator library.