better formatting of build-column error

[shriram]

t = table: a, b
  row: 1, 2
  row: 3, 4
end

t.build-column("a", lam(r): 4 end)

The error comes out as

which has a very non-built-in look, and furthermore, the parameter and the column names are written without strings, which could mislead some students.

[jpolitz]

Thanks, this we can definitely improve. Looks like a stringly-constructed message in a library rather than a custom error constructor.

On Mon, Apr 26, 2021 at 8:12 AM, Shriram Krishnamurthi < @.*** > wrote:

t = table: a, b row: 1, 2 row: 3, 4 end

t.build-column("a", lam(r): 4 end)

The error comes out as

image ( https://user-images.githubusercontent.com/75030/116106591-3d55f400-a680-11eb-802d-9623e778f2a1.png )

which has a very non-built-in look, and furthermore, the parameter and the column names are written without strings, which could mislead some students.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub ( https://github.com/brownplt/pyret-lang/issues/1584 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAA5IU4AUYNQEBU6L2REZL3TKV7HRANCNFSM43TCZD2Q ).

[blerner]

Indeed. We have a lot of string messages still floating around in our code, and I'm torn: on the one hand we want all our error messages to be artisanally crafted, formatted and informative; on the other, errors.arr is a cesspit of tedious code and a common source of the dreaded "internal errors prevented us from displaying ..." errors, plus we're trying to make it easier for external libraries to be written for Pyret that don't get to have baked-in support for bespoke error messages. We could define a new custom message here, and I'm inclined to: tables are baked-in values of the language and should have baked-in support. But we should reconsider how to better decouple "nicely formatted" errors from "having to bake them in to errors.arr"...

[jpolitz]

Yeah, agreed. This is possible now by defining an object with render-reason and/or render-fancy-reason methods. But actually writing those methods in JS would be painful and needs a better API.

On Mon, Apr 26, 2021 at 12:13 PM, Ben Lerner < @.*** > wrote:

Indeed. We have a lot of string messages still floating around in our code, and I'm torn: on the one hand we want all our error messages to be artisanally crafted, formatted and informative; on the other, errors.arr is a cesspit of tedious code and a common source of the dreaded "internal errors prevented us from displaying ..." errors, plus we're trying to make it easier for external libraries to be written for Pyret that don't get to have baked-in support for bespoke error messages. We could define a new custom message here, and I'm inclined to: tables are baked-in values of the language and should have baked-in support. But we should reconsider how to better decouple "nicely formatted" errors from "having to bake them in to errors.arr"...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub ( https://github.com/brownplt/pyret-lang/issues/1584#issuecomment-827080211 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAA5IU34KGAX6HBCCH2PJ6TTKW3NRANCNFSM43TCZD2Q ).