Re: [Swarm-Modelling] Announce: metaABM 1.0.0

[Miles T. Parker]

On Nov 23, 2007, at 2:55 PM, Marcus G. Daniels wrote:

> Hi Miles,
>
> Many configurable apps that use XML or similar (e.g. Interface  
> Builder NIB files) provide little more functionality than a way to  
> hook up a fixed set of parts together.  That simplification is often  
> useful, especially when the domain is well understood and the  
> underlying language for making components is commonly used.  But if  
> that configuration language is a modeling language, and the  
> underlying language (or toolkit) is considered a black box, then the  
> situation is more troubling because the domain of use gets radically  
> limited.

I think you're unnecessarily belittling the approach or don't quite  
grok it. There is no "underlying language" per se. We are not talking  
about wiring together Java beans or something here. Just because the  
domain is limited, doesn't mean that its trivial. I find a lot of  
value in "simplifications" that allow expressive, information dense  
sharing of information. That is really the very nature of science --  
or at least reductionist science --  isn't it? % the costs I  
acknowledged in last post..

Your claim that the domain of use is "radically limited" is a radical  
assumptive :), unless you mean "radically limited" with respect to the  
entire universe of possible models of nature, in which case, granted.  
I am assuming that you are playing a bit of devil's advocate here, but  
for that to be a fair critique, I think you should look at the design  
and describe the "radically large" set of current ABM models that  
cannot be represented within it. I'm serious, because that would  
either a) provide a set of design cases that would help to refine and  
enrich that current meta-model or b) reveal the folly of this  
enterprise at the earliest possible stage and save me and others a lot  
of time.. :)

I guess I don't quite understand how the underlying toolkit is seen as  
a "black-box" anymore than say "Java" is. The specification should  
certainly be complete and unambiguous and implementations would need  
to produce consistent repeatable results (perhaps against some  
reference implementations) from the same set of specifications.

> Domain specific languages don't have to have this property.   Lisp  
> macros provide one way to make a DSL, where users can step outside  
> that abstract language as needed.   Some implementations like Dr.  
> Scheme even provide different default levels of language/API  
> exposure for teaching contexts so that users cannot accidentally  
> step outside a prescribed dialect (DSL).

Yes, of course this kind of support is needed. Again, I think you  
should take a look at the design before deciding what it does. :) I'm  
going to have an updated diagram that inclues the behaior stuff RSN;  
but if you just take a look at metaabm.ecore it should be pretty  
clear. You can load arbitrary external classes (in fact this was the  
original usage) and as a more encouraged use you can map to arbitrary  
functions. I'm not claiming that any of this is perfect but...

> Marcus
>
> _______________________________________________
> Modelling mailing list
> address@hidden
> http://www.swarm.org/mailman/listinfo/modelling