Stack overflow when parameter name is same as object property name

[sin-ack]

The following fails:

class Point {
  x: Float
  y: Float
  z: Float
}

function Point(x: Float, y: Float, z: Float) = new Point { x = x; y = y; z = z }

foo = Point(1.0, 2.0, 3.0)
bar = foo.x

With the following error:

–– Pkl Error ––
A stack overflow occurred.

┌─ 643 repetitions of:
│ 7 | function Point(x: Float, y: Float, z: Float) = new Point { x = x; y = y; z = z }
│                                                                    ^
│ at test#Point.x (file:///.../test.pkl, line 7)
└─

10 | bar = foo.x
           ^^^^^
at test#bar (file:///.../test.pkl, line 10)

106 | text = renderer.renderDocument(value)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
at pkl.base#Module.output.text (https://github.com/apple/pkl/blob/3a31188/stdlib/base.pkl#L106)

The following works as expected, however:

function Point(x_: Float, y_: Float, z_: Float) = new Point { x = x_; y = y_; z = z_ }

I would expect object properties to be in a different "namespace" and such not cause a self-assignment.

[holzensp]

You might expect that, but does that mean you'd also expect that as soon as you're inside a function, you can't reference object properties at all anymore? How would you write this?

function Uniform(x_: Float): Point = new { x = x_; y = x; z = x }

[sin-ack]

Hmm, you are right. Then the issue becomes "it should give a nice error instead of stack overflowing" :)

[gian-didom]

Bumped into this

[holzensp]

This is something to get used to, but it's rather unavoidable, given Pkl's dynamic name resolution. In a general sense, this is indistinguishable from a stack overflow (even though this direct case seems obvious; it doesn't generalise and most "real" scenarios involve at least one indirection). I'd argue the stack overflow is already kind of nice, in that it shows what the loop was explicitly.

Closing this for lack of further specificity.