4 ms·

It's only semantically a pass-by-value, in reality a reference is passed and the data is only copied if needed (i.e. value is mutated while shared).

zahlman 8mo ago
So the language has reference semantics, and (per the edit) for every object (like in Python)? (Ah, no, your example elsewhere in the thread suggests that the referred-to structures get implicitly copied all over the place.)
- jcparkyn 8mo ago
  Nope, it's value semantics (unlike Python), the references are just an internal optimization. Implicit copies happen when a list/dict with more than one reference is mutated.
  - zahlman 8mo ago
    > the references are just an internal optimization Optimization specifically for function calls, or... ? Because if you're doing all this copy-on-write anyway, the indirection seems to be a needless cost in other contexts.
    - jcparkyn 8mo ago
      This applies everywhere, and it fundamentally wouldn't be possible for just function calls. > needless cost Are you comparing to a language with mutable references or a our functional language? A language with mutable references will of course be faster, but this is more intended as an alternative to pure functional languages (since functions are referentially transparent). In this case, the cost of the indirection is approximately zero (relative to the cost of just doing reference counting), since passing a reference just requires a bump to the refcount. And most of the time the refcount increments are skipped by "moving" instead of copying the reference.
      - zahlman 8mo ago
        I'm comparing to the same language implemented without the supposed internal optimization, according to my understanding of what you're doing. But I think at this point I'd have to read and analyze the code to have a proper understanding. ... Although granting that you already have paid the cost of reference-counting GC (and, I assume, per-object allocation), it probably is indeed insignificant. And special-casing where the reference count == 1 is also kinda neat. (E.g. CPython doesn't "move references" per se if I'm thinking clearly; but it does detect cases where it can safely mutate the underlying implementation of a type that's "immutable" from the perspective of language syntax.)

zahlman 8mo ago

So the language has reference semantics, and (per the edit) for every object (like in Python)? (Ah, no, your example elsewhere in the thread suggests that the referred-to structures get implicitly copied all over the place.)

jcparkyn 8mo ago
Nope, it's value semantics (unlike Python), the references are just an internal optimization. Implicit copies happen when a list/dict with more than one reference is mutated.
- zahlman 8mo ago
  > the references are just an internal optimization Optimization specifically for function calls, or... ? Because if you're doing all this copy-on-write anyway, the indirection seems to be a needless cost in other contexts.
  - jcparkyn 8mo ago
    This applies everywhere, and it fundamentally wouldn't be possible for just function calls. > needless cost Are you comparing to a language with mutable references or a our functional language? A language with mutable references will of course be faster, but this is more intended as an alternative to pure functional languages (since functions are referentially transparent). In this case, the cost of the indirection is approximately zero (relative to the cost of just doing reference counting), since passing a reference just requires a bump to the refcount. And most of the time the refcount increments are skipped by "moving" instead of copying the reference.
    - zahlman 8mo ago
      I'm comparing to the same language implemented without the supposed internal optimization, according to my understanding of what you're doing. But I think at this point I'd have to read and analyze the code to have a proper understanding. ... Although granting that you already have paid the cost of reference-counting GC (and, I assume, per-object allocation), it probably is indeed insignificant. And special-casing where the reference count == 1 is also kinda neat. (E.g. CPython doesn't "move references" per se if I'm thinking clearly; but it does detect cases where it can safely mutate the underlying implementation of a type that's "immutable" from the perspective of language syntax.)