Re: [Swarm-Modelling] Announce: metaABM 1.0.0

[Miles T. Parker]

On Nov 25, 2007, at 12:00 PM, Marcus G. Daniels wrote:

> Miles T. Parker wrote:
> > > And I think we can agree that toolkit approaches don't force users  
> > > to compress toward a well-factored set of primitives.  They also  
> > > don't prevent it.
> >
> > But if you're speaking in terms of APIs / frameworks then that does  
> > strongly encourage a particular compression. That is, someone could  
> > write their own low-level graphic subsystem using nothing but  
> > drawBytes, but for the vast majority of people that's a distinction  
> > w/o a difference.
> Sure it encourages a certain set of library calls, but that doesn't  
> encourage users to constantly factor the rest of their simulation  
> code (that is using those calls) or follow any particular set of  
> practices.

??? really? perhaps we need to distinguish toolkits from frameworks  
here, but if I am using say a vector graphics API, I am going to be  
doing vector graphics, similarly if I am using an ABM framework, I am  
going to be doing a specific kind of ABM. If I decide not to use that  
API, then I can not use it, but the same can be said of a meta-model  
or DSL. The only difference is one of kind, that is the amount of  
leverage gained balanced against the additional cognitive dissonance  
of "switching gears".

>  Those habits, to the extent they exist, come from examples or the  
> community of practice, or personal aesthetics.

Or what is simply convenient within the particular API chosen, no?

> A declarative domain specific language, however, can force the user  
> toward a small set of more optimal constructs and also facilitate  
> the computer noticing redundancy, etc.  That's a good thing to the  
> extent the primitives are optimal and general (or at least well  
> suited to a domain).

Agree totally.

> > OTOH, the only way a metaModel could be said to 'prevent' something  
> > is for those with an extreme lack of imagination or who couldn't or  
> > wouldn't have done so in the first place. After all, the code  
> > produced is directly editable in its target language / toolkit so  
> > there is always an opt-out provision.
> But the opt-out isn't not unified with the high level  
> representation.  Once generated code of a model for a target  
> language / toolkit is elaborated by hand in that target language,  
> it's opaque to the meta representation past the interfaces to which  
> it conforms to.   How do you pull the meaning of those elaborations  
> back into the high level representation so they can be applied to  
> another toolkit?

You don't as they are by their nature outside of the representative  
structure of the meta-model. If you want to be able to apply something  
to another toolkit, you want another high-level representation for it  
or to keep it in the (potentially implicit) meta-model of the target  
language / toolkit.

 I do not btw argue at all that the selectively constrained or  
leveraged systems of languages such as the Lisp macro and Dr. Scheme  
approaches you mention are not very cool ways to accomplish  
essentially the same thing -- thus my statement in my first reply..  
"All of the C derivatives are "pretty close" structurally and  
syntactically -- which is why I think an Obj-C or C++ would be a good  
next order target to shoot for, instead of, say LISP ***(but then why  
would you need a meta-model? :D)****"

I think both approaches are totally valid and cool. I appreciate the  
elegance of a top-to-bottom syntactic structure, and I would love to  
see that whole approach explored and implemented. (Are you involved or  
aware of such?) My aesthetic and practical intuition based on seeing  
syntax and in some part semantics as an arbitrary construct is that we  
should represent our internal model as explicitly and abstractly as  
possible and make language an implementation of that meta-model.  But  
I had a completely different  view when it came to Java v. CLR --  
perhaps in that case because I saw CLR as just a skien over the Java  
object model.

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