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

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

[...]
> > Human endeavors are not; code design and implementation should... I am
> > very strict on that topic. And I have paid the price of non clear-cut
> > designs way too often in the past myself... (BTW that was the number
> > one reason why I was motivated to start with Orocos in the first
> > place.)
> 
> I'm not talking about code design, I'm talking about language design
> and if language design were simple and clear cut than we would have
> one language and everything would be written in it.  The reality is
> that there are hundreds of programming languages for doing a wide
> range of different things.  Although I'm not going to imply that
> every programming language is well designed, I don't think that just
> because there exists a multiplicity that at least all but one must
> be poorly designed.
I never said anything like that... But we _are_ talking about
computer-processed languages, and these should be unmabiguous,
shouldn't they?

[...]
> It is interesting to note that you invoke patterns and the factory
> pattern specifically.  It is interesting to me for two reasons.
> First, Ralph Johnson (a co-author of "Design Patterns") was on my
> thesis committee so I'm familiar with many of the patterns.
Nice to know !!! :-)

[...]
> 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...

> 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.) So, what I meant in a previous email is that
the sequence of constructors
   Factory.RevoluteJoint joint;
   Factory.InertiaBase base;
   Factory.Link link;
would not be allowed to happen without the connections
   connect(joint,link.a);
   connect(base,link.b);
Using your example, I would prefer to see something like this
(violating the Modelica syntax, I know):
  Factory.InertiaBase base;
  Factory.Link link; connect(base,link.b);
  Factory.RevoluteJoint joint; connect(joint,link.a);
The difference with your example is that the file parser can detect
inconsistencies _immediately_, while in the Modelica the checks are
"delayed" until the parser reaches the "equation" section. This is not
a problem for small scale files, but it is for large scale models,
where the human cannot oversee the complexity anymore. Or when models
are changed/adapted at runtime (which is inevitable in complex
interactions). That means that a valid Modelica description can make
you loose lots of time, for the same reason as a non-allocated memory
pointer causes problems in large-scale C-programs...
Of course, the Factory cannot guarantee that what it constructs
corresponds to what the programmer _thought_ he was modelling, but
lots of errors could be caught this way.



> 
> > I just did: an XML + Schema based model representation :-) I would
> > replace the annotations with a well-discussed set of extensions.
> > This set would follow quite straightforwardly from a survey of the
> > reasons that people currently are using the annotations for.
> > The graphical Icons and Diagrams are already in the specs; maybe one
> > doesn't need more... I still find it not a good idea to encode
> > graphical shape in the Modelica file: what do you do when you want
> > different visualisations? (E.g., a high resolution and low
> > resolution.)
> 
> I suspect you will always find the inclusion of the graphical
> annotations distasteful so I'm not really going to attempt to
> convince you otherwise, but here are some of the reasons that went
> into the decision to have them in the model:
> 
> 1 - Annotations are not used strictly for graphical representation.

The more uses you find for the annotations the worse they become!
Haven't we learned enough times that a standard that has a
construction with which the user of the standard can do what he likes
is not a standard anymore! Suppose Dymola would use the annotations
to decribe geometry in a proprietary format; that means that it would
lock its users into its own software, because other Modelica
compatible software could _parse_ the file but not _use_ it in the
same way as Dymola...

> In addition, annotations are used for documentation as well (e.g.
> embedded HTML).  The result is that you can consider a single
> Modelica model to be composed of several different orthogonal
> layers.  One layer is the icon (the external view of the model).
> This is provided by one annotation.  Another layer is the diagram
> layer and this is controlled by a different class of annotations.
> The third layer is the documentation which represents the content of
> the documentation annotation.  Finally, there is the remainder of
> the model which is everything that isn't an annotation.  This is
> strictly the behavioral aspect of the model.  One reason I consider
> annotations a good thing is that I can bundle all this up together
> and it also facilitates automatic generation of HTML documentation
> that combines all this information (all the layers) into a very
> nicely organized an coherent document.  Think of it as "literate !
>  modeling" (ala literate programming).

Works fine until a single player abuses it. I would definitely refuse
to make my software or applications dependent on such a "standard"...

> 2 - Annotations currently only deal with static data, but there is
> no fundamental constraint about this.  What this means in practice
> is that you can tie the graphical representation of the model to the
> content in the model.  So to answer you question about different
> visualizations, you can have the appearance of the graphics be a
> function of the parameters in the model (i.e. you can control the
> appearance in this).  Going even further, you can associate the
> representation of the graphics with the time-varying signals in the
> model and produce some very nice 2D animations via the annotations.

Don't try convince me of the _power_ of annotations: I know you can do
_anything_ you like with them. But that's exactly my point: this
flexibility comes at a big price, vendor lock-in and resulting
monopolies being just one of them.

Let's take a similar standard: PDF. Fully controlled by one company,
but fully specified and royalty free for anyone to use. It also allows
a "hook" to do anything (most people don't seem to know): it allows
you to include JavaScript in the PDF. That means that you get similar
power of extension as with the Modelica annotation, _but_ (and this is
a big _but_) Javascript itself is a standard language, well
thought-out and platform independent, and not allowing really
everything (i.e., no memory access etc.)
Modelica might consider doing the same thing: using JavaScript instead
of annotations to extend its functionality.


> 3 - One reason annotations are not rigidly defined is that different
> tools may use different sets of annotations.  There is a principle
> in the design of the language that if a tool doesn't recognize an
> annotation (i.e. a certain kind of meta data) that it should simply
> leave it alone (and pass it along).  This gives different tools
> flexibility in being able to embed additional kinds of meta data
> without having to worry that another tool will strip it out just
> because it doesn't know what the data is.

That only corroborates what I said above: annotations make your
standard 

> As I said before, I don't have an objection to introducing a way of
> validating meta data.  I think you're proposal to use XML is really
> practical.  I think it would be too jarring to use XML for the
> annotations and try and reconcile it with the syntax of the
> remainder of the language.  

I agree with that. But the solution I would prefer is then to do away
with the annotation, and not to live with the box of Pandora that they
are :-)

[...]
> I happen to think this design is a very nice compromise because it
> lets you implement your own validation scheme for your data, lets
> you completely ignore the metadata or use meta-data in a free form
> way.  A big part of building a standard is to recognize the need for
> compromise.  You seem to think the system is flawed because it
> doesn't force the rest of the world to implement exactly your level
> of rigidity whereas I see the system as elegant for exactly the same
> reasons.

Here we clearly differ in opinion... At least we now know very well
why, because we have narrowed down everything to a well-described
feature: you like the flexibility of the "void pointer", I don't.
It has been a very interesting discussion, which gave me much more
insight :-)

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