Well said. Sent from my mobile
On Aug 24, 2020, at 1:39 PM, Jeffrey Kantor <jeff.kan...@gmail.com> wrote: 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<mailto: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 ________________________________ This e-mail and any attachments may be confidential or legally privileged. If you received this message in error or are not the intended recipient, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained herein. Please inform us of the erroneous delivery by return e-mail. Thank you for your cooperation.
