Re: [SED-ML-discuss] Future of SED-ML

[Nicolas Le N. <le...@eb...>]

I am not sure we reached a closure on that. I believe most people 
expressing their opinion were leaning towards Frank approach.

Personally, I think the nesting itself does not make SED-ML much more 
imperative than declarative. If this is the case, then CellML is imperative 
since we can nest components. And other language describing complex 
geometries for instance. In SBML, the multi proposal would be imperative, 
describing the building of species from other species.

What we should do so that everyone is happy, is to make sure we say

"task 1 is made of 100 task 2 with parameter X taking 100 values, 
logarithmically distributed between value a and b."

rather than

"perform task 1 by iteratively performing task 2 with parameter X taking 
successively 100 values logarithmically distributed from a to b."

I realise it is merely a semantic trick, but would-that satisfy everyone?

We can still have classes of simulation that would be used in those tasks. 
So it is not merely a generic declarative language either.

Then we could move on the proposal itself, trying to see it it fits the 
bill of the current needs:

Parameter scan (dose response)
Steady-state analysis
Optimisation (parameter sampling)
Population sampling (for PK models)
other?

On 20/01/12 00:09, Andrew Miller wrote:
> On 20/01/12 12:29, Frank T. Bergmann wrote:
>>
>>>> I would argue, that we are not re-inventing the wheel. What we are
>>>> doing is creating a language independent specification of simulations.
>>>
>>> If we are creating a new language to describe simulation procedures
>>> imperatively, it isn't language-independent - it is dependent on the new
>>> language we invent (you wouldn't be able to describe your simulations
>>> independently of the new 'nested simulations' language).
>>>
>>
>> Language independent here meant programming language independent. As XML
>> parsers are accessible in any programming language it would be straight
>> forward to use the new construct in all of them, with considerably less
>> overhead than it would take to embed / execute a description in any script
>> language we chose.
>
> My point is that the direction we are moving with nested simulations is
> to create a new scripting language marked up in XML - that is, we are
> creating a new programming language.
>
> Tools that work with SED-ML will already have an XML parser, but parsing
> is a tiny fraction of the work needed to implement a scripting language.
> Python's grammar itself is actually very simple
> (http://docs.python.org/reference/grammar.html) - likewise for Haskell
> http://hackage.haskell.org/trac/ghc/browser/compiler/parser/Parser.y.pp;
> many Lisp dialects are even simpler.
>
> Getting from the language to an abstract syntax tree is a bit easier
> with XML - but that step is a fairly minor part. From this point,
> everything is specific to the language, and the fact that it originally
> came from XML makes no different; for example, code might perform
> optimisations on the AST, and compile the AST to byte-code, or it might
> step through the AST in an interpreter - but in any case, the amount of
> machinery needed to make this work dwarfs the size of the parser anyway.
>
> There is therefore negligible difference in the code-size overhead of
> software tools between XML-based scripting languages and non-XML-based
> scripting languages.
>
>>
>>>
>>> This same argument applies equally to a newly created nested simulations
>>> language, except that a newly created language will have a far smaller
>> base of
>>> existing code to try to interoperate with.
>>>
>>
>> And so no, people are still free to choose the programming language for
>> their tools with minimal overhead.
>
> If the nested simulations proposal becomes a programming language (i.e.
> continues in the same direction) then people are not free to choose not
> to implement that programming language, and the code to support that
> programming language will add overhead to the tools.
>
> Python itself (as opposed to many of the libraries that come with
> CPython, which you probably wouldn't need just for sequencing
> simulations) can be implemented in 64k of code: http://www.tinypy.org/,
> and Python can already be embedded from a wide variety of programming
> languages (and Python is just an example - there are other choices than
> Python that may be even smaller and simpler to implement).
>
> Best wishes,
> Andrew
>
>>
>>> We are trying to do two slightly different things.
>>
>> I agree with this at least :) And I think your and my position is quite
>> clear at this point. We just need to sort out where the community wants this
>> to move.
>>
>> Cheers
>> Frank
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/