Peter, I'm copying this to the Poly/ML list as you suggested.
It would be nice to have SML emacs mode working with Poly/ML for those who would like to use it but my feeling is that it is rather old-fashioned. Poly/ML now supports a much more extensive interface designed for an IDE. The best example of this is Isabelle's ML mode. See http://sketis.net/2014/isabellepide-as-ide-for-standard-ml which has a nice screen-shot. Lucas Dixon and I both had a go at producing IDEs which were completely independent of Isabelle but we didn't get as far as Makarius has.
It all works by having the Poly/ML compiler as a function which takes a large set of parameters most of which have simple defaults. All the interaction with the compiler is through ML functions. The default REPL just calls the compiler with streams connected to the console but it's very easy for a user to replace the REPL with something else. The Isabelle IDE is just using the Poly/ML compiler function but passing in parameters which capture error messages and also allow browsing of the parse-tree to get information about the types. So far the debugger hasn't been fully integrated with this but it's something I have in mind.
The format that the default REPL uses for error messages was one that was used by various compilers at one time and it used to be possible to parse it automatically. If there's a more up-to-date format I'm happy to change to it. I don't know if anyone is parsing the current format automatically and would be inconvenienced by a change.
David
On 03/12/2014 03:26, Peter Gammie wrote:
Dave,
I?ve been talking to Stefan about the SML mode for emacs that he maintains. I?m hoping to use it with Poly/ML and it is starting to come together.
Stefan observed that it would be super-helpful if Poly/ML generated errors in a standard format, such as e.g. the one that GCC or clang use, as far as that makes sense.
Would you be open to that? I could try to crank out some patches to Poly/ML if so.
BTW I am wondering how people interact with Poly/ML?s repl. With more hacking it is likely to be somewhat emacs-friendly, but I?m still struggling to understand how people have done it in the past.
For instance, I presently more-or-less just load all modules into poly with a series of ?use?s in dependency order. Now I?d like to use the debugger and it seems I have to hack all this scaffolding to do so. From the looks of it Isabelle does the same.
Feel free to reply via the Poly/ML list if you prefer.
Thanks for the awesome system. I hope I can make some use of the concurrency!
thanks, peter
automatically. If there's a more up-to-date format I'm happy to change to it. I don't know if anyone is parsing the current format automatically and would be inconvenienced by a change.
Don't know about "up-to-date", since I use and work on "old-fashioned" software, but there's:
https://www.gnu.org/prep/standards/html_node/Errors.html#Errors
which is used by a wide variety of programs (e.g. TeX now supports this format as well).
Stefan
On Wed, 3 Dec 2014, David Matthews wrote:
It all works by having the Poly/ML compiler as a function which takes a large set of parameters most of which have simple defaults. All the interaction with the compiler is through ML functions. The default REPL just calls the compiler with streams connected to the console but it's very easy for a user to replace the REPL with something else.
Here is also an example for that, to implement a home-made "eval" function in Poly/ML: http://stackoverflow.com/questions/9555790/does-sml-poly-have-a-cl-like-repl
This should give some clues how to do it. It is up to that function to say how errors are printed.
An actual REPL requires a bit more work, with proper handling of interrupts in contrast to regular exceptions. Isabelle2014 still happens to have such a REPL in isar.ML, but it is not used by default and already deleted for the next release. (Such a nostalgic REPL is actually more complicated than having a direct editing model that is now standard in Isabelle/PIDE.)
Makarius
---------------------------------------------------------------------------- http://stop-ttip.org 997,299 people so far ----------------------------------------------------------------------------
David, Makarius,
On 3 Dec 2014, at 13:20, Makarius <makarius at sketis.net> wrote:
Here is also an example for that, to implement a home-made "eval" function in Poly/ML: http://stackoverflow.com/questions/9555790/does-sml-poly-have-a-cl-like-repl
This should give some clues how to do it. It is up to that function to say how errors are printed.
An actual REPL requires a bit more work, with proper handling of interrupts in contrast to regular exceptions. Isabelle2014 still happens to have such a REPL in isar.ML, but it is not used by default and already deleted for the next release. (Such a nostalgic REPL is actually more complicated than having a direct editing model that is now standard in Isabelle/PIDE.)
Thanks for the pointer. I?ve stashed this one away for a rainy day. Right now I just want to interact with Poly/ML in the most straightforward way.
On 3 Dec 2014, at 5:33, David Matthews <dm at prolingua.co.uk> wrote:
It would be nice to have SML emacs mode working with Poly/ML for those who would like to use it but my feeling is that it is rather old-fashioned. Poly/ML now supports a much more extensive interface designed for an IDE. The best example of this is Isabelle's ML mode. See http://sketis.net/2014/isabellepide-as-ide-for-standard-ml which has a nice screen-shot. Lucas Dixon and I both had a go at producing IDEs which were completely independent of Isabelle but we didn?t get as far as Makarius has.
I?m not adverse to trying out JEdit, but it seems to dodge the issues somewhat. Is anyone using it for hacking large-scale SML programs?
One measure of adequacy might be if JEdit/SML (err, Isabelle/SML?) can load the foundational Isabelle stuff, e.g. Pure/ROOT.ML. (How do you hack Isabelle/Pure presently?)
In particular I?d want access to Poly/ML?s concurrency primitives. It seems to nuke Poly/ML?s ?use? function, which is a little unfriendly.
BTW I have no problem cranking out .thy files as a kind of fake build system if that?s what it takes.
The format that the default REPL uses for error messages was one that was used by various compilers at one time and it used to be possible to parse it automatically. If there's a more up-to-date format I'm happy to change to it. I don?t know if anyone is parsing the current format automatically and would be inconvenienced by a change.
Me neither. Hide it under a flag? Or are you (and Makarius) suggesting that I hand-roll my own REPL? (I?m not adverse to that either.)
thanks, peter
On Wed, 10 Dec 2014, Peter Gammie wrote:
I?m not adverse to trying out JEdit, but it seems to dodge the issues somewhat. Is anyone using it for hacking large-scale SML programs?
The largest ML program that I know of is Isabelle/HOL with all its add-on tools: even big things like the Metis prover are incorporated there. The Prover IDE is used routinely for editing Isabelle/HOL theories and ML modules -- I also made special tricks in IDE memory management to support this on current mainstream/low-end hardware with only 8 GB.
One measure of adequacy might be if JEdit/SML (err, Isabelle/SML?) can load the foundational Isabelle stuff, e.g. Pure/ROOT.ML. (How do you hack Isabelle/Pure presently?)
I don't "hack" on Isabelle/Pure, but edit it carefully and thoughtfully, using plain jEdit with its static ML mode. It is still not possible to load this ML bootstrap environment of Isabelle into Isabelle/PIDE, though. There are some partial solutions to that: many ML modules of Isabelle/Pure can be loaded individually into the Prover IDE via ML_file in Pure.thy.
In particular I?d want access to Poly/ML?s concurrency primitives. It seems to nuke Poly/ML?s ?use? function, which is a little unfriendly.
Can you explain what you mean? PolyML.use is not part of the SML standard. The Isabelle/SML environment takes care to load sources via 'SML_file' commands -- it has to do that to manage changes and versions properly.
BTW I have no problem cranking out .thy files as a kind of fake build system if that?s what it takes.
This sounds like you still think in terms of "make" files to build things. In PIDE you just assemble your project, presently by some .thy file as shown in the SML example in the Documentation panel, and then edit without further thinking about it.
An open problem is to generate a compiled application directly from this IDE model, but right now Isabelle/SML is not a specific "product" for such standalone application development yet (unless you want to ship it as Isabelle session).
Makarius
---------------------------------------------------------------------------- http://stop-ttip.org 1,127,322 people so far ----------------------------------------------------------------------------
Makarius,
On 11 Dec 2014, at 4:14, Makarius <makarius at sketis.net> wrote:
On Wed, 10 Dec 2014, Peter Gammie wrote:
I?m not adverse to trying out JEdit, but it seems to dodge the issues somewhat. Is anyone using it for hacking large-scale SML programs?
The largest ML program that I know of is Isabelle/HOL with all its add-on tools: even big things like the Metis prover are incorporated there. The Prover IDE is used routinely for editing Isabelle/HOL theories and ML modules ? I also made special tricks in IDE memory management to support this on current mainstream/low-end hardware with only 8 GB.
One measure of adequacy might be if JEdit/SML (err, Isabelle/SML?) can load the foundational Isabelle stuff, e.g. Pure/ROOT.ML. (How do you hack Isabelle/Pure presently?)
I don?t "hack" on Isabelle/Pure, but edit it carefully and thoughtfully, using plain jEdit with its static ML mode.
Sorry, my mistake.
Sounds like I might as well use emacs rather than ?plain jEdit with its static ML mode? for this purpose.
It is still not possible to load this ML bootstrap environment of Isabelle into Isabelle/PIDE, though. There are some partial solutions to that: many ML modules of Isabelle/Pure can be loaded individually into the Prover IDE via ML_file in Pure.thy.
So, err, if my little project is more like the ?ML bootstrap environment of Isabelle? and less like ?many modules of Isabelle/Pure? then ?the Prover IDE? is not going to help me, is it?
In particular I?d want access to Poly/ML?s concurrency primitives. It seems to nuke Poly/ML?s ?use? function, which is a little unfriendly.
Can you explain what you mean? PolyML.use is not part of the SML standard. The Isabelle/SML environment takes care to load sources via ?SML_file' commands -- it has to do that to manage changes and versions properly.
So I think we run the risk of the no true Scotsman fallacy here. One could argue that Isabelle is not an SML program (ah, I note you said it was the ?largest ML program that I know of?).
I don?t want to (merely) sit around splitting hairs - I want to hack a program that uses Poly/ML?s wonderful concurent/parallel runtime.
BTW I have no problem cranking out .thy files as a kind of fake build system if that?s what it takes.
This sounds like you still think in terms of "make" files to build things. In PIDE you just assemble your project, presently by some .thy file as shown in the SML example in the Documentation panel, and then edit without further thinking about it.
No, I think in terms of wonderful dependency-discovering tools like ?ghc ?make Main.hs? that go off and build my universe for me. Yes, they don?t work so well with preprocessors etc. I?m looking for the (S)ML equivalent of ghci.
I need to think about the guts of the thy file as I have to list my (S)ML files in dependency order, and every time I add another file to my project, which is common for new things.
An open problem is to generate a compiled application directly from this IDE model, but right now Isabelle/SML is not a specific ?product" for such standalone application development yet (unless you want to ship it as Isabelle session).
That takes us far away from my simple concerns about REPLs and error messages.
Thanks for all your work on this. I wish I could use it.
cheers peter
On Thu, 11 Dec 2014, Peter Gammie wrote:
On 11 Dec 2014, at 4:14, Makarius <makarius at sketis.net> wrote:
I don?t "hack" on Isabelle/Pure, but edit it carefully and thoughtfully, using plain jEdit with its static ML mode.
Sounds like I might as well use emacs rather than ?plain jEdit with its static ML mode? for this purpose.
I did this myself until 2006 and then switched to jEdit. After 2 weeks of unlearning ESCAPE-META-ALT-CONTROL-SHIFT I became much more productive with the new editor. Then I set out to make a full-scale IDE based on it: 8 years later it is there.
It is still not possible to load this ML bootstrap environment of Isabelle into Isabelle/PIDE, though. There are some partial solutions to that: many ML modules of Isabelle/Pure can be loaded individually into the Prover IDE via ML_file in Pure.thy.
So, err, if my little project is more like the ?ML bootstrap environment of Isabelle? and less like ?many modules of Isabelle/Pure? then ?the Prover IDE? is not going to help me, is it?
As I said, the Prover IDE can load many modules of Isabelle/Pure later on, as a second copy within the context of Pure.thy. I still wonder how relevant this is for users of PIDE for general ML development, even for users of Isabelle. As a user of Linux I also don't edit the kernel sources, neither do I "hack" on it.
Below Pure.thy several delicate bootstrap stages turn the raw ML system into something that can then support user-space Isabelle/ML, and now also regular Standard ML.
So I think we run the risk of the no true Scotsman fallacy here. One could argue that Isabelle is not an SML program (ah, I note you said it was the ?largest ML program that I know of?).
Isabelle/Pure is definitely not an SML program. I usually say "ML" in a general sense, and "SML" in the specific sense of SML'97.
The "largest ML program that I know of" was referring to Isabelle/HOL: it is an application of Isabelle/ML with Pure.thy as starting point.
Makarius
---------------------------------------------------------------------------- http://stop-ttip.org 1,138,652 people so far ----------------------------------------------------------------------------
There is an interesting thing here which I'd like make sure is said explicitly: if you're interested in writing ML (not SML'97 as Makarius points out), then writing your program on top of Isabelle is something you should seriously consider. You get a better build system, an IDE, and tons of very helpful libraries. One downside of using this approach is you end up with a bigger binary.
If you really want plain SML'97, then your best approach might be to cannibalize Isabelle, pull out it's build system, and hack it's IDE a little, and build your own SML'97 IDE. But this is probably quite a big task. Short of that, I'd go for using a custom PolyML use function with some modifications. This is more or less what was done for Quantomatic ( https://github.com/Quantomatic/quantomatic/blob/stable/core/ROOT.ML) - along with pulling out a bunch of the lovely Isabelle library functions. But it is worth noting that what you get here is not necessarily exactly SML'97, it's very likely to end up with some PolyML specific magic in it (at least that's how quantomatic ended up).
If I was to do Quantomatic again, I'd probably have just built it directly on Isabelle, and not worried about all the background theory stuff (main reason not to at the time was that I didn't get the benefits of the IDE as it was still early days).
best, lucas
On 12 December 2014 at 02:55, Makarius <makarius at sketis.net> wrote:
On Thu, 11 Dec 2014, Peter Gammie wrote:
On 11 Dec 2014, at 4:14, Makarius <makarius at sketis.net> wrote:
I don?t "hack" on Isabelle/Pure, but edit it carefully and thoughtfully, using plain jEdit with its static ML mode.
Sounds like I might as well use emacs rather than ?plain jEdit with its static ML mode? for this purpose.
I did this myself until 2006 and then switched to jEdit. After 2 weeks of unlearning ESCAPE-META-ALT-CONTROL-SHIFT I became much more productive with the new editor. Then I set out to make a full-scale IDE based on it: 8 years later it is there.
It is still not possible to load this ML bootstrap environment of
Isabelle into Isabelle/PIDE, though. There are some partial solutions to that: many ML modules of Isabelle/Pure can be loaded individually into the Prover IDE via ML_file in Pure.thy.
So, err, if my little project is more like the ?ML bootstrap environment of Isabelle? and less like ?many modules of Isabelle/Pure? then ?the Prover IDE? is not going to help me, is it?
As I said, the Prover IDE can load many modules of Isabelle/Pure later on, as a second copy within the context of Pure.thy. I still wonder how relevant this is for users of PIDE for general ML development, even for users of Isabelle. As a user of Linux I also don't edit the kernel sources, neither do I "hack" on it.
Below Pure.thy several delicate bootstrap stages turn the raw ML system into something that can then support user-space Isabelle/ML, and now also regular Standard ML.
So I think we run the risk of the no true Scotsman fallacy here. One
could argue that Isabelle is not an SML program (ah, I note you said it was the ?largest ML program that I know of?).
Isabelle/Pure is definitely not an SML program. I usually say "ML" in a general sense, and "SML" in the specific sense of SML'97.
The "largest ML program that I know of" was referring to Isabelle/HOL: it is an application of Isabelle/ML with Pure.thy as starting point.
Makarius
http://stop-ttip.org 1,138,652 people so far
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
On Fri, 12 Dec 2014, Lucas Dixon wrote:
If you really want plain SML'97, then your best approach might be to cannibalize Isabelle, pull out it's build system, and hack it's IDE a little, and build your own SML'97 IDE. But this is probably quite a big task.
Lucas, we've had many private discussions about that in the past, so lets continue that publicly now.
What I've done in Isabelle2014 is the following:
* The Isabelle/Pure/PIDE environment is able to include strict SML'97 modules with their own toplevel ML name space: command 'SML_file'.
* It is possible to move toplevel bindings back and forth between the Isabelle/ML and SML environment: command 'SML_import' and 'SML_export'.
In $ISABELLE_HOME/src/Tools/SML/Examples.thy there are some tiny examples to illustrate that, e.g. the Isabelle/ML function Output.writeln is re-used for SML to make output actually visible in the IDE and not get lost on bare stdout via TextIO.print etc.
Another example is to re-use the Isabelle/ML Par_List.map combinator for SML: it provides already some realistic parallel programming facility at very little cost for an existing program.
Many things can be imagined beyond this:
* Some way to single-out SML programs for standalone builds, without the Isabelle or PIDE framework around it.
* Some way to allow multiple simultaneous arguments for SML_file: the compiler could be instructed to find signature/structure/functor definitions according to certain naming conventions of source files, without requiring the usual sequential load order of the logical framework.
* Emulation of the SML/NJ make system, to allow easy inclusion of other SML projects.
As a start, I am considering to make a stand-alone Isabelle/SML/PIDE distribution next time. I have already reduced the disk footprint drastically, by using only JRE and not full JDK, and without the Isabelle/HOL image it will come out rather small.
Makarius
---------------------------------------------------------------------------- http://stop-ttip.org 1,143,454 people so far ----------------------------------------------------------------------------
Thanks for the update!
I'm going to try and update TheoryMine to the latest Isabelle, that way I'll get to play with all that cool new work you've been doing :)
On 13 December 2014 at 02:15, Makarius <makarius at sketis.net> wrote:
On Fri, 12 Dec 2014, Lucas Dixon wrote:
If you really want plain SML'97, then your best approach might be to
cannibalize Isabelle, pull out it's build system, and hack it's IDE a little, and build your own SML'97 IDE. But this is probably quite a big task.
Lucas, we've had many private discussions about that in the past, so lets continue that publicly now.
What I've done in Isabelle2014 is the following:
The Isabelle/Pure/PIDE environment is able to include strict SML'97 modules with their own toplevel ML name space: command 'SML_file'.
It is possible to move toplevel bindings back and forth between the Isabelle/ML and SML environment: command 'SML_import' and 'SML_export'.
In $ISABELLE_HOME/src/Tools/SML/Examples.thy there are some tiny examples to illustrate that, e.g. the Isabelle/ML function Output.writeln is re-used for SML to make output actually visible in the IDE and not get lost on bare stdout via TextIO.print etc.
Another example is to re-use the Isabelle/ML Par_List.map combinator for SML: it provides already some realistic parallel programming facility at very little cost for an existing program.
Many things can be imagined beyond this:
Some way to single-out SML programs for standalone builds, without the Isabelle or PIDE framework around it.
Some way to allow multiple simultaneous arguments for SML_file: the compiler could be instructed to find signature/structure/functor definitions according to certain naming conventions of source files, without requiring the usual sequential load order of the logical framework.
Emulation of the SML/NJ make system, to allow easy inclusion of other SML projects.
As a start, I am considering to make a stand-alone Isabelle/SML/PIDE distribution next time. I have already reduced the disk footprint drastically, by using only JRE and not full JDK, and without the Isabelle/HOL image it will come out rather small.
Makarius
http://stop-ttip.org 1,143,454 people so far
I've actually been updating quantomatic to take advantage of the new IDE support. It's generally pretty straightforward, since we've been emulating Isabelle's toplevel (rather than SML) for a long time now.
In terms of organisation, this is what I had in mind. Basically, we need to be able to load ~100 ML files in one of two ways. The first is within Isabelle/jEdit (IDE-style) for development. The second is to batch-process them to make a heap, for deployment as part of the Quantomatic GUI.
My thinking was to use .thy files to play the role of old-style ROOT.ML files, and have one thy file for each "logical chunk" (i.e. subdirectory) of the code, which would just contain many "ML_file" declarations. Then, for batch processing, use a shell script to turn these thy files into plain ML, essentially by deleting the front-matter and replacing "ML_file" by "use". Then, process these files these with poly, after loading our isabelle-emulation code.
Given that I want to keep isabelle strictly optional to the build process, this seems the most efficient. Any comments/pointers?
On 13 December 2014 at 13:53, Lucas Dixon <lucas.dixon at gmail.com> wrote:
Thanks for the update!
I'm going to try and update TheoryMine to the latest Isabelle, that way I'll get to play with all that cool new work you've been doing :)
On 13 December 2014 at 02:15, Makarius <makarius at sketis.net> wrote:
On Fri, 12 Dec 2014, Lucas Dixon wrote:
If you really want plain SML'97, then your best approach might be to cannibalize Isabelle, pull out it's build system, and hack it's IDE a little, and build your own SML'97 IDE. But this is probably quite a big task.
Lucas, we've had many private discussions about that in the past, so lets continue that publicly now.
What I've done in Isabelle2014 is the following:
The Isabelle/Pure/PIDE environment is able to include strict SML'97 modules with their own toplevel ML name space: command 'SML_file'.
It is possible to move toplevel bindings back and forth between the Isabelle/ML and SML environment: command 'SML_import' and 'SML_export'.
In $ISABELLE_HOME/src/Tools/SML/Examples.thy there are some tiny examples to illustrate that, e.g. the Isabelle/ML function Output.writeln is re-used for SML to make output actually visible in the IDE and not get lost on bare stdout via TextIO.print etc.
Another example is to re-use the Isabelle/ML Par_List.map combinator for SML: it provides already some realistic parallel programming facility at very little cost for an existing program.
Many things can be imagined beyond this:
Some way to single-out SML programs for standalone builds, without the Isabelle or PIDE framework around it.
Some way to allow multiple simultaneous arguments for SML_file: the compiler could be instructed to find signature/structure/functor definitions according to certain naming conventions of source files, without requiring the usual sequential load order of the logical framework.
Emulation of the SML/NJ make system, to allow easy inclusion of other SML projects.
As a start, I am considering to make a stand-alone Isabelle/SML/PIDE distribution next time. I have already reduced the disk footprint drastically, by using only JRE and not full JDK, and without the Isabelle/HOL image it will come out rather small.
Makarius
http://stop-ttip.org 1,143,454 people so far
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
On Wed, 10 Dec 2014 20:52:36 -0600, Peter Gammie <peteg42 at gmail.com> wrote:
Peter> Me neither. Hide it under a flag? Or are you (and Makarius) Peter> suggesting that I hand-roll my own REPL? (I?m not adverse to that Peter> either.)
FWIW, I have hacked Stefan's SML mode to understand PolyML error messages.
It is sad that I feel the need to say this in advance, but I won't be drawn into any debate on the usefulness or otherwise of "old-fashioned" software.
On 11 Dec 2014, at 19:26, Ian Zimmerman <itz at buug.org> wrote:
On Wed, 10 Dec 2014 20:52:36 -0600, Peter Gammie <peteg42 at gmail.com> wrote:
Peter> Me neither. Hide it under a flag? Or are you (and Makarius) Peter> suggesting that I hand-roll my own REPL? (I?m not adverse to that Peter> either.)
FWIW, I have hacked Stefan?s SML mode to understand PolyML error messages.
Yes, I should have been clearer: this is not (just) about the emacs sml-mode but the generic emacs ?compile? machinery. The latter could be educated to understand Poly/ML?s warnings and errors, or Poly/ML could conform to some ?standard?. I was sounding David out about the latter, and also about Poly/ML?s REPL.
I saw your emails in the Poly/ML archives and was hoping you?d opine about how you interact with the system.
It is sad that I feel the need to say this in advance, but I won't be drawn into any debate on the usefulness or otherwise of "old-fashioned" software.
Why not? IMHO if you?re using (S)ML you?ve already taken a substantial position in such a debate. :-)
cheers peter
On Thu, 11 Dec 2014 22:19:42 -0600, Peter Gammie <peteg42 at gmail.com> wrote:
Peter> Yes, I should have been clearer: this is not (just) about the Peter> emacs sml-mode but the generic emacs ?compile? machinery. The Peter> latter could be educated to understand Poly/ML?s warnings and Peter> errors, or Poly/ML could conform to some ?standard?. I was Peter> sounding David out about the latter, and also about Poly/ML?s Peter> REPL.
Peter> I saw your emails in the Poly/ML archives and was hoping you?d Peter> opine about how you interact with the system.
I mostly do the same as you: I have ML scripts that play the role of makefiles, by recursively sourcing ML files in a DFS of a project directory. They also spit out blurbs just like make does when it recurses, ie. "Entering directory foo" and "Leaving directory foo".
This works well enough with the Emacs compile mechanism. You know that you can have the compile command run anything, right? Not just make. So in my case the command is usually "poly < load-all.sml". With my hack Emacs can see the errors and warnings, colorizes them and makes them hot, so hitting Enter over them takes you to the error location. Or you can cycle through them in order with C-x ` just like in any other compilation. The make-like blurbs mean that this will even work for subdirectories.
As for the REPL, setting the variable sml-program-name and then using the command run-sml works for me: I get a comint-like buffer with all the usual features (mostly the searchable history) and poly as the interpreter. I may have had to add a tiny bit of code for this to Stefan's tree, I don't remember now. It definitely wasn't hard.
I haven't tried to use the debugger from Emacs yet. I guess I'll leave that for next time I feel really nostalgic (to reclaim a word I have seen used in this thread, but giving it a sweeter taste).
On 12/12/2014 04:19, Peter Gammie wrote:
On 11 Dec 2014, at 19:26, Ian Zimmerman <itz at buug.org> wrote:
On Wed, 10 Dec 2014 20:52:36 -0600, Peter Gammie <peteg42 at gmail.com> wrote:
Peter> Me neither. Hide it under a flag? Or are you (and Makarius) Peter> suggesting that I hand-roll my own REPL? (I?m not adverse to that Peter> either.)
FWIW, I have hacked Stefan?s SML mode to understand PolyML error messages.
Yes, I should have been clearer: this is not (just) about the emacs sml-mode but the generic emacs ?compile? machinery. The latter could be educated to understand Poly/ML?s warnings and errors, or Poly/ML could conform to some ?standard?. I was sounding David out about the latter, and also about Poly/ML?s REPL.
I'm sorry I gave the wrong impression in my earlier comment. By saying that I thought the approach was "rather old fashioned" I was trying to say that I felt there was now the scope to do more than simply parse text error messages. I wasn't trying to imply anything about emacs itself.
I seem to recall that the current format of error messages was designed to be parsed by emacs but probably as long ago as the 1980s. I have no objection at all to changing the format to something more appropriate. It probably needs no more than a change to the bit of code around line 443 in basis/FinalPolyML.sml that assembles a text error message from the location information. If you want to experiment and send me a patch that works for you I'm happy to look at it.
David
David,
On 14 Dec 2014, at 9:23, David Matthews <David.Matthews at prolingua.co.uk> wrote:
I seem to recall that the current format of error messages was designed to be parsed by emacs but probably as long ago as the 1980s. I have no objection at all to changing the format to something more appropriate. It probably needs no more than a change to the bit of code around line 443 in basis/FinalPolyML.sml that assembles a text error message from the location information. If you want to experiment and send me a patch that works for you I?m happy to look at it.
Here?s a very minor patch to generate Emacs-compatible errors and warnings. See below. It?s an SVN diff - hope that works for you.
cheers, peter
Index: basis/FinalPolyML.sml =================================================================== --- basis/FinalPolyML.sml (revision 1980) +++ basis/FinalPolyML.sml (working copy) @@ -441,10 +441,14 @@ else (* Plain text form. *) ( printString(concat - ( (if hard then ["Error-"] else ["Warning-"]) @ + ( (if file = "" then ["poly: "] else [file, ":"]) @ + (if startLine = 0 then [] else [Int.toString startLine]) @ + (if startPosition = 0 then [": "] else [".", Int.toString startPosition, "-", Int.toString endPosition, ": "]) @ + (if hard then ["error: "] else ["warning: "]) )); +(* ( (if hard then ["Error-"] else ["Warning-"]) @ (if file = "" then [] else [" in '", file, "',"]) @ (if startLine = 0 then [] else [" line ", Int.toString startLine]) @ - (if startLine = 0 andalso file = "" then [] else [".\n"]))); + (if startLine = 0 andalso file = "" then [] else [".\n"]))); *) PolyML.prettyPrint(printString, !lineLength) fullMessage ) end
Peter, Thanks for that. I've applied it to SVN so unless someone objects that it has messed up their error message parsing it will be in the next release. Regards, David
On 14/03/2015 20:39, Peter Gammie wrote:
David,
On 14 Dec 2014, at 9:23, David Matthews <David.Matthews at prolingua.co.uk> wrote:
I seem to recall that the current format of error messages was designed to be parsed by emacs but probably as long ago as the 1980s. I have no objection at all to changing the format to something more appropriate. It probably needs no more than a change to the bit of code around line 443 in basis/FinalPolyML.sml that assembles a text error message from the location information. If you want to experiment and send me a patch that works for you I?m happy to look at it.
Here?s a very minor patch to generate Emacs-compatible errors and warnings. See below. It?s an SVN diff - hope that works for you.
cheers, peter
Index: basis/FinalPolyML.sml
--- basis/FinalPolyML.sml (revision 1980) +++ basis/FinalPolyML.sml (working copy) @@ -441,10 +441,14 @@ else (* Plain text form. *) ( printString(concat
( (if hard then ["Error-"] else ["Warning-"]) @
( (if file = "" then ["poly: "] else [file, ":"]) @(if startLine = 0 then [] else [Int.toString startLine]) @(if startPosition = 0 then [": "] else [".", Int.toString startPosition, "-", Int.toString endPosition, ": "]) @(if hard then ["error: "] else ["warning: "]) ));+(* ( (if hard then ["Error-"] else ["Warning-"]) @ (if file = "" then [] else [" in '", file, "',"]) @ (if startLine = 0 then [] else [" line ", Int.toString startLine]) @
(if startLine = 0 andalso file = "" then [] else [".\n"])));
(if startLine = 0 andalso file = "" then [] else [".\n"]))); *) PolyML.prettyPrint(printString, !lineLength) fullMessage ) end
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
My Makefiles contain something like the following:
@set -o pipefail ; \ poly --use load.sml \ | tee polyml.log \ | (grep -E -e "^(Warning-|Error-|Exception-)" || true)
The primary purpose is to print any warnings in the terminal as they are produced whilst redirecting the full log to a file for reference. (I don't like this because it's necessary to use the Bash-specific option "pipefail" to prevent piping losing the exit status and this doesn't work with other shells like Dash.)
Is there a way to tell Poly/ML to print warning/error message to stderr as well as stdout? That would avoid needing to match on the
I don't have any objection to the patch however - the above is easily changed.
Phil
15/03/15 14:38, David Matthews wrote:
Peter, Thanks for that. I've applied it to SVN so unless someone objects that it has messed up their error message parsing it will be in the next release. Regards, David
On 14/03/2015 20:39, Peter Gammie wrote:
David,
On 14 Dec 2014, at 9:23, David Matthews <David.Matthews at prolingua.co.uk> wrote:
I seem to recall that the current format of error messages was designed to be parsed by emacs but probably as long ago as the 1980s. I have no objection at all to changing the format to something more appropriate. It probably needs no more than a change to the bit of code around line 443 in basis/FinalPolyML.sml that assembles a text error message from the location information. If you want to experiment and send me a patch that works for you I?m happy to look at it.
Here?s a very minor patch to generate Emacs-compatible errors and warnings. See below. It?s an SVN diff - hope that works for you.
cheers, peter
Index: basis/FinalPolyML.sml
--- basis/FinalPolyML.sml (revision 1980) +++ basis/FinalPolyML.sml (working copy) @@ -441,10 +441,14 @@ else (* Plain text form. *) ( printString(concat
( (if hard then ["Error-"] else ["Warning-"]) @
( (if file = "" then ["poly: "] else [file, ":"]) @(if startLine = 0 then [] else [Int.toStringstartLine]) @
(if startPosition = 0 then [": "] else [".",Int.toString startPosition, "-", Int.toString endPosition, ": "]) @
(if hard then ["error: "] else ["warning: "]) ));+(* ( (if hard then ["Error-"] else ["Warning-"]) @ (if file = "" then [] else [" in '", file, "',"]) @ (if startLine = 0 then [] else [" line ", Int.toString startLine]) @
(if startLine = 0 andalso file = "" then [] else[".\n"])));
(if startLine = 0 andalso file = "" then [] else[".\n"]))); *) PolyML.prettyPrint(printString, !lineLength) fullMessage ) end _______________________________________________ polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
-
aleks0＠gmail.com -
David.Matthews＠prolingua.co.uk -
dm＠prolingua.co.uk -
itz＠buug.org -
lucas.dixon＠gmail.com -
makarius＠sketis.net -
monnier＠iro.umontreal.ca -
peteg42＠gmail.com -
phil.clayton＠lineone.net