Sam Mohr (Jan 02 2025 at 15:33): Sam Mohr (Jan 02 2025 at 15:33):With the move to parentheses-based function calls (let's say PNC), we now have a potential schism between how we call user-defined functions and our special keywords: dbg, crash, try. It's likely that try gets removed once PNC is ready, but the other 2 will still be around. They are not currently visually distinct from function calls (unless syntax highlighting is aware of them), but it would be nice to know when your special keywords (dbg logs to the console) were visually distinct for scanning code.
We have a few options as to how we can call them, given these type signatures:
dbg : a -> a where a.to_str() -> Str
crash : Str -> a # an unbound variable
dbg "abc"
func.call(123, dbg)
Maintain the current syntax, but allow for passing them around as functions.
dbg("abc")
func.call(123, dbg)
@dbg("abc")
func.call(123, @dbg)
dbg!("abc")
func.call(123, dbg!)
Of these options, I'd vote for @ prefixes since they're unique in Roc and don't confuse users about !, but are visually distinct. Close second is using parens and relying on syntax highlighting. Thoughts?
Brendan Hansknecht (Jan 02 2025 at 15:38):I see no reason to make them special. I would vote for just treating them like normal functions
Richard Feldman (Jan 02 2025 at 16:04):keep in mind return doesn't do this
Richard Feldman (Jan 02 2025 at 16:04):and it doesn't in mainstream languages either
Sam Mohr (Jan 02 2025 at 16:04):Yep
Richard Feldman (Jan 02 2025 at 16:04):so there's precedent both ways
Richard Feldman (Jan 02 2025 at 16:04):same with stuff like throw or raise
Sam Mohr (Jan 02 2025 at 16:05):Roc has been good at annotating control flow subversion with purity inference, however
Sam Mohr (Jan 02 2025 at 16:05):You're right that this would be exceptional
Brendan Hansknecht (Jan 02 2025 at 16:21):Personally, they just feel like normal functions to me. So I really don't feel there is any need to make them stick out more than a slightly different syntax coloring. They should be usable where a lambda is usable.
Brendan Hansknecht (Jan 02 2025 at 16:23):Oh, just realized that today crash and dbg can't be used as lambdas and passed into other functions
Brendan Hansknecht (Jan 02 2025 at 16:24):In my opinion, if we allow them to be passed into other functions like lambdas (which I think makes sense), they should just be normal functions. If instead they are not allowed to be passed into other functions, it makes sense to keep them extra special
Richard Feldman (Jan 02 2025 at 16:26):yeah I don't think they should be passed into other functions :big_smile:
Brendan Hansknecht (Jan 02 2025 at 16:29):I mean they are already trivial to pass into other functions \x -> crash "unreachable"
Brendan Hansknecht (Jan 02 2025 at 16:30):And I could see someone using dbg for a logger function in a simple platform.
Brendan Hansknecht (Jan 02 2025 at 16:30):So might pass it into a module param for a logger in another module
Sam Mohr (Jan 02 2025 at 16:30):dbg is weird because it's currently either a statement or an expression. We could probably make it just an expr of type a -> a where a.to_str() -> Str but then we'd need to treat it specially for dbg(x) statements, since pure statements need to return {} and this returns x.
Sam Mohr (Jan 02 2025 at 16:31):So at least dbg can't just be a normal function all the time, even if it is most of the time
Brendan Hansknecht (Jan 02 2025 at 16:32):Fair enough
Brendan Hansknecht (Jan 02 2025 at 16:32):I think that means it makes most sense to leave these fully special like return
Sam Mohr (Jan 02 2025 at 16:35):It'd be nice to remove whitespace calling within expressions, but we have that for math operators
Sam Mohr (Jan 02 2025 at 16:36):Like func.call(123, crash "an error occurred") would be nice to deprecate in favor of func.call(123, crash("an error occurred"))
Sam Mohr (Jan 02 2025 at 16:39):Then assuming there's no prefix/suffix for these special functions, I'd vote for calling them like normal functions without spaces
Sam Mohr (Jan 02 2025 at 16:40):Since it removes all whitespace delimiting from expressions
Anthony Bullard (Jan 02 2025 at 16:45):I'd like dbg to have the signature a -> a where a.to-str: (a -> Str) -> a
Anthony Bullard (Jan 02 2025 at 16:45):I love that Elm debug functions the passed in value
Richard Feldman (Jan 02 2025 at 16:45):Sam Mohr said:
Like
func.call(123, crash "an error occurred")would be nice to deprecate in favor offunc.call(123, crash("an error occurred"))
in general I'd actually like to give a warning for using crash as an expression like this
Sam Mohr (Jan 02 2025 at 16:45):That'd be nice
Anthony Bullard (Jan 02 2025 at 16:46):So much so that I implemented it in the formula language we use dynamic configuration of components in the product I work on at work
Brendan Hansknecht (Jan 02 2025 at 16:46):Anthony Bullard said:
a -> a where a.to-str: (a -> Str) -> a
dbg has two signatures a -> a where a.to-str: (a -> Str) -> a and a -> a where a.to-str: (a -> Str) -> {}
Richard Feldman (Jan 02 2025 at 16:46):it's reasonable to use crash as an expression being given to a short-circuiting operator
Richard Feldman (Jan 02 2025 at 16:46):but foo(bar, baz, crash ...) never makes sense
Richard Feldman (Jan 02 2025 at 16:46):because it's just going to crash, so you might as well delete the foo(bar, baz part
Brendan Hansknecht (Jan 02 2025 at 16:47):it's reasonable to use
crashas an expression being given to a short-circuiting operator
We could still suggest using a if ... then in those cases.
Anthony Bullard (Jan 02 2025 at 16:47):Yeah, so if we keep that our statements are:
?
Richard Feldman (Jan 02 2025 at 16:47):Brendan Hansknecht said:
Anthony Bullard said:
a -> a where a.to-str: (a -> Str) -> adbg has two signatures
a -> a where a.to-str: (a -> Str) -> aanda -> a where a.to-str: (a -> Str) -> {}
and worth noting that in Elm, the equivalent of dbg only has the expression version, and it leads to people doing things like _ = dbg ... all the time
Brendan Hansknecht (Jan 02 2025 at 16:48):Yeah, so if we keep that our statements are:
and dbg
Anthony Bullard (Jan 02 2025 at 16:48):I wonder if you could just have a UnitIgnoreExpr statement?
Anthony Bullard (Jan 02 2025 at 16:48):That's just an Expr that's followed by other statements, and in can we find out if the expr has the type {}?
Anthony Bullard (Jan 02 2025 at 16:49):Sorry for using the name Unit but that's how my functional brain thinks of that type
Sam Mohr (Jan 02 2025 at 16:49):I presumed the long term plan for parsing output is that a module is:
function bodies are just lists of type or value statements as well
Anthony Bullard (Jan 02 2025 at 16:51):I would hate it if we enforced a separation of types and values long-term
Sam Mohr (Jan 02 2025 at 16:54):it would be
pub enum Statement {
Alias(Pattern, Type),
Import(Module, Vec<Exposes>),
ImportFile(Path, Type),
Assignment(Pattern, Expression),
Return(Expression),
Dbg(Expression),
Bare(Expression),
}
pub struct Module {
header: Header,
defs: Vec<Statement>,
}
pub enum Expression {
Function {
args: Vec<Args>,
body: Vec<Statement>,
},
Value ...
}
And then canonicalization would block Dbg and Return outside of functions
Anthony Bullard (Jan 02 2025 at 16:59):What about annotated defs?
Anthony Bullard (Jan 02 2025 at 17:00):Is that just an Alias followed by a Bare?
Sam Mohr (Jan 02 2025 at 17:00):You either during parsing combine Alias followed by Bare without anything between (like comments or newlines) into a AnnotatedAssignment
Sam Mohr (Jan 02 2025 at 17:01):Or you do that in can
Anthony Bullard (Jan 02 2025 at 17:02):Yeah, that's reasonble
Sam Mohr (Jan 02 2025 at 17:02):All that said, it means that generic "statements" are like 99% of a module
Anthony Bullard (Jan 02 2025 at 17:03):I'd probably collapse Return and Dbg into a single case where the first item would be a enum of {Return, Dbg} but yeah, this is good
Anthony Bullard (Jan 02 2025 at 17:04):And we'd also have to enforce imports at the top
Anthony Bullard (Jan 02 2025 at 17:04):Unless we want to parse the entire file to find dependencies
Sam Mohr (Jan 02 2025 at 17:04):I don't think so, but I'd be okay with that
Anthony Bullard (Jan 02 2025 at 17:04):I'd be ok with it if we get local imports and import destructures :wink:
Anthony Bullard (Jan 02 2025 at 17:05):But I don't think that works with ImportFile
Anthony Bullard (Jan 02 2025 at 17:05):Unless it's replaced with a binding of a local variable to a module-level constant
Sam Mohr (Jan 02 2025 at 17:07):I'm working on the can rewrite, and it entails us first compiling modules in silos for maximum cache friendliness. We need to go find all imports even within blocks anyway for that to do its job, so I don't think it's a problem if we allow nested (file) imports
Sam Mohr (Jan 08 2025 at 22:57):It seems like @Anthony Bullard took away that we were gonna do dbg func(arg1, arg2), but I thought the takeaway was that we'd do dbg(func(arg1, arg2)). Which are we going for? The latter seems more consistent
Sam Mohr (Jan 08 2025 at 22:57):And I presume Anthony and Josh would agree that it makes parsing simpler in addition
Luke Boswell (Jan 08 2025 at 22:58):I thought it was the PNC version too
Sam Mohr (Jan 08 2025 at 22:58):We are making crash a function, so only dbg is left as a "function" that uses whitespace. return uses whitespace, but it's different since it can only start an expression
Luke Boswell (Jan 08 2025 at 22:59):Is there like a statement version that uses whitespace, and an inline expression version that is a function and just passes the value through?
Brendan Hansknecht (Jan 08 2025 at 23:01):I would argue at this point that they are clearly keywords/intrinsics and not functions
Brendan Hansknecht (Jan 08 2025 at 23:01):As such, none of the should use function calling syntax
Brendan Hansknecht (Jan 08 2025 at 23:01):Instead they should use the space calling syntax and be distinct.
Brendan Hansknecht (Jan 08 2025 at 23:02):So crash "my str" return abc and dbg some_fn(123)
Sam Mohr (Jan 08 2025 at 23:02):A few points against that:
val.dbg()crash use parens Sam Mohr (Jan 08 2025 at 23:03):But I'm okay with it so long as crash and dbg act the same
Richard Feldman (Jan 08 2025 at 23:03):hm, why are we having crash use parens? :face_with_raised_eyebrow:
Sam Mohr (Jan 08 2025 at 23:03):Maybe I misread the code
Richard Feldman (Jan 08 2025 at 23:03):I agree with Brendan, I think all of these should be like return or try or catch or throw in other languages
Richard Feldman (Jan 08 2025 at 23:03):as in, no parens
Brendan Hansknecht (Jan 08 2025 at 23:04):For me, the main issue is that they don't fully act like functions. You have to wrap them in a lambda to pass them into another function.
Anthony Bullard (Jan 08 2025 at 23:04):I just wish they were parsed solely as expressions
Richard Feldman (Jan 08 2025 at 23:04):I think it's ok if we have both dbg foo and foo.dbg()
Anthony Bullard (Jan 08 2025 at 23:04):That would simplify the grammar a lot
Richard Feldman (Jan 08 2025 at 23:04)::thinking: although...if we have static dispatch, is there a reason we couldn't just always make it be foo.dbg()?
Anthony Bullard (Jan 08 2025 at 23:05):What about for non-nominal types?
Richard Feldman (Jan 08 2025 at 23:05):we infer it
Anthony Bullard (Jan 08 2025 at 23:05):That would REALLY lead people to Nominal-land
Richard Feldman (Jan 08 2025 at 23:05):just like we do for .equals
Anthony Bullard (Jan 08 2025 at 23:05):Ah
Richard Feldman (Jan 08 2025 at 23:05):yeah we already infer a ton of things :big_smile:
Richard Feldman (Jan 08 2025 at 23:05):.inspect too
Anthony Bullard (Jan 08 2025 at 23:05):Man, I just don't love the magical intrinsic methods
Anthony Bullard (Jan 08 2025 at 23:05):But i'm just one human
Richard Feldman (Jan 08 2025 at 23:06):well I think it's essential that { ... } == { ... } works
Richard Feldman (Jan 08 2025 at 23:06):among other things
Richard Feldman (Jan 08 2025 at 23:06):and inferred methods seems like the obvious way to achieve that, especially if we want nominal types to be able to customize how == works on them
Richard Feldman (Jan 08 2025 at 23:07):and it's not just equality, but also hashing (e.g. wanting to be able to use structural records, tags, and tuples as keys in dictionaries and sets)
Sam Mohr (Jan 08 2025 at 23:07):and encoding/decoding
Anthony Bullard (Jan 08 2025 at 23:08):I guess that I don't like that now I have to know "if i see .equals() it is a compiler inferred implementation.....or maybe not...."
Richard Feldman (Jan 08 2025 at 23:09)::thinking: what's the difference between that and any other method?
Richard Feldman (Jan 08 2025 at 23:10):like anytime you see .equals() you have to know the type of the thing before the . to know where its implementation lives
Richard Feldman (Jan 08 2025 at 23:10):and if you know its type is nominal, then you know it's in a module somewhere, but if you know it's structural, then you know it has to be compiler-inferred because there's no module where arbitrary structural records are defined :big_smile:
Anthony Bullard (Jan 08 2025 at 23:11):But if it's compiler derived normally, I might just assume there is no custom implementation
Richard Feldman (Jan 08 2025 at 23:12):I see
Richard Feldman (Jan 08 2025 at 23:12):I think that would only be true of dbg
Anthony Bullard (Jan 08 2025 at 23:13):And equals
Richard Feldman (Jan 08 2025 at 23:13):oh equals you can for sure override!
Richard Feldman (Jan 08 2025 at 23:13):so that you can customize how equality works e.g. for a user-defined collection like a tree data structure where you don't want equality to care about insertion order
Agus Zubiaga (Jan 08 2025 at 23:47):I vote for only having .dbg()— that works everywhere.
The only caveat is that we have to allow it as a statement even if the value is not {}/().
So you can do:
…
result.dbg()
…
Currently that’s only allowed if the function is effectful
Agus Zubiaga (Jan 08 2025 at 23:48):I mean, it’s allowed, but it triggers a warning
Sam Mohr (Jan 08 2025 at 23:51):Presumably, we can desugar that to dbg(expr), and for top-level pure stmts check if it's an Apply(Dbg, ...) and not emit the warning. Should be simple to support
Sam Mohr (Jan 08 2025 at 23:52):I like the idea of only having one way to do things, but in this case dbg expr seems like it reads forward a lot better
Sam Mohr (Jan 08 2025 at 23:53):So it would be a downgrade to always read the dbg after the expression we're debugging
Anthony Bullard (Jan 08 2025 at 23:58):I think the warning should only be if the return type is NOT Unit
Anthony Bullard (Jan 08 2025 at 23:58):And then problem solved
Sam Mohr (Jan 08 2025 at 23:58):Not quite for dbg
Sam Mohr (Jan 08 2025 at 23:58):That's true for everything else
Anthony Bullard (Jan 08 2025 at 23:59):Or can’t we have an exception if the func is Dbg?
Sam Mohr (Jan 08 2025 at 23:59):That's the idea, yep
Anthony Bullard (Jan 08 2025 at 23:59):dbg returns a?
Sam Mohr (Jan 09 2025 at 00:00):Yep, so you can do func(dbg arg)
Anthony Bullard (Jan 09 2025 at 00:00):I think right now I’ve worked on the compiler for more hours than I’ve written Roc code :cry:
Sam Mohr (Jan 09 2025 at 00:00):I'm DEFINITELY in that boat
Sam Mohr (Jan 09 2025 at 00:00):It's a living
Sam Mohr (Jan 09 2025 at 00:00):You can work on libraries any time, we need plenty of those
Sam Mohr (Jan 09 2025 at 00:01):It would be a two step check for whether a pure statement is allowed:
Apply(Dbg, ...){} Agus Zubiaga (Jan 09 2025 at 00:04):Yeah, so for the purposes of the warning, we would treat dbg as effectful
Agus Zubiaga (Jan 09 2025 at 00:04):because it kind of is
Sam Mohr (Jan 09 2025 at 00:06):But only at the top-level, I presume. Since Str.repeat("abc", 3.dbg()) would be doing work outside of the thing it debug printed
Agus Zubiaga (Jan 09 2025 at 00:12):Yeah, but that’s the same rule for effectful fns
Sam Mohr (Jan 09 2025 at 00:16):I don't think I agree. I thought that:
Sam Mohr (Jan 09 2025 at 00:17):But func(arg1, val.dbg()) wouldn't work like 3 because the func(arg1, part isn't "debugful"
Sam Mohr (Jan 09 2025 at 00:17):I'm sure I'm missing something here
Sam Mohr (Jan 09 2025 at 00:17):Not sure how important it is for you to explain it to me as long as the implementation works :smile:
Brendan Hansknecht (Jan 09 2025 at 00:26):Personally I prefer dbg to generally be at the beginning of the line so I don't have to see:
"some really long message that feels out of place with the quote at the beginning of the line: ${var.to_str()}".dbg()
Same
Sam Mohr (Jan 09 2025 at 00:27):It's why we at least need dbg expr if not also expr.dbg()
Agus Zubiaga (Jan 09 2025 at 00:33):oh, I didn’t mean we would actually consider dbg effectful like in the type system, but only for the purposes of the discarded result in statement warning where I think would work the same.
Sam Mohr (Jan 09 2025 at 00:35):I agree with that, I just think that you can't make all dbg calls as effectful for that to work since only the top one should get that tracking
Sam Mohr (Jan 09 2025 at 00:36):Since I don't think we should allow Str.repeat("abc", 3.dbg()) as a pure statement unless the top-level value was debugged
Agus Zubiaga (Jan 09 2025 at 00:37):Str.repeat("abc”, get_count!()) is effectful but would still produce the warning
Agus Zubiaga (Jan 09 2025 at 00:37):Because you’re discarding the result of repeat
Sam Mohr (Jan 09 2025 at 00:37):Oh, great!
Agus Zubiaga (Jan 09 2025 at 00:37):So I think it’s the same
Sam Mohr (Jan 09 2025 at 00:37):Didn't know that was the case
Sam Mohr (Jan 09 2025 at 00:37):If that's the case, then we're good
Richard Feldman (Jan 09 2025 at 02:46):Brendan Hansknecht said:
Personally I prefer
dbgto generally be at the beginning of the line so I don't have to see:"some really long message that feels out of place with the quote at the beginning of the line: ${var.to_str()}".dbg()
I dunno, I'm kinda skeptical that this would come up a lot in practice :sweat_smile:
Richard Feldman (Jan 09 2025 at 02:46):I'd like to try it as just the method style and see how it goes
Richard Feldman (Jan 09 2025 at 02:46):because we know we want that style so it can be used in pipelines
Richard Feldman (Jan 09 2025 at 02:46):and maybe we want both, but let's see how much demand there is in practice if we have only the one way to do it
Joshua Warner (Jan 09 2025 at 05:49):What should the precedence of dbg be?
In particular, how should dbg 4 / 2 be parsed?
That's currently (dbg 4) / 2, but if dbg is a keyword like return, I feel it should be parsed like dbg (4/2).
Joshua Warner (Jan 09 2025 at 05:51):I ask, because I'm troubleshooting a bug the fuzzer found, where this:
dbg(a/a)
d
is formatted as this:
dbg a / a
d
... which of course is parsed differently.
Joshua Warner (Jan 09 2025 at 05:52):I can have the formatter add parens like this fairly easily:
dbg (a / a)
d
... but when I read the above thread, it occurred to me that we may want to change the precedence of dbg anyway.
Sam Mohr (Jan 09 2025 at 06:04):Secret option: we parse dbg in two ways
Sam Mohr (Jan 09 2025 at 06:04):As the start of a statement, or as a method call
Sam Mohr (Jan 09 2025 at 06:04):Then the precedence question goes away
Sam Mohr (Jan 09 2025 at 06:05):I guess for now we can't do that yet, so we can maybe just treat dbg as a normal function call for simplicity
Joshua Warner (Jan 09 2025 at 06:06):We absolutely can do that now. (unless I'm missing something?)
Joshua Warner (Jan 09 2025 at 06:06):And that's roughly the direction I'm thinking here
Sam Mohr (Jan 09 2025 at 06:06):I don't think we should focus on keeping it a space call even within expressions at this time
Joshua Warner (Jan 09 2025 at 06:07):Hmm, can you more explicitly state what you think we _should_ focus on?
Sam Mohr (Jan 09 2025 at 06:07):Sure
Joshua Warner (Jan 09 2025 at 06:07):(or just, what you think we should do?)
Sam Mohr (Jan 09 2025 at 06:08):My goal is to subvert complexity arising from an intermediate state that we don't care about
Sam Mohr (Jan 09 2025 at 06:08):It seems like this question is effort we don't need to put in
Sam Mohr (Jan 09 2025 at 06:08):Unless you really think so
Sam Mohr (Jan 09 2025 at 06:09):My vote would be:
Sam Mohr (Jan 09 2025 at 06:09):Copy the return <expr> parser
Sam Mohr (Jan 09 2025 at 06:09):Make a dbg one
Sam Mohr (Jan 09 2025 at 06:09):And otherwise allow treating dbg like a function for now
Sam Mohr (Jan 09 2025 at 06:09):With parens
Joshua Warner (Jan 09 2025 at 06:10):I think we're way more on the same page than you think we are
Sam Mohr (Jan 09 2025 at 06:10):Oh, great
Sam Mohr (Jan 09 2025 at 06:11):I'm distracted with choir stuff right now, I'll stop trying to multitask
Joshua Warner (Jan 09 2025 at 06:11):Haha np
Brendan Hansknecht (Jan 09 2025 at 18:10):Richard Feldman said:
Brendan Hansknecht said:
Personally I prefer
dbgto generally be at the beginning of the line so I don't have to see:"some really long message that feels out of place with the quote at the beginning of the line: ${var.to_str()}".dbg()
I dunno, I'm kinda skeptical that this would come up a lot in practice :sweat_smile:
I do this fairly often when working on roc code. Sometimes I need more context than just the variable. Or want to print multiple variables in a single dbg statement.
Last updated: Jun 16 2026 at 16:19 UTC