Jonathan Blow on Closures

okay why not closures what are the alternatives to closures what can we do in the language is equivalent to what closures provide okay so early on in the design I assumed that I was going to add closures relatively soon and I just have never done it because honestly it has not been that important for what I do um I understand that some people like them um I did computer science at University of California berkele where they teach how awesome closures are in the very first class um since then though I got cult deprogrammed and I don't actually think they're awesome um for many reasons not least of which is efficiency of your program right for the same reasons that I talk about sometimes in lectures also in the howt for the language about paradigms like objectoriented programming or even just um things like the fact that you should use Smart pointers for memory allocation um the same way that those things insidiously make your program very slow and hard to understand understand in ways that you don't expect um closures do the same things because a closure is like look this is this is an instantiated thing with certain particular data that has its own lifetime separate from other data and you honestly don't really want to do that if you can help it it's just it's not um it imposes a lot of costs that people don't necessarily think about now that said um it is still a it is still in the road map probably to provide closures at some point um there are practical implementation questions of how do we provide all the flexibility that you have in the language with regard to allocators and that sort of thing um without making closures too much of a hassle also how do you avoid the big uh annoying thing that like C++ did right so in C++ a closure is essentially you know a functor which is essentially a struct with an overloaded pen operator but that means it's not actually a function type so anytime that you want a negative function or a closure you need a special thing and actually of course because C++ like a member function is also a different type right so like C style function member function and closure are all totally different things actually right and then you need to paper over that at user level um how do you avoid that well I think I think the way to avoid it is um by having all uh the standard function type in the language be a fat pointer right um where uh every every function has a data pointer that it could refer to right because for example when we're talking about allocators right you have allocator and allocator data all the the time and you need to pass those right why is that well you might have a lot of different heaps right and the allocator might be the Heap handling function which might be the same for all those heaps but the allocator data might be the pointer to the base of the Heap which is different for all those heaps right um so even without closures very often you want to have a data pointer for functions this is also true just with thread safety generally right so like Q sort in C was like hey here's the here's the type for the sort function that you pass to Q sort it takes two arguments and not really that much else right and so uh historically in C if you wanted to do Q sort and you needed more you needed more data you would just put the stuff into the global data you'd make some Global variables that that function reads I mean and put the values in there and then run Q sword on those and uh it would do the thing right but that's very bad for thread safety right um so now maybe you put those in thread local storage but that has performance penalties and also it's Error prone and all these things right and so um it's just kind of a good idea to have a data pointer with a function pointer right um so that is probably what will happen of course you still need to specify sometimes if you want to have a function pointer that you pass into C you have to specify that it's actually just the bare code pointer with no data pointer and so forth right um so that's been the vague plan for a long time it's just that some of these other things seem more important right like um the module features I discussed before seem a lot more important to me than add en closures and so that that is what that is but I would expect that okay I would expect that first having um data pointers be part of the function pointer type would happen and then you could explicitly set those the same way a string has like you know data and count probably a function does too and it's probably you know code and dat or something right um and then uh after that so first we would Implement that see what all the ramifications are deal with that and then Implement closures on top of that and then the nice thing about that is once that's done you can have all kinds of stuff right um like you don't have the C++ problem of a functor and a native function type being a totally different thing they're like the same thing right um so you don't need to make a mess everywhere like you do in C++ I'm not getting through the questions very fast but you know what we're just going to go I'm just going to go through the the questions in order and if everybody gets tired and leaves and we go way too long um we can just do another one next week or in a couple weeks um we'll see I didn't uh preset a prescribed length for this session um so we'll just see how long it goes and yeah okay uh you often talk about how syntax is not definite right now is there anything that you are seriously considering changing in the future looking at you AutoCast yeah AutoCast maybe um it is weird uh the dereferencing pointers is a little bit weird um that said I'm thinking about looking at a little bit more implicit casting I'm looking at adding an implicit pointer dreference so if you have a pointer to something and you're calling a function that takes that thing by value implicitly dereferencing that which might sound scary CU it's like oh I might get a a ndi reference in a weird place that's hard to debug but in a debug build you can have a compile time check for that just like an array bounds check and so it would be very easy to isolate uh where that went wrong right um so that would result in writing D references explicitly less often but yeah like changing the dreference um but honestly I'm not thinking that hard about that stuff yet because I really do want to do a uh question everything kind of syntax uh approach a little later on when like once things go in maybe before open Beta right because you want to you don't want everyone in open Beta to have to like do a big syntax adaptation but you know do a look we're questioning everything we're questioning every operator the way declarations happen all that stuff and just seeing you know some of the syntax I think works out very well and unlikely to change but but some of it uh you know some of it there are clear uh downsides to so for example the colon equals versus equals thing is an easy to make mistake um like I've said it's also an easy to catch mistake hopefully um but uh until we actually Implement that checking and see how often that mistake is caught that assertion that it's an easy to catch mistake is untested right and so there might be something still not easy to catch about that um which might lean more strongly on oh we should change that right um so that's the story about syntax changes as with standard modules could there be standard metaprogram modules which could be included to enhance build processes for instance to impose common house rules yes and so so okay so you already could have that right now um in fact modules check is one of these so if I go there um you can just call this function it's not it's not documented right now but you can call this function do error checking on a compiler message right and uh it it does some stuff right it does 200 lines worth of stuff uh including um print F checking so like print F and and scanf like functions um is that all that it does right now that's all that it does right now um but you could add other standard checking in here right or add more modules or something right now the thing that this doesn't do this is just a function that you call right what if this requires some setup right um what if uh what if it requires some shutdown right I don't know and so there's a question of should we um should we make more of a convention for that and well I think the answer to that is I should make it possible so that there's more of a convention and I should maybe make one that you could start with but I don't want to um I don't want to constrain that either like if people decide that they have a better way to organize these right and so if we put up like the standard metap program um like I was saying at the beginning the question is would things be pluggable into that like that's that's another question is can these read command line arguments right I mean they could already just of their own volition look at the command line because you have a call to like get that um but is that a good idea like does the main program want to filter out arguments meant for one thing versus another thing I don't know all this really I think uh is to be figured out um what that structure could look like

Channel: Jonathan Blow Highlights

Views: 8,444

Keywords:

Id: okDvOw9KHhA

Length: 11min 22sec (682 seconds)

Published: Tue Jul 09 2024