[racket-users] DrRacket: No signature (blue) boxes for teaching languages?

[Kennis Koldewyn]

I'm running DrRacket 7.5 on MacOS 10.14 (Mojave), and I'm seeing the 
"signature boxes" (previously known as "blue boxes") as expected in the 
upper-right corner of the definitions window and the interactions window 
when using the Racket language.  However, if I choose a teaching language 
(Beginning Student, Intermediate Student with lambda, etc.), then the 
signature boxes are never visible, even though the checkbox "Show signature 
boxes and signature box arrow semi-circle in upper-right corner" is checked 
in the preferences.  Is this by design, and if so, is there a way to change 
it?  I'd like to introduce a young student to Racket, and the signature 
boxes would be very helpful (since it basically brings a big chunk of the 
documentation right into the user interface).

Best regards and a happy new year to all,

Kennis

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/956d729c-092a-4f63-980d-e7134597ef0b%40googlegroups.com.

Re: [racket-users] How do I provide a name as both a match expander and contracted function?

[Eric Griffis]

Hi Jack,

It can be done with make-rename-transformer.

(define (foo? obj) (equal? obj foo-impl))
> (define foo-widget list)
>
> (define/contract (foo-impl _) (-> number? symbol?) 'a-foo)
>
> (define-match-expander foo
>   (syntax-parser [(_ widget) #'(? foo? (app foo-widget widget))])
>   (make-rename-transformer #'foo-impl))
>
> ; (foo #t) ; contract violation
>
> (foo 123)


Eric


On Mon, Dec 30, 2019 at 7:07 PM Jack Firth  wrote:

> If I'm making my own data types, one common thing I want to do is make
> smart constructors that double as match expanders. I could use
> `define-match-expander` with two transformers, but then I can't add a
> contract to the smart constructor with `contract-out`. If I try to write
> this:
>
> (provide
>  (contract-out
>   [foo (->* (widget?) (#:name symbol?) foo?)]))
>
> (define (make-foo widget #:name [name #f])
>   ...)
>
> (define-match-expander foo
>   (syntax-parser [(_ widget) #'(? foo? (app foo-widget widget))])
>   (syntax-parser [(_ arg ...) #'(make-foo arg ...)]))
>
> ...then the use of `contract-out` hides the fact that `foo` is a match
> expander. What should I do?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/2dac85e9-8058-437c-b5bc-a92f659c02f6%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAORuSUwWSyb42_-a1fgoRDFi0rKeCiRHmO7st3E3n_j-CKdL1w%40mail.gmail.com.

[racket-users] How to prepare and present new pict3d internal documentation?

[Hendrik Boom]

How to prepare and present new pict3d internal documentation?

I'm busy working on new internal documentation of pict3d.
I'd like some advice on how to prepare and present the resulting document 
(which isn't even a draft yet).

Pict3D's various components look to be useful on their own,
and I'd like to use texture mapping with it.  This requires some level of 
understanding of it internals.

At present there seems to be no such internal documentation.
(or is there an ancient thesis or lost internal project report or some thing 
like that?  If so I haven't foud it.)

What I have now is a file of ragged notes on pict3d.

It constitutes a kind of diary of my questions and discoveries as I work my way 
into it, a few hours at a time every week or two.

you can see it on github:
https://github.com/hendrikboom3/rackettown/blob/master/notes.pict3d

If you bother to look at them it's obvious that they won't constitute the 
internal documentation I' looking for.

Before I actually start producing definitive documentation, I'd like to have a 
few answers.

In what form should I present the internal API?

Of course, a scribble document, and there are conventions for that.

(1) Should it be a separate document from the existing pict3d user 
documentation?

(2) Should it be part of the source code for pict3d?  (which would presumably 
result in a pull request someday)  That might well make the pict3d source code 
itself somewhat more comprehensible, at least while I'm trying to read it. But 
I'd need a mechanism to extract comments and other information from the source 
code and assemble it into a readable document.

Or should it be a separate file within the pict3d source code?

Or should it have its own source repository?

(3)  Are there any established conventions for API documentation in Racket 
source code?

(3a) I've found there is no shortage of hard-to-use API documentations 
generated automatically from source code.  But it's possible to do better.  The 
Trestle Reference Manual ( http://www.opencm3.net/doc/src_reports/src-068.pdf ) 
is an example of it done right.  I'd like to do it right myself.


This is an open project.  Advice, critique, proposed content, and useful 
information are all welcome.

Especially answers to relevant questions I haven't thought of yet!

-- hendrik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20191231123027.lcspvrc6nc5sdlgr%40topoi.pooq.com.