Use (and Abuse?) of Ada 2022 Features in Designing a JSON-like Data Structure
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Mosteo, Alejandro R.
Ada 2022 is around the corner with many goodies in the form of new features and featurettes. Arguably small syntax sugar additions combine for the programmer's comfort, like for example user-defined literals and container aggregates, that allow natural initialization of user-defined containers with the same expressions used for basic arrays since the beginnings of Ada. In this talk, I discuss how these features allow the initialization of a container data type for heterogeneous values (a-la JSON) without the need of crutch functions (like the usual "+"). Such an structure could be used for compiled-in definitions but, more ambitiously, a relatively simple parser for a strict subset of Ada could leverage this data structure for natural-looking (to the Ada programmer) configuration files. Such configuration files could be useful for tools that are strictly Ada-oriented, written by and for Ada programmers.
 Hello everybody and thank you for being here in this talk in which I would talk about new features in the ADA 2022 revision of the language that lead to more natural looking initialization of data. So normally I would ask you some questions if this were a live presentation, so you are going to have to play in your head, but basically is this a valid ADA initialization and okay there's a trick but we can agree that this is a valid initialization as long as we are using strings of the same length because in ADA, array elements have to have a definite size and also the same size for every element. So this is something that beginners struggle with which is that you cannot have this because your strings are not of the same length and the compiler will not accept this kind of array declaration in which the string is unconstrained. So this leads to the typical workaround which is abusing the class operator for this kind of conversion in which we use another type which is definite as the array element and the conversion is done as I said using this operator. This is normally seen in ADA so it's already part of the culture of the language but it's ugly at least in my opinion, I think nobody likes to do this in purpose. So let's continue with our suppositions and again if I ask you if this is valid ADA, here we have a new string type that is inside the package I'm using for this experiment with this JSON as a joke of the Spanish transliteration of the JSON acronym and okay you can say if I define my string like this or as an array of characters okay this is valid but what if I ask you if this can be done for an irregular private type and here depending on your knowledge of ADA 2022 you will tell me no this is not valid ADA because it wasn't but it's going to be valid and for the record my experiments are done with GNAT 11.2.3 and with this we can achieve this kind of initialization for private types so in turn this means that we can have an array of this type that can be initialized which is private so it's definite although we don't yet know how to do this and I will show you shortly but what if I told you that this can be achieved not for arrays but also for any kind of type also a private type and to achieve this we need a few new features of the language which are coming the forms of aspects and the first one is that for any type you can specify this string literal aspect which in turn binds a function with the initialization in the sense that you will get a call to the specified function with a wide wide string that is any unicode string and then and there you can convert it to your to your type internal information and what about arrays so there is also this new aspect aggregate which has several sub aspects in which for example you can define an append function which will add elements to your container so with these two new aspects indeed you can have the kind of initialization that we were seeing which is this one the string literal takes care of the strings inside the array and the second aspect the aggregate takes care of initializing an array array like data structure is there something similar for maps in which we have keys and values well there it is and instead of the aspect add unnamed we have the aspect add named and here the function has to have this prototype and well with this we are all set to do that and this leads us to the question which is behind this presentation so there are several text formats to represent information for example json with this JavaScript object notation which I must say I think it's not intended for human consumption it doesn't allow commands for example and it's a structure data description well structure to some extent because we can have for example heterogeneous arrays another equivalent representation this time intended for humans is jammer that is jammer and a markup language so we have there an in-joke recursive acronym and we can represent essentially the same information that is different kinds of numbers booleans booleans nested objects and so on then we have tumble which is tom obvious markup language which I must tell you is not that obvious once you get deep nesting in the data structure and as you can see the differences are minimal there are some quotes quotes around that in some cases are necessary in some cases are not anyway the thing is that this got me thinking if I wanted to represent this information in Ada in a natural looking way could I do that with code that looks like this for example so as you can see here you have maps we have vectors we have mixed types oh no and this is the question I'm going to try to answer in this presentation can we achieve this kind of code in new Ada and well just like we saw for initializing strings the first thing that we can clear is that we can do the same for numbers and I think a part of the reasons behind this is that the new big number library which is a standard package in Ada 2022 needs something like this so variables can be initialized without using explicit conversions and just like we have the conversion from a unique code string here a string is enough to represent all digits so that's the difference in the prototype of this function which also is good because it breaks an ambiguity here so my first idea when I knew about these aspects and started to play with Vimis is can I do this so can I have different initializations for the same type with different literals and surprisingly yes this is accepted by the compiler so now we can write this is it a good idea I'm not going to enter into that but basically I can initialize with any of those three expressions and it flies by the compiler so that's like that's a step in the direction we want to to go and the obvious idea next is okay if I can use different initializations for a same type what about different aggregates for the same type so we would have something like this and here the bad news begin because this is rejected by the compiler with a quite precise message pointing me to the reference manual which is something that GINAT doesn't do always so it's like saying okay now you are very wrong and the reason is here in the reference manual so so shame on you and actually if you go to the manual indeed it says that you cannot mix that kind of aspects why well it seems logical not to mix vector like and map like initialization but in this case I don't know why limit me about this I will discuss this a bit later so in conclusion this means that I cannot have just one type for the kind of initialization I'm trying to do at least I have to split the vector and map initialization in two types so with this information I did a first attempt in which we have a basic type or the core type in which we have all the literal initializations and also for example the map initialization and then we have an axi-layer type for the vector initializations and a conversion function that returns the core type from the axi-layer type and with this we are really near our objective because we can have this kind of code which we can have better genius vectors and the only sacrifice is that we have to make explicit that this is a vector and also that those two parenthesis are not optional because in Eda there is a rule that you can omit double parenthesis where there is no ambiguity but he here that would mean that instead of one parameter for the function there are three so this is ambiguous so here you cannot remove that and in the end I didn't like this solution because it has an asymmetry between vectors and maps which is kind of ugly of course you could force map initialization with another axi-layer type still you would have the problem of the two parenthesis anyway so I decided to try to continue looking for another solution so I have another idea which is instead of having a single type can we have a single class I mean a single family of types which belong to the same class and so we have the base class we derive from here for maps with their own initialization vectors with their own initialization as we know and since we are doing this for vectors and maps we can have own types for all the rest of the data types around so we have a bit more of a type checking which is also nicer than what we had just before and well apparently this is working well because we can have initializations for each kind of scalar type if we can call strings scalar in this context a vector with mixed integers and strings but what if instead of using variables I use literals well it turns out that for some reason the user defined literal isn't being it's kicking here to convert the literals so okay this doesn't work I'm not sure if it should work but at present it doesn't work and the thing is that you can give a hint to the compiler and it will properly convert those those literals so I don't know do views well when things like that happen with new features I just try to move things around a bit to work around the compiler and so it is said well let's try to move the literal initializations to the base type which is the first one that the compiler maybe will attempt to to convert to and surprisingly or not this works and now we can have again this kind of mixed vectors maps maps that contain vectors and so next attempt was okay I can use a vector variable but what if I use a vector literal inside another vector or another map and sadly again we hit an error which is that the aggregate cannot be class-wide and this is not anywhere I have seen this before for example in functions that return a class-wide type but I'm looking a bit more in detail what's happening here is a bit contrary intuitive because we know that the only type that can be that expression on top is a vector so it doesn't matter that the placeholder is class-wide because we are using an expression that can only be a vector but I think the compiler is right here because in Ada having a new width cannot change compilation so although right now that's the only possible initialization for that vector maybe in the future we would have other derived types in the same family class that would be really ambiguous about this so right now I'm convinced that this is actually not proper I would like to discuss this with with a language lawyer but anyway again we see that with a hint this will work and as I said I'd like to discuss about this because maybe in this case this should work without ambiguity but anyway things as they are now is that you cannot do that so where do those leave us well I have not been able to solve this this conundrum so right now the best I have is this kind of initialization where you have to make explicit nested initializations for aggregates if they are vectors or maps although for us it's clear that there cannot be ambiguity at least we can get rid in this case right of the double parenthesis that we have before so this would be the current result how is this achieve here we have a summary of all the aspects that are coming together to achieve this there is a exception for booleans there is no support for this kind of initialization but you can get around it because false and true are not reserved words so you can reuse them that's okay and well you see how everything works together to that problem of the aggregate that cannot be class-wide I can see two solutions at the moment one is to discuss if that restriction is really needed because well it's in your hand to make your maps proper maps or proper vectors but maybe in this kind of situation you want to have both initializations and if that is if there's some alternate motive for that decision okay another possibility would be that the aspect could be overloaded this is already done for example for indexing so we can index a container with a numeric index a key for example in a map and as we will see indeed with any other type for example a cursor but here I will leverage this to use paths I will see in a moment but the important thing right now is that this constant indexing with a function name actually refers to three different functions while for the initialization for the append if you try to do this the compiler will silently ignore the all but the last matching function and since in Eda ignoring things silently is not normal I hopeful that this might be an omission that will be working in the future or at least we would get an error that one of those is not being that you have conflicting functions for the aspect because as I say right now only this exists for the kind of aggregate initializations we are attempting now that I have brought up the topic of indexing what if I define this nested vector inside a map and I ask you what's at the position one key second index so it seems clear that the answer should be first them and and by using the constant indexing aspect indeed this works out of the box this returns any class that can be indexed again and internally of course we are checking types so this is safe at runtime but I also thought okay if I have a sequence of indexes indeed I can represent those indexes in a vector and this vector will work for this indexing I mean this opened the possibility of using building indexes dynamically but what happens I try to do that directly in an expression with literals and then this fails there's a catch 22 here I'm not going to go into too much detail but if you have a prototype with accepts and a string that string could be a vector of one element but if you remove that prototype with an string it won't recognize it as a vector with one element so you cannot do both or even if you remove one of the confliction functions so again you can give a hint to the compiler or the solution alternative solution is to again leverage an operator to build an ambiguous expression and this is I have seen this in other libraries I have done this in my own libraries when discussing when using for example file system path which is used the forward slash to denote a path inside a structure so this I think it's a nice solution I don't feel that this is so abusing as the plus operator at this point you may be wondering why I spend so much energy in this kind of trivial thing and well I admit I like to push new features to the limit so why not and the other reason is that well it comes from a layer I in the beginning a layer used a data code to represent releases so in essence I'd like to have a data structure that can be both compiled modified with a compiler or parsed at runtime and I think this could be useful for tools that are to be used by Ada programmers this is not still in the library of course parsing a subset of Ada might be tricky we'll see if this arrives anywhere in conclusion I think that users define literals strict a good balance between runaway implicit conversions on or using the ugly operator all the new aspects come together nicely there is this problem with the aggregate initialization ambiguity we'll see if they're one of the solutions that I discussed making two into the compiler that's all I hope to find the talk interesting and I'm happy to discuss anything with you you we have one question from Jeremy Gosse is there support for JSON schema well no right right now the library is just bare bones the experiments I I have just presented so there is no loading of JSON or any of the other formats although it's an obvious feature that I'd like to have in the future being able to export the same daytime initializing this way to be able to export it to JSON jamal or toml or whatever or well in general that that kind of text representations I had another question personally that I thought about while listening to the talk these aggregates can they be used during elaboration of the program or do they have to wait until after elaboration no I don't think there is any restriction it's just a normal initialization and in fact in in the code in my library most of the initializations that I used to test these new features are performed during the elaboration of the main executable all right we have another question now just a right what other 2022 features are you looking forward let me think a bit well obviously the I was looking forward to the parallelism features the parallel loops and this feature I don't know how to how what's the official name but where you have like two or three blocks of code and you execute them in parallel like do this and this and this and this and the compiler will create for you three short live tasks that don't interact but it's a nice way to to split work into several cores of the CPU I think that the parallelism things are the ones that I was most looking forward to although I have heard that they are not going to be in D NAT at least in the short term and I also like the reduction of containers when you have a collection of elements and you can apply a function to reduce the container to a result those are the features that I the top of my mind I'm looking forward to that's not as interesting but it goes back to the question of elaboration I'm not sure if tasking will be available during elaboration maybe that's a question for later we have another one another question from Fernando are these techniques the ones showed during the presentation currently in use for the ADA TOML package well this package is from I'm not the author and I don't know I don't think so I guess the right now precisely for that package the author would want to have maximum compatibility not to restrict himself to ADA 22 okay maybe the author of ADA TOML I have the name in my head but since I'm trying to answer without delaying I can't it is difficult to answer questions no no let me then we have a very interesting remark from Boyan Petrovic which is not a question I feel that as more aspects like these accumulate in the language standard the more background knowledge is needed for a programmer to understand what is actually happening behind nice syntax at some point my head's going to have no free space yeah I have to comment but before the author of ADA TOML is Pierre Marie the the Rola sorry about about the mental skip and about this yes well the thing I don't like too much about aspects is that when you use a type which has aspects as a formal for a generic you are whipping out the aspects because the aspects don't appear in the generic parameters and so I feel that in some way aspects and generics are not 100% well integrated but this is probably a minor it doesn't come often as a any kind of problem but it's true that we have more and more aspects every time and yes it's really I think that's what you said at the end of your presentation you have to strike a very fine balance between easy for the reader and easy for the writer basically yeah that's true and in some cases the sorry go ahead when you when you write a very complex data structure with nested components or whatnot using all of these aspects it looks like adjacent data structure so it's very legible for the human but then a programmer human looking at this might scrap their head asking themselves what's happening and how all of these get initialized and maybe we'll want to attach a debugger in order to understand how these are executed because it's really not abuse yeah the thing is that for some aspects I think they are very simple to understand for example those aspects to to make initialization for a literal that's pretty straightforward but for example the aspects for iterators are really hard to I mean every time I try to use them I have to go to the basic samples and relearn them every time for clients is not a problem because they just use the aspects and that's okay sorry not the aspects the the data types transparently but for writers is really not so obvious sometimes right again it's a matter of balance historically Ada has struck the balance towards the reader yeah and the thing is that for example with this uh integer literal you can write a universal integer and it will recognize it and use it for the initialization but you cannot use any other variable of an integer type so there's that's the limit there 10 seconds um if anyone wants to join us in the in the back room they can now
 Hello everybody and thank you for being here in this talk in which I would talk about new  features in the ADA 2022 revision of the language that lead to more natural looking initialization  of data.  So normally I would ask you some questions if this were a live presentation, so you  are going to have to play in your head, but basically is this a valid ADA initialization  and okay there's a trick but we can agree that this is a valid initialization as long  as we are using strings of the same length because in ADA, array elements have to have  a definite size and also the same size for every element.  So this is something that beginners struggle with which is that you cannot have this because  your strings are not of the same length and the compiler will not accept this kind of  array declaration in which the string is unconstrained.  So this leads to the typical workaround which is abusing the class operator for this kind  of conversion in which we use another type which is definite as the array element and  the conversion is done as I said using this operator.  This is normally seen in ADA so it's already part of the culture of the language but it's  ugly at least in my opinion, I think nobody likes to do this in purpose.  So let's continue with our suppositions and again if I ask you if this is valid ADA, here  we have a new string type that is inside the package I'm using for this experiment with  this JSON as a joke of the Spanish transliteration of the JSON acronym and okay you can say if  I define my string like this or as an array of characters okay this is valid but what  if I ask you if this can be done for an irregular private type and here depending on your knowledge  of ADA 2022 you will tell me no this is not valid ADA because it wasn't but it's going  to be valid and for the record my experiments are done with GNAT 11.2.3 and with this we  can achieve this kind of initialization for private types so in turn this means that we  can have an array of this type that can be initialized which is private so it's definite  although we don't yet know how to do this and I will show you shortly but what if I  told you that this can be achieved not for arrays but also for any kind of type also a private type  and to achieve this we need a few new features of the language which are coming the forms of aspects  and the first one is that for any type you can specify this string literal aspect which in turn  binds a function with the initialization in the sense that you will get a call to the specified  function with a wide wide string that is any unicode string and then and there you can convert  it to your to your type internal information and what about arrays so there is also this new aspect  aggregate which has several sub aspects in which for example you can define an append function  which will add elements to your container so with these two new aspects indeed you can have  the kind of initialization that we were seeing which is this one the string literal takes care  of the strings inside the array and the second aspect the aggregate takes care of initializing an array  array like data structure is there something similar for maps in which we have keys and values  well there it is and instead of the aspect add unnamed we have the aspect add named and here  the function has to have this prototype and well with this we are all set to do that and this leads  us to the question which is behind this presentation so there are several text formats to represent  information for example json with this JavaScript object notation which I must say I think it's  not intended for human consumption it doesn't allow commands for example and it's a structure  data description well structure to some extent because we can have for example heterogeneous arrays  another equivalent representation this time intended for humans is jammer that is jammer  and a markup language so we have there an in-joke recursive acronym and we can represent essentially  the same information that is different kinds of numbers booleans booleans nested objects and so on  then we have tumble which is tom obvious markup language which I must tell you is not that obvious  once you get deep nesting in the data structure and as you can see the differences are minimal  there are some quotes quotes around that in some cases are necessary in some cases are not  anyway the thing is that this got me thinking if I wanted to represent this information in  Ada in a natural looking way could I do that with code that looks like this for example  so as you can see here you have maps we have vectors we have mixed types  oh no and this is the question I'm going to try to answer in this presentation can we achieve  this kind of code in new Ada and well just like we saw for initializing strings the first thing  that we can clear is that we can do the same for numbers and I think a part of the reasons behind  this is that the new big number library which is a standard package in Ada 2022 needs something like  this so variables can be initialized without using explicit conversions and just like we have  the conversion from a unique code string here a string is enough to represent all digits so  that's the difference in the prototype of this function which also is good because it breaks  an ambiguity here so my first idea when I knew about these aspects and started to play with Vimis  is can I do this so can I have different initializations for the same type with different literals  and surprisingly yes this is accepted by the compiler so now we can write this is it a good  idea I'm not going to enter into that but basically I can initialize with any of those three expressions  and it flies by the compiler so that's like that's a step in the direction we want to to go  and the obvious idea next is okay if I can use different initializations for a same type  what about different aggregates for the same type so we would have something like this  and here the bad news begin because this is rejected by the compiler with a quite precise  message pointing me to the reference manual which is something that GINAT doesn't do always so it's  like saying okay now you are very wrong and the reason is here in the reference manual so  so shame on you and actually if you go to the manual indeed it says that you cannot mix that kind  of aspects why well it seems logical not to mix vector like and map like initialization but in this  case I don't know why limit me about this I will discuss this a bit later so in conclusion  this means that I cannot have just one type for the kind of initialization I'm trying to do at least  I have to split the vector and map initialization in two types so with this information I did a  first attempt in which we have a basic type or the core type in which we have all the  literal initializations and also for example the map initialization and then we have an  axi-layer type for the vector initializations and a conversion function that returns the  core type from the axi-layer type and with this we are really near our objective because we can have  this kind of code which we can have better genius vectors and the only sacrifice is that we have to  make explicit that this is a vector and also that those two parenthesis are not optional because  in Eda there is a rule that you can omit double parenthesis where there is no ambiguity but he  here that would mean that instead of one parameter for the function there are three so this is ambiguous  so here you cannot remove that and in the end I didn't like this solution because it has an  asymmetry between vectors and maps which is kind of ugly of course you could force  map initialization with another axi-layer type still you would have the problem of the two  parenthesis anyway so I decided to try to continue looking for another solution so I have another idea  which is instead of having a single type can we have a single class I mean a single family of  types which belong to the same class and so we have the base class we derive from here for maps  with their own initialization vectors with their own initialization as we know and since we are  doing this for vectors and maps we can have own types for all the rest of the data types around  so we have a bit more of a type checking which is also nicer than what we had just before  and well apparently this is working well because we can have initializations for each kind of  scalar type if we can call strings scalar in this context a vector with mixed integers and strings  but what if instead of using variables I use literals well it turns out that for some reason  the user defined literal isn't being it's kicking here to convert the literals so  okay this doesn't work I'm not sure if it should work but at present it doesn't work  and the thing is that you can give a hint to the compiler and it will properly convert those  those literals so I don't know do views well when things like that happen with new features I just  try to move things around a bit to work around the compiler and so it is said well let's try to move  the literal initializations to the base type which is the first one that the compiler maybe will  attempt to to convert to and surprisingly or not this works and now we can have again this kind of  mixed vectors maps maps that contain vectors and so next attempt was okay I can use a vector variable  but what if I use a vector literal inside another vector or another map and sadly again we hit an  error which is that the aggregate cannot be class-wide and this is not anywhere I have seen this  before for example in functions that return a class-wide type but I'm looking a bit more in  detail what's happening here is a bit contrary intuitive because we know that the only type  that can be that expression on top is a vector so it doesn't matter that the placeholder is class-wide  because we are using an expression that can only be a vector but I think the compiler is right here  because in Ada having a new width cannot change compilation so although right now that's the only  possible initialization for that vector maybe in the future we would have other derived types  in the same family class that would be really ambiguous about this so right now I'm convinced  that this is actually not proper I would like to discuss this with with a language lawyer  but anyway again we see that with a hint this will work and as I said I'd like to discuss about this  because maybe in this case this should work without ambiguity but anyway things as they are now is  that you cannot do that so where do those leave us well I have not been able to solve this  this conundrum so right now the best I have is this kind of initialization where you have to make  explicit nested initializations for aggregates if they are vectors or maps although for us it's clear  that there cannot be ambiguity at least we can get rid in this case right of the double  parenthesis that we have before so this would be the current result how is this achieve here we have  a summary of all the aspects that are coming together to achieve this there is a exception for  booleans there is no support for this kind of initialization but you can get around it because  false and true are not reserved words so you can reuse them that's okay and well you see how  everything works together to that problem of the aggregate that cannot be class-wide I can see two  solutions at the moment one is to discuss if that restriction is really needed because well it's in  your hand to make your maps proper maps or proper vectors but maybe in this kind of situation you  want to have both initializations and if that is if there's some alternate motive for that  decision okay another possibility would be that the aspect could be overloaded this is already done  for example for indexing so we can index a container with a numeric index a key for example in a map  and as we will see indeed with any other type for example a cursor but here I will leverage this to  use paths I will see in a moment but the important thing right now is that this constant indexing  with a function name actually refers to three different functions while for  the initialization for the append if you try to do this the compiler will silently ignore the  all but the last matching function and since in Eda ignoring things silently is not normal I  hopeful that this might be an omission that will be working in the future or at least we would get  an error that one of those is not being that you have conflicting functions for the aspect  because as I say right now only this exists for the kind of aggregate initializations we are attempting  now that I have brought up the topic of indexing what if I define this nested vector inside a map  and I ask you what's at the position one key second index so it seems clear that the answer  should be first them and and by using the constant indexing aspect indeed this works out of the  box this returns any class that can be indexed again and internally of course we are checking types  so this is safe at runtime but I also thought okay if I have a sequence of indexes indeed I can  represent those indexes in a vector and this vector will work for this indexing I mean this  opened the possibility of using building indexes dynamically but what happens I try to do that  directly in an expression with literals and then this fails there's a catch 22 here I'm not going  to go into too much detail but if you have a prototype with accepts and a string that string  could be a vector of one element but if you remove that prototype with an string it won't recognize  it as a vector with one element so you cannot do both or even if you remove one of the confliction  functions so again you can give a hint to the compiler or the solution alternative solution is to  again leverage an operator to build an ambiguous expression and this is I have seen this in other  libraries I have done this in my own libraries when discussing when using for example file system path  which is used the forward slash to denote a path inside a structure so this I think it's a nice  solution I don't feel that this is so abusing as the plus operator at this point you may be wondering  why I spend so much energy in this kind of trivial thing and well I admit I like to push new features  to the limit so why not and the other reason is that well it comes from a layer I in the beginning  a layer used a data code to represent releases so in essence I'd like to have a data structure that  can be both compiled modified with a compiler or parsed at runtime and I think this could be useful  for tools that are to be used by Ada programmers this is not still in the library of course  parsing a subset of Ada might be tricky we'll see if this arrives anywhere in conclusion I think  that users define literals strict a good balance between runaway implicit conversions on or using  the ugly operator all the new aspects come together nicely there is this problem with the  aggregate initialization ambiguity we'll see if they're one of the solutions that I discussed  making two into the compiler that's all I hope to find the talk interesting and I'm happy to discuss  anything with you  you  we have one question from Jeremy Gosse is there support for JSON schema  well no right right now the library is just bare bones the experiments I  I have just presented so there is no loading of JSON or any of the other formats although it's an  obvious feature that I'd like to have in the future being able to export the same daytime  initializing this way to be able to export it to JSON jamal or toml or whatever or well in  general that that kind of text representations I had another question personally that I thought  about while listening to the talk these aggregates can they be used during elaboration of the program  or do they have to wait until after elaboration no I don't think there is any restriction it's  just a normal initialization and in fact in in the code in my library most of the initializations  that I used to test these new features are performed during the elaboration of the main  executable all right we have another question now just a right what other 2022 features are you  looking forward let me think a bit well obviously the I was looking forward to the parallelism  features the parallel loops and this feature I don't know how to how what's the official name but  where you have like two or three blocks of code and you execute them in parallel like do this and  this and this and this and the compiler will create for you three short live tasks that don't interact  but it's a nice way to to split work into several cores of the CPU I think that the parallelism  things are the ones that I was most looking forward to although I have heard that they are not going  to be in D NAT at least in the short term and I also like the reduction of containers when you  have a collection of elements and you can apply a function to reduce the container to a result  those are the features that I the top of my mind I'm looking forward to that's not as interesting  but it goes back to the question of elaboration I'm not sure if tasking will be available during  elaboration maybe that's a question for later  we have another one another question from Fernando are these techniques the ones  showed during the presentation currently in use for the ADA TOML package well this package is from  I'm not the author and I don't know I don't think so I guess the right now precisely for that package  the author would want to have maximum compatibility not to restrict himself to ADA 22  okay maybe the author of ADA TOML I have the name in my head but since I'm trying to answer  without delaying I can't it is difficult to answer questions no no let me  then we have a very interesting remark from Boyan Petrovic which is not a question  I feel that as more aspects like these accumulate in the language standard the more  background knowledge is needed for a programmer to understand what is actually happening behind  nice syntax at some point my head's going to have no free space yeah I have to comment but before  the author of ADA TOML is Pierre Marie the the Rola sorry about about the mental skip  and about this yes well the thing I don't like too much about aspects is  that when you use a type which has aspects as a formal for a generic you are whipping out the aspects  because the aspects don't appear in the generic parameters  and so I feel that in some way aspects and generics are not 100% well  integrated but this is probably a minor it doesn't come often as a any kind of problem  but it's true that we have more and more aspects every time and yes  it's really I think that's what you said at the end of your presentation you have to strike a  very fine balance between easy for the reader and easy for the writer basically yeah that's true and  in some cases the sorry go ahead when you when you write a very complex data structure with nested  components or whatnot using all of these aspects it looks like adjacent data structure so it's very  legible for the human but then a programmer human looking at this might scrap their head asking themselves  what's happening and how all of these get initialized and maybe we'll want to attach a debugger  in order to understand how these are executed because it's really not abuse  yeah the thing is that for some aspects I think they are very simple to understand for example  those aspects to to make initialization for a literal that's pretty straightforward but  for example the aspects for iterators are really hard to I mean every time I try to use them I have  to go to the basic samples and relearn them every time for clients is not a problem because they  just use the aspects and that's okay sorry not the aspects the the data types transparently  but for writers is really not so obvious sometimes right again it's a matter of balance  historically Ada has struck the balance towards the reader yeah and the thing is that for example  with this uh integer literal you can write a universal integer and it will recognize it and  use it for the initialization but you cannot use any other variable of an integer type so there's  that's the limit there 10 seconds  um if anyone wants to join us in the in the back room they can now
ada_2022_json_like_0_1079.png ada_2022_json_like_1080_1271.png ada_2022_json_like_1272_1439.png ada_2022_json_like_1440_2783.png ada_2022_json_like_2784_3287.png ada_2022_json_like_3288_3371.png ada_2022_json_like_3372_3515.png ada_2022_json_like_3516_3599.png ada_2022_json_like_3600_3647.png ada_2022_json_like_3648_5279.png ada_2022_json_like_5280_6383.png ada_2022_json_like_6384_6479.png ada_2022_json_like_6480_6527.png ada_2022_json_like_6528_8075.png ada_2022_json_like_8076_9671.png ada_2022_json_like_9672_11159.png ada_2022_json_like_11160_12011.png ada_2022_json_like_12012_12119.png ada_2022_json_like_12120_13847.png ada_2022_json_like_13848_16007.png ada_2022_json_like_16008_16127.png ada_2022_json_like_16128_17663.png ada_2022_json_like_17664_18503.png ada_2022_json_like_18504_18791.png ada_2022_json_like_18792_19703.png ada_2022_json_like_19704_20147.png ada_2022_json_like_20148_20471.png ada_2022_json_like_20472_20687.png ada_2022_json_like_20688_21419.png ada_2022_json_like_21420_23123.png ada_2022_json_like_23124_26183.png ada_2022_json_like_26184_26423.png ada_2022_json_like_26424_27047.png ada_2022_json_like_27048_35855.png ada_2022_json_like_35856_42839.png ada_2022_json_like_42840_43025.png