Dependable Software by Design [sciam.com]

Pragma ericanderton at yahoo.removeme.com
Mon Sep 11 10:52:07 PDT 2006


Lionello Lunesu wrote:
> A must read:
> 
> http://www.sciam.com/article.cfm?articleID=00020D04-CFD8-146C-8D8D83414B7F0000&sc=I100322 
> 
> 
> The obvious question is: could some of the features of Alloy (the app 
> mentioned in the article) be included in D / DMD?
> 
> L.

This was news to me, so I went looking for the project mentioned in the 
article.  Why don't these news pieces ever link anything directly?

http://alloy.mit.edu/

Technically, D already has some of these features built in.  Namely, 
in/out/body and invariant sections provide a kind of contract checking 
that can be used to ensure correctness of a given model at runtime.

IMO:  I haven't groked the manual fully, but I'll go out on a limb and 
say that I think the Alloy language as such is a bad candidate for 
inclusion into D directly.  However it may prove useful for D in other 
ways...

Alloy it has significant overlap with D gramatically. I for one, would 
find it difficult to work in a language that contains sub-grammars that 
aren't orthogonal to the main one.  A practical example of this kind of 
language morass is working in ColdFusion Script (broken ECMAScript), 
Java and JavaScript in a web-app; the only way to keep from going 
cross-eyed here is to keep those languages as separate as possible.

Now, on the other hand: Alloy it has significant overlap with D 
*structurally*.  I can easily see Alloy being brought to task as a sort 
of "side-car" arrangement with D, but probably not in any official 
sense.  The D ABI provides enough leeway to do some neat things at 
runtime with any given program - and this may very well be enough for 
Alloy to function.  Another option would be to translate Alloy 
expressions into D, to provide modules suitable for linking in with a 
program, all bound together by an Alloy API.

-- 
- EricAnderton at yahoo



More information about the Digitalmars-d-announce mailing list