On 19 February 2014 23:47, Ján Veselý <[email protected]> wrote:
> On Tue, Feb 18, 2014 at 1:36 PM, Jiří Zárevúcky > <[email protected]> wrote: > > On 18 February 2014 00:28, Ján Veselý <[email protected]> wrote: > >> > >> > >> TLDR: > >> I think a C replacement should be more than one language trying to be > >> perfect and do everything, but rather a collection of languages, one > >> for each domain. > >> > > > > I completely agree. You seem to be implying that what I wrote is trying > to > > be perfect for everything, which is a complete opposite of what I think I > > wrote about. C may be used for everything today, but that does not mean > a "C > > replacement" should be similarly misused. Right now I consider only the > > bottom of the stack -- kernel, drivers and servers around it. Stuff that > > should be able to run with minimum support code and as much provable > > correctness as you can get. > > the point I was trying to make was that even at the bottom of the > stack there is a plenty space for diversity. > to be more specific: the features you proposed would not be of > significant help when writing a usb hc driver, or usb bus driver, or > usbhub. or sb16.* > on the contrary, I would miss almost all the features mentioned by > Martin (fixed types, endian, alignment, ...) > > Just to clarify, those features you mentioned will not be missing. Except that fixed types would have to be an alias to a specific integer range. There is no reason for the language to treat "byte" differently from "range 0..255". If you need wrap-around behavior, you just use a bit mask in one place instead of letting numbers overflow everywhere else. > > > > As for doing anything and everything, I would prefer a single core > language > > with independent domain-specific extensions, than a separate incompatible > > language for every single piece of the system. > > The paper I mentioned shows how the opposite approach, DSL with > connections to existing code, can be beneficial. > Arguably all drivers I worked on are rather simple, so my view is > probably biased, but my point is: ignore drivers, they are not going > to benefit. you can omit all the stuff you'd need to accommodate them, > and design better language for other use-cases. > I think that is kind of short-sighted. I read some of the paper, and you have to consider the problem I solve and the problem the DSL solves. I am aiming for creating a way to express classical programs in a completely type-safe and fault-safe manner (modulo stuff specific for interaction with the underlying machine, which is inherently up to the developer to do correctly). P, on the other hand, solves the problem of expressing the control flow structure of the event handling in a better way than how standard languages express control flow. But that is the only defining characteristic, and you still need to write standard sequential code for every state. In this sequential code, it is rather pointless to use a different language than in the rest of the system. In fact, in my limited knowledge of P, I think that the defining part would be deceptively simple to embed as an extension in an already existing language. The state machine description fragment is a fairly tiny part compared to the rest of the complexity of a programming language, and its function is pretty much orthogonal to any other language feature short of threading support and ordinary control flow statements, both of which you would need or want in some form anyway. TL;DR: Better to assume that drivers (and other parts) will use DSL to generate some of the logic or boilerplate, which is sensible, but this DSL embeds another language to express the actual code, because you shouldn't need many changes there, and creating a complete language from scratch would be more expensive than just writing the original code in the common language.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
