ffi-lib and scribble/srcdoc

19 views
Skip to first unread message

Dominik Pantůček

unread,
Dec 23, 2019, 3:10:32 AM12/23/19
to Racket Users
Hello,

apart from parallel sorting and working with unsafe ops, I stumbled upon
a very strange behavior using ffi-lib:

------>8------
#lang racket
(require scribble/srcdoc)
(provide
(proc-doc/names
a-struct?
(-> any/c boolean?)
(a)
("Returns true if a is a-struct")))
(struct a-struct (b))
----->8-----

Running this works without a glitch:

$ racket test1.rkt
$

But if we require ffi/unsafe, something bad happens:

------>8------
#lang racket
(require ffi/unsafe scribble/srcdoc)
(provide
(proc-doc/names
a-struct?
(-> any/c boolean?)
(a)
("Returns true if a is a-struct")))
(struct a-struct (b))
----->8-----

$ racket test2.rkt
test2.rkt:8:4: proc-doc/names: unsupported procedure contract form (no
argument names)
at: (-> any/c boolean?)
in: (proc-doc/names a-struct? (-> any/c boolean?) (a) ("Returns true
if a is a-struct"))
location...:
test2.rkt:8:4
context...:
do-raise-syntax-error
/usr/share/racket/pkgs/scribble-lib/scribble/srcdoc.rkt:342:2:
proc-doc/names-transformer
/usr/share/racket/pkgs/scribble-lib/scribble/srcdoc.rkt:127:24
/usr/share/racket/pkgs/scribble-lib/scribble/srcdoc.rkt:124:0:
do-provide/doc
/usr/share/racket/collects/racket/provide-transform.rkt:63:2:
pre-expand-export
/usr/share/racket/collects/racket/private/reqprov.rkt:708:2: provide
apply-transformer-in-context
apply-transformer52
dispatch-transformer41
do-local-expand50
/usr/share/racket/collects/syntax/wrap-modbeg.rkt:46:4:
do-wrapping-module-begin
apply-transformer-in-context
apply-transformer52
dispatch-transformer41
loop
finish
...
$

I assume that ffi/unsafe somehow re-defines -> and it does it in a very
srcdoc-incompatible way. Did anyone spot the same behavior? Can it be
fixed? That is without rewriting the whole ffi/unsafe library.

I am using a simple workaround to scribble my libraries with ffi/unsafe
requires:

----->8-----
#lang racket
(require
ffi/unsafe
scribble/srcdoc)
(provide
(proc-doc/names
a-struct?
(->* (any/c) () boolean?)
((a) ())
("Returns true if a is a-struct")))
(struct a-struct (b))
----->8-----

But it is kind of strange to use (-> any/c boolean?) contract for
predicate in one module and (->* (any/c) () boolean?) in another one.

It sort of feels like the problem with requiring unsafe-vector-ref
without knowing. Although this is also "without knowing", it at least
exhibits itself at the syntax stage (and not at run-time).



Cheers,
Dominik

Sam Tobin-Hochstadt

unread,
Dec 23, 2019, 9:30:09 AM12/23/19
to Dominik Pantůček, Racket Users
What you're seeing is that `scribble/srcdoc` looks for the _binding_
of `->` from `racket/contract` which is being shadowed by the version
of `->` from `ffi/unsafe`. I would do something like this:

#lang racket
(require (rename-in ffi/unsafe [-> -->]) scribble/srcdoc)
(provide
(proc-doc/names
a-struct?
(-> any/c boolean?)
(a)
("Returns true if a is a-struct")))
(struct a-struct (b))

and then use `-->` in ffi declarations.

Sam
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/2ac9a533-4325-53da-6855-01bd07da81a3%40trustica.cz.

Dominik Pantůček

unread,
Dec 23, 2019, 12:03:40 PM12/23/19
to racket...@googlegroups.com
Hi,

On 23. 12. 19 15:29, Sam Tobin-Hochstadt wrote:
> What you're seeing is that `scribble/srcdoc` looks for the _binding_
> of `->` from `racket/contract` which is being shadowed by the version
> of `->` from `ffi/unsafe`. I would do something like this:
>
> #lang racket
> (require (rename-in ffi/unsafe [-> -->]) scribble/srcdoc)
> (provide
> (proc-doc/names
> a-struct?
> (-> any/c boolean?)
> (a)
> ("Returns true if a is a-struct")))
> (struct a-struct (b))
>
> and then use `-->` in ffi declarations.

that is exactly what I was looking for. All the "unsafe" parts can get
really "unsafe" during any stage though ...


Thank you!
Dominik
Reply all
Reply to author
Forward
0 new messages