On Fri, 29 Mar 2013, Rob Arthan wrote:
On 29 Mar 2013, at 11:50, David Matthews
<david.matth...@prolingua.co.uk> wrote:
On 29/03/2013 08:42, Gergely Buday wrote:
Back to the original question: this is why I would like to suppress
any compiler message.
I did not find such a flag in the manual, would it be possible to add
one, David?
There have been a few suggestions for how to write your own top level
and that's definitely the best way if you really want control over the
output. I've just committed a change so that the -q option now sets
PolyML.print_depth to zero so that by default the output won't be
printed. To suppress the prompt you would be better off using the
--use option to run the file directly. You will need to add
OS.Process.exit OS.Process.success: unit; at the end if you don't want
to enter the main read-eval-print-loop.
Quite a common thing to do in UN*X applications is not to prompt if the
input isn't a terminal. Obviously, I can write my own read-eval-print
loop that does that (indeed the read-eval-print loop in my earlier post
on this topic doesn't prompt at all), but it might be a nice companion
to the change you have just made to make the top level do that out of
the box. That would give Gergely Buday exactly what he is asking for
(i.e., the ability to have poly read code from the standard input and
only output what the compiled code outputs).
Note that for a full stand-alone solution, Gergely also needs to take care
of the shebang line in the ML "script".
Anyway, looking at the bigger picture, the general question is how much
conventional Unixoid behaviour Poly/ML should provide by default. Using
it as script interpreter is one thing. Doing cc-like compilation of
object modules and executables is another.
People have occasionally pointed out to me that the bias of Poly/ML to the
good old image dumping looks very alien to the man on the street.
Systems like OCaml imitate the compile/link phase of cc more faithfully,
which gives many people a better feeling. (I am personally not very
excited about how OCaml compilation works.)
One could do a little bit here by including certain polyml options or
shell scripts by default, to address both the scripting and the
batch-compilation problem in a way that looks familiar to the masses.
Makarius
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
