Why do we need an extra dash in `00-` ?

[volodya-lombrozo]

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]

@maxonfjvipon Can you help with this please?

[yegor256]

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

[volodya-lombrozo]

@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]

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

[maxonfjvipon]

@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]

@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]

@yegor256 @maxonfjvipon Can we just remove it?

[maxonfjvipon]

@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]

@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]

@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]

@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]

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

[maxonfjvipon]

@volodya-lombrozo

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

[maxonfjvipon]

@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]

@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]

@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]

@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]

@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!