Allow #lang sugar/debug shorthands in other phases #12

This allows for instance

#lang sugar/debug racket/base
(require (for-meta 1 (only-in racket/base begin-for-syntax))
         (for-meta 2 (only-in racket/base begin-for-syntax))
         (for-meta 3 (only-in racket/base #%datum)))
(begin-for-syntax
  (begin-for-syntax
    (begin-for-syntax
      #R5)))

To work properly.

This allows for instance ``` racket #lang sugar/debug racket/base (require (for-meta 1 (only-in racket/base begin-for-syntax)) (for-meta 2 (only-in racket/base begin-for-syntax)) (for-meta 3 (only-in racket/base #%datum))) (begin-for-syntax (begin-for-syntax (begin-for-syntax #R5))) ``` To work properly.

The new test passes for version 6.2, 6.2.1, and HEAD, but in 6.0 and 6.1 there appears to be a bug in how local-require works at other phase levels. What should I do?

The new test passes for version 6.2, 6.2.1, and HEAD, but in 6.0 and 6.1 there appears to be a bug in how `local-require` works at other phase levels. What should I do?

We should carve off sugar/debug as a separate package. Remove the dependency on TR. Drop support for < 6.2 (I don't want to do that for sugar generally)

We should carve off `sugar/debug` as a separate package. Remove the dependency on TR. Drop support for < 6.2 (I don't want to do that for `sugar` generally)

What’s the shortest sensible name? dbg?

What’s the shortest sensible name? `dbg`?

d?

`d`?

I personally wouldn't mind typing out debug once at the top of the file, as long as the abbreviations in the middle are short and easy to type.

Also note that this change doesn't break anything in previous versions that wasn't broken already. It only unbreaks it for the more recent versions, but the added test shows that it didn't unbreak it for the previous versions.

Would you rather I remove the test?

Re: separate package: Should you make the new debug package, or should I?

Just created https://github.com/AlexKnauth/debug

Can I move the rest of sugar/debug into the new package — time-repeat, compare, et al.?

Can I move the rest of `sugar/debug` into the new package — `time-repeat`, `compare`, et al.?

Those don't really seem as useful as debugging tools though.

Hah, how quickly the hammer comes down!

I don't mean that as a hammer; they could be useful for testing and performance checking.

Some would say slow performance is a bug ;)

But seriously, my idea is that you’ve come up with a clever way of hooking up these diagnostic (better, more inclusive word?) functions with a meta-lang. Thus IMO it would be sensible to fold these diagnostic functions into one module, where they can all share the meta-lang scaffolding, rather than duplicate the scaffolding between modules.

For instance, analagously to #R, I would enjoy being able to do timing with #T rather than (time ...)

I also have foreseen a function that wraps #%app in order to inspect function arguments, etc.

In which case maybe debug is too narrow a name for the module — diag?

Some would say slow performance is a bug ;) But seriously, my idea is that you’ve come up with a clever way of hooking up these _diagnostic_ (better, more inclusive word?) functions with a meta-lang. Thus IMO it would be sensible to fold these diagnostic functions into one module, where they can all share the meta-lang scaffolding, rather than duplicate the scaffolding between modules. For instance, analagously to `#R`, I would enjoy being able to do timing with `#T` rather than `(time ...)` I also have foreseen a function that wraps `#%app` in order to inspect function arguments, etc. In which case maybe `debug` is too narrow a name for the module — `diag`?

Um, I wouldn't. Slow performance means you at least have the concept down of what this thing should actually do, but if you try to make it too fast without actually checking for correctness, I would call that a bug. (This recently happened to me when I was writing a program for factoring that I submitted for homework, but then found a bug) I had chosen the wrong base case, because I wanted a more efficient one. But it was wrong. But anyway ...

Yes, the name debug might be too narrow.

A debugging tool for #%app would definitely be useful. I'll get right on making a macro for that, but what do you think the reader shorthand should be?

Um, I wouldn't. Slow performance means you at least have the concept down of what this thing should actually do, but if you try to make it too fast without actually checking for correctness, I would call that a bug. (This recently happened to me when I was writing a program for factoring that I submitted for homework, but then found a bug) I had chosen the wrong base case, because I wanted a more efficient one. But it was wrong. But anyway ... Yes, the name debug might be too narrow. A debugging tool for `#%app` would definitely be useful. I'll get right on making a macro for that, but what do you think the reader shorthand should be?

Should the app version report each argument separately, or should it report them together in a reconstructed s-expression?
So like this?

(report/app (+ (* 2 3) (* 3 4)))
;+ = #<procedure:+>
;arg 0 = 6
;arg 1 = 12
;result = 18

Or like this?

(report/app (+ (* 2 3) (* 3 4)))
;(+ 6 12) = 18

Which do you think would be the most clear and convenient?

Should the app version report each argument separately, or should it report them together in a reconstructed s-expression? So like this? ``` racket (report/app (+ (* 2 3) (* 3 4))) ;+ = #<procedure:+> ;arg 0 = 6 ;arg 1 = 12 ;result = 18 ``` Or like this? ``` racket (report/app (+ (* 2 3) (* 3 4))) ;(+ 6 12) = 18 ``` Which do you think would be the most clear and convenient?

Slow performance means you at least have the concept down

I used to think this was true, but no longer.

But we needn’t debate what is properly included in debugging. I’m just arguing that one benefit of splitting this into a new module is to let it have more inclusive scope. (Or then slice it into diag/debug, diag/perf, etc)

> Slow performance means you at least have the concept down I used to think this was true, but no longer. But we needn’t debate what is properly included in debugging. I’m just arguing that one benefit of splitting this into a new module is to let it have more inclusive scope. (Or then slice it into `diag/debug`, `diag/perf`, etc)

Another thing that could go in diag is simple logging — when you want to create a quick & dirty logfile of some behavior without committing to a whole logging subsystem.

Another thing that could go in `diag` is simple logging — when you want to create a quick & dirty logfile of some behavior without committing to a whole logging subsystem.

I used to think this was true, but no longer.

(What I think today is that performance is a consideration in the design of the program, and validating this part of the design is relevant at all stages, not just the end)

> I used to think this was true, but no longer. (What I think today is that performance is a consideration in the design of the program, and validating this part of the design is relevant at all stages, not just the end)

Ok. I'm not saying a diagnostic library would be a bad thing. It's just more than I think belongs in something called debug. And it's more than what I need right now to debug a couple of macros.

Ok. I'm not saying a `diagnostic` library would be a bad thing. It's just more than I think belongs in something called debug. And it's more than what I need right now to debug a couple of macros.

Should the app version report each argument separately, or should it report them together in a reconstructed s-expression?

They probably both have their uses, like #R and #RR. If you’re going to spend multiple lines of output, I would suggest more verbose descriptions, e.g. —

(report/app (+ (* 2 3.0) (* 3 4)))
;+ = #<procedure:+>
;a0: 6.0 flonum 
;a1: 12 exact integer
;= 18.0 flonum

Easy if you were willing to depend on the describe package, which is pretty great.

> Should the app version report each argument separately, or should it report them together in a reconstructed s-expression? They probably both have their uses, like `#R` and `#RR`. If you’re going to spend multiple lines of output, I would suggest more verbose descriptions, e.g. — ``` racket (report/app (+ (* 2 3.0) (* 3 4))) ;+ = #<procedure:+> ;a0: 6.0 flonum ;a1: 12 exact integer ;= 18.0 flonum ``` Easy if you were willing to depend on the `describe` package, which is pretty great.

Or maybe using explorer would be useful for the multi-line version. So what would the abbreviations be?

Or maybe using [explorer](https://github.com/tonyg/racket-explorer) would be useful for the multi-line version. So what would the abbreviations be?

It's just more than I think belongs in something called debug

Agreed — that’s why I propose that you change the name of your new package to diag, so it can be a hub for these tools.

> It's just more than I think belongs in something called debug Agreed — that’s why I propose that you change the name of your new package to `diag`, so it can be a hub for these tools.

Or maybe using explorer would be useful for the multi-line version.

Whatever works.

So what would the abbreviations be?

IMO report/args makes more sense as the function name. And thus #RA and #RAA seem to follow as abbreviations.

That verbose output example looks untidy. It should be columnized:

(report/app (+ (* 2 3.0) (* 3 4)))
+     #<procedure:+>
6.0   flonum 
12    exact integer
18.0  flonum

> Or maybe using explorer would be useful for the multi-line version. Whatever works. > So what would the abbreviations be? IMO `report/args` makes more sense as the function name. And thus `#RA` and `#RAA` seem to follow as abbreviations. That verbose output example looks untidy. It should be columnized: ``` racket (report/app (+ (* 2 3.0) (* 3 4))) + #<procedure:+> 6.0 flonum 12 exact integer 18.0 flonum ```

I thought you were going to make this diag library.

I thought you were going to make this `diag` library.

Then so shall it be.

Labels Milestones

Allow #lang sugar/debug shorthands in other phases #12

Step 1:

Step 2: