legacy
legacy copied to clipboard
smlnj
REPL should always print reals as valid SML real literals.
Version
110.99.6.1 (Latest)
Operating System
- [X] Any
- [ ] Linux
- [ ] macOS
- [ ] Windows
- [ ] Other Unix
OS Version
No response
Processor
- [X] Any
- [ ] Arm (using Rosetta)
- [ ] PowerPC
- [ ] Sparc
- [ ] x86 (32-bit)
- [ ] x86-64 (64-bit)
- [ ] Other
System Component
Core system
Severity
Cosmetic
Description
The REPL uses Real.toString to format real numbers when printing, but this means that some reals are printed without a decimal point. The REPL should print results that have correct SML syntax, even when they are less concise.
Transcript
Standard ML of New Jersey [Version 110.99.6.1; 64-bit; October 25, 2024]
- 1.0;
val it = 1 : real
Expected Behavior
Standard ML of New Jersey [Version 110.99.6.1; 64-bit; October 25, 2024]
- 1.0;
val it = 1.0 : real
Steps to Reproduce
Type an integer-valued real literal into the REPL.
Additional Information
Fixing this issue will probably require a special implementation of real to string conversions in the REPL printer.
Email address
As far as Real.toString is concerned, I comment here to note that implementations differ on this. For this function: fun real2() = print(Real.toString (real 2)), SML/NJ 110.99.7.1 prints 2, MLton prints 2, but PolyML prints 2.0, and SOSML (on the web) prints 2.0. This variation seems problematic, but I don't know if the proper result for this is defined. EDIT: I read your and Ganser's The Standard ML Basis Library, p. 367, as saying in effect it should be 2, not 2.0 .
Interesting experiment. I believe it is a choice of implementation whether SML/NJ goes to printed 2.0 as just 2 as MLton does. But this change makes it harder to writie code generating a sml code dealing with real literals. In fact, yesterday I faced to many type errors in codes generated by my existing code (for example, you have Math.sqrt(1 + xx) instead of Math.sqrt(1.0 + xx) ), and it took several hours to find the thing is Real.toString.
It seems to me you are talking about the representation of code that is printed by the interactive system after a declaration followed by a semicolon and newline. The contents of the interactive printout is not guaranteed to be an exact representation of what was interactively entered, or even to be semantically equivalent. In other words, we don't guarantee successful "round tripping" where the compiler prints our a correct and semantically equivalent representation of the code that was entered (either interactively via stdin or from a file.). There are features of the language that make round-tripping tricky to successfully implement, especially for an isolated fragment of code without context. This should be made clearer in the documentation of the system. The moral is, don't depend on code that is outputted by the compiler to be correct or to be equivalent to the code that was entered. Sorry if I misunderstood the point of the bug report or your comments.
Nevertheless, it does seem that it would be best for Real.toString to produce a string representation that would be valid notation for a real number when input, so I agree that it should be "2.0" rather than "2".
