
@kcf.jackson has joined the channel

There are a number of podcasts that do conference announcements - is it worth sending details of the racket-con/summer-school to ‘cognicast’, ‘functional geekery’ and any others? https://con.racket-lang.org https://summer-school.racket-lang.org/2018/
As I can’t justify the con/school (my day job is cache/MUMPS) so I rely on podcasts and the YouTube videos from racketcon, I’d be interested to know if racketeers would recommend any other podcasts (or YouTube channels) for aspiring Racketeers?
Kind Regards,
Stephen

I didn’t look at Hackett’s implementation, but I think I understand the problem, now. So far, the most consistent and workable idea I have is to add a notion of “interned” scope, so that different unmarshalings arrive at the same scope. To do that, we’d add make-interned-syntax-introducer
, which takes a symbol and returns an introducer for the same scope whenever the given symbol is the same. Then, your example could be made to work by using (make-interned-syntax-introducer 'hackett-type #t))
in “ns.rkt”. I have also been tempted to think of the problem in terms of phases and to add a way to bind at, say, symbol-keyed phases. I’m not sure that’s a good direction, though, and it involves a lot more pieces.

I think what you say makes sense, and it does seem like the most direct path to making what I want to work actually work. For what it’s worth, I’ve spent a lot of time comparing namespaces to phases, and the similarities are extremely tempting, but I think I’ve come down firmly on the conclusion that namespaces are not phases, and there are things about them that do not map directly. That doesn’t mean making a notion of namespaces baked in would necessarily be a bad or unhelpful idea, since it would eliminate the need for my complicated dancing wrt require
and provide
, but I don’t think that alone makes a very compelling argument for doing that amount of work and complicating the expander even more when a userspace implementation will do.

Is this something you think I could reasonably implement on my own? I am willing to take on the effort if you think it’s something you think is a reasonable idea and something I can feasibly do, since I’d rather not burden you with any more than I have to. You’ve given me enough of your time over the past few weeks already. :)

Yes. You’ll probably have to work a little to figure out serialization, and adding a new expander export may not be completely obvious (hint: a provide
from the expander’s “main.rkt” isn’t useful) but the change looks otherwise straightforward. Just in case, keep in mind that that the expander must act as if it’s lock-free (in case a thread is killed while it is expanding) – which matters for a scope-intern table, but a symbol-keyed eq?
-based weak hash table should just work.

Okay, great. I’ll look into it today, and I’ll send questions your way if I have them.

(Correction: … an eq?
-based hash table with values wrapped in emphemerons.)

@mflatt I am looking into what we discussed a couple days ago: determining if a compiled module was compiled with errortrace support. I get the code with (define code (get-module-code "/home/pmatos/Projects/.../main.rkt"))
and then (module-compiled-imports code)
but this only seems to return the direct imports of the module independently of how it was compiled or if it was compiled at all. Where was errortrace/errortrace-key
supposed to show up?

It would be in the direct imports. But maybe a better approach: A ".zo" isn’t going to have code instrumented for errortrace unless its’ in “compiled/errortrace” subdirectory, so maybe a better/simpler test is to check for that file being present and up-to-date.

Thanks, will give that approach. I might be wrong but the only way to generate compiled bytecode with errortrace is through raco setup --mode errortrace
, right?

I assume that there are already functions in the api checking if the zo is present? and if it is up to date, right?

@mflatt Does it make sense for make-interned-syntax-introducer
to still accept a use-site?
argument like make-syntax-introducer
does? If the answer is yes, are interned scopes with distinct kinds considered distinct scopes? That is, does each symbolic key effectively produce up to two scopes, one with a macro
kind and another with a use-site
kind? Or should make-interned-syntax-introducer
dispense with kinds entirely?

Either of those two options would be fine with me.

Probably not in the direct way that you want, unless I’m forgetting something. An implementation would be somewhere in get-module-code
.

@pocmatos ISTR seeing similar things in the source for dynamic-rerequire


Thanks for the pointers.

@mflatt It looks like I have something that works, but I’m not sure how to properly write a test case that exercises marshalling/unmarshalling. Are there some existing tests I could look at? I haven’t found them.

Look for (write (compile ...))
patterns in “module.rktl” or “syntax.rktl”

@robby Looks like background expansion got stuck for me again… here’s what ended up in my stderr, if it helps: drracket-background-compilation: expanding-place.rkt: 00 starting monitors
drracket-background-compilation: expanding-place.rkt: 01 starting thread
drracket-background-compilation: expanding-place.rkt: 02 setting basic parameters
drracket-background-compilation: expanding-place.rkt: 03 setting module language parameters
drracket-background-compilation: expanding-place.rkt: 04 setting directories
drracket-background-compilation: expanding-place.rkt: 05 installing security guard
drracket-background-compilation: expanding-place.rkt: 06 setting uncaught-exception-handler
drracket-background-compilation: expanding-place.rkt: 07 starting read-syntax
drracket-background-compilation: expanding-place.rkt: 08 read
drracket-background-compilation: expanding-place.rkt: 09 starting expansion
drracket-background-compilation: expanding-place.rkt: kill; worker-thd stack (size 5) dead? #f:
drracket-background-compilation: (make-generic-self-module-path-index . #f)
drracket-background-compilation: (expand-module18 . #f)
drracket-background-compilation: (expand-capturing-lifts . #f)
drracket-background-compilation: (expand-single . #f)
drracket-background-compilation: (#f . #(struct:srcloc #<path:/Users/alexis/gits/racket/racket/racket/share/pkgs/drracket/drracket/private/expanding-place.rkt> 123 7 4558 8520))

Cool!

Can you send email with that to Matthew (and me)?

The make-generic-self-module-path-index
looks promising, since that involves an interning table

can do

No need – it’s clear that the table used by make-generic-self-module-path-index
is the problem in this case

okay, cool

Oh sorry

I didn’t realize we were in general. :)

(serves me right for trying to answer things on my phone in another meeting :wink:)

My Typed Racket is rusty so maybe this is new, but I don’t understand the notation (-> Any Boolean : point)
here https://github.com/racket/typed-racket/pull/699/files#diff-50cc6fcfab42d982f6c481cca2318893R108 I don’t see it explained here: https://docs.racket-lang.org/ts-guide/types.html#%28part._.Function_.Types%29

Oh, it’s in the next section https://docs.racket-lang.org/ts-guide/occurrence-typing.html

> The type (-> Any Boolean : String)
has three parts. The first two are the same as any other function type and indicate that the predicate takes any value and returns a boolean. The third part, after the :
, represents the logical propositions the typechecker learns from the result of applying the function

Is it wrong to think of this as a shorthand for (case-> (-> String True) (-> Any False))
? (Or maybe Any
is more like "(Not String)
")

@pnwamk ^

@greg it’s kind of right, but also kind of wrong

that isn’t how TR works

but you could imagine a different system that does work that way

and @pnwamk and I have been working on that

To be clear, I have no deep thoughts about this. Just sharing one person’s naive first intuition. :slightly_smiling_face:

The intuition I’d go for is (-> Any Boolean : String)
says that it’s a predicate for String
s

To expand more, I think an example would be ; Assume f has type (-> Any Boolean : String)
(if (f x)
... ; in this branch, x has type String
...) ; in this branch, x would be something not a String

without : String
I guess TR won’t know that calling f
would haved revealed the type of x

How does contract-out
work exactly?