Demo with Run-Time Type Information / introspection / reflection / whatever you want to call it. Application to variable-argument functions and serialization.
Good stuff as always. Some observations/comments: 1) The varargs thing is nice, but it should be possible to strongly type it and say that you only want varargs of a certain type. And in those cases you should be able to pass them both as varargs, but also as a precomposed array. Passing arguments of unmatching types should cause a compile error. Example: func :: (a : float, vectors : ..Vector3[]) {}. 2) Notes (annotations, really) would benefit a lot by being strongly typed and defined in the code. So rather than strings they should be some user defined complex type. Like a struct. Then one could use the struct type info for storage and introspection of it. Then the compiler would find typos and other mistakes. The same mechanism could also be used then to signal things to the compiler via built in notes with parameters. For instance it could look something like this:@HelloWorld(a: 2.4, b: "stuff") or simply @HelloWorld(2.4,"stuff"). C#, for instance, have strongly typed "attributes" which you can define yourself or use built in. The compiler is also aware of some of them and can act on them (for instance you can do struct member memory offsets using attributes to create unions). 3) All Type_Info would benefit in terms of simplicity if they had a friendly name that you can easily print without casting. Like typeInfo.name. Not just for structs as it seems to be now. 4) Many languages use "typeof()" rather than "type_info()". Probably good to follow that convention. Is also close to C's "sizeof". Also faster to type and looks more visually pleasing. 5) Rather than having to check the "Any" if it is a struct at runtime in the field_by_name() demo there should be a way to limit the acceptable type at compile time and get an error if not matching. get_field could be defined somewhat like this: get_field :: (thestruct : Any(struct), name : string) {...}. Same problem in the serialize example.
1) how is the dynamic Array -- which is of variable length anyway -- different from strongly typed vararg? 4) typeof seems to be only usable in an if statement where the typeof() function returns a true/false; whereas type_info() returns an actual struct full of information.
Serge Ratke 1) The difference is that you can enforce a certain type at compile time. Like you have a function that takes a variable number of vectors for instance. The current varargs takes any types in a mixed array, so you need to validate each member. 4) typeof in most languages returns actual type info. Actually I don't know of any language that returns a bool for that. Some languages do have an "is" or "isKindOf" keyword, but that is not what I'm talking about. typeof() will in most languages return type info or atleast the name of the type. Not a bool. Just like type_info() does in this example. It is a small thing, but I just would like it to be renamed to what most other languages call it.
Fredrik Malmer 1) uhhmm, foo := ( vectors: [] Vector3 ) does actually what you are asking for. it is of variable length and the values have to be of Vector3
Fredrik Malmer 4) well again, the name of a function is quite important to convey its purpose. typeof() suggests that it'll return the type -- not the info for the type. type_info on the other hand does what it suggests. furthermore, there's no such thing as a convention to retrieve meta data. c++ has no such thing called typeof d has something that is called typeinfo javascript has typeof so, meh
Serge Ratke 1) Yes, but can you call it in a varargs fashion? foo(v1, v2, v3)? The demo doesn't make it clear if you can. It would make sense if there was an easy way to mark the last argument of a method as supporting varargs type calling. Such as adding those two dots in front of the type. 4) Well there might not be a convention, but typeof is the the only one I can find in more than one language for that kind of feature (go, c#, javascript for instance). And it is similiar to C's sizeof, which I assume this language will also have eventually. It was a minor observation, and really nothing that is very important either. I just felt that type_info was a bit too long. Not remotely worth having a debate over. The language's syntax will probably change a lot before it is done anyways. My thoughts on "notes" are of more importance to me than the name of a keyword.
everything that can help to debug, understand what is going on, helps a lot in a young language without a debugger. not only introspection, but some simple functions that dump data and meta to the screen can go a long way. that's the way people "debug" Go programs even today.
One of my tests I like to use to see if a language is "too strict for me" is how easy and short it is to write a json parser from scratch (that doesn't cheat and use eval or an existing tool or something). I have a feeling Jai is going to do well.
@@suneelfreimuth396 Python and JavaScript. Although since I wrote that I've started using C++ for the sake of performance. In fact I recently wrote a quick and dirty json parser in C++. It took about 50 times more effort than it takes in Python or JavaScript, but. that's the price of performance I guess.. until we have Jai maybe.
I'm loving this language already and will be trying it out as soon as it will be available. It is already better than C and nearly better than C++! + The notes system is awesome. I can already see many uses for this! (skeletal animation (joints and weights) and many more!) + Const Pointers would be useful but then you have the C "problem" of the difference between `const type *` and `type * const` and how to declare it. ? I noticed that some if statements used `then` in some cases and not is others. I thought the `then` was for single lined statements but it seems that you can just remove it. Wouldn't it be better to just remove the `then` keyword all together? + In C++, most of the time, I have a struct/class with a variable that I want to read_only but read_write by the structs methods/friend functions. I know a method could be used (getVar()) and I know of some hacks in C++ that can do this (const type& x = m_x;) but this isn't really a solution as it creates a pointer in the struct; thus increasing its size by sizeof(pointer). ? I remember you saying something about parameterized types (e.g. std::vector, std::map, etc.). How will (and if) you implement this? Or will you make dynamic arrays and maps/dictionaries as standard type (like in Go)? In C++, a map is implemented as a std::vector of a std::pair (2 parameterized/templated types). + In some game projects that I have done, I have used an entity component-like system. This makes it easy to extend an entity to include rendering, physics, ai, etc. with just a component. This however requires either flags or virtual methods. Using flags (C-like) is very cumbersome. Using Single Inheritance simplifies the problem but requires virtual methods. This may not be the best approach as it's kind of requires OOP (which is never really needed nor helpful in most cases) and by the looks of it, this language will never need. + (Not really that important but) Would it not be better to use: @ to get the address, * for a pointer and to dereference (non-English keyboards), and $ for notes. (Again this is just not really that important.) ? What is the size of an array? sizeof(array) = number of elements * sizeof(type); sizeof(array) = number of elements * sizeof(type) + sizeof(u64);? On another note, have you seen the C library libCello? libCello is a library that introduces higher level programming to C such as duck typing, interfaces, constructors/destructors, exceptions, and more just by hacking C a lot!
In C#, for example, a common pattern is to associate a class with another class using attributes. That way you could do something like [myEditor(typeof(BlaEditor))] class SomeClass {} Which is useful in some situations Now you could still do something like that with notes ... but it's kind of nice to have compile time syntax checking. It should also make it possible to be able to stuff like IDE refactoring later on. With strings that wouldn't be possible (or at least very hard). Also typos. Perhaps instead of having strings you could supply a readonly/'const' string or a method that returns a string? for example: @mymethod(someparams, typeinfo(bla)) @myReadonlyString @"myHardcodedString" If you represent notes as a data structure (like C#) instead of a string it would probably make it easier to work with on the reflection side though
Wrt serialization: would you be able to serialize a struct definition, send it over to another process, and have that process reconstruct the struct definition locallly? That would avoid having to compile the struct definition in explicilty in the other process - leaving issues aside with handling that dynamic type.
This Any wrapping business seems to go diametrically against the spirit of leveraging compile-time execution. We take information available during compilation and repackage it to use at run-time. I guess it was a bit greedy to expect some sort of code generation/transformation facilities at this stage. In my dream language printf with constant format string magically becomes a sequence of writes and statically typed lexical casts. Oh, one day.
One thing that's bothering me is the two 'type' in 'any.type.type' - I think from previous videos we could use 'using' to pull the second type so we could just write 'any.type' that would look nicer me thinks or maybe rename one of the types so 'any.type.id' or 'any.info.type' or something like that.
^pointers, 8-bit clean strings, RTTI, ALGOL-like syntax, build options in source code, fast compilation, Delphi alright :) it's sad that Delphi was a commercial product and it was only known by the database/corporate people, and then it died, and nobody else knows how superior it was to C/C++
that doesn't mean that your language will not be better than Delphi, it already is in many ways, and you probably won't sell it to MS for a cold mil $ either, so don't take this the wrong way :)
Hi Jon, What happens if you store the address of one of those constants in your function taking a varargs array that has no way of knowing that it's looking at a constant? Or for that matter what happens even if it's not a constant? Who then has ownership of that memory? What about the array that you're implicitly creating, when is that freed given that you think GC is such a bad idea? Thanks.
Jonathan Blow C-up local references solve this problem, although I sense you don't think it is one. Have a look at www.c-up.net if you're interested - I don't mind if you borrow the idea :-) Either way, it's good to see you enjoying designing a language so much - it is an incredibly positive experience and I'm enjoying sharing it with you.
with varargs, wouldn't test :: (s: string, args : [] Any) work just as well? .. you could then also have strong typed varargs by doing something like test :: (s: string, args: [] string) ... no extra syntax necessary?
@@homelikebrick42 Assume it‘s a stack-allocated struct of size „10 ints“ (whatever), that‘s clearly larger than a void-pointer. Are you saying that the void pointer points to the beginning of the struct and a safe cast (using type-info at runtime) will make sure you can access all other fields of the struct in a safe way? Bonus question: what if you return an „Any“ from a function where it was created and then try to cast it later on? The struct it is referring to would be destroyed in the meantime.
I program in C# all the time, and have been for years. It pays an enormous price for an introspection system that is big, slow and painful to use. This is way better imo.
