-------- Forwarded Message -------- From: Jeffrey Kantor <jeff.kan...@gmail.com> To: Andrew Makhorin <m...@gnu.org> Cc: "Meketon, Marc" <marc.meke...@oliverwyman.com>, Domingo Alvarez Duarte <mingo...@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 <m...@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 > >