also, john can you make another "ideas about a new programming language for games" video. it's almost gonna be 2 years since you made that video and it would be cool to know or recap what things didn't work since that video, what things will stay, and what things will be added in the future, of development, thanks again, for spending your time working on this. everyone is greatly appreciated. and one last thing, it will be cool to have a website for things that were developed in jai, and or a committee to aid in developing very efficient code. if not, thanks anyway take care.
About the situation with the nightmare with $A and $K: Imagine this situation: combined :: (x: $T, f1: (T) -> $U, f2: (U) -> $V) -> V { return f2(f1(x)); } square_and_increment :: (x: $T) -> $U { return combined(x, t => t * t, t => t + 1); } ints := {:int: 1, 2, 3}; for map(ints, square_and_increment) print(it); Let me explain: "combined" takes some value and two functions. It applies the first function to the value and then the second function to the result from the first call and returns that result. The return type of the first function depends on the type of the passed value and the return type of the second function and whole function depends on that. So now you build "square_and_increment": It calls "combined" with that value, a function which squares its argument and a function which increments its argument. This should probably be valid. If I understand this right: If you add the restriction then this code will not compile because the compilation of square_and_increment results in some unfixed generic types which will only be fixed once square_and_increment is passed as an argument to map or called. And only if that pass or call happens in a "non-generic manner". That is: square_and_increment_items :: (array: $T[]) -> R[] { return map(array, square_and_increment); } This would also not compile (which seems weird) because when square_and_increment is passed as an argument the type parameters cannot be fixed (but that's intended in this case).
Have you ever read a proposal by Damian Conway and Ben Werther on a new syntax for C++? Link here: www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
Oh, I am not suggesting fixing C++, but I did find their syntax to be much easier to read than real C++ syntax and didn't know if there would be any ideas you would want to appropriate for Jai
Also about the "type of second return value" problem: what can "type_of" do? Can you just put any expression in the parentheses and the compiler tells you the type of that expression? If so, could you do this?: twoval :: () -> int, string { return 42, "Hello, Sailor"; } figure_it :: (f: () -> ($A, $B)) -> B { a, b := f(); return b; } figured :: type_of(figure_it(twoval)); print("second type is % ", figured); Or possibly something crazy like this, if the "=> arrow lambdas" can have whole bodies (they can in C# btw): figured :: type_of((x => { a, b := x(); return b; })(twoval));
Actually yes, that first option should work fine. I am not sure why I didn't think of just doing that during the demo, except that I get tired after demos and also have a lot to think about!
I may have missed this, but how can you refer to the outer iterateror if you're nesting, say, two levels? Surely the 'it' works in non-nested blocks, but how about the nested ones?
Probably not a very good question, but I have a hard time finding anything about this: is there some sort of schedule you keep for your streams? I'd really like to follow one of your streams but I live in europe so I have to plan ahead a bit (at least, that's what I expect, correct me if I'm wrong).
John can you add a speech to text recognition for commenting code with a shortcut key in jai, if you're too busy, can someone add it to their ide, idk if it's dumb, but maybe it can help make it easier for people comment their code through they're development process, i would do it, but i'm a noob programmer.
This way of accessing the variable $B type by simple calling B is kind of strange to me. I could be wrong, but this did not break encapsulation of the f lambda? Maybe I have a object-oriented mindset, but it would not be better to call a function like get_lambda_return_type(f, 1) to get the second variable type?
Encapsulation has never been a goal of Jai. Plus, it's not encapsulation when the type is part of the interface. Hiding the type wouldn't have any benefit because encapsulation in the sense of "if I modify the internals, it won't break everything else" wouldn't apply there; if you changed the type of a function, you would necessarily have to change every call to that function throughout your code base. Because of the way you can have functions on types, etc. you can even have code that is resilient to changes for the interface of a function specifically because the type is known publicly.
also, john can you make another "ideas about a new programming language for games" video. it's almost gonna be 2 years since you made that video and it would be cool to know or recap what things didn't work since that video, what things will stay, and what things will be added in the future, of development, thanks again, for spending your time working on this. everyone is greatly appreciated.
and one last thing, it will be cool to have a website for things that were developed in jai, and or a committee to aid in developing very efficient code. if not, thanks anyway take care.
About the situation with the nightmare with $A and $K:
Imagine this situation:
combined :: (x: $T, f1: (T) -> $U, f2: (U) -> $V) -> V {
return f2(f1(x));
}
square_and_increment :: (x: $T) -> $U {
return combined(x, t => t * t, t => t + 1);
}
ints := {:int: 1, 2, 3};
for map(ints, square_and_increment) print(it);
Let me explain: "combined" takes some value and two functions. It applies the first function to the value and then the second function to the result from the first call and returns that result. The return type of the first function depends on the type of the passed value and the return type of the second function and whole function depends on that. So now you build "square_and_increment": It calls "combined" with that value, a function which squares its argument and a function which increments its argument.
This should probably be valid. If I understand this right: If you add the restriction then this code will not compile because the compilation of square_and_increment results in some unfixed generic types which will only be fixed once square_and_increment is passed as an argument to map or called. And only if that pass or call happens in a "non-generic manner". That is:
square_and_increment_items :: (array: $T[]) -> R[] {
return map(array, square_and_increment);
}
This would also not compile (which seems weird) because when square_and_increment is passed as an argument the type parameters cannot be fixed (but that's intended in this case).
Have you ever read a proposal by Damian Conway and Ben Werther on a new syntax for C++? Link here: www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
I skimmed it. But I am not that interested in modifications to C++, because it's really the semantics that are the biggest problem.
Oh, I am not suggesting fixing C++, but I did find their syntax to be much easier to read than real C++ syntax and didn't know if there would be any ideas you would want to appropriate for Jai
Also about the "type of second return value" problem:
what can "type_of" do? Can you just put any expression in the parentheses and the compiler tells you the type of that expression? If so, could you do this?:
twoval :: () -> int, string {
return 42, "Hello, Sailor";
}
figure_it :: (f: () -> ($A, $B)) -> B {
a, b := f();
return b;
}
figured :: type_of(figure_it(twoval));
print("second type is %
", figured);
Or possibly something crazy like this, if the "=> arrow lambdas" can have whole bodies (they can in C# btw):
figured :: type_of((x => { a, b := x(); return b; })(twoval));
Actually yes, that first option should work fine. I am not sure why I didn't think of just doing that during the demo, except that I get tired after demos and also have a lot to think about!
I may have missed this, but how can you refer to the outer iterateror if you're nesting, say, two levels?
Surely the 'it' works in non-nested blocks, but how about the nested ones?
You can name them if you want, I just usually don't.
Probably not a very good question, but I have a hard time finding anything about this: is there some sort of schedule you keep for your streams? I'd really like to follow one of your streams but I live in europe so I have to plan ahead a bit (at least, that's what I expect, correct me if I'm wrong).
No.
Aw, too bad.
He usually tweets about it a few days before a stream.
Oh, I didn't know that, that already works for me! Thanks for the heads up
John can you add a speech to text recognition for commenting code with a shortcut key in jai, if you're too busy, can someone add it to their ide, idk if it's dumb, but maybe it can help make it easier for people comment their code through they're development process, i would do it, but i'm a noob programmer.
Any idea of a release time?
Just a question. On the figure_it function, B of $B should be the same as type_of($B)?
No; type_of(B) would be Type.
What is type_of(type_of(B)) then? :^)
This way of accessing the variable $B type by simple calling B is kind of strange to me. I could be wrong, but this did not break encapsulation of the f lambda? Maybe I have a object-oriented mindset, but it would not be better to call a function like get_lambda_return_type(f, 1) to get the second variable type?
Why? the type of the parameters is part of the signature of the lambda
Encapsulation has never been a goal of Jai. Plus, it's not encapsulation when the type is part of the interface. Hiding the type wouldn't have any benefit because encapsulation in the sense of "if I modify the internals, it won't break everything else" wouldn't apply there; if you changed the type of a function, you would necessarily have to change every call to that function throughout your code base. Because of the way you can have functions on types, etc. you can even have code that is resilient to changes for the interface of a function specifically because the type is known publicly.
Are you on Twitch? if so what is your twitch channel called?
+Sam Auciello www.twitch.tv/naysayer88/videos/all ;)
Lambas ( ͡° ͜ʖ ͡°)