But looks like it will be impossible to implement this sugar without required module type annotation after This because of recursive module syntax (under sugar). include F(This : T1)(X) include G(X)(This : T2)(Y)

Yes we've considered something like that. Maybe the conversation around the upstream maintainers will push us in this direction -- we're definitely open to the idea. But the existing syntax is simpler and works fantastically in practice. I don't immediately see why we'd need an annotation in recursive modules.

This is a small example for demonstration. But even in bigger examples, this feature doesn't save all that much typing.... yet it's gotten tremendous uptake within Jane Street, without any encouragement from us language folk. We simply made the feature available, and now it appears thousands of times.

OK, should have read the description first...

Yes, this is just syntactic sugar. But it's very sweet!

I don't have benchmarks to report. Part of the problem with benchmarks is that it's hard to make any that are not misleading. That is, I bet I could get an arbitrary percentage speedup by switching to locals, if I have the freedom to write my own program, so writing my own program is not a good way to address this. I could use existing programs, but because using locals well requires some annotations, those programs would have to be edited. How much should we edit? Now that locals exist, we might be able to make large restructuring to a program that will make it clearer without losing performance.... but how does the benchmark take that into account? I'm not trying to say that these problems don't have solutions, just that "measure the perf improvement" is never quite as easy as it sounds. Incidentally, the biggest place within Jane Street that makes use of locals isn't around performance improvement, but is instead around code improvement. That is, there are some applications with performance requirements. Previous to locals, those applications used other techniques to meet their needs. Now with locals, programs can be written more idiomatically (making them easier to maintain), all without losing performance. So the biggest win -- maintainability -- is even harder to measure.

Yes, there are lots of different uses of the terminology out there. I don't particularly defend our choices, but instead I acknowledge that I think any choice of term would have thrown off some potential learners. As for modality vs mode: We use modality to mean a function from mode to mode. Suppose we have a record r at mode m whose type has a field x with a modality f. Then an access of r.x is at mode f(m). The `global` modality is the constant function that always returns `global`. But we have imagined other modalities that actually depend on their argument.

@@RichardEisenberg-JS Cool, thanks for the explanation! Yeah figuring out terminology for new things is definitely hard, and I don’t envy the compromises you have to make. There's always going to be people confused or frustrated and it's hard to predict that in the future - it could be fine, or it could be grumbled about for years, and there's only so many words to choose. Anyway, thanks again for your work and your efforts in explaining this stuff, it's greatly appreciated!

Heyy can u plzz tell me that a B.E Cse graduate can apply in jane street or not..

hey now that's rude. respect your programming elders especially when they volunteer their time to show you stuff that entitled behavior is no good

Most of the annotations here aren't necessary. They're there to make everything more explicit for the video. The `exclave_`s are necessary, but nothing else. Marking lcoals in mli files is necessary though, to enable separate compilation.

check out cornell's cs 3110 with professor clarkson! i am taking that now lmk if u have any questions.

In which year are you going to give JEE Advanced exam?

i hoope microsoft do the serious works with F# on CLR, it's ocmal inspired language basically.

the lesser the language can do in term of syntax (concise/suctinct), the more optimization can be done. as it's narrow down the possiblity of developer `creatitivy` that sometimes abuse the language features

Branchless programming definitely helps! But of course isn't always possible.

Yes that's a good point! I wish I had made that point in the video. :)

Spot on, yes. In general, we have a free choice here: we could say (A) that the contents of a local list are local or (B) the contents of a local list are global. (A) means that we can store local things in a list but we can't let the contents of a local list escape; (B) means that we can let the contents of a local list escape, but we can't store local things in a list. We can't have both. But we can, actually, via a thing called the global modality. We'll get there in a few videos. In brief, it allows you to label a field of a structure as acting like (B). So you get an (A)-list (the normal list type) and a (B)-list (something you'd have to write yourself). These would be different types. This is a bit annoying, for sure, but having one type that can both store local things and then let them escape is definitely worse!

I know we will work with the OCaml community maintainers to get this to be a part of the language -- but not for a while. Our approach is to experiment locally (ha ha) here at Jane Street, gain experience about what's good and what's bad, and then to work to upstream when we have more confidence. In the end, language design is hard to get right, and we want to take advantage of the fact that we can somewhat easily undo mistakes before this is all part of the official language.

@@RichardEisenberg-JS aaah the puun! :D nice to watch though. not sure if OCaml can get more popular and widely adopted at this point but ML is the bomb, so here's hoping something ML does!

Decent points, indeed. (Though these functions have the complexity that hits locals -- bigger functions aren't necessarily harder in this respect.) We're currently working our way through `base` (our open-source standard library), adding local annotations throughout. It's not particularly easy! And yet the benefits we're seeing seem worth the cost. A big question we're thinking about is how this will all shake out in the end, which is one of the reasons we want to develop this on a branch of the compiler instead of pushing early for inclusion in general OCaml.

But then does it mean that for functions we want to explicitly type we wont benefit from the inferred locality and have to go through the hassle anyway?

This is a bit subtle. We're not going to infer exclaves, because doing so can change the asymptotic runtime of your program. (Actually, I should make a video about that. But not for a few weeks!) We can infer everything else -- but (as @goodnight_noom suggests) every time you write a type, you potentially interrupt that inference. So it really is some hassle. And yet my colleagues here at Jane Street are happy to put in the time adding the annotations to get their speedup. The whole system is opt-in, so indeed you'd probably only want to do this where it really counts.

@@RichardEisenberg-JS Why can't there be mode inference even if you specify the types? Why does specifying a type without a mode annotation mean it's global?

@@pdp11 I suppose we could have something like `_ t1 -> _ t2` that indicates we should infer the mode. (Well, not that syntax.) But we need to know what `t1 -> t2` means: is it saying global implicitly? Or does it want inference? Right now, if you write a type, its modes are considered known. (This has to be the case in interface files, regardless of what we do on function annotations.)

Well, yes! Rust is an inspiration for what we're up to, but we're not trying to mimic it directly. Instead, we see how Rust uses lifetimes to effectively allow stack allocation, and we want that, too. :)

@@RichardEisenberg-JS, sure, I get it. but as a dude that is trying to get into ML, with OCaml already being a hard sell -- queries like "Why Ocaml sucks" bring up interesting, if sometimes outdated, results -- it looks a bit cumbersome to throw this in the mix. just like the sentence I just wrote, inadvertently!

@@adicide9070 Makes sense. There's always a delicate balance between expressiveness and simplicity. We're hoping to gain experience by targeting primarily fellow Jane Streeters, figure out where the pain points are, and then try to make it so that all of this becomes simple. One nice bit of feedback I've gotten roaming the office is that some programmers here don't even really know what locals are -- that means that you can successfully use OCaml without knowing about this niche feature.

It depends on what you mean by "difference". Your two `f`s (I'll call them f1 and f2) have different types. Because f1's argument is local_, the compiler will try to treat its argument as local. While explored more in the next video, this means that allocations that happen in the argument can be made on the stack, instead of on the heap. (This is good.) In the actual code here, though, the argument is just a constant, so no allocation is necessary. In both cases, `x` is local. (But actually this won't compile as written, because the syntax you've used is for elements of a module, and a variable in a module cannot be local. You don't need exclave_ because there is no allocation in your f.)

@@RichardEisenberg-JSyeah, sorry - I was mostly interested in the difference for the variable x declared on the 2nd line. It should be local in both cases - so I was curious if there were any advantages to the first option over the second one. Maybe the first option doesn't require a local_ mode on the function parameter for this example, it would probably make my question clearer then - my intuition on all of this isn't that good yet.

Global/local is something that applies to expressions and values, not memory locations. So in your example, z is local (and would not be allowed to escape) and y is global. So returning y is just fine -- even if y and z are aliased in memory. The same is true for a mutable reference: a local variable can be aliased with a global, and the global one is allowed to escape.

@@RichardEisenberg-JS I see I was just thinking in terms of your previous example with a file handle. Say, a function creates and returns a file handle - wouldn't it be able to retain it through those means? Or it then just guarantees that the ref is local, not the underlying value? Anyways I'm glad to be learning OCaml during such resurgence :)

@@huge_letters There's a subtlety in the way that question is phrased, mentioning returning the file handle. If a function returns a file handle, then the handle can't be local -- there's no way to control where it will end up (as you rightly surmise). But we can still protect file handles by using a callback (or continuation, if you prefer that term): `with_file : string -> (local_ handle -> 'r) -> 'r`. Once something is local, it can't be made global, so that file handle will be protected.

By annotating, we can check whether our belief meets reality, turning a mistaken belief into a compile-time error. Annotating also informs future readers of our code and makes the code easier to understand.

@@RichardEisenberg-JS Thank you. Is the stack allocation not implemented if it is not annotated?

@@JeanNoelAvila Inferring stack allocation (not covered in depth in the video, but it will be!) works just fine. You don't need to annotate for that.

I think thunks should be fine; it's just that the thunk itself would have to be local in order to capture local data. It would be a pretty major lift, though -- getting this working in OCaml wasn't easy. (I don't take credit, as most of it was implemented before I started at Jane Street.)

Do you have an example? Should work fine with unpacking GADTs.

@@RichardEisenberg-JS i had an issue with unpacking GADTs where their type escaped the region. it works as intended but have to be careful bc so many ways fail. which is good since thats partially why local_ is there, to spot mistakes

Indeed! Well, it's a little different from Rust's interpretations of lifetime (ours are simpler; Rust's are more expressive). But I didn't want to start by assuming knowledge of Rust.

​@@RichardEisenberg-JSI think simpler is better for something that can become as mind-numbing to take care of manually as lifetimes. In rust, they tend to blow up, pushing you to just clone everything everywhere

Happy to be back on KZbin. 😁