Do we represent package objects in PHI correctly?

[maxonfjvipon]

This ticket gave me an idea, that our package objects like org or eolang are not correctly represented in PHI:

{[
  org -> [
    eolang -> [...],
    L> Package
  ]
]}

1. They have \lambda asset and bound attributes, like org has attribute eolang which is wrong (?)
2. The presence of the bound attribute makes the presence of \lambda unnecessary
3. The \lambda is supposed to return the object, but what object does package object \lambda return?

@yegor256 WDYT?

[yegor256]

The \lambda is supposed to return the object, but what object does package object \lambda return?

@maxonfjvipon this is the key question. Indeed, lambda is not necessary here, since we already have all attributes in place. Moreover, when we convert two .eo files to .phi, we get this:

{[
  org -> [
    eolang -> [...],
    L> Package
  ]
]}

and then in another file:

{[
  org -> [
    foo -> [...],
    L> Package
  ]
]}

How can they be merged? According to what rules? I believe, we don't have them defined anywhere.

[maxonfjvipon]

Notes:

1. we use lambdas in package objects only as indicators so we can convert them to +package meta and convert to java in a right way
2. if we remove these lambdas - objects org and eolang should be converted to regular java classes and maybe this is what we need
3. maybe we can introduce an XSL transformation that would convert all abstract objects without bound attributes to packages