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.

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

Why do we need an extra dash in 00- ? #3546

Closed
volodya-lombrozo opened this issue Nov 25, 2024 · 18 comments
Closed

Why do we need an extra dash in 00- ? #3546

volodya-lombrozo opened this issue Nov 25, 2024 · 18 comments
Labels

Comments

@volodya-lombrozo
Copy link
Member

volodya-lombrozo commented Nov 25, 2024

From this comment, I can see that if we have a single byte, we should use 00-. It's confusing. Why can't we just use 00? Does this extra dash have some specific meaning, or are we just wasting extra space?

@volodya-lombrozo
Copy link
Member Author

@maxonfjvipon Can you help with this please?

@yegor256
Copy link
Member

yegor256 commented Nov 25, 2024

@volodya-lombrozo without the dash, we won't be able to differentiate 42 (integer, 8 bytes) from 42 (array of one byte)

@volodya-lombrozo
Copy link
Member Author

@yegor256 Sorry, I can't digest it. I'm talking about bytes object:

 <o base="org.eolang.bytes">00-00-00-00-00-00-00-1A</o>

Do you have an ability to save integers to bytes object?

 <o base="org.eolang.bytes">42</o> <!-- (integer, 8 bytes) -->

Looks like a crutch to me.

@yegor256
Copy link
Member

@volodya-lombrozo I believe, it's some technical limitation in our XSL processor. @maxonfjvipon am I right?

@maxonfjvipon
Copy link
Member

@volodya-lombrozo it's just a bit convenient that bytes XMIR looks the same as they are in original EO and there's no need to make some extra unnecessary manipulations. Also when we print XMIR to EO, at the certain point of time XMIR may contain strings and numbers after unhexing. And here there's no way we can differentiate one byte from integer number if byte does not end with dash

@volodya-lombrozo
Copy link
Member Author

@maxonfjvipon I understand, that it is done only for development convenience:

it's just a bit convenient that bytes XMIR looks the same as they are in original EO and there's no need to make some extra unnecessary manipulations.

In this case it makes development easy (only for you, btw), but confusing for other people who works with XMIR. In reality, we spend unnecessary space and confuse readers.

As for this:

And here there's no way we can differentiate one byte from integer number if byte does not end with dash

Actually you have org.eolang.number and org.eolang.bytes markers, as I understand. Even if you didn't have them, it still would look like a crutch rather than a proper solution.

@volodya-lombrozo
Copy link
Member Author

@yegor256 @maxonfjvipon Can we just remove it?

@maxonfjvipon
Copy link
Member

maxonfjvipon commented Nov 25, 2024

@volodya-lombrozo I think we can't, at least for now. It really simplifies development because you don't need to:

  1. convert dashes to spaces on EO parsing
  2. convert spaces to dashes on printing XMIR to EO
  3. convert spaces to dashes on printing XMIR to PHI
  4. convert dashes to spaces on PHI parsing

All you need is either correct EO/PHI grammar if you start from EO/PHI, or handle dashes if you start from XMIR

@maxonfjvipon
Copy link
Member

@volodya-lombrozo

In this case it makes development easy (only for you, btw), but confusing for other people who works with XMIR. In reality, we spend unnecessary space and confuse readers.

I believe the convenience of development main eo-maven-plugin is top priority

@volodya-lombrozo
Copy link
Member Author

@volodya-lombrozo I think we can't, at least for now. It really simplifies development because you don't need to:

  1. convert dashes to spaces on EO parsing
  2. convert spaces to dashes on printing XMIR to EO
  3. convert spaces to dashes on printing XMIR to PHI
  4. convert dashes to spaces on PHI parsing

All you need is either correct EO/PHI grammar if you start from EO/PHI, or handle dashes if you start from XMIR

@maxonfjvipon I don't against dashes in bytes. I agains the last dash in 00-. I believe we need to remove it. I'm not talking about spaces here.

@yegor256
Copy link
Member

@volodya-lombrozo the tailing dash is part of the syntax in EO (and phi-calculus). We technically can remove it in XMIR, but this will make XMIR a special case. What for?

@volodya-lombrozo
Copy link
Member Author

@yegor256 Why the last dash is a part of syntax? What for?

@maxonfjvipon
Copy link
Member

@volodya-lombrozo

without the dash, we won't be able to differentiate 42 (integer, 8 bytes) from 42 (array of one byte)

@maxonfjvipon
Copy link
Member

@volodya-lombrozo consider the next EO code:

[] > object
  42 > num
  42 > byte-no-dash

How to write a one byte 42 so it differ from num?

@volodya-lombrozo
Copy link
Member Author

@maxonfjvipon In EO frontend you might use anything you want:

[] > object
  42 > num
  byte > byte-no-dash
    42

or

[] > object
  42 > num
  0x101010 > byte-no-dash

Btw, do you think it's understandable, that 42 are bytes here?

[] > object
  42 > num
  42- > byte-no-dash

To be honest, It doesn't matter at all, actually. It is a frontend. Why do you carry all this to XMIR? Moreover, we can remove all the types and use only bytes in XMIR, isn't it? I don't understand why we might need this type information in XMIR and further in phi, especially if we have markers as org.eolang.number and org.eolang.bytes.

@volodya-lombrozo
Copy link
Member Author

@volodya-lombrozo

In this case it makes development easy (only for you, btw), but confusing for other people who works with XMIR. In reality, we spend unnecessary space and confuse readers.

I believe the convenience of development main eo-maven-plugin is top priority

@yegor256 btw, do you agree with this?

@yegor256
Copy link
Member

@volodya-lombrozo we won't change the format of bytes/numbers in EO and phi. It's not an option anymore. Then, the question is whether we should have a different format of bytes in XMIR or use the one that we have in EO and phi? I say, we use one format everywhere. I understand that we can use another format (for a number of reasons), but it's better to stay with one format everywhere. My subjective, opinionated, and final decision :)

@0crat
Copy link

0crat commented Nov 27, 2024

@volodya-lombrozo Hello! Thank you for submitting this ticket. Unfortunately, it was not accepted by the team. As per our policy, this results in a deduction of 16 points. While this outcome is disappointing, please don't be discouraged. Your efforts in reporting issues are valuable for improving our project's quality. Moving forward, we encourage you to be more thorough in your submissions. Remember, bug reports are always welcome when properly documented. Keep up the good work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants