Stack overflow when parameter name is same as object property name #145

Closed
opened 2025-12-30 01:21:30 +01:00 by adam · 4 comments
Owner

Originally created by @sin-ack on GitHub (Apr 22, 2024).

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.

Originally created by @sin-ack on GitHub (Apr 22, 2024). The following fails: ```pkl 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: ```pkl 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.
adam closed this issue 2025-12-30 01:21:31 +01:00
Author
Owner

@holzensp commented on GitHub (Apr 23, 2024):

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 }
@holzensp commented on GitHub (Apr 23, 2024): 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 } ```
Author
Owner

@sin-ack commented on GitHub (Apr 26, 2024):

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

@sin-ack commented on GitHub (Apr 26, 2024): Hmm, you are right. Then the issue becomes "it should give a nice error instead of stack overflowing" :)
Author
Owner

@gian-didom commented on GitHub (Jun 15, 2024):

Bumped into this

@gian-didom commented on GitHub (Jun 15, 2024): Bumped into this
Author
Owner

@holzensp commented on GitHub (Jun 19, 2024):

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.

@holzensp commented on GitHub (Jun 19, 2024): 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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#145