double objects implementation

[maxonfjvipon]

Is (or will be) there a way we can try to implement object in eo before java?

Example: we have object float.plus that is implemented in java. We have in eo-math object nan.plus that is implemented in eo . IEEE says that every every math operation with nan as argument(s) must return nan.

And here we go: nan.plus 42.2 returns nan (this it how it's done), but what 42.2.plus nan will return? It must be nan but I think it'll be an exception on compilation.

Mb somehow we'll be able to do something like this:

[] > float
   [x] > plus
     if. > @
       x.as-bytes.eq nan
       nan
       /float # here is some signal that if x is not nan we should return what java implementation returns

Or how can this be solved in another way?

[Graur]

@maxonfjvipon On the one hand I agree with your idea: we need to think about such operations. On the other hand, we are making our eo-runtime dependent on objects from eo-math, which would be incorrect. Perhaps we can store these objects as constants and compare them within the $ object? e.g.

[] > float
  [] > nan-bytes
     7F-C0-00-00 > @

@yegor256 WDYT?

[yegor256]

@Graur I think that nan has to be part of eo-runtime

[maxonfjvipon]

@yegor256 what about infinities then? They require some extra logic too, like nan (see here)

[yegor256]

@maxonfjvipon I had an impression that nan is infinity. No? https://en.wikipedia.org/wiki/NaN

[maxonfjvipon]

@yegor256 IEEE says that no, they are different. NaN is 0/0, +inf is 1/0, -inf is -1/0. They have different logic and different results of the operations.

[yegor256]

@maxonfjvipon than we have to have them all in eo-runtime, I believe

[yegor256]

@maxonfjvipon another approach would be to make float aware of nan, inf+ and inf+, but their presence will only be detectable by number from eo-math:

0.div 0 > x
QQ.math.number x > y
y.is-nan

[maxonfjvipon]

@yegor256 I moved random, number and angle to eo-math.

1. Should I make a PR with removing these objects from eo-runtime?
2. What's the plan about the main topic of this issue? 0.div 0 is not only way to get nan as a result. I mean, it's allowed to write QQ.math.nan.plus 42 and we get the right result - nan. And it should be allowed to write 42.0.plus (QQ.math.nan).

[yegor256]

@maxonfjvipon what's up with this ticket? we still need it?

[maxonfjvipon]

@yegor256 I think I can close it for now

[maxonfjvipon]

@yegor256 I did a little research about the EO parser and I think I'm ready to try to implement this feature, but there are some things I'm not sure about...

This is the code we'll discuss.

[] > float
  [x] > plus
    if. > @
      (number x).is-nan
      nan
      <signal>

1. EO syntax. We need to replace <signal> to something that will signal that instead of return nan we must create float.plus object that is implemented in java (EOfloat$EOplus). There is a thought in my mind that this signal somehow should contain info about type, but it's not accurate.
2. ALNTR. I suggest to extend head rule to be able to parse it.
3. XML. All objects that are implemented in java (as I understood - foreign), like float.plus in xml look like

<o abstract="" atom="float" name="div" ...>
  <o name="x" .../>
</o>

And all local objects look like:

<o base="int" data="...">...</o>
// or
<o base="x"/o>

So what will the right xml with this signal look like? I think this <o> element has to contain name and atom parameters (so it can be transpiled to java) but I'm not sure about abstract.

Let me know what do you think about all of it?