Having said that, I think it would be wiser to handle this as (report/line ...) rather than (report ... #:line), because:
I’m not aware of any precedent for treating the raw keyword signal as an argument. Moreover the keyword signal won't actually accept an argument: something like (report ... #:line #t) produces a "bad syntax" error.
report is a debugging tool, so in terms of ergonomics, it’s nicer to only have to type in one location. It's easier to change a (report ...) to (report/line ...) than to (report ... #:line).
I will make this tweak and update the docs.
Having said that, I think it would be wiser to handle this as `(report/line ...)` rather than `(report ... #:line)`, because:
1. I’m not aware of any precedent for treating the raw keyword signal as an argument. Moreover the keyword signal won't actually accept an argument: something like `(report ... #:line #t)` produces a "bad syntax" error.
2. `report` is a debugging tool, so in terms of ergonomics, it’s nicer to only have to type in one location. It's easier to change a `(report ...)` to `(report/line ...)` than to `(report ... #:line)`.
I will make this tweak and update the docs.
1:
The precedents are things like (struct ... #:transparent), (defmodule ... #:no-declare) and (syntax-parse stx #:disable-colon-notation ...), and since report is a macro, it doesn't have to accept an argument after the keyword, so (report 5 #:line) works fine and shows the output:
5 = 5 on line 3
5
2:
I was thinking of keyword options because if more options are added, you don't need to add a form for every option, or even worse, a form for every possible combination of options, it's all handled by one form. For example originally there were many variants of defmodule with different options, but then keyword options were added to the main one for this same reason (I think).
1:
The precedents are things like `(struct ... #:transparent)`, `(defmodule ... #:no-declare)` and `(syntax-parse stx #:disable-colon-notation ...)`, and since `report` is a macro, it doesn't have to accept an argument after the keyword, so `(report 5 #:line)` works fine and shows the output:
```
5 = 5 on line 3
5
```
2:
I was thinking of keyword options because if more options are added, you don't need to add a form for every option, or even worse, a form for every possible combination of options, it's all handled by one form. For example originally there were many variants of `defmodule` with different options, but then keyword options were added to the main one for this same reason (I think).
P.S. I had a problem with sugar/debug.rkt not noticing that typed/sugar/debug.rkt had changed, where normally it would. I'm guessing the require-via-wormhole messed it up. Do you know of any way to tell racket that sugar/debug.rkt depends on typed/sugar/debug.rkt?
P.S. I had a problem with `sugar/debug.rkt` not noticing that `typed/sugar/debug.rkt` had changed, where normally it would. I'm guessing the `require-via-wormhole` messed it up. Do you know of any way to tell racket that `sugar/debug.rkt` depends on `typed/sugar/debug.rkt`?
I was thinking of keyword options because if more options are added, you don't need to add a form for every option, or even worse, a form for every possible combination of options, it's all handled by one form
I’d agree if there were clearly a bunch of options that needed to be handled. But it’s taken quite a while just to get to a second (actually I also added a third, report/file). So for now, the principle of YAGNI applies (moreover it does not preclude keyword args later).
BTW another reason to not use keywords: makes it possible to search and replace one form of report for another.
BTW2, I have long thought it would be valuable to make a debug metalanguage that would enable certain atomic marks within the reader, so instead of writing out (report (proc arg ...)) you could do something like ^(proc (arg ...)) which would expand to the same thing, similar to ' and quote. Again, for ergonomic purposes, so that it would be fast to get these marks in & out of the source. One annoyance even with (report ...) is that you have to deal with the closing parenthesis.
I'm guessing the require-via-wormhole messed it up. Do you know of any way to tell racket that sugar/debug.rkt depends on typed/sugar/debug.rkt?
I think this happens because it’s a multi package, so the sugar and typed/sugar modules have separate compiled directories, but connected in an unorthodox way with require-via-wormhole. Seems like a job for info.rkt, though I haven’t experimented to see if it can specify intra-package dependencies.
> I was thinking of keyword options because if more options are added, you don't need to add a form for every option, or even worse, a form for every possible combination of options, it's all handled by one form
I’d agree if there were clearly a bunch of options that needed to be handled. But it’s taken quite a while just to get to a second (actually I also added a third, `report/file`). So for now, the principle of YAGNI applies (moreover it does not preclude keyword args later).
BTW another reason to not use keywords: makes it possible to search and replace one form of `report` for another.
BTW2, I have long thought it would be valuable to make a `debug` metalanguage that would enable certain atomic marks within the reader, so instead of writing out `(report (proc arg ...))` you could do something like `^(proc (arg ...))` which would expand to the same thing, similar to `'` and `quote`. Again, for ergonomic purposes, so that it would be fast to get these marks in & out of the source. One annoyance even with `(report ...)` is that you have to deal with the closing parenthesis.
> I'm guessing the require-via-wormhole messed it up. Do you know of any way to tell racket that sugar/debug.rkt depends on typed/sugar/debug.rkt?
I think this happens because it’s a `multi` package, so the `sugar` and `typed/sugar` modules have separate `compiled` directories, but connected in an unorthodox way with `require-via-wormhole`. Seems like a job for `info.rkt`, though I haven’t experimented to see if it can specify intra-package dependencies.
closes #1
Genius.
Having said that, I think it would be wiser to handle this as
(report/line ...)rather than(report ... #:line), because:(report ... #:line #t)produces a "bad syntax" error.reportis a debugging tool, so in terms of ergonomics, it’s nicer to only have to type in one location. It's easier to change a(report ...)to(report/line ...)than to(report ... #:line).I will make this tweak and update the docs.
1:
The precedents are things like
(struct ... #:transparent),(defmodule ... #:no-declare)and(syntax-parse stx #:disable-colon-notation ...), and sincereportis a macro, it doesn't have to accept an argument after the keyword, so(report 5 #:line)works fine and shows the output:2:
I was thinking of keyword options because if more options are added, you don't need to add a form for every option, or even worse, a form for every possible combination of options, it's all handled by one form. For example originally there were many variants of
defmodulewith different options, but then keyword options were added to the main one for this same reason (I think).P.S. I had a problem with
sugar/debug.rktnot noticing thattyped/sugar/debug.rkthad changed, where normally it would. I'm guessing therequire-via-wormholemessed it up. Do you know of any way to tell racket thatsugar/debug.rktdepends ontyped/sugar/debug.rkt?I had to explicitly run
raco setup sugarto make sure it noticed the changes, and that's probably why you saw the syntax error.I’d agree if there were clearly a bunch of options that needed to be handled. But it’s taken quite a while just to get to a second (actually I also added a third,
report/file). So for now, the principle of YAGNI applies (moreover it does not preclude keyword args later).BTW another reason to not use keywords: makes it possible to search and replace one form of
reportfor another.BTW2, I have long thought it would be valuable to make a
debugmetalanguage that would enable certain atomic marks within the reader, so instead of writing out(report (proc arg ...))you could do something like^(proc (arg ...))which would expand to the same thing, similar to'andquote. Again, for ergonomic purposes, so that it would be fast to get these marks in & out of the source. One annoyance even with(report ...)is that you have to deal with the closing parenthesis.I think this happens because it’s a
multipackage, so thesugarandtyped/sugarmodules have separatecompileddirectories, but connected in an unorthodox way withrequire-via-wormhole. Seems like a job forinfo.rkt, though I haven’t experimented to see if it can specify intra-package dependencies.ff87149376.Step 1:
From your project repository, check out a new branch and test the changes.Step 2:
Merge the changes and update on Gitea.