RE: comp.lang.ada Digest, Vol 19, Issue 114

RE: comp.lang.ada Digest, Vol 19, Issue 114

[Robert C. Leif]

   Although in principle these additions would be useful, the simulation
capability should be separated from the mathematical capacity.  Ada should
stop being based on glass-typewriters!  The new front end should be XML
including MathML.  Ada sources would be in XHTML-strict.  Ada should be able
to parse expressions written in MathML. Simulation could then be added to
this with outputs in scalable vector graphics (SVG).  This would result in a
language with some SEX-Appeal.
   Bob Leif
   -------------------------------------------------
   
   Message: 1
   Date: Thu, 17 Mar 2005 16:35:10 +0100
   From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
   Subject: Re: NOACE- End of the road for Ada?
   To: comp.lang.ada@ada-france.org
   Message-ID: <1wuefxdhphvq5.1te56e3jttqln.dlg@40tude.net>
   Content-Type: text/plain; charset="us-ascii"
   
   On Thu, 17 Mar 2005 13:25:25 GMT, Marin David Condic wrote:
   
   > adaworks@sbcglobal.net wrote:
   >> 
   >> 
   >> It would be really cool to have a standard interface between Ada and
   >> Matlab.
   >> 
   > Probably, but it would be even MORE cool if there was an entire Ada
   > equivalent of Matlab, et alia. The whole bundle of stuff produced by
The 
   > Mathworks is pretty cool for the modeling world, but I think it has 
   > problems when people try to bring it into production. It is very 
   > tempting to say "Well, now that you've defined the control in the model

   > world and conducted a bunch of tests on it, why don't we just compile
it 
   > and take that code into the production box..." But the model world
likes 
   > to play fast and loose with all the things that might cause problems in

   > a production world. (For example, everything tends to be just a "real" 
   > number - not much type checking going on. Or not much support for 
   > low-level representations of data that might matter when the zeros and 
   > ones actually connect to the hardware. Or any number of other
complaints.)
   > 
   > So people like to just build these models then take the code into 
   > production, but might it not be BETTER if the modeling tool had 
   > capabilities aimed at the production world? Might it not be BETTER if a

   > modeling tool took into consideration the needs of and proven
techniques 
   > of embedded software development? So if someone designed such a
modeling 
   > tool and incorporated Ada-isms into it and had it generating Ada code, 
   > and it provided BETTER capabilities to the guy designing models, might 
   > that not create an interesting marketplace for Ada?
   
   It absolutely true.
   
   I can confirm that in the automotive area it would be a great
breakthrough,
   if something like above existed. Simulink lacks multi-threaded middleware
   for deploying the models. Considering a wide range of complex protocols
   which need to be supported (from CAN to TCP/IP), clearly there is an
abyss
   between the code generated by Simulink to the code needed. More to the
   point, there is no chance that people drawing diagrams would be able to
get
   this communication code right. An Ada platform with a middleware taking
   care of this mess would be technically unbeatable.
   
   However, there is a problem of acceptance. People want C. Even more they
   want C#. Lots of projects are doomed to fail before they change their
   minds...
   
   -- 
   Regards,
   Dmitry A. Kazakov
   http://www.dmitry-kazakov.de
   
   ***********************************

Re: comp.lang.ada Digest, Vol 19, Issue 114

[Georg Bauhaus]

Robert C. Leif wrote:

Have you looked at Simon Wright's ASIS2XML?
http://www.pushface.org/asis2xml/

>    Although in principle these additions would be useful, the simulation
> capability should be separated from the mathematical capacity.  Ada should
> stop being based on glass-typewriters!  The new front end should be XML
> including MathML.  Ada sources would be in XHTML-strict.

(X)HTML has been criticized for missing good structuring
properties (sections are not headings, div is only a workaround ...).
Examples in the book by David Megginson's book.

>  Ada should be able
> to parse expressions written in MathML. Simulation could then be added to
> this with outputs in scalable vector graphics (SVG).  This would result in a
> language with some SEX-Appeal.

Hm. I think this is the job of a good editing environment.
Ada has a grammar. The grammar can be mapped to an internal
XML representation that is internal to the editor, o.K..
 But why touch Ada?
A fairly simple XSL program can be used to extract plain Ada source text from
a combined source text document that includes graphics, reference, etc.,
in addition to the Ada source text.
A fancy XSL program can do all sorts of project specific processing.
 For sure, if you only touch some non-Ada piece of a source document,
the Ada part doesn't need to be recompiled. This needs some bookkeeping,
at least. A piecewise intergration with a VCS seems desirable, and XML
can help here.
 Sounds like quite a bit of work to make such a thing.

A similar technique has used text processor macros to separate source
text from prose and pictures, IIRC.

Georg