RE: Re: dynamics: comment about MBdyn...

On Wed, 16 Jul 2003, Tiller, Michael (M.M.) wrote:

> 
> > From: Herman Bruyninckx [mailto:[email protected]]
> > Subject: RE: [Orocos] Re: dynamics: comment about MBdyn...
> > 
> > 
> > On Wed, 16 Jul 2003, Tiller, Michael (M.M.) wrote:
> 
> > [...]
> > > other words, you can use the factory pattern in Modelica (my group
> > > uses it in a couple of different ways in fact).  It is a pretty
> > > advanced idiom in Modelica, but the language definitely supports it.
> > 
> > There is a big difference between _supporting_ something, and
> > _promoting_ or _enforcing_ something. Modelica supports in principle
> > anything, because there is this undefined "annotation" statement...
> 
> Just to be clear, this feature has nothing to do with annotations.
> I find your position rather strange since everything in the patterns
> book is an idiom...none of them are directly supported of enforced
> by the language?!?

That is indeed true. But I would very much like to use a modelling
file format that _guarantees_ a consistent model after parsing. I
don't have this guarantee with Modelica. Fine, but not scalable.

On the other hand, if the price for this guaranteed consistence is
"too high", then I will compromise without problem. At this moment,
however, I still have not a clear idea how high this price would be,
so I will stick to my theoretical objections until you find the
convincing arguments to make me change my mind :-)



> 
> > > Here is a simple example:
> > > 
> > > package PartsFactory
> > >   partial model RevoluteJoint
> > >   end RevoluteJoint;
> > >   partial model InertiaBase
> > >   end InertiaBase;
> > >   partial model Link
> > >   end Link;
> > > end PartsFactory;
> > > 
> > [...]
> > > model MyRobot
> > >   replaceable package Factory=SimplePartsFactory extends 
> > PartsFactory;
> > >   Factory.RevoluteJoint joint;
> > >   Factory.InertiaBase base;
> > >   Factory.Link link;
> > > equation
> > >   connect(joint,link.a);
> > >   connect(base,link.b);
> > > end MyRobot;
> > > 
> > [...]
> > > Keep in mind I'm just typing this in off the top of my head so I
> > > probably made a few mistakes.  The point is to convey the concepts.
> 
> > No problem with the syntax :-) But in my opinion, a real Factory does
> > more than what you describe: it should perform checks during
> > construction. (Of course, I guess it is difficult to enforce these
> > checks in a file format.)
> 
> I still feel like you are still not quite understanding the
> implications here.  Modelica isn't just a file format.  As I keep
> saying, there are semantic implications when I write these things.

Indeed! And this brings me to another (potential) problem with
Modelica: if you need _code_ in addition to the _data_ from the file,
in order to determine the semantics of the file, than this code should
be standardized too. Otherwise there is no standard!

That is only possible with an open source code base, not with various
vendors implementing their own semantics... ("Code is law" is well
known in the open source community.) Take the MS Word or HTML
examples: it's basically the software that determines the result,
which gives an unfair advantage over competitors. So, this leads me to
a logical conclusion _if_ one doesn't want to go with an open source
reference implementation: all semantics should be in the file. The PDF
example I gave before proves that this is possible: PDF files render
everywhere the same, on all platforms, with all viewers. (Unless you
miss the fonts, of course.)

> In short, It does perform checks!
Yes, but where has the Modelica foundation defined what these checks
should be and what happens if they fail? And where has it defined what
is allowed in the annotations....?

> There are subtype requirements that are implied in the semantics of
> the language.  The original factory defines what the interface is
> for the RevoluteJoint, InertiaBase and Link classes will be.  It
> happens that in my example I didn't include anything in the
> interfaces, but if I did, all factories would be required to provide
> implementations that were subtypes that supported the original
> interfaces.
Ok, but this is only part of the picture: strong type checking is not
enough. We come back to where we started a week ago: the difference
between "parsing" and "symbolic processing". I can now express my
objections a bit clearer: the behaviour of the symbolic processing
should be standardized too.

[...]
> I don't really understand what specific benefit you see in this.
> For example, even if you made the connect statements syntactically
> close to the declarations, it still doesn't say at what point the
> semantic processing will check anything.  

If the consistency is not there at the end of the scope of each newly
constructed object, than there is no guarantee that it will ever be...

> Furthermore, it isn't clear to me what it would detect?  You just
> want to check that the model was connected to something?  
To something meaningful, yes.

> You can do that without requiring that they be syntactically close
> to each other.  Are you worried about the amount of time it would
> take to process the declarations 

I am worried about guaranteeing a simulatable model, from the file
description alone. (Without having to rely on an _implementation_ over
which I have no control.)

[...]
> That can also be dealt with in the language by making an assertion
> in the model requiring that a port be connected.  That is support!
>  ed by the language.
Please, I am talking about _guarantees_, not about _support_. This is
a world of difference!

[...]
> I didn't make this point explicitly, but annotations are used for
> things that DO NOT affect the behavior of the model.  As such, it
> should always be safe to ignore them and still be able to simulate a
> model.

Nothing  prevents one from using them to affect behaviour...
(For example (_your_ example) using an annotation to define
dependencies between variables in the model.) And where is my
guarantee that Dymola will not start to use them for that purpose...? 
Where is my guarantee that I can change software vendors without
loosing my investment in models?

The common practice in the feature-bloated IT industry has proven time
and again that this is what is going to happen, sooner or later...
Unless the standard is complete and guaranteed.

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480