[Fwd: Re: Adding if/then/else statement to GMPL]

[Andrew Makhorin]

-------- Forwarded Message --------
From: Jeffrey Kantor <jeff.kantor@gmail.com>
To: Andrew Makhorin <mao@gnu.org>
Cc: "Meketon, Marc" <Marc.Meketon@oliverwyman.com>, Domingo Alvarez
Duarte <mingodad@gmail.com>, help-glpk@gnu.org <help-glpk@gnu.org>
Subject: Re: Adding if/then/else statement to GMPL
Date: Mon, 24 Aug 2020 12:38:42 -0500

> Respectfully, and I very much appreciate the careful design of GMPL
> and its utility for creating ‘beautiful’ models, I have to disagree.
> What is being proposed, I think, is not a general purpose programming
> language, but rather extensions to GMPL making it more suitable to
> expressing well accepted models for important OR applications. Stock
> cutting is one example, but there are many others.
> 
> GMPL is very well suited to documenting models and applications,
> especially for teaching and education. They’re short, to the point,
> and above all, largely self-documenting. Extending the language should
> and could maintain these attributes. zWithout these extensions, I fear
> that GMPL will whither on the vine in favor of precisely what you
> describe … modeling tools embedded in higher level languages like
> Python and Julia.
> 
> My hope is the GMPL v2 would, like GMPL v1, something that, once
> created, stays fixed for decades. This is the advantage of a reference
> language for representing models, a role for which GMPL has been
> successful.  Models embedded in Python, Julia, etc, typically require
> additional maintanece as the languages and extensive libraries evolve.
> With GMPL one doesn’t have to worry about that. 
> 
> 
> > On Aug 24, 2020, at 12:17 PM, Andrew Makhorin <mao@gnu.org> wrote:
> > 
> > On Mon, 2020-08-24 at 14:00 +0000, Meketon, Marc wrote:
> > > I've always felt that GMPL needed if-then-else, for-loops, 'let'
> > > statements and the ability to re-solve to be a true modeling
> > > language.  And Andrew has always disagreed.
> > > 
> > > Many of the models that I create ultimately are 'iterative' where
> > > I
> > > need to take the results of one model and use it to setup another
> > > model.  To me, that is also modeling.  GMPL doesn't have it.
> > > 
> > > So often, I use GMPL for an initial model - it is a wonderful
> > > language, and I find it faster to code than alternatives.  But
> > > then
> > > when I 'get it right' I have to re-code it in PYOMO or PULP or
> > > write
> > > directly to an 'lp' file within a Python or C# or other language
> > > script.
> > > 
> > > Having the ability to run, adjust variables, add/take away
> > > constraints, re-run would be extremely useful, and make GMPL more
> > > of a
> > > one-stop modeling language.
> > > 
> > 
> > I agree that programming features like "goto" (as well as its
> > structured
> > versions) sometimes are necessary, but in my opinion it should be
> > another language. Probably something like MPL (Math Programming
> > Language) developed by G.Dantzig in 70's is what you would like to
> > have;
> > see https://dl.acm.org/doi/10.1145/800184.810495 .
> > The initial design of AMPL, which GNU MathProg is based on, is not
> > suitable to make AMPL a full-featured programming language, and in
> > my
> > opinion all further additions just broke the design being
> > incompatible
> > with it.
> > 
> > On the other hand, developing and implementing yet another (even
> > domain-specific) programming language is not a good idea. I think
> > that
> > modeling features might be built *over* an appropriate programming
> > language. A good example of such approach is the GNU LilyPond (a
> > music
> > engraving program; see https://lilypond.org/ ), where the domain-
> > specific part is built over the Scheme programming language (a
> > dialect
> > of Lisp): in normal circumstances the user writes all things with
> > domain-specific constructions, but if something unusual is needed,
> > he/she may write things on a lower level directly in Scheme.
> > 
> > 
> > Andrew Makhorin
> 
>