[meeting] [joint] 19.04.2024

[deemp]

Nickolay's pre-meeting notes

1. Bugs in dataization implementation (fixed on Nikolai's machine):

• Dataization should not happen inside dispatch (and application)
• Dataization did not correctly handle context for Package

2. Problems in normalization rules:

• It is not specified in the rules that ρ is void by default?
  • If ρ is void, then we cannot normalize inside any object, before specifying its ρ.
• Handling of ξ is incorrect in Yegor's rules (and also the version in yegor.yaml is wrong):
  • At the very least it does not handle ξ inside arguments of applications
  • Also it should only be fully determined when we perform dispatch (otherwise, we may have some void attributes, such as ρ)
  • Suggestion: use substitution for ξ when doing dispatch, like in the minimal calculus (but simpler, because we do not have arbitrary locators, only ξ)
• Handling of ρ is incorrect in the rules (but EO works correctly):
  • Counterexample: {⟦ x ↦ ⟦ b ↦ ⟦ Δ ⤍ 01- ⟧, φ ↦ ⟦ b ↦ ⟦ Δ ⤍ 02- ⟧, c ↦ ⟦ a ↦ ξ.ρ.ρ.b ⟧.a ⟧.c ⟧.φ, λ ⤍ Package ⟧}
  • Intuition that I have:
    1. ξ.ρ = this in Java (when implementing a method, matches the current implementation of standard EO objects, such as int, bool)
       ξ.ρ.ρ = this in Java (when implementing a method and writing something in a nested function/object)
    2. ρ preserves environment, so using application is not correct, since the environment changes for all subterms (except inside subformations) as well
    3. Attaching ρ is basically closure conversion.
  • Suggestion: inject ρ in all formations as part of ξ-substitution!

3. Metrics:

• When objects contain unknown atoms, we inline/expand definitions uses of object (such as int/bool), which increases metrics
• When explicitly adding ρ-attribute, metrics grow exponentially — another reason to avoid ρ as attribute
• However, when all atoms are known and all is good in the input, metrics indeed decrease (e.g. bool-tests.phi)

4. Questions about the EO compiler:

• α0 instead of as-bytes for positional arguments; should this be handled by the normalizer or by eoc phi?
  • Support positional arguments #303
• org.eolang.bytes does not have a void Δ-attribute; should this be handled by the normalizer or by eoc phi?
  • eo:phi doesn't generate an empty \Delta binding for int, bool, etc. eo#3082
• we currently add λ → Package to program; should this be handled by eoc instead? maybe λ → Test for test files?
  • Fix: no top-level lamdba package in generated PHI programs eo#3129
• why Lorg_eolang_bytes_as_int and Lorg_eolang_bytes_as_float are atoms and not defined in pure EO?
  • replace bytes.as-float, bytes.as-int, and bytes.as-string with EO code eo#3116
• is there a documentation/specification for standard atoms somewhere?

Anatoliy's meeting notes

• as_bytes attribute issue cannot be resolved in general on EO's side, it will be handled on normalizer's side.
• EO team added void delta attribute, waiting for release.
• Yegor agreed to add a λ -> Test.
• as_float atom and others will be removed.
• Atoms are described in https://arxiv.org/abs/2206.02585 and https://github.com/objectionary/on-the-origins-of-objects
• Void ρ results in block of available rules, since we cannot reduce inside of formations with void attributes.
• Suggested update on ξ term rules.
  • Update all top-level ξ's during dispatch.
• Showed example of how ρ after dispatch breaks.
• ρ reminds of working with closures. There is a suggestion to deal with ρ outside of reduction rule, but on a lower level of a virtual machine of some kind.
• Atoms are being implemented.