Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

607 update eo to 0.49.1 #617

Open
wants to merge 17 commits into
base: develop
Choose a base branch
from
Open

607 update eo to 0.49.1 #617

wants to merge 17 commits into from
+7,849 −461

Conversation

deemp
Copy link
Member

@deemp deemp commented Dec 6, 2024

@deemp deemp linked an issue Dec 6, 2024 that may be closed by this pull request
Update eo to 0.49.1 #607
Open
2 tasks
@deemp deemp changed the base branch from master to develop December 16, 2024 19:25
@deemp deemp changed the title 607 update eo to 0.46.0 607 update eo to 0.49.1 Dec 16, 2024
@deemp
Copy link
Member Author

deemp commented Dec 16, 2024 •
edited
Loading

@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
Copy link
Member

@deemp use --easy option for eoc

@deemp
Copy link
Member Author

deemp commented Dec 17, 2024 •
edited
Loading

@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
Copy link
Member Author

deemp commented Dec 17, 2024

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

image

@yegor256
Copy link
Member

@deemp yes, exactly

@deemp
Copy link
Member Author

deemp commented Dec 17, 2024 •
edited
Loading

@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
Copy link
Member Author

deemp commented Dec 19, 2024 •
edited
Loading

@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
Copy link
Member

@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
Copy link
Member

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

@deemp
Copy link
Member Author

deemp commented Dec 20, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Update eo to 0.49.1
2 participants
@deemp @yegor256