Honestly, I prefer the more typical bracket syntax like foo::bar() i.e. types are parameters in a separate section. It's more clear and doesn't have the ambiguity problem like your random function. I think you should revisit the syntax sometime and try to come up with a way that's a clear improvement.
9 ปีที่แล้ว +15
I know you are hesitant to publish the compiler at this early stage but I was wondering if you would maybe agree to dumping all this juicy demo code somewhere (like GitHub for example). I'd really like to be able to look over these at my own pace (I view them as a form of 'language spec' that isn't as dull as a formal language definition).
I was just there, fighting G++ as usual (why can't it even manage includes properly?), and I wished for something better. Then I opened youtube and found a new demo video! You kind of make my day every time you post these :D Keep up the good work!
Currently learning Python, I am somewhat of a noob, however this video has helped to unlock some of the mysteries I have been having trouble with. Thank you.
22:30 How about presenting the error in top down fashion instead of bottom up, assuming that the error was made at the very last location (where the function is used), which I think is more likely. The 'user' of the function is to blame for supplying arguments that caused compilation to fail, rather than the implementation (the '+' operation that the current error message states first). This becomes even more obviously the wrong way to state the error if you assume multiply_and_add_with_constants is a library function - the user might think it is the library's fault that compilation failed. So the error might go like: Error: do_math_things cannot be generated with supplied types: Ta : float32, Tb : float64 ... because multiply_and_add_with_constants cannot be generated with supplied type: Ta : float32 ... because binary operator + gets incompatible argument types float32, float64 It might also make sense to formulate all error messages in the present tense (after all, the error still exists in the program... and then you don't have to think about tenses while writing these, plus it might be a bit easier to read).
43:12 ok, so concepts/traits/etc are extra complexity - but in Rust and Swift they re-used that piece of complexity for 2 purposes: vtable interfaces or generic type bounds; thats' quite neat I think - also consider they'll give you Dot Autocomplete on generic types. But I prefer the C++ proposal because concepts will be optional.. you only use that complexity if it benefits you. Overall I do like the look of the polymorphic functions presented here.. the approach in Rust is a bit too rigid for my liking.
Great demo! 2 questions: Can you #bake a varargs procedure (like e.g. print)? When you #bake a procedure which has a #modify, but you don't specify all the types at the "bake-site", does the #modify not run (since the #modify might not work if only some of the types are known) until the baked procedure gets called (i.e. when we learn about the remaining types)?
I don't entirely agree with using the dollar sign to signify the "authoritative type" in a polymorphic procedure. Because the caller might not be the author of the function, assuming which type is "wanted" might not match the caller's expectation, so you risk being confusing more than if you weren't assuming any authority on the type. E.g. in the multiply_and_add_with_constants, only the type of "a" can be authoritative, because it's the only polymorphic type, so the error message says "wanted 32 bits, got 64 bits". But the matter of fact is that the function will only ever work if you supply 64 bits, so in that sense the caller is the one that "wants" 32 bits, but the function is the one that "wants" 64 bits. Now, since the original premise was for the author of the function to specify type authority, it only makes sense to tell the user what the function, or it's author "wants", not the caller. So "wants" as an expression in the error message conflicts with the original premise of the language design. That confused me immediately when I read the error message.
Ivan Leben Basically, rather than running the risk of the error message being confusing, I would prefer syntactical consistency (which you also seem to value highly), which you'd get if the dollar sign always had to be used for the polymorphic type. Also, in the case of function 'add' at the start of the video, the current error message doesn't give you the identifier of the polymorphic type that was wrong. It just says "number mismatch: X vs Y, wanted this, got that", so you need to figure out yourself *why* is it that one thing is wanted instead of another. I would prefer for the error message to just say "type mismatch in polymorphic type '$T' ... given 'float32' here .... given 'float64' here"
Did you consider baking only some template arguments? Or would you just let the user do this (well actually, this would work for regular baking as well...): f :: (a : $T, b : $F) {...} g :: (a : int, b : $F) {f(a,b);} however that would fail for inner type variables.
Detail: Why would find() take an array, but array_add a pointer to an array? As for the error messages, imo "A versus B" doesn't make it clear which one of the two was actually expected.
37:17 I see you can create (inner) functions with := and ::. Is the second one available before declaration, just like a regular function, while the other works more like a variable? That would make sense.. and then outside of functions, you can only use :: (because that's not executed code).
clankill3r I imagine so. And since *J* appears to be taken already, this could be pronounced just the same without running into legal issues. Of course we could also call it *Blow*, which would allow for rather humorous employment ads.
Isn't "compile time execution" illegal on windows? I've heard somewhere that Windows disallows in it's AGB that a running program generates machine code. Also, will it share the same license as the C++ compiler?
Neon Sturm Compile-time execution does not run machine code currently. But you could do that anyway by writing out a DLL and then dynamically loading the DLL.
What is the real interest of the de-duplication? To save RAM during the compilation stage or more to reduce the number of symbols in the binary (which will speed up the link too)? With pointers on template types can be risky as the function will accept both, values and pointers because if the user doesn't take care multiple implementations will be generated. This could lead to increase heavily the number of symbol the compiler will generate without talking about hidden copies of big struct parameters. Do you planned to add some warning messages if a polymorphic procedures is sometimes called with values and some times with a pointer of the same types?
Compilation speed and binary size. We deduplicate before compiling the body of the procedure, which means we save a lot of work if the procedure is big (or calls other polymorphic procedures, which is probably does).
Jonathan Blow About time speed and binary size, I was wondering if the typeinfo related to the names of enums members is saved in lazy or for every enums even if those typeinfos aren't used. If jai can already be used to build dynamic library, are symbols exported in the C conventions? Or do you have an other convention and maybe a particular runtime?
Find it strange you would pick up on the RL semantics of 'generics' as being problematic, I always associated 'generics' with a programming-only usage, whereas 'generic' is certainly more a real-world english construct.
No, that's a good point. I guess I meant that the brain is increasingly able to contextualize words, but you're right in that, in this scenario, it would create conflicts.
I can't take anyone serious he insists on using emacs or vim or some other unnecessarily complicated editor (that here doesn't even have syntax highlighting)...
huh? An editor is something that you get used to if you used it for a long time. He's already used to emacs and since it's free software it will always be available for years. I would never use a proprietary editor full time, because it can change anytime in future. Let's assume I bought sublime and used it for 2 years and now I am used to it, they changed some feature and now I have to break my flow, may be they decided raise the price, maybe they abandon it. Emacs/Vim survived for 30+ years and they will continue to be so. "Muscle Memory and Habit > Any Feature" I have seen notepad++ users writing faster than vim and vice versa.
Honestly, I prefer the more typical bracket syntax like foo::bar() i.e. types are parameters in a separate section. It's more clear and doesn't have the ambiguity problem like your random function. I think you should revisit the syntax sometime and try to come up with a way that's a clear improvement.
I know you are hesitant to publish the compiler at this early stage but I was wondering if you would maybe agree to dumping all this juicy demo code somewhere (like GitHub for example). I'd really like to be able to look over these at my own pace (I view them as a form of 'language spec' that isn't as dull as a formal language definition).
I was just there, fighting G++ as usual (why can't it even manage includes properly?), and I wished for something better. Then I opened youtube and found a new demo video!
You kind of make my day every time you post these :D Keep up the good work!
Currently learning Python, I am somewhat of a noob, however this video has helped to unlock some of the mysteries I have been having trouble with. Thank you.
very very very simple and nice language
22:30 How about presenting the error in top down fashion instead of bottom up, assuming that the error was made at the very last location (where the function is used), which I think is more likely. The 'user' of the function is to blame for supplying arguments that caused compilation to fail, rather than the implementation (the '+' operation that the current error message states first). This becomes even more obviously the wrong way to state the error if you assume multiply_and_add_with_constants is a library function - the user might think it is the library's fault that compilation failed.
So the error might go like:
Error: do_math_things cannot be generated with supplied types: Ta : float32, Tb : float64
... because multiply_and_add_with_constants cannot be generated with supplied type: Ta : float32
... because binary operator + gets incompatible argument types float32, float64
It might also make sense to formulate all error messages in the present tense (after all, the error still exists in the program... and then you don't have to think about tenses while writing these, plus it might be a bit easier to read).
43:12 ok, so concepts/traits/etc are extra complexity - but in Rust and Swift they re-used that piece of complexity for 2 purposes: vtable interfaces or generic type bounds; thats' quite neat I think - also consider they'll give you Dot Autocomplete on generic types. But I prefer the C++ proposal because concepts will be optional.. you only use that complexity if it benefits you. Overall I do like the look of the polymorphic functions presented here.. the approach in Rust is a bit too rigid for my liking.
Great demo! 2 questions:
Can you #bake a varargs procedure (like e.g. print)?
When you #bake a procedure which has a #modify, but you don't specify all the types at the "bake-site", does the #modify not run (since the #modify might not work if only some of the types are known) until the baked procedure gets called (i.e. when we learn about the remaining types)?
I don't entirely agree with using the dollar sign to signify the "authoritative type" in a polymorphic procedure. Because the caller might not be the author of the function, assuming which type is "wanted" might not match the caller's expectation, so you risk being confusing more than if you weren't assuming any authority on the type. E.g. in the multiply_and_add_with_constants, only the type of "a" can be authoritative, because it's the only polymorphic type, so the error message says "wanted 32 bits, got 64 bits". But the matter of fact is that the function will only ever work if you supply 64 bits, so in that sense the caller is the one that "wants" 32 bits, but the function is the one that "wants" 64 bits. Now, since the original premise was for the author of the function to specify type authority, it only makes sense to tell the user what the function, or it's author "wants", not the caller. So "wants" as an expression in the error message conflicts with the original premise of the language design. That confused me immediately when I read the error message.
Ivan Leben Basically, rather than running the risk of the error message being confusing, I would prefer syntactical consistency (which you also seem to value highly), which you'd get if the dollar sign always had to be used for the polymorphic type. Also, in the case of function 'add' at the start of the video, the current error message doesn't give you the identifier of the polymorphic type that was wrong. It just says "number mismatch: X vs Y, wanted this, got that", so you need to figure out yourself *why* is it that one thing is wanted instead of another. I would prefer for the error message to just say "type mismatch in polymorphic type '$T' ... given 'float32' here .... given 'float64' here"
Did you consider baking only some template arguments? Or would you just let the user do this (well actually, this would work for regular baking as well...):
f :: (a : $T, b : $F) {...}
g :: (a : int, b : $F) {f(a,b);}
however that would fail for inner type variables.
Detail: Why would find() take an array, but array_add a pointer to an array? As for the error messages, imo "A versus B" doesn't make it clear which one of the two was actually expected.
Because find doesn't modify the array, but add does.
37:17 I see you can create (inner) functions with := and ::. Is the second one available before declaration, just like a regular function, while the other works more like a variable? That would make sense.. and then outside of functions, you can only use :: (because that's not executed code).
Thank you for taking the time to edit.
The more I learn about this language, and the more a start talking about it to people, the more I need a name for it. is there idea for that ?
He mentioned this in a previous talk, it's currently called "Jai"
Where does it stand for? Jonathan ...
clankill3r I imagine so. And since *J* appears to be taken already, this could be pronounced just the same without running into legal issues.
Of course we could also call it *Blow*, which would allow for rather humorous employment ads.
Sunil Rao lol Jai sounds ridiculously familiar to Indians. Jai Maata Di!
XD
Yep, I'm pretty sure it's intentional. Looking forward to the details of the language in future lectures.
Isn't "compile time execution" illegal on windows?
I've heard somewhere that Windows disallows in it's AGB that a running program generates machine code.
Also, will it share the same license as the C++ compiler?
Neon Sturm Compile-time execution does not run machine code currently. But you could do that anyway by writing out a DLL and then dynamically loading the DLL.
Do I understand well this is compile-time polymorphism? Are there any plans for run-time polymorphism?
C already had that, it's a struct with procedure pointers on it. We'll be doing the same thing.
What is the real interest of the de-duplication? To save RAM during the compilation stage or more to reduce the number of symbols in the binary (which will speed up the link too)?
With pointers on template types can be risky as the function will accept both, values and pointers because if the user doesn't take care multiple implementations will be generated. This could lead to increase heavily the number of symbol the compiler will generate without talking about hidden copies of big struct parameters. Do you planned to add some warning messages if a polymorphic procedures is sometimes called with values and some times with a pointer of the same types?
Compilation speed and binary size. We deduplicate before compiling the body of the procedure, which means we save a lot of work if the procedure is big (or calls other polymorphic procedures, which is probably does).
Jonathan Blow About time speed and binary size, I was wondering if the typeinfo related to the names of enums members is saved in lazy or for every enums even if those typeinfos aren't used.
If jai can already be used to build dynamic library, are symbols exported in the C conventions? Or do you have an other convention and maybe a particular runtime?
Find it strange you would pick up on the RL semantics of 'generics' as being problematic, I always associated 'generics' with a programming-only usage, whereas 'generic' is certainly more a real-world english construct.
Sure, but you end up using the adjective version all the time. "Generic procedure", "generic data structure", etc.
No, that's a good point. I guess I meant that the brain is increasingly able to contextualize words, but you're right in that, in this scenario, it would create conflicts.
6:57 Why does it say "wanted: s32" in the first but "given: int" in the second?
You lost me on the #modify directive
Can I use this to hack Bill Gates bank account?
I can't take anyone serious he insists on using emacs or vim or some other unnecessarily complicated editor (that here doesn't even have syntax highlighting)...
huh? An editor is something that you get used to if you used it for a long time. He's already used to emacs and since it's free software it will always be available for years. I would never use a proprietary editor full time, because it can change anytime in future. Let's assume I bought sublime and used it for 2 years and now I am used to it, they changed some feature and now I have to break my flow, may be they decided raise the price, maybe they abandon it. Emacs/Vim survived for 30+ years and they will continue to be so. "Muscle Memory and Habit > Any Feature" I have seen notepad++ users writing faster than vim and vice versa.