@samth: do you think you could answer some simple questions about the Complete and Easy Bidirectional Typechecking paper? or is it mostly unfamiliar?

I haven’t read that paper

alright, I figured I’d ask

I might ask the authors some questions but my questions are likely extremely trivial

@ben: Frog is unhappy with the blog post in your PR:

2017–04–18-type-tailoring.md: Ignoring unknown metadata: “Tags:”

error: 2017–04–18-type-tailoring.md: Must start with metadata but missing Tags

Interesting combo. :)

ruh roh. @stamourv @ben If this is a recently-updated Frog — it might be something broke when adding optional new Authors tag, that my tests don’t catch? Can I get a link to the PR and 2017-04-18-type-tailoring.md so I can try?

@greg here’s the PR https://github.com/racket/racket-lang-org/pull/51

and here’s the .md https://github.com/bennn/racket-lang-org/blob/ec44334f59959354f3d2abd1b6445f425fce1c4a/blog/_src/posts/2017-02-26-type-tailoring.md

I was using Frog 0.25

looks like Vincent fixed this by adding a whitespace after “Tags:” https://github.com/racket/racket-lang-org/commit/10938be21db3bcb2b6ce95730e4d44cafe2f59c0

whoa @stamourv @greg , is _hello_ different from *hello* in frog? EDIT: nevermind they look the same on Frog 0.26

(I’ll go ahead & test this now, I’m just surprised about <https://github.com/racket/racket-lang-org/commit/2dd32dae23ad64b3d06bd83ad861dfcb0e375e80>)

@ben: May be the same. As I was debugging, I was just trying to get it as close to one of the working blog posts as possible. :)

@greg: I was using the latest frog, and what ben pointed out is what was causing me trouble.

@mflatt Do you have time to answer some general questions I have about linklets, Racket-on-Chez, and module serialization?

@stamourv @ben Thanks! Logged and will push a commit to fix. https://github.com/greghendershott/frog/issues/189

notjack: yes

@greg: Thanks!

Thanks! Feel free to answer these whenever you get a moment:

1) How do linklets handle phases? Can linklets import each other at different phases? Does that question even make sense? 2) Do linklets match one to one with modules? If I have modules A, B, and C, and a main module M, does compilation first create four individual linklets, then a single linklet that represents M with A, B, and C included, then that linklet is converted to a Chez Scheme module and then a binary by the Chez compiler? 3) How much work is done “ahead of time”, that is in the module->linklet translation? Can I perform optimizations on the linklet of module A which is required by module B without knowing about B? 4) Are linklets always serializable? If not, when aren’t they?

1) linklets are phase-independent. A module is composed of multiple linklets, one for each phase level

2) If A, B, C, and M have no compile-time part, then four linklets will be generated. But if some of the have code at phases other than 0, there will be more linklets

3) Linklets are separately compiled; they’re not necessarily independently compiled, because cross-linklet optimization might happen for a linklet of B that imports a linklet of A (but that cross-linklet optimization is not yet set up in the Chez implementation)

4) It’s possible to create a non-serializable linklet via 3-D code, the same as a non-serializable module (i.e., with something non-serializable under a quote); if a linklet originates from something that read-syntax produces, then it will be serializable (assuming no cross-linklet optimization involving a 3-D-derived linklet)

Linklets are not serializable in the sense of serialize; when you put them in a linklet bundle, then the linklet implementation knows to serialize them when written

1) What are the platform-specific parts of the Racket-module to Chez-compiled binary process? Does the module->linklet transformation or linklet optimization involve anything platform specific?

2) What is a linklet bundle?

3) Are linklets Racket-version specific?

Oh, and 4) How much of this process is deterministic?

1) module-to-linklet compilation is platform-independent; the linklet compilation process is platform-dependent on Chez 2) a “linklet bundle” groups linklets for a module; a “linklet directory” groups bundles for a module and its submodules (and linlet directories also serialize when written) 3) effectively yes, since macros from racket/base can change the full expansion, and therefore the linklet compilation; the bytecode form of a compiled linklet on the Racket VM is also version-specific 4) like the current bytecode compiler, the module-to-linklet and linklet-to-bytecode (for the Racket VM) pipeline is meant to be determinsitic – but there are probably some little problems right now due to a hash table or gensym here and there

One more I can think of: how much compile-time code is “optimized away”? If module A imports module B at phase 1 for utilities in defining some macros and does not export those macros, only uses them, does linklet compilation expand the macros and remove the dependency on B?

Similar question for when module A imports macros from module B, how is that reflected in the linklets?

For background I’m daydreaming about a distributed build system for Racket, something with high scalability that used a distributed blobstore instead of a filesystem to store artifacts like linklets. Any thoughts you have on that would be most appreciated :)

The linklet for A’s run-time code will not use any linklets from B, but the module layer will keep the dependency as usual. Still, having linklets separated out can be useful to something like a demodularizer. For example, the flattener that is applied to the expander’s own implementation in linklet form gathers only the linklets that are actually used or that end up at phase 0 and may have side effects, and linklets from any other phase can be ignored

I don’t know whether it helps for something like a distributed blobstore, but maybe

The important bit is that building package A and package B that both use package X triggers a series of distinct actions like “convert module X into phase linklets” and individual linklets are stored, so they end up reused across machines without having to rely on a shared build environment

This has been really helpful though, thanks a lot :) Good luck on the Chez work, that plus the Racket-powered expander seems like a huge step forward for Racket!