51

Re: The report on Nitra

I>>> Here by the way video showing real development on Ammy https://vimeo.com/198873582 T>> thanks, I at a leisure, can, I will look T>> at council: make an example as this you Ammy is combined with Prism / Navigation API / devExpress Themes, lay out all it on github then it can be will to represent  interest for real enterprise developers I> If fairly, I do not try to attract developers at present. It would not be desirable operation and so , and to put the time in support of Ammy to me. Ammy now is an example of how the correct language for marking UI (in my judgement certainly could look). In practice support.NETStandard as it appeared later than Ammy does not work. For this purpose it is necessary to rewrite , and I do not want to do it. There are defects in studio integration, are not present  VS for Mac. More shortly, infrastructural problems suffice, and to solve them, actually, there is nobody. Well here I about same: When there is any semiready product, is easier with it not to begin at all

52

Re: The report on Nitra

Hello, takTak, you wrote: T> well here I about same: when there is any semiready product, is easier with it not to begin at all Partly agrees. Though I used Ammy in the projects very much and saved a heap of time and nerves. The problem is faster in that that Ammy is not Microsoft, so not future proof. Though and at MS c problems happen it.

53

Re: The report on Nitra

Hello, ionoy, you wrote: I> To me as to the author, it seems that the code on Emmi more readable http://rsdn.org/forum/philosophy/7138070.1 the Author: VladD2 Date: 08.05 00:31 it is possible, but it is an esthetics and it is subjective.  both decisions are equally indicative. Do not perceive it as criticism Ammy, I looked at video, impressed and I do not have ideas as it is possible to make better remaining XAML/C#-. However having normal target language (not C#, a for example N) allowing to write built in DSL, it is not necessary so to do the same. I> But also you are right is, typification  at present is not present. It not absolutely trivial task in view of the architecture  in XAML. But, for example,  after key c convert it is typified completely. Here in docks read that expression in convert it not absolutely C#. Mine  also labels  from meta data viewmodel. I think this not probably from Ammy, but it so,  about Vlad's fairy tales on "seamless integration". I> Now the mode generally went to mold UI in general purpose language. I even for the LiveXAML  similar functionality: https://twitter.com/ionapps/status/993399338255732736 I> But it shows wretchedness XAML as language and unwillingness of the big companies to spend resources on modern language development more likely. I> I all the same would prefer something like Ammy only licked and completely typified. The same example on the Rock though is close by an amount of lines, but adds many unnecessary characters, from which  in eyes. It does not turn out,  it simply is too difficult and expensive in case of a statics. In dynamics it is possible, the same QML, but in a statics of examples simply is not present. I have a possibility to compare two approaches from the point of view of the ultimate user and the big company as I quantize also all these  is not written, and only I use. The head - is not infinite, and UI 10 %-. As an example - till now I do not remember how to write comments in xml. Therefore about "unnecessary characters and ripples in eyes" it for me almost empty place, and here "additional language, the compiler, the bad integration and bugs accompanying them" it is necessary to motivate talks seriously. You do not think and we have fans  the languages for ours  tasks. Only they  which unlike you with Vlad gramatiku/parser to write not in a state, and  the ideas on XML, as MS with , instead of that what to master normal Rock.

54

Re: The report on Nitra

Hello, ionoy, you wrote: I> On http://www.ammyui.com/ there are examples, but in Russia, diligence , a site now .  and Jutrub plow. Give the reference to video.

55

Re: The report on Nitra

Hello, takTak, you wrote: T> well here I about same: when there is any semiready product, is easier with it not to begin at all Here a question in demand. Such as you argue, and do not want to use. If there would be a demand, all could be made. For now at it shot Live XAML. A product a hundred times more simple. But its people buy. More shortly, works  thinking and nonsense. That Ammi went to it someone is necessary with the big PR possibilities. Here then it forces out any , etc. But to the big companies on figs.  and so drips. They put it in a horse-radish knows that but not in similar things.

56

Re: The report on Nitra

Hello, ionoy, you wrote: I> it partly agree. Though I used Ammy in the projects very much and saved a heap of time and nerves. The problem is faster in that that Ammy is not Microsoft, so not future proof. Though and at MS c problems happen it. Microsoft already showed on an example  the nonsense. That that at them does not suffice brains to estimate Ammi or Nitra is besides too most. There people struggle for occupation of a warm place. And on an innovations by it for a long time to spit. Here those who were punched on above, those can drag something. But already also it is not especially necessary for them. Here also take not mind, and .

57

Re: The report on Nitra

Hello, takTak, you wrote: T> T> Literally back to Basics... T> In particular Microsoft Visual Basic (v.6.0).FRM files: T> Evolution is just a spiral indeed. And what?.FRM-files of Vasika were very readable. Where is more readable than that that turned out in VinFormsah. Here  in them did not suffice. Well, and  syntax or brackets is a question of taste and a habit. But, I ask to note.FRM-files of Vasika is too DSL!

58

Re: The report on Nitra

Hello, novitk, you wrote: N> Vlad, at me dab here is wider. On what dab handed over? N> I quite agree that Nitra approaches for handling exterior DSL, including set forth above. Simply I do an emphasis that internal it is much more convenient. For the different tasks, different decisions. For Nitra there is no difference exterior it  or internal. By the way, for many exterior DSL languages of general purpose (such as C#) in itself are embeddable languages.  for example Razor. There C# is the built in language. And so  the approach of Nitra that all languages created on the basis of Nitra and uniform  can be integrated well and simply enough. It is not necessary to select that better exterior or built in. It is possible to do both that and another, the blessing technology allows! N> exterior DSL - worthless integration. In Nitra good integration only with N1. These are your conjectures which perfectly break about same Ammi. And in the same Nitra Nemerl is integrated. It for it also is embeddable language. And Nitra is integrated into projects of Nemerla. Writing the code on Nitra you at once you can use the classes generated on it in Nemerle. Too most works and on the contrary. Now support  for integration of Nitra in Grew dumb and reversely does not work. But it of that Nemerl is not written on Nitra. If it to make, all changes also they seamless will be integrated. N> in QML not XML, and a certain json-similarity with js, but you are absolutely right, typification there misses, as DSL completely exterior and as language was dynamics is taken certainly. But there convenient , instead of poverty from . At you a logical output wildly you limp. You do outputs of untied things. Typification there limps not because is any  in exterior DSL. She there limps because they did not have so powerful tool as Nitra. And to write typification in manual it it is bluntly expensive. Here it there also is not present. For same Kzamla Dzhet Brejs made not the bad typification (in a design time).  there works not badly. A problem of Hamala that projected it so,  there by default not . But it is a problem of design and language implementation, instead of the approach. Communications meanwhile that  exterior and that in it the bad typification - is not present. You from a finger exhaust it. And Nitra just also gives all that is necessary for typification of any languages and for integration of types from DSL in  and is reverse. At all of us it is described by characters. On characters it is possible to create others. We tell on characters of nuclear heating plant then we create the character of classes. And Nemerl starts to "see" classes generated on nuclear heating plant, and on the contrary. As we give an engine of unification and system of dependent calculations. They allow to make typification much easier. And the main thing, all of us do it component and expanded. Any  can expand  language. Whether also to us it will be important it is built in  or exterior. We can both that and another. And all it  also is checked in . N> Because these languages are not suitable for creation DSL. But how helps here Nitra? You will not implement  parser/tipizator for seamless integration. Yes it is fine to you! Forms to describe on both without problems it is possible. The Same author Ammi here now does analog for the code: https://twitter.com/ionapps/status/993399338255732736 And DSL-POSSIBILITIES With ++ are precisely quite good. In difference from different Kotlinov there DSL in compile time are processed. In Sklae macroes have been for this purpose built in. Also check to me they Nemerla come. We made macroes of new generation. They can much more than macroes of Nemerla or the Rock. Practically we achieved the full extensibility . But masses while did not grow before. It is necessary for them that all too most  Microsoft, Google or Eppl. And not simply made, and spoon-fed with a heap of presentations, articles and buffet tables. Here then masses will clap and tell "ah as it fine". For now they walk and criticize what even cannot understand. N> not only, but preferable. IRL all certainly is more difficult. You mistaking. Different tasks demand different lines of thought. The same forms the majority prefer to see in a separate file, instead of in a type DSL TH in a class. And tasks such a heap. N> internal DSL there for N1 that not so . At all did not understand the told. Where it there? And whom ? Nitra is means. You can create not it everything. You can create  and build in it DSL. You can create exterior  and integrate it with  written on Nitra. You can make so that yours  as it was built in in , and on the contrary. And, simultaneously. Restrictions are not present. N> For exterior languages Nitra as I already told, approaches, but I do not know any seamless (with  etc.) Integrations exterior DSL with target language. You is better me know for what Nitra approaches? I as though invented it and implemented. Why to you simply me not to hear and not to cease to sound the conjectures? I am ready to explain any details if it is really interesting to you. And I am responsible for each word. N> I do not have confidence that check of types which you implemented in Nitra strongly helps at implementation of the modern languages with the heaped up type systems, for example such as the Rock or Rast. The parcer on indents as I understand, too is not present. On all time etc. is necessary, but I simply judge about leaking a state and perspectives. At you it is a lot of in what there is no confidence. But at me that it is. I not simply know something on . I it invented all and implemented.  and the Rock is enough not difficult languages in typification. The system of an output of types of Nemerla was development of type system of the Rock. And I studied it up and down as expanded its possibilities. Actually ideas also were scooped from Nemerla. We took idea of usage of unification and stretched it on our system of dependent calculations. The general-purpose decision turned out. A rock, Nemerl also I (think) Rast are made under the old classical circuit of multipass compilation. The nuclear heating plant which it is then typified in some passes on it there is under construction. Makry Nemerla are uncovered during time .  rocks - after it. Makry Rasta (as I understand) before typification. From here  Rasta the most ailing. At Makrosov Nemerla there are lacks, but also the advantages. At Rock macroes too. As a matter of fact the idea of macroes of the Rock was thrown by me. And check to me we invented system which much more cleverly prehistoric multipass circuits. We just also used the DSL-APPROACH in Nitra. In Nitra the nuclear heating plant have so-called Dependent Properties (). They allow to describe calculations locally, on each branch of nuclear heating plant, and then to splice in  all calculations and to receive one correct order of calculations. Further there is a mechanism  and class hierarchy of areas of visibility (Scope) with which help it is possible to describe the most difficult types of areas of visibility easily enough. By the way, the most difficult types of areas of visibility not in the Rock or Raste and as it is not paradoxical, in Sharpe (and, as consequence, in Nemerle). To all to it the unification engine (similar which are used almost in all compilers JAP of types supporting an output, i.e. Haskele, the Rock, etc.) is added . Together it is all gives the general-purpose decision on which basis it is possible to implement any language. The developer needs to describe only language on the basis of our DSL. Certainly, it not the trivial task in case of difficult  like Sharpa, the Rock or Nemerla. But it in tens times is easier, rather than, if it to do from zero manually. And for this purpose it is necessary much less knowledge. We incapsulated this knowledge in Nitra and enveloped them in much more simple in learning the form DSL. N> in general I do not know, fairly. If language + a platform.+ knowledge of Nemerle => on Nitra probably faster. Well, here, and I know. The more difficult language, the it will be easier it to describe on Nitra. It all the same what to write  from zero, using drawing primitives, or to take XAML, QML, Windows. Forms or another . And in case of  still volume of knowledge of the theory not such big. And in the field of development  it reads off scale. 99 % of people do not lift further level of learning BNF and the recursive, condescending parsing. And an output of types for 90 % it is simple  . Here estimate. Author Ammi did not write before the languages. And author NLiquid. Thus at both statically-typed languages turned out. And to it for this purpose it should be studied anything. Author NLiquid wanted even to make dynamics. But I showed to it and proved that with Nitra to create static typification with an output of types, even it will be easier to make. And so it also quitted. Here, an example on NLiquid, a showing output of types. https://github.com/ifle/NLiquid/blob/ma … -else.test {% assign customer = ' kevin ' %} {% if customer == ' kevin ' %} Hey Kevin! {% elsif customer == ' anonymous ' %} Hey Anonymous! {% else %} Hi Stranger! {% endif %} If to replace types in expressions going more low assign, the message on type mismatch will be produced. It, of course, a simple example. But the same essence. N> I investigated into a problematics and anywhere  you did not name. Simply area application and the approach to me does not see perspective. Check to me. You concerned its brown eyes. This hare hole is very deep.

59

Re: The report on Nitra

Hello, novitk, you wrote: N> the Majority writes all at once in the Rock. It quickly. For the sketch can use , but then translate in DSL. The seamless variant when view leads separate life as in XAML, it is possible, but in practice is not claimed. Probably because pure draughtsmen at us are not present.  here not so it is a lot of sense, as without live  to adjust UI it is problematic. Well, here at Ammi live . You start the application and in real time change  describing . You push Ctrl+S and you  is automatically updated taking the data from real objects. On devices it  accelerates development process! Here look itself: https://vimeo.com/198873582

60

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> For simple languages, of course, and built in descends. But what advantages gives built in DSL generally? Tasks different happen. Many  are good in the form of host language extensions. An excellent same example linq. But your opponent, as a whole, is not right. And just because tasks different happen. For Razor and to it similar DSL where embedding  in , than on the contrary is better approaches.

61

Re: The report on Nitra

Hello, novitk, you wrote: N> It is imperative , developed in 80, with badly integrated built in in them a shit-DSL th for the description of requests,  in 60, under title SQL. Well, yes. Language old and not without problems. But here SQL there it is integrated, just, very much even well. And in difference from linq in it  all commands SQL supported SQL Servers, and not just a data sampling subset. Many, because of limitation linq, create stored procedures and cause from business logic therefore as so it turns out more effectively and conveniently.

62

Re: The report on Nitra

Hello, VladD2, you wrote: VD> Well, yes. Language old and not without problems. But here SQL there it is integrated, just, very much even well. Awfully it is integrated. A hybrid  with . Metaprograms are not written as all should be beaten nails (try on Transact-SQL to write the elementary XP which accepts a name of the table and creates its remark), the composition normal is not present etc. VD> Many, because of limitation linq, create stored procedures and cause from business logic therefore as so it turns out more effectively and conveniently. If linq in something it is restricted, it is necessary to expand it. I speak about the approach, instead of about specific implementation under C#. That to XP me once convinced that they are useful to speed of replication when the channel between bases were a shit, but it was hundred years ago. Other favor I in them do not see.

63

Re: The report on Nitra

Hello, novitk, you wrote: N> If ANTLR  there would be on a rock they to unwinding were highlit in VS, Subl and other. If ANTLR grammar were on the Rock it a horse-radish was not highlit by grammar rules, and it would be highlit by Rock rules. And here if grammar ANTLR was on Nitra it would really be highlit and for it there would be full . Besides the rock has syntactic restrictions. You can only  syntax of the Rock, but cannot change it. At a rock, of course, floppy syntax. But also it has the restrictions. Besides I am not assured that in  Rocks it is possible to create types.

64

Re: The report on Nitra

Hello, VladD2, you wrote: VD> Well, here at Ammi live . You start the application and in real time change  describing . You push Ctrl+S and you  is automatically updated taking the data from real objects. On devices it  accelerates development process! Here look itself: VD> https://vimeo.com/198873582 Vlad, well come on! 2018-year on a court yard. Than you want me to surprise? I  do not understand why S the such did not master. In all normal languages for a long time is  and all is certainly adjusted in live directly on built in DSL. At us also WYSIWYG the editor is, which to you DSL inhausts and spits out (truth roundtrip not seamless). Even at C# appeared  under a title C# Interactive, truth only in a hammock on Windows.

65

Re: The report on Nitra

Hello, VladD2, you wrote: VD> For the different tasks, different decisions. For Nitra there is no difference exterior it  or internal. Show me the task where exterior DSL it will be better than internal, except compatibility/legasi support. VD> and so  the approach of Nitra that all languages created on the basis of Nitra and uniform  can be integrated well and simply enough. It is not necessary to select that better exterior or built in. It is possible to do both that and another, the blessing technology allows! Upon it was clarified that WPF-bajnding in Ammy the dynamic. So excuse, but I do not trust you. [A skip "in  all could be abruptly, but is not completed"] VD> At you a logical output wildly limp. You do outputs of untied things. VD> typification there limps not because is any  in exterior DSL. She there limps because they did not have so powerful tool as Nitra. And to write typification in manual it it is bluntly expensive. Here it there also is not present. You at all about that. Here and everywhere under  I understand exceptional  to viewmodel, aka Binding  in XAML or a word "bind" v Ammi, instead of static descriptions of properties  in Nitra. And so this  in QML is made on js and  it dynamic. And a surprise, a surprise on Ammy too! [A skip "in  it is possible as in , but in  it is better"] N>> Because these languages are not suitable for creation DSL. But how helps here Nitra? You will not implement  parser/tipizator for seamless integration. VD> yes it is fine to you! Forms to describe on both without problems it is possible. The Same author Ammi here now does analog for the code: VD> https://twitter.com/ionapps/status/993399338255732736 the Correct approach, only C# is awful. It is necessary N2! VD> And DSL-POSSIBILITIES With ++ are precisely quite good. It is bad, very bad. And you know it. VD> in difference from different Kotlinov there DSL in compile time are processed. In Sklae macroes have been for this purpose built in. Also check to me they Nemerla come. Actually macroes if language is set up under creations DSL are necessary rarely and in the core for speed and accuracy of errors, but the code which I wrote them uses - yes. [A skip " it is abrupt, but anybody does not understand it"] VD> You mistaking. Different tasks demand different lines of thought. The same forms the majority prefer to see in a separate file, instead of in a type DSL TH in a class. And tasks such a heap. No, do not prefer. Simply thought that all will be  in Blend. N>> I do not have confidence that check of types which you implemented in Nitra strongly helps at implementation of the modern languages with the heaped up type systems, for example such as the Rock or Rast. The parcer on indents as I understand, too is not present. On all time etc. is necessary, but I simply judge about leaking a state and perspectives. VD> at you it is a lot of in what there is no confidence. But at me that it is. I not simply know something on . I it invented all and implemented.  and the Rock is enough not difficult languages in typification. The system of an output of types of Nemerla was development of type system of the Rock. And I studied it up and down as expanded its possibilities. Actually ideas also were scooped from Nemerla. We took idea of usage of unification and stretched it on our system of dependent calculations. The general-purpose decision turned out. So Nemerle after all on Nitra too is not implemented. You advertize all time of an implementation detail, but the modern language created on this basis there are no many years. In this time enthusiasts made of a shit and sticks everyones  etc. [a skip "Nitra "] VD> Here estimate. Author Ammi did not write before the languages. And author NLiquid. Thus at both statically-typed languages turned out. And to it for this purpose it should be studied anything. Author NLiquid wanted even to make dynamics. But I showed to it and proved that with Nitra to create static typification with an output of types, even it will be easier to make. And so it also quitted.  and on health. I not here am at war with Nitra, and with exterior DSL.

66

Re: The report on Nitra

Hello, VladD2, you wrote: VD> If ANTLR grammar were on the Rock it a horse-radish was not highlit by grammar rules, and it would be highlit by Rock rules. And here if grammar ANTLR was on Nitra it would really be highlit and for it there would be full . And from what you solved it that I accept your illumination from a box in VS? I can I want to watch grammar on  in 3D. And with my approach I can allow it to myself as at me the heap of free time was released. I after all should not understand with 10  DSL and Nemerle, and to concentrate efforts that is really necessary for me. VD> Besides I am not assured that in  Rocks it is possible to create types. Like is, well at us such things do through compiler plug-ins.

67

Re: The report on Nitra

Hello, VladD2, you wrote: VD> Tasks different happen. Many  are good in the form of host language extensions. An excellent same example linq. But your opponent, as a whole, is not right. And just because tasks different happen. For Razor and to it similar DSL where embedding  in , than on the contrary is better approaches. +1. About Razor th quite good argument, is accepted.

68

Re: The report on Nitra

Hello, novitk, you wrote: N> it is possible, but it is an esthetics and it is subjective.  both decisions are equally indicative. Do not perceive it as criticism Ammy, I looked at video, impressed and I do not have ideas as it is possible to make better remaining XAML/C#-. However having normal target language (not C#, a for example N) allowing to write built in DSL, it is not necessary so to do the same. General purpose languages are good that are general-purpose. But it is necessary to pay for scalability. N> here in docks read that expression in convert it not absolutely C#. Mine  also labels  from meta data viewmodel. I think this not probably from Ammy, but it so,  about Vlad's fairy tales on "seamless integration". Here an example: ` bind convert (MyViewModel vm) => vm. Name ` That it worked engine Ammy should have complete type information MyViewModel, differently then in  it will not be launched. If you about it, certainly. N> it does not turn out,  it simply is too difficult and expensive in case of a statics. In dynamics it is possible, the same QML, but in a statics of examples simply is not present. Ammy as much as possible close comes nearer to that that is necessary. Nitra, by the way, helps with it much. Almost all typification works through its mechanisms. N> I have a possibility to compare two approaches from the point of view of the ultimate user and the big company as I quantize also all these  is not written, and only I use. The head - is not infinite, and UI 10 %-. As an example - till now I do not remember how to write comments in xml. Therefore about "unnecessary characters and ripples in eyes" it for me almost empty place, and here "additional language, the compiler, the bad integration and bugs accompanying them" it is necessary to motivate talks seriously. It agree - nobody wants to learn a modern language, especially if it rarely use. But development UI is for 30 % of time much almost from the general operation. For such people optimization can bring essential advantages. Generally, I for the present am in a hover concerning this dispute. Recently added  code update in LiveXAML, and now I think as though this business to use for more scale purposes. Including meta-frejmvork, working atop Xamarin Forms, but with UI in the code. Can and turns out to make something digestible, we look.

69

Re: The report on Nitra

Hello, novitk, you wrote: VD>> And so  the approach of Nitra that all languages created on the basis of Nitra and uniform  can be integrated well and simply enough. It is not necessary to select that better exterior or built in. It is possible to do both that and another, the blessing technology allows! N> upon it was clarified that WPF-bajnding in Ammy the dynamic. So excuse, but I do not trust you. N> [a skip "in  all could be abruptly, but I am not completed"] already answered above, but it seems to me quitted . bind Name convert (string name) => "Hello," + name In this case Name will not be . A problem that this property Name can come from the arbitrary source, such as model, UI, exterior type, and generally everything. In  cases we can learn type, in others are not present. At first I made two variants, one typified where it was necessary to specify manually model type, and the second not typified when the model is not specified. It worked, but the code turned out , and I wanted to finish to release faster. Therefore simply commented out functionality and left this part . Expression after a keyword convert is typified completely because I for it should construct model of the code and to send with each update, to launch in .

70

Re: The report on Nitra

Hello, ionoy, you wrote: I> In this case Name will not be . A problem that this property Name can come from the arbitrary source, such as model, UI, exterior type, and generally everything. In  cases we can learn type, in others are not present. At first I made two variants, one typified where it was necessary to specify manually model type, and the second not typified when the model is not specified. It worked, but the code turned out , and I wanted to finish to release faster. Therefore simply commented out functionality and left this part . At me  is not present. The model description is only in C# and access to it at Ammy is not present. It is necessary:) model beforehand to push in the assembly and  from there  with Roslyn and studio c) to implement the C# on  All difficult and inconveniently. With internal DSL-om such problems are not present.

71

Re: The report on Nitra

Hello, novitk, you wrote: N> At me  is not present. The model description is only in C# and access to it at Ammy is not present. It is necessary: N> model beforehand to push in the assembly and  from there It it is made. N> c) to implement the C# on  And it. N>)  with Roslyn and studio And it is not present, but it is necessary. # too quickly develops.

72

Re: The report on Nitra

Hello, ionoy, you wrote: N>> At me  is not present. The model description is only in C# and access to it at Ammy is not present. It is necessary: N>> model beforehand to push in the assembly and  from there I> It is made. You absolutely tangled me. That is in  type check  is? N>> c) to implement the C# on  I> And it. Is C# front-end on ? N>>)  with Roslyn and studio I> And it is not present, but it is necessary. # too quickly develops. c) also are not confused? To take Roslyn and to set it on the code it is represented to me much easier than support of the parallel compiler.

73

Re: The report on Nitra

Hello, novitk, you wrote: I>> It is made. N> you absolutely tangled me. That is in  type check  is? As I also wrote above, after a word bind checks of type are not present, because there not always property obviously whence comes. It was possible to make, but I decided to simplify to myself the task. After convert type check is, for example expression convert (MyVM vm) => vm. FirstName + "" + vm. LastName it will be completely typified, just as it does the compiler . Here  loading types from assembly https://github.com/AmmyUI/AmmyUI/blob/m … nBackend.n It on , and generally, a bit clumsy, but works. Truth it does not work now with.NETStandard and it is necessary to pass on Roslin. Then and source codes at the same time . N>>> c) to implement the C# on  I>> And it. N> is C# front-end on ? Yes. But support 7  there already is not present. It quitted later, and these had nobody to be engaged. The parcer here https://github.com/rsdn/nitra/tree/mast … rp.Grammar Typification here https://github.com/rsdn/nitra/tree/mast … DotNetLang N>>>)  with Roslyn and studio I>> And it is not present, but it is necessary. # too quickly develops. N> c) also are not confused? To take Roslyn and to set it on the code it is represented to me much easier than support of the parallel compiler. When it was written Ammy, Roslyn yet there was no in that state in which it now, therefore has been decided to use the Nitrovsky engine. Now I would be not against to rewrite  on Roslin, but it is considerable volume of operation.

74

Re: The report on Nitra

Hello, ionoy, you wrote: I> As I also wrote above, after a word bind checks of type are not present, because there not always property obviously whence comes. It was possible to make, but I decided to simplify to myself the task. At us it is specified explicitly, i.e. "Label () <- vm.hello". I suspect that  in Ammy grows from WPF, not? I> It on , and generally, a bit clumsy, but works. Truth it does not work now with.NETStandard and it is necessary to pass on Roslin. Then and source codes at the same time . I in this direction would dig, but  the support price will be all the same strong more expensively the built in variant.

75

Re: The report on Nitra

Hello, novitk, you wrote: I>> As I also wrote above, after a word bind checks of type are not present, because there not always property obviously whence comes. It was possible to make, but I decided to simplify to myself the task. N> at us it is specified explicitly, i.e." Label () <- vm.hello ". I suspect that  in Ammy grows from WPF, not? Yes. In WPF it is possible to specify a source . Normally it is representation model, but can be and something like" 6 element above on a tree ". In that case or to ask the developer to specify explicitly member type, or to refuse typification absolutely. I>> It on , and generally, a bit clumsy, but works. Truth it does not work now with.NETStandard and it is necessary to pass on Roslin. Then and source codes at the same time . N> I in this direction would dig, but  the support price will be all the same strong more expensively the built in variant.  it is easy enough to use. But some architectural decisions there, on mine, strange. For example to receive the information on the character, you cause compilation. GetSymbolInfo transferring interesting you SyntaxNode in parameter. The character returns or not, you do not know until then will not try yet. I would prefer GetSymbol extension method directly on most  to remove this ambiguity. But as a whole from Roslina at me good impressions.