Unexpected whitespace sensitivity in ob-sml

[dpkatz]

Extra whitespace in source blocks seems to matter to ob-sml in unexpected ways (at least when interacting with smlnj). Here's an org file that shows the issue:

* A problem with ob-sml?
In general, if I evaluate expressions in a BEGIN_SRC/END_SRC block,
I expect that whitespace in the block will matter only to the extent
that it matters in the language.  I seem to be seeing something else
in ob-sml as it currently stands, at least when dealing with smlnj.
Here are some test cases.

emacs           : 24.3.50.1
ob-sml Version  : 20130612.22
SML     : smlnj 110.74 on linux and 110.75 on OS X
sml-mode    : 6.4

** Case with no white-line between BEGIN_SRC and code
I expect the results block to get '5 : int'.  Instead, I get, well,
something somewhat less useful.
#+BEGIN_SRC sml
2 + 3;
#+END_SRC

#+RESULTS:
: val it = "stdIn" : string

** Case with 1 white-line between BEGIN_SRC and code
Adding a whitespace line helps?
#+BEGIN_SRC sml

2 + 3;
#+END_SRC

#+RESULTS:
: val it = 5 : int

** Case with 2 white-lines between BEGIN_SRC and code
Notice the new "-" sign in the result.
#+BEGIN_SRC sml

2 + 3;
#+END_SRC

#+RESULTS:
: - val it = 5 : int

** Case with 3 white-line between BEGIN_SRC and code
Add one more whiteline, get one more "-" sign.

#+BEGIN_SRC sml

2 + 3;
#+END_SRC

#+RESULTS:
: - - val it = 5 : int

[michiakig]

I just opened a pull request that fixes part of this issue -- the leading dashes. You can fix the other ("stdIn") by simply removing the semicolon from your source blocks. It's caused by some quirks of the way Babel and SML/NJ interact and how the output of SML/NJ is cleaned up before turning into the results block.

I think you should almost never need to add a semicolon to the end of a source block, unless something changes with the interactive prompt for SML/NJ. For instance:

#+BEGIN_SRC sml
  datatype 'a option = Some of 'a | None
  datatype ('a, 'b) either  = Left of 'a | Right of 'b
#+END_SRC

ob-sml.el will add a single semi colon to the end of this before sending it to SML/NJ, which is all you need. I think this is preferred since it will be exported (or tangled) to produce the same code you would write in a regular source file, i.e. with semicolons only where absolutely necessary (imperative code).