1

Topic: The report on Nitra

6th were read by the report on Nitra. Not high, but like it is possible to disassemble quality of record. https://www.youtube.com/watch?v=JdHD9har8YA

2

Re: The report on Nitra

3

Re: The report on Nitra

Hello, Kolesiki, you wrote: K> And still, Nitra is a lockup. Amusing  which complexity does it absolutely . Irrespectively all remaining, Nitra is very convenient and simple enough in usage. I as the grateful user tell it. Very much it would be desirable, that a product finished to release. (And here Nemerle-2 what for is necessary or own C# - mind I will not put).

4

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> (And here Nemerle-2 what for is necessary or own C# - mind I will not put). As what for that on it to rewrite Nitra

5

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> Irrespectively all remaining, Nitra is very convenient and simple enough in usage." It is simple ", you speak?... When you read the beginning, there all  - rules, output agents, all classically (and even there a heap of quotients of"ideas"over classical PEG). But then such horror which, is assured begins, will be absolutely not accompanied concentrate of thought which comes on a thousand fraction of a second after an hour nirvana. So should not be - we solve or any not that task, or any not in such a way. _> (and here Nemerle-2 what for is necessary or own C# - mind I will not put). And what for Nitra is necessary? To write in " gave birth to a parcer, grew up nuclear heating plant-tree "? Just Nemerlja-to also is necessary to EVERYTHING that it is easy to write  programs. Nitra is necessary to a narrow circle of experts which can be set for one beer little table. I think, the failure of ZhetBrynzy is connected to it and from Nitra - it is too abstract and far from" a product which can be sold ". Yes  there to sell... To UNDERSTAND it is already a call to a brain! -2 (On my representations) should become "correction of mistakes" which we did not make. But ideologically - the full repetition of Nemerly-1. But in a heat "we destroy to , and then", Vlad ran into the abstract jungle and instead of one solid step, made "a jump in eternity" that not only is premature, but also basically it is not especially useful." The designer of compilers "? Seriously?? ONE successful compiler on the company - already  wines, and practically is not present those. The designer of such scale is not simply monstrously difficult in implementation, but even in usage. And considering""designing of Nitra, it only multiplies complexity and inability of" high layers of programmers " modern languages. Therefore I am absolutely assured in 1) "designer"(that it turned out SIMPLE, powerful and floppy) 2) Necessities of a rewriting of Nemerli-1. Eventually, to CREATE the COMPILER - too the enormous task to which can be proud! And to make its successful - generally a jump in the history annals. And to mold clumsy, purely academic horses in vacuum - well... I would not become.

6

Re: The report on Nitra

Hello, Kolesiki, you wrote: K> When you read the beginning, there all  - rules, output agents, all classically (and even there a heap of private "ideas" over classical PEG). But then such horror which, is assured begins, will be absolutely not accompanied concentrate of thought which comes on a thousand fraction of a second after an hour nirvana. So should not be - we solve or any not that task, or any not in such a way. And what was specific horror? On mine dsl  easily and to write and read, and auxiliary Nemerle not too it is a lot of code for rather simple languages. K> and what for Nitra is necessary? To write in  "gave birth to a parcer, grew up nuclear heating plant-tree"? Personally to me - for rapid development DSL with which are convenient for using. From conveniences Nitra gives to me, as to the developer, besides a parcer, convenient means for typification and binding, and also for  not only syntactic, but also logical errors. Well and on an output - high-level model with which  much easier to work, than from nuclear heating plant on an output of traditional parcers. Nitra first of all gives to users, besides, high-grade error messages (that is the complete list of clear errors, instead of "at you the wrong character on such line, and further I not "), and support IDE (here that to mind to finish). On mine it is a lot of.

7

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> On mine dsl  easily and to write and read I yet do not see an abundance "" even against the last upstarts of type Go/rastov. Probably, something stops them... Me here - an abundance of these of all details and  all process. I willingly believe that the most necessary has been imported only, but it does not mean that it has been imported optimally or that has been imported to a proper place. As the private example, XAML - that in C# becomes in one refined line, in the declarative form turns to an unreadable verbiage. Certainly, now you will tell that "XML to read easily and conveniently", but here  it is not convenient!  is the most irritating part XAML which precisely fastened " was", instead of for the sake of convenience. With Nitra I feel similarly: like also I understand that in the given place in another way - in any way, but as it stands it is far not the best variant. K>> and what for Nitra is necessary? To write in  "gave birth to a parcer, grew up nuclear heating plant-tree"? _> Personally to me - for rapid development DSL with which are convenient for using. This teenage, itself recovers! You realize that introduction in the project even ONE . Language, moreover and "", it is the whole epopee with support, training, consistency, etc.? There is no in that a merit that you can "easily rivet hundreds DSL - a merit in managing one everywhere where it is optimal. Concern languages as to normal, linguistic concepts: introduction in Russia the Spanish language - is far not the most simple task and with program languages the same. _> on mine it is a lot of. TOO MUCH. It is obvious that  the minimum on the order will be always more difficult than a specialized thing. I am ready to sacrifice some"usefulness"of Nitra in favor of its simplification. Unfortunately, I can not show right now where and that - here it is necessary to dive into a subject for a week a minimum. But that fact that Nitra can is difficult even not so much, how many is bulky. As self-modular furniture - mind you understand that in hands - the right armrest, but 15 holes of the different size say what to fasten its two screws it will not be possible! Here absolutely exact analogy of that I feel to Nitra. I.e. I understand separate high concepts of type AST, parsing tree, binding, but behind Nitro-syntax all thoughts sink. And still I am convinced that "designer"  is not necessary to us, neither from an IT position, nor with .. Business. Imagine "designer" in space world: to whom is the designer of the ships necessary?? It is an individual thing which collect with a specific goal. To do the general-purpose robot, capable to mount any detail of any device... Yes you kill at meeting! With Nitra is not easier at all, even despite it "" - large, senseless swing on one more "is unnecessary", which unique task - to write on it other language which it "is already necessary". Sense??  and so CONCEPTUALLY ABOVE any language - it is enough of it that even an average hand the expert could use easy it and even to refine a little. For me a charm of Nemerli not that I can write ten DSL, and in an internal power when it is possible to work out one stable "adverb" and to use all command. And not to wait yet for everyones Vshlippertov with their justifications and to create language constructions how should be, instead of as Hindus  solved, leaning against the backward business principles. Here. Children, you go to success, but already it is time to skip, instead of to harness a horse in a yet not assembled pedal cart.

8

Re: The report on Nitra

Hello, Kolesiki, you wrote: K> Bajndingi is the most irritating part XAML which precisely fastened " was", instead of for the sake of convenience. Here you also got. Nitra it even not easily manages, and with Nitra on another.... <<RSDN@Home 1.3.110 alpha 5 rev. 62>>

9

Re: The report on Nitra

Hello, Kolesiki, you wrote: K> I yet do not see an abundance "" even against the last upstarts of type Go/rastov. Probably, something stops them... From what? From implementation Go/Rust on Nitra? For whom and what for it could be necessary? K> you realize that introduction in the project even ONE . Language, moreover and "", it is the whole epopee with support, training, consistency, etc.? I too so am able: hiring of ONE . The programmer it is the whole epopee with a workplace, training, the salary, etc. But same the demagogy, always is pro and contra. DSL should be simple - then both training is trivial, and support demands minimum expenditures of labor, and implementation DSL slightly differs from library implementation. K> Concern languages as to normal, linguistic concepts: introduction in Russia the Spanish language - is far not the most simple task and with program languages the same. Please. Two plus two equally four. Conveniently? Or all the same it is necessary DSL? DSL it is necessary - as glue for interaction between systems, as the interface of nontrivial systems for , as a modeling tool, as embeddable toolkit for others DSL and general purpose languages. But DSL demands instrumental support, differently from the decision it turns to a problem. Nitra provides this support. K> TOO MUCH. It is obvious that  the minimum on the order will be always more difficult than a specialized thing. I am ready to sacrifice some "usefulness" of Nitra in favor of its simplification. What for to sacrifice. Certainly, it is necessary to simplify usage. Well so the project at all  still, resources, obviously, no. K> Here. Children, you go to success, but already it is time to skip, instead of to harness a horse in a yet not assembled pedal cart. Just in case, I have no relation to a command of Nemerle and Nitra, and I speak only on its own behalf.

10

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> DSL it is necessary - as glue for interaction between systems, as the interface of nontrivial systems for , as a modeling tool, as embeddable toolkit for others DSL and general purpose languages. _> but DSL demands instrumental support, differently from the decision it turns to a problem. Nitra provides this support. Nitra  it is is specific for DSL, as exterior DSL in itself very inconvenient piece. /QML demonstrates limitation of such approach - normal integrations with target language to do very difficult. The correct way - LINQ, that is seamless integration into target language. Therefore  common languages on which internal DSL to do conveniently - in the speaker core, but there is also a statics, type of the Rock/haskelja or same Nemerle. That before usage of Nitra for creation of data general programming languages as it actually and  (N2), that here  to it from a box the functional is too small (is not present  for JVM/LLVM/nativa) and it is inconvenient (it is necessary.NET and Nemerle).

11

Re: The report on Nitra

Hello, novitk, you wrote: N> Nitra  it is is specific for DSL, as exterior DSL in itself very inconvenient piece. /QML demonstrates limitation of such approach - normal integrations with target language to do very difficult. The correct way - LINQ, that is seamless integration into target language. Therefore  common languages on which internal DSL to do conveniently - in the speaker core, but there is also a statics, type of the Rock/haskelja or same Nemerle. At first area of applicability built in DSL much more already areas of applicability exterior DSL. Built in DSL - not a variant if one of following conditions is fulfilled at least: 1) it is required  in some target languages (or usage by several languages) 2) DSL-scripts represent exterior in relation to application resources (automation, modeling, etc.) 3) target language gives it is possible to continue too restricted possibilities of metaprogramming and this list easily. Secondly, I again do not understand, what is offered alternative XAML. The code on C# and VB? Seriously? XAML it is not ideal, but to express marking UI on C# is very strange idea. It is added: N> normal integrations with target language to do very difficult we Take at random some examples DSL: SQL, reStructuredText, ANTLR grammar, google protobuf, lua (for application automation), configs of the apache. What the quoted phrase in a context of usage of these languages means?

12

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> At first area of applicability built in DSL much more already areas of applicability exterior DSL. Built in DSL - not a variant if one of following conditions is fulfilled at least: _> 1) it is required  in some target languages (or usage by several languages) _> 2) DSL-scripts represent exterior in relation to application resources (automation, modeling, etc.) _> 3) target language gives too restricted possibilities of metaprogramming If speech about  MS the need forced it. It is necessary to use suitable languages and DSL will turn out good. _> and this list it is possible to continue easily. Unconditionally. If it is restricted  will be . _> Secondly, I again do not understand, what is offered alternative XAML. The code on C# and VB? Seriously? XAML it is not ideal, but to express marking UI on C# is very strange idea. Here analog WPF on built in DSL for . Syntax selection, autocompletion, debugging and other works from a box in normal IDEA. object TextTestApp extends UiExampleApp {val tte = TextTestEntity () def mainGui = gui {Window (_.title: = "Text Properties Test", _.renderAsPage: = true) {Grid (_.columns: = 2) {Text (_.enabled <- tte.enabled, _.readOnly <- tte.readOnly, _.span: = (2, 1), _.numOfVisibleLines <- tte.numLines, _.tag: = "testText", _.tooltip: = tte.tooltip, _.hotKeys: = Seq (HotKey (_.key: = Key. F1)-> tte.sayGoodbye _)) <- tte.text Label (_.span: = (2, 1), _.tag: = "testTextStatus") <- tte.text1 Button (_.text <- tte.text2, _.tag: = "toggleText")-> tte.toggleEnabled Button (_.text <- tte.text3, _.tag: = "readWriteText")-> tte.toggleReadOnly Button (_.text: = "More Lines", _.tag: = "moreLinesBtn")-> tte.moreLines

13

Re: The report on Nitra

Hello, novitk, you wrote: _>> At first area of applicability built in DSL much more already areas of applicability exterior DSL. Built in DSL - not a variant if one of following conditions is fulfilled at least: _>> 1) it is required  in some target languages (or usage by several languages) _>> 2) DSL-scripts represent exterior in relation to application resources (automation, modeling, etc.) _>> 3) target language gives too restricted possibilities of metaprogramming N> If speech about  MS the need forced it. It is necessary to use suitable languages and DSL will turn out good. At first Kolesiki for some reason resulted XAML as an example of lacks of Nitra, and now XAML the pattern is answerable for all exterior DSL. What for the logician such - exterior DSL are not necessary, because XAML it is not necessary? No, speech not about XAML. I in the last message added (probably too late) list DSL exterior by the nature (instead of because someone built in DSL did not master) for an example - SQL, reStructuredText, ANTLR grammar, google protobuf, lua (for application automation), configs of the apache. N> here analog WPF on built in DSL for . Syntax selection, autocompletion, debugging and other works from a box in normal IDEA. N> N> object TextTestApp extends UiExampleApp {N> val tte = TextTestEntity () N> def mainGui = gui {N> Window (_.title: = "Text Properties Test", _.renderAsPage: = true) {N> Grid (_.columns: = 2) {N> Text (N> _.enabled <- tte.enabled, N> _.readOnly <- tte.readOnly, N> _.span: = (2, 1), N> _.numOfVisibleLines <- tte.numLines, N> _.tag: = "testText", N> _.tooltip: = tte.tooltip, N> _.hotKeys: = Seq (HotKey (_.key: = Key. F1)-> tte.sayGoodbye _) N>) <- tte.text N> Label (_.span: = (2, 1), _.tag: = "testTextStatus") <- tte.text1 N> Button (_.text <- tte.text2, _.tag: = "toggleText")-> tte.toggleEnabled N> Button (_.text <- tte.text3, _.tag: = "readWriteText")-> tte.toggleReadOnly N> Button (_.text: = "More Lines", _.tag: = "moreLinesBtn")-> tte.moreLines N> I can Easily understand and partly divide criticism XAML, but when alternatively - here such something is difficult even to object. However, we forget even about syntax. How to implement exterior toolkit of type Blend? Yes at least the visual editor with it works? And if suddenly yes that happens when I in it a mouse will change the size of the button?

14

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> Is not present, speech not about XAML. I in the last message added (probably too late) list DSL exterior by the nature (instead of because someone built in DSL did not master) for an example - SQL, reStructuredText, ANTLR grammar, google protobuf, lua (for application automation), configs of the apache.  it is not necessary it is all! In sense it certainly is necessary for  and compatibility but if you now language for requests of basis did what for to you a hand-made article from 60 under title SQL? Make model describing requests, tie it API, on top add DSL for expressiveness. N>> here analog WPF on built in DSL for . Syntax selection, autocompletion, debugging and other works from a box in normal IDEA. _> I can Easily understand and partly divide criticism XAML, but when alternatively - here such something is difficult even to object. And what not so that? It more shortly, more expressively, more compactly also does not demand knowledge of special syntax. Where you see lacks? _> how to implement exterior toolkit of type Blend? Yes at least the visual editor with it works? Is, but primitive. It is possible to outline, save, translate a sketch in DSL.  there "do not play" certainly, as well as in Blend but if very much it would be desirable to separate the designer from the programmer they can be added  from the code. _> and if suddenly yes that happens when I in it a mouse will change the size of the button? You DSL  confuse to serialization. It only in  this one and too as normal DSL on C# not to make. DSL it for people, to the computer it without need.

15

Re: The report on Nitra

Hello, novitk, you wrote: _>> Is not present, speech not about XAML. I in the last message added (probably too late) list DSL exterior by the nature (instead of because someone built in DSL did not master) for an example - SQL, reStructuredText, ANTLR grammar, google protobuf, lua (for application automation), configs of the apache. N> Dak is not necessary it is all! It is necessary, certainly. Also it is everything, and many other things. N> in sense it certainly is necessary for  and compatibility but if you now language for requests of basis did what for to you a hand-made article from 60 under title SQL? Make model describing requests, tie it API, on top add DSL for expressiveness. Even if so (I argue because it agree, that is why that to irrelevantly considered subject) this DSL all the same should be . Otherwise value of basis aspires to zero. I remind, a post above you reproached with Nitra (which and is as a matter of fact exterior DSL) absence  under JVM. N> And what not so that? It more shortly, more expressively, more compactly also does not demand knowledge of special syntax. Where you see lacks? It not more expressively and still as demands knowledge of special syntax. At me blood from eyes from all these is>, <-, _. Etc. But the main problem not in it, and what this DSL is beaten by nails to Scala, and XAML is not present, and is used in a heap of languages, tools and platforms (see for example https://www.noesisengine.com/) _>> And if suddenly yes, that happens when I in it a mouse will change the size of the button? N> you DSL  confuse to serialization. It only in  this one and too as normal DSL on C# not to make. DSL it for people, to the computer it without need. These people want, that the same form could be edited as in the visual editor, and manually. As causes a choice exterior DSL. And "normal" DSL on Scala this problem does not solve. And to tell the truth, on this argument I simply did not understand your objection. Your sight seems to me too radical, and I awkwardly feel, resulting trivial arguments in protection of things which seem me obvious and self-evident. Therefore, yours faithfully to your position, I nevertheless leave  dispute

16

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> Even if so (I argue because it agree, that is why that to irrelevantly considered subject) this DSL all the same should be . Give nevertheless we define criteria.  the main criterion is clearness and efficiency. What gives to you ? I Pay attention that portability here is orthogonal. Model,  through  DSL which you saw saw, it is possible to use directly from normal  or other jvm-language or through serialization in semblance XAML (at us json, but not an essence). You did not lose absolutely nothing. And now on the contrary with exterior DSL? You lost type-checking. To you it is necessary code-behind. At you the assembly and complexity became complicated. You cannot use means  in the DSL. _> Differently value of basis aspires to zero. Basis here at all at what. The question costs so: you want to glue a SQL-line or to use LINQ? The answer  is unambiguous. Here similar for regex http://imaginatio.github.io/REL/, but at bare regex though there is an advantage of compactness. _> I remind, a post above you reproached with Nitra (which and is as a matter of fact exterior DSL) absence  under JVM. It is different aspect. It is a question only of comparing of a current functional with other toolkit for creation exterior DSL. For example ANTLR supports a heap . Only it is not necessary to me to tell that in  there is a heap of a functional which is not present in  - I in course. Simply if you create for example Rast most likely  from Nitra to you it will be not necessary, and here the parcer  and ANTLR can be used, and with  . N>> And what not so that? It more shortly, more expressively, more compactly also does not demand knowledge of special syntax. Where you see lacks? _> it not more expressively and still as demands knowledge of special syntax. At me blood from eyes from all these is>, <-, _. Etc." Special "syntax here only the operator" <- "/"-> "/" <-> "which describe , but  it is obvious. All remaining a normal rock. N>> you DSL  confuse to serialization. It only in  this one and too as normal DSL on C# not to make. DSL it for people, to the computer it without need. _> these people want, that the same form could be edited as in the visual editor, and manually. As causes a choice exterior DSL. And"normal"DSL on Scala this problem does not solve. And to tell the truth, on this argument I simply did not understand your objection. Once again XAML it  not DSL. It is a format of serialization of object model WPF. People do not want to correct it hands, but they simply do not have alternative. Not so long ago Vlad here advertized the tool created by means of Nitra for creation something more digestible which it is possible to name already dsl th with translation in .

17

Re: The report on Nitra

Hello, novitk, you wrote: I hardly have time to track hands, but courses, fortunately, are written down. I remind a context, there is arguing SQL. _>> Even if so (I argue because it agree, that is why that to irrelevantly considered subject) this DSL all the same should be . N>... XAML... And here XAML again? _>> differently value of basis aspires to zero. N> basis here at all at what. The question costs so: you want to glue a SQL-line or to use LINQ? The answer  is unambiguous. To begin with I simply want to fulfill at any time request and to receive result. For this purpose my basis should support language of requests. We name it YASQL. Sometime I will start to write application on C#, and, perhaps, I will want to use LINQ. LINQ and YASQL - languages not mutually exclusive, but complementary. And in what LINQ  request - in YASQL or still in what is minor for the user an implementation detail. N> For example ANTLR supports a heap . Only it is not necessary to me to tell that in  there is a heap of a functional which is not present in  - I in course. Simply if you create for example Rast most likely  from Nitra to you it will be not necessary, and here the parcer  and ANTLR can be used, and with  . It too is written down: _>> I in the last message added (probably too late) list DSL exterior by the nature (instead of because someone built in DSL did not master) for an example - SQL, reStructuredText, ANTLR grammar, google protobuf, lua (for application automation), configs of the apache. N> Dak is not necessary it is all! So it is necessary or it is not necessary? Now it is possible and about XAML. N> Once again XAML it  not DSL. I will remind that the first your post in this subject began with the statement about inconvenience and uselessness exterior DSL, and as an example have been resulted XAML and QML. It is necessary to be defined. N> Model,  through  DSL which you saw saw, it is possible to use directly from normal  or other jvm-language or through serialization in semblance XAML (at us json, but not an essence). You did not lose absolutely nothing. On it I in the third time say that I lost possibility to edit a marking as hands, and in the visual editor in a design time. XAML to me this possibility gives, and its any lacks (besides it is basic ) do not justify this loss. And it is absolutely unimportant, whether you consider thus XAML for DSL or not. N> People do not want to correct it hands And here this dsl marking in the Rock - want?

18

Re: The report on Nitra

Hello, meadow_meal, you wrote: N>> Basis here at all at what. The question costs so: you want to glue a SQL-line or to use LINQ? The answer  is unambiguous. _> to begin with I simply want to fulfill at any time request and to receive result. For this purpose my basis should support language of requests. We name it YASQL. Why not to use LINQ in repl target language? As an example in Mongo it is used JS. The absolutely same approach in modern  systems: gradle, sbt, scons... N>> For example ANTLR supports a heap . Only it is not necessary to me to tell that in  there is a heap of a functional which is not present in  - I in course. Simply if you create for example Rast most likely  from Nitra to you it will be not necessary, and here the parcer  and ANTLR can be used, and with  . _> So it is necessary or it is not necessary? There are 2 independent theses: In an ideal exterior DSL are not necessary if to use the modern target language, but sometimes without them in any way from for  and practicalities If to compare toolkit on creation of the full language infrastructure (exterior DSL or the general ) Nitra has not enough trumps in comparison with competitors, for example ANTLR. A above about b). N>> Once again XAML it  not DSL. _> I will remind that the first your post in this subject began with the statement about inconvenience and uselessness exterior DSL, and as an example have been resulted XAML and QML. It is necessary to be defined. There is some duality.  as language of serialization UI of model it  as DSL is not present. _> On it I in the third time say that I lost possibility to edit a marking as hands, and in the visual editor in a design time. Unconditionally, but I repeat ours  allows to use and , as in XAML. Simply at us is also normal DSL with , helps etc. And in WPF it is not present. What approach is Below described benefits upon. N>> people do not want to correct it hands _> And here this dsl marking in the Rock - want? 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. Our approach is not unique. Look on React, there in JSX it is made as.

19

Re: The report on Nitra

Hello, novitk, you wrote: N> Why not to use LINQ in repl target language? There is no target language. At me the basis is installed, both all. And the functional from creation of tables and roles before review of plans of requests is necessary to me. Both automation possibility. And stored procedures. And possibility to send the code to the colleague, without receiving in the answer "and at me target language another". N> As an example in Mongo it is used JS. Yes, therefore at requests of Mongo without tears you will not look. N> there are 2 independent theses: N> In an ideal exterior DSL are not necessary if to use the modern target language, but sometimes without them in any way from for  and practicalities N>) If to compare toolkit on creation of the full language infrastructure (exterior DSL or the general ) Nitra has not enough trumps in comparison with competitors, for example ANTLR. About b) it is clear, though I and I hold opposite judgement (binding, typification and support IDE against possibility to compile on JVM? Yes what to me a difference than to compile?). And here about a) is not present. How to use ANTLR without it DSL? And if you want it to build in target language in what it is is specific? Markdown and analogs where we build in, or it too not DSL, we eliminate? Language of a configuration of the apache, a squid and similar is difficult-configured products? protobuf and thrift which in essence should generate the code under a heap of languages and platforms - where we build in? N> the majority writes all at once in the Rock. It quickly. For the sketch can use , but then translate in DSL. Here this moment is not clear. How translate? And what for? N>  here not so it is a lot of sense, as without live  to adjust UI it is problematic. For this purpose there is a design time the data.

20

Re: The report on Nitra

Hello, meadow_meal, you wrote: N>> Why not to use LINQ in repl target language? _> there is no target language. At me the basis is installed, both all. And the functional from creation of tables and roles before review of plans of requests is necessary to me. Both automation possibility. And stored procedures. Horses, people mixed up in a heap. Target language at you and now is - it is called TransactSQL, PL/SQL, PG/SQL and .. Only it  on comparing even with JS, not to mention C# or especially to the Rock. Earlier necessity of it spoke that that SQL in a C badly climbs that was unconditional truth, but it is full  from the point of view of the modern FP/metaprogramming and LINQ to that an example. On what to write the built in procedures depends only on presence of a platform of their spelling at the server. In PG like it is possible to write them on the Python and Java. _> and possibility to send the code to the colleague, without receiving in the answer "and at me target language another". Agree with it about target language for an exchange. Or use any queryrepl on a js/python delivered . N>> As an example in Mongo it is used JS. _> Yes, therefore at requests of Mongo without tears you will not look. And me , we and it do not use At us and here native DSL which works in  if it is necessary to look at something and in IDE with  and . N>>) If to compare toolkit on creation of the full language infrastructure (exterior DSL or the general ) Nitra has not enough trumps in comparison with competitors, for example ANTLR. _> About b) it is clear, though I and I hold opposite judgement (binding, typification and support IDE against possibility to compile on JVM? Yes what to me a difference than to compile?) . Couple of years the parcer of simple formulas (excel like) for a product on  back was necessary to me. Would be at   in jvm, I it can and considered, and so good-bye. Made on ANTLR. _> And here about a) is not present. How to use ANTLR without it DSL? And if you want it to build in target language in what it is is specific? That's just the point that DSL  antlr  it is not necessary. Simply it is made on  Java where built in DSL it is impossible. On the Haskele/rock where there is a mad amount of different parcers and other to anybody and in a head would not come such to do. Would write in target language in DSL-e seasoned on taste macroes and other. It is possible even in "semipoor" pluses, look  . _> Markdown and analogs where we build in, or it too not DSL, we eliminate? Certainly, absolutely foolish not expanded approach. All should be on the contrary, look React JSX, TeX for example I etc. Want to renew all from the Arabian numbering on a Latin, and functions that and are not present. There would be it in a python/js there would be no problems. _> language of a configuration of the apache, a squid and similar is difficult-configured products? If all is simple, DSL is absolutely not necessary. To do deserialising of a config of model from xml/json/yaml enough. Nitra will be . If all can be difficult, DSL unconditionally it is better to do in target language. So are for example made a configuration of build-systems of type gradle. _> protobuf and thrift which in essence should generate the code under a heap of languages and platforms - where we build in? +1. Here it is possible yes. But matter is not in "to a heap of languages and platforms" - the generator from model will be absolutely identical, and that similar DSL on  can and concede in that on that convenience that is. It is necessary ! N>> the Majority writes all at once in the Rock. It quickly. For the sketch can use , but then translate in DSL. _> Here this moment is not clear. How translate? And what for? From  it is possible to generate DSL on . Works certainly only in one side. N>>  here not so it is a lot of sense, as without live  to adjust UI it is problematic. _> for this purpose there is a design time the data. At us it is possible to make too most, but without the full dynamics of model it  suits only on the sketch.

21

Re: The report on Nitra

Hello, novitk, you wrote: N> Target language at you and now is - it is called TransactSQL, PL/SQL, PG/SQL and .. It DSL, built in basis. Yes, now is. You suggested to remove (or to replace on REPL Rocks? I am not assured that understood correctly). All right, SQL replace in adjacent  so here I grazed. N> that's just the point that DSL  antlr  is not necessary. Simply it is made on  Java where built in DSL it is impossible. N> on the Haskele/rock where there is a mad amount of different parcers and other to anybody and in a head would not come such to do. Would write in target language in DSL-e seasoned on taste macroes and other. It is possible even in "semipoor" pluses, look  . For simple languages, of course, and built in descends. But what advantages gives built in DSL generally? Lacks - 1) I cannot use the same grammar in different languages 2) built in DSL most likely there will be dirtier (I can not forget "_." In a petroglyphic markup language) 3) it is impossible (or it is depreciated, since the same ANTLR is spread to some orders more widely, than any DSL Rocks) creation of the general-purpose tools working with DSL of grammar, type such: https://marketplace.visualstudio.com/it … ode-antlr4 _>> Markdown and analogs where we build in, or it too not DSL, we eliminate? N> it is finite, absolutely foolish not expanded approach. All should be on the contrary, look React JSX, TeX for example I etc. Want to renew all from the Arabian numbering on a Latin, and functions that and are not present. There would be it in a python/js there would be no problems. As what for in a python? I want  to edit, instead of on a python . TeX - same DSL, only it is more difficult. JSX how much I understood, solves other task, the documentation on it do not write. _>> language of a configuration of the apache, a squid and similar is difficult-configured products? N> if all can be difficult, DSL unconditionally it is better to do in target language. So are for example made a configuration of build-systems of type gradle. Build-systems - the bad example. There programmed scenarios of the assembly are set. Crash of such scenario - a regular situation. The product of type of the apache demands, actually, a configuration, and to function with  a configuration is not capable (and  is easier the data, than the program). That is the conditional Python it is possible to build in, but it is senseless and even it is harmful, as a config potentially formatting a disk, it is not necessary. _>> protobuf and thrift which in essence should generate the code under a heap of languages and platforms - where we build in? N> +1. Here it is possible yes. But matter is not in "to a heap of languages and platforms" - the generator from model will be absolutely identical I do not understand that it means. If I download a file of the protocol and I compile it under dozen languages this protocol is exterior DSL already on usage method. Attempts to make its correct code on the Rock are deprived sense. N>>> the majority writes all at once in the Rock. It quickly. For the sketch can use , but then translate in DSL. _>> Here this moment is not clear. How translate? And what for? N> From  it is possible to generate DSL on . Works certainly only in one side. That is works once, the further editing is impossible. But same congenital defect, it is simply impossible to correct it. And here type safety in XAML (or analog) it is potentially possible to add, and syntax  to change for more digestible - too.

22

Re: The report on Nitra

Hello, meadow_meal, you wrote: N>> Target language at you and now is - it is called TransactSQL, PL/SQL, PG/SQL and .. _> It DSL, built in basis. Yes, now is. 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. For example despite the full presence of means (DDL,  returning meta data, cursors etc.) Writing of the elementary metaprogram (basis replication, etc) represents space complexity, as toolkit at all . I suggest to use  the modern toolkit which it is identical  to all scenarios. _> you suggested to remove (or to replace on REPL Rocks? I am not assured that understood correctly). I do not insist on the Rock, but yes for support/working out service is necessary interactive . Unconditionally ipython or even any box repl is much better than sqlplus and other misunderstanding, is finite at a condition that they have LINQ. _> it is fine, SQL replace in adjacent  so here I grazed. There in the core about speed of execution, I am exceptional about ergonomics and expressiveness. _> but what advantages gives built in DSL generally? _> lacks - _> 1) I cannot use the same grammar in different languages Agree, only not clearly what for it can be necessary. _> 2) built in DSL most likely will be dirtier (I can not forget "_." In a petroglyphic markup language) It is possible to make  so simply autocompletion you receive free of charge. Besides it is an idiom in the Rock. _> 3) it is impossible (or it is depreciated, since the same ANTLR is spread to some orders more widely, than any DSL Rocks) If ANTLR  would be on a rock they to unwinding were highlit in VS, Subl and other. _> as what for in a python? I want  to edit, instead of on a python . _> TeX - same DSL, only it is more difficult. You in course that in Those are macroes and generally it Turing-complete? I too want, but to study the next language of 60 desires was not present. Therefore give to me  markdown in a wrapper! N>> if all can be difficult, DSL unconditionally it is better to do in target language. So are for example made a configuration of build-systems of type gradle. _> build-systems - the bad example. There programmed scenarios of the assembly are set. Crash of such scenario - a regular situation. The product of type of the apache demands, actually, a configuration, and to function with  a configuration is not capable (and  is easier the data, than the program). Then it is a simple situation and the normal standardized markup language with it to consult. Special DSL/Nitra - it is not necessary. _> that is the conditional Python it is possible to build in, but it is senseless and even it is harmful, as a config potentially formatting a disk, it is not necessary. Here it is is specific CPython not a successful choice as with safety there seams, but it is a problem of is exceptional given implementation. js for example no it has. _>>> protobuf and thrift which in essence should generate the code under a heap of languages and platforms - where we build in? N>> +1. Here it is possible yes. But matter is not in "to a heap of languages and platforms" - the generator from model will be absolutely identical _> I do not understand that it means. If I download a file of the protocol and I compile it under dozen languages this protocol is exterior DSL already on usage method. Attempts to make its correct code on the Rock are deprived sense. It means that you will download IDL and  which creates to you proxies/stubs for any language. Certainly all  for all will it is written in this case jvm, but they and are now written on one platform as the parcer was written exactly in one language. _> but same congenital defect, it is simply impossible to correct it. And here type safety in XAML (or analog) it is potentially possible to add, and syntax  to change for more digestible - too. If all it to add at you completely integrated system,  internal DSL turns out.

23

Re: The report on Nitra

Hello, novitk, you wrote: _>> 1) I cannot use the same grammar in different languages N> Agree, only not clearly what for it can be necessary. For example, to take ready: https://github.com/antlr/grammars-v4 Or to give to indirect developers grammar of own language in standard enough format. _>> 2) built in DSL most likely will be dirtier (I can not forget "_." In a petroglyphic markup language) N> It is possible to make  so simply autocompletion you receive free of charge. Besides it is an idiom in the Rock. So-so justifications. _>> 3) it is impossible (or it is depreciated, since the same ANTLR is spread to some orders more widely, than any DSL Rocks) N> If ANTLR  would be on a rock they to unwinding were highlit in VS, Subl and other. There more than syntax highlighting. Also  grammar. N> you in course that in Those are macroes and generally it Turing-complete? Also what, TeX ceases to be DSL from it? N> then it is a simple situation and the normal standardized markup language with it to consult. Special DSL/Nitra - it is not necessary. Certainly consults, only anybody thanks does not tell. That domain specificity is lost. For an example follow the elementary example of a file of a zone from here: https://www.tldp.org/HOWTO/DNS-HOWTO-7.html also try to write down it on JSON or XML. Simplicity of reading and editing, as manual and machine (in particular  a punctuation and a context, and  on sed or awk - still pair of excellent examples exterior dsl - any more ) is lost. N> Here it is is specific CPython not a successful choice as with safety there seams, but it is a problem of is exceptional given implementation. js for example no it has. Well change formatting for an infinite loop, changes nothing. Yes even the error report will already anchor to row number a problem. N> it means that you will download IDL and  which creates to you proxies/stubs for any language. Truly, and I once again will repeat that it does IDL DSL exterior on usage method. Attempt to make its correct code on the Rock - your personal, is more to nobody necessary, a call. _>> but same congenital defect, it is simply impossible to correct it. And here type safety in XAML (or analog) it is potentially possible to add, and syntax  to change for more digestible - too. N> If all it to add at you completely integrated system,  internal DSL turns out. Internal/built in DSL is DSL, being correct syntax in target language and compiled by the compiler of this language. So is not present. XAML on the former it will be compatible at least with C# and VB. Besides, while I can edit a subject in Blend and load it in  from an exterior resource - this DSL remains exterior on usage method.

24

Re: The report on Nitra

Hello, novitk, you wrote: N> Nitra  it is is specific for DSL, as exterior DSL in itself very inconvenient piece. /QML demonstrates limitation of such approach - normal integrations with target language to do very difficult. Tell you you do not see logical errors these lines? Well, how it is possible to prove any examples "" something? And generators of parcers, CSS, Markdown, HTML, LaTeX, Liquid? They as in your "theory" it is inscribed? And the main thing! How worthless integration DSL th can justify application  which is just created for good integration? Sounded XAML and QML from that also are ugly that their authors instead of creation of readable syntax decided to use XML, and in absence something comparable with Nitra washed down  typification of these . And at all thus programmers prefer to describe UI on XAML and QML, instead of  the similar code on C# and a C ++. N> the Correct way - LINQ, that is seamless integration into target language. Aha. Only one way! N> Therefore the Consequence from incorrect premises on determination is insignificant. N>  common languages on which internal DSL to do conveniently - in the speaker core, but there is also a statics, type of the Rock/haskelja or same Nemerle. And on surprising coincidence, Nitra just also it is intended for creation of such languages. And it gives both means of seamless integration exterior, and internal DSL. N> That before usage of Nitra for creation of data general programming languages as it actually and  (N2), that here  to it from a box the functional is too small (is not present  for JVM/LLVM/nativa) and is inconvenient (is necessary.NET and Nemerle). The generator if it is based on such high-level abstractions (by the way, DSL) as Java byte code, LLVM or.Net MSIL is insignificant enough code amount in the compiler. The compiler master code is made by check of types and resolution of names. Simply include logic. On what to create  easier. In general purpose language, writing all stages of compilation manually, or on means which does not give only the last stage. Well, and in plans was to cover and it. A problem only that such project is the extremely difficult for developing the for-fan. On it money is necessary. They now are not present. And so would be both code generation, and macroes for any language and expanded versions Nemerle, C# and everything another. Technologies allow. Well, and such as you simply want to criticize that in what not especially understand. It how to criticize politicians controlling the huge country or developers of space vehicles. To tell "" and it "is not necessary" always is easier, than even simply to investigate in .

25

Re: The report on Nitra

Hello, meadow_meal, you wrote: _> At first area of applicability built in DSL much more already areas of applicability exterior DSL. And I do not understand what for them to oppose. Just in Nitra we made so that the difference in creation exterior and built in DSL is not present. And problems of integration with languages of general purpose Nitra too solves. So here there is nothing to argue. It is possible to do both that and another. For built in it will be necessary to create on Nitra language in which these DSL to be built in. And further them will do in times easier than exterior. But also exterior will be integrated with host-language very qualitatively. _> Secondly, I again do not understand, what is offered alternative XAML. The code on C# and VB? Seriously? XAML it is not ideal, but to express marking UI on C# is very strange idea. It agree. And the alternative is already created on the same Nitra is Ammy language (http://www.ammyui.com/ the site temporarily knocks). _> we Take at random some examples DSL: SQL, reStructuredText, ANTLR grammar, google protobuf, lua (for application automation), configs of the apache. What the quoted phrase in a context of usage of these languages means? Here is still more ridiculous. Just Nitra on away eliminate a problem integration exterior DSL. But it for it also criticize, citing as an example  on  hml-shaped freaks.