Home » Archived » AMP » DSL For Amp
|
| Re: DSL For Amp [message #556302 is a reply to message #556172] |
Tue, 31 August 2010 16:28   |
 Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| Tony Kennedy wrote on Tue, 31 August 2010 04:18 |
Has anyone been working on, or had any thoughts on, a DSL for AMP.I've been asked to produce a proposal and costing for a DSL for AMP, current thinking is something similar to that produced by the Gamma project (details on Gamma Wiki) but extended by the use of a blocked grammar one block for GSI one for Bio one for economic modeling etc. all operating from a functional base, current thinking is Scarla for the base, XText seems to be able to cope with the production, a limited Scarla has been produced as PoC. As this will be a substantial amount of work I don't want to be reinventing the wheel or treading on anyone toes.
|
Hi Tony,
I think DSLs are critical - could be extremely powerful and have the important side benefit of helping people to see the AMF model not just as the hierarchical editor but as a generic representation that can be authored to in many different ways.
I've put a lot of effort into a DSL for the last couple of years but have had to back bench it -- just too many irons in the fire at once. I'd like to polish it up and put it out there so that people can see at least what a version 0.1 of such a thing would look like. I've just been fiddling with syntax etc. a bit. I am not sure how well it will scale but that should be simply on the limits of XText and I'm not too worried. Let me take a quick look and see what would be involved in doing an early alpha release.
I think there is room for many different ways of doing this and so I'd not worry about stepping on toes  , but of course it is nice not to have to duplicate effort. I'm not sure at this point if it will be an open spec and open source or simply an open spec as Metascape is still looking for ways to generate software revenue -- but of course interest from other parties will always tend to push us in the direction of the latter.
I'm not familiar with the Gamma approach but I'm intrigued by what you mention regarding blocked grammars and would love to hear more especially examples.
I'll say a bit about the approach I've been taking. It being a software language the important part is the name: I was calling it "Sugar" but that's way too overused, so I thought of "Alan" for "Agent Language" and Turing, of course.
Essentially it can be thought of as a spatial and collection-oriented query and transformation language, with named queries so that there is a kind of functional flavor as well. The language itself is essentially a mapping to AMF Acore/MetaABM but with some higher level semantics so that the representation could actually be a bit denser / more expressive in places. More importantly it is designed to be much more composable / dockable so that you can take snippets of code and bundle them together in more arbitrary ways than you currently can with the AMF meta-model. The language DSL is then transformed at desing time into .metaabm. (I toyed with going directly to .metaabm but this turned out to be really unworkable in practice, plus there is gains to be had by having another layer of abstraction.)
One neat aspect I think is that because AMF provides an non-imperative (semi-imperative I guess would be more accurate) approach the language takes on a bit of the flavor of a Logic language as well. And again like AMP there is a bit of a data-flow flavor as well. It really isn't as complicated as I'm making it sound!
The basic structure is all layed out and I finally got it working early this year. There have definitely been some tricky bits with respect to parsing -- complicated by the XText API changing during the course of design. I think I'll need to shake it out a bit more to get it working with the 1.0.0 API. One nice thing is that all of the tooling works -- this means that you can save a model, have it translated into a .metaabm model and have the model built without any other user intervention.
I'd love to hear more about your ideas WRT this and any pilot you'd like to share.
cheers and as always you bring up the most interesting issues,
Miles
|
|
|
| Re: DSL For Amp [message #557349 is a reply to message #556172] |
Tue, 07 September 2010 03:46 |
Tony Kennedy
Messages: 17
Registered: June 2010 |
Junior Member |
|
|
Some corrections its the Gama Platform <http://code.google.com/p/gama-platform/wiki/Xtext>, they have a basic Xtext DSL and the platform architecture is similar to that of AMP and for block read DSEL in my previous post.
Agent based models can be defined using a domain-specific language designed specifically for the domain and the environment in which the ABM is being executed, the problem with this is the size of the modeling domain, just about anything can be modeled given the time and money to do so, and for a language to be useful and provide an appropriate degree of abstraction in any one domain would be difficult; but in all imposable. The use of such a DSL which is closely coupled to the model using algorithms which attempt to capture all possible strategies makes the model inflexible when compared to natural behavior the aspect which makes natural behaviour so versatile, and the one we want the ABM to capture, is the ability to asses the information and adapt to the situation by selecting the best possible strategy.
One approach to language design appropriate to domain-specific ABM's that overcomes these difficulties is embedding a language within a general purpose host language; the host providing abstraction for the modelling environment, the embedded the abstractions necessary for the model domain at hand. This produces a nice division of labour between modelling environment expertize and domain expert who does not necessarily have or want to extend their expertize to the computing environment, versatile by dynamic generation and modification of the DSEL by the DSL by querying and reacting to the state of the model; by the use of multi-tiered DSEL's, giving different levels of abstraction in the ABM; .
In the discussions i've had so far and I stress this very early days, we have adopted this approach to ABM language design using DSEL's where the embedded DSEL is an object in the host giving the following characteristics:
Enabling parametrized strategies to be manipulated by the host program in response to the model state.
The use of embedding also makes possible the creation of adaptive scripts during a modelling session, allowing the model to become dynamic and enabling it to act in a manner approximating natural behaviour since by embedding the DSEL the DSEL's become objects of the host language allowing the host to manipulate them
By querying the model and selecting the appropriate strategy, the host language can act as a meta-language which generates an appropriate DSEL for the situation.
Multi-tiered DSEL's where DSEL's which vary in level of abstraction are embedded within one another show another another natural characteristic, that of translating abstractions into concrete operations by translating high-level tactics written in an abstract language into lower-level tactical plans of a less abstract nature until an operational script is reached.
There are of course many other desirable characteristics which have yet to be discussed, I intend to take this forwarded by enumerating the different characteristic discovered and by producing some models which demonstrate this use of the technique in differing modeling domains and post then here together with attributions and a reading list if there is any interest. Where would Alan fit in the above a DSL or DSEL?
The use of DSEL's in a host language allows the approximation of a human behaviour by an ABM. DSLs plus DSEL's offer the right amount of abstraction for ABM but creating a new language from scratch for each domain requires a prohibitive amount of work the use of an existing language whose properties meet the requirements of the modelling environment, then adapting it to a particular domain by the use of DSEL it is possible to create the required DSL with the added advantages of reduced risk, costs, time and effort. Xtext tooling seems to allow this though I think the above should be run by them before serious work begins.
Language names: Turing seems good, can't really argue living in Greater Manchester, not far from his Wilmslow home, but as an offering for the most bazaar DSL name BrainCurry from the neuro science domain.
Interesting things: if the above does not interest then how about the use of the GPU in model execution, the introduction of X-Stream techniques into AMP, making AMP embeddable, my predecessor embedded Ascape into Knime as a node and in a similar manner in to a streaming database manager called Streambase again as a node though only PoC they did some interesting work. Many other interesting things came out of the modelling survey these are the top ten
|
|
|
| Re: DSL For Amp [message #557511 is a reply to message #557349] |
Tue, 07 September 2010 21:46 |
Miles Parker
Messages: 1341
Registered: July 2009 |
Senior Member |
|
|
| Tony Kennedy wrote on Mon, 06 September 2010 23:46 | Some corrections its the Gama Platform <http://code.google.com/p/gama-platform/wiki/Xtext>, they have a basic Xtext DSL and the platform architecture is similar to that of AMP and for block read DSEL in my previous post.
|
Oh yes -- I had forgotten, I think you had discussed that actually. It uses an XML back end and I actually approached the hoping to see if they were interested in joining effort. Too much NIH everywhere, I'm just as guilty as the next person and hoping we can break through that! GAMA is again alas GPL.
| Quote: | Agent based models can be defined using a domain-specific language designed specifically for the domain and the environment in which the ABM is being executed, the problem with this is the size of the modeling domain, just about anything can be modeled given the time and money to do so, and for a language to be useful and provide an appropriate degree of abstraction in any one domain would be difficult; but in all imposable. ..
By querying the model and selecting the appropriate strategy, the host language can act as a meta-language which generates an appropriate DSEL for the situation.
Multi-tiered DSEL's where DSEL's which vary in level of abstraction are embedded within one another show another another natural characteristic, that of translating abstractions into concrete operations by translating high-level tactics written in an abstract language into lower-level tactical plans of a less abstract nature until an operational script is reached.
|
Let me play it back to you and see if I sort of have it..
a) The language approach is along the lines of the eponymous DSL approach, where you really are restricting the language to a particular usage domain i.e. "Social Network" or "Knowledge Communication" as opposed to say a particular methodology, e.g. "Math" or "ABM" or "Relational Databases".
b) There are really two (one and a half?) languages, the host language which is a DSL in the larger sense of an XText specified language, and then some ability to modify that language on top.
c) There is a requirement for dynamic behavior definition something that is obviously not possible in Java GPL per se.
re: c this is a key issue. It is currently not supported in AMF *within a model run* as we rely on code generation for the many benefits that has. But a significant desirable feature is dynamic model execution, which would be analogous to how things are done in EMF, i.e. you could choose static or dynamic model depending on where you wanted flexibility / performance tradeoff.
| Quote: | There are of course many other desirable characteristics which have yet to be discussed, I intend to take this forwarded by enumerating the different characteristic discovered and by producing some models which demonstrate this use of the technique in differing modeling domains and post then here together with attributions and a reading list if there is any interest. Where would Alan fit in the above a DSL or DSEL?
|
A huge amount of interest from me at least especially for demonstration models as I'm lazier about the reading part.
I've spent the last week trying to get Alan up and running again under XText 1.0 with some success. Unfortunately, I can't afford to spend more time on the implementation right now and have to focus on the stuff that people want to pay me to do. But If I put a somewhat broken version up without BNF but with ability to build simple models would that be useful?
| Quote: | The use of DSEL's in a host language allows the approximation of a human behaviour by an ABM. DSLs plus DSEL's offer the right amount of abstraction for ABM but creating a new language from scratch for each domain requires a prohibitive amount of work the use of an existing language whose properties meet the requirements of the modelling environment, then adapting it to a particular domain by the use of DSEL it is possible to create the required DSL with the added advantages of reduced risk, costs, time and effort. Xtext tooling seems to allow this though I think the above should be run by them before serious work begins.
|
I've had a lot of experience playing around with XText so perhaps I can give you a first cut of what is and isn't doable. Where do you see the biggest implementation risks / challenges?
| Quote: | Language names: Turing seems good, can't really argue living in Greater Manchester, not far from his Wilmslow home, but as an offering for the most bazaar DSL name BrainCurry from the neuro science domain.
|
Yeah, I like Alan -- it fits in with "acore" as well as the very simple domain languages already there "apar" "adata" and "atest". Not search engine firendly, but if google can use "Go"...
| Quote: | Interesting things: if the above does not interest then how about the use of the GPU in model execution,
|
Yes, that has been contemplated for some time. There is a group up at Michigan State that has had an interest on implementation side. A couple of years ago they were demoing hand-crafted Sugarscape models that were running models with 10^6 agents at 30fps which was pretty cool -- though there are potential issues, especially with WRT to repeatability and artifacts.
But the very important point here that I've been trying to make in arguing for AMF approach is that you can a) validate and verify the model using very safe code-generation targets and then b) execute very large sets of runs on GPU target platform. This way you get the best of both worlds.
| Quote: | the introduction of X-Stream techniques into AMP, making AMP embeddable,
|
Oh, cool..
| Quote: | my predecessor embedded Ascape into Knime as a node and in a similar manner in to a streaming database manager called Streambase again as a node though only PoC they did some interesting work.
|
Neat! I had no idea there was an Ascape node for Knime -- I'm always the last to know these things and it makes me grin to hear that.
| Quote: | Many other interesting things came out of the modelling survey these are the top ten
|
Yeah, every time I discuss this stuff with people there are soo many amazing things to do. And much (though certinaly not all) of it is low-hanging fruit -- i.e. I keep saying to myself "if I only had a month or two to work on this instead of the paying stuff or build maintenance" -- as all of us do. If you want to tackle any of that, the project could really use your expertise.
One of the things that is becoming more and more clear to me as a need that would enable a lot of important stuff is to support dynamic execution. I'll discuss a related topic once I've had time to make my ideas a bit more coherent.
cheers!
Miles
|
|
|
Goto Forum:
Current Time: Thu Apr 25 21:12:48 GMT 2024
Powered by FUDForum. Page generated in 0.03806 seconds |
] 
Search
Help
Register
Login
Home
