9

I'm new to SML and in debugging I usually print out the variable to see if it matches up to what I expected it should be. I would like to print out a variable within a function
what i have is this :
function header..

let val prod 
 val prod = c + x * y;
in 
 (print "product "; prod mod 10):: (multiplyAux (prod div 10) xs y)
end;


Right now its printing the string product, but I would like to be able to print the variable prod itself.

user4348719
  • 351
  • 1
  • 2
  • 13

1 Answers1

11

The only thing that print can print is strings. So to print a numeric value, it must first be converted to a string. For example:

- print("product " ^ (Int.toString (43 mod 5)) ^ "\n");
product 3
val it = () : unit

Note that Int.toString uses the curried function syntax (i.e. it does not require a tuple for it's argument) so the parenthesis around 43 mod 5 are to make the value clear not to make Int.toString work.

- Int.toString 5;
val it = "5" : string
ben rudgers
  • 3,647
  • 2
  • 20
  • 32
  • 6
    I would +1 this, but for the odd statement that "`Int.toString` is a curried function"; that term does not mean what you think. (See http://en.wikipedia.org/wiki/Currying.) The reason the parentheses are needed is that prefix function application has higher precedence than infix. – ruakh Feb 14 '15 at 06:31
  • I think you both agree, just express it differently. Ben has a good point to make about parentheses not being required when calling functions, and you have a good point to make that `Int.toString` is not curried because it takes a single argument anyway (all SML functions take a single argument though). – Ionuț G. Stan Feb 14 '15 at 15:00
  • @ruakh I did not try to imply anything. – Ionuț G. Stan Feb 15 '15 at 00:43
  • @ruakh right, I phrase that poorly. What I meant was that `Int.toString` conceptually needs a single argument to do its job, as opposed to `op+`, for example, which needs two arguments conceptually, even though it's defined to take a single one (a tuple). That's why I think one can talk about a curried version of `op+`, but not about a curried version of `Int.toString`. – Ionuț G. Stan Feb 15 '15 at 01:02
  • @IonuțG.Stan: Ah, O.K., I think I see what you're saying; and yes, I agree. :-) – ruakh Feb 15 '15 at 01:28
  • @ruakh I was thinking syntactically and using "curried" in the sense of passing a tuple as argument as **Ionut G. Stan** surmised. I have clarified my answer. Thanks. – ben rudgers Feb 16 '15 at 18:53
  • @benrudgers: Your clarified answer has the same problem. "Curried" does not have the sense that you want it to have. (As Ionuț says: "one can talk about a curried version of `op+`, but not about a curried version of `Int.toString`".) – ruakh Feb 16 '15 at 20:57
  • @ruakh So far as I am aware, the SML community lacks a term to describe the **variation in syntax.** If I was aware of a better alternative that captures the syntactic difference, I would use it. What term do you propose as replacement? – ben rudgers Feb 16 '15 at 23:11
  • @benrudgers I think it's better to say that function application is syntactically denoted by whitespace characters between a function value and its argument, not by a pair of parentheses. – Ionuț G. Stan Feb 16 '15 at 23:40
  • 1
    @benrudgers: I think the reason we lack a term for that variation in syntax is that we also lack that variation in syntax. You seem to be thinking that if a function's argument is a tuple, then the argument is indicated using parentheses? But that's not the case. It's just that the tuple notation itself involves parentheses. Note that `foo (bar, baz)` is equivalent to `foo (((bar, baz)))` or to `foo { 1: bar, 2: baz }`. – ruakh Feb 17 '15 at 01:13
  • @ruakh But neither will work when `foo bar baz` does. What term describes *that* syntax better? – ben rudgers Feb 17 '15 at 03:19
  • @benrudgers: `foo bar baz` is curried: it takes multiple arguments, effectively, by returning an intermediate function. `foo (bar, baz)` is not curried: it takes multiple arguments, effectively, also, but by taking a tuple. `Int.toString` is not curried, either: it takes just one argument, and likes it! – ruakh Feb 17 '15 at 03:33
  • 1
    (I guess what I'm saying is -- I don't see what commonality you see between unary functions and curried ones, as opposed to ones that take tuples, that makes you want to extend the word "curried" to cover unary functions. But even if I did see it, I'd say that trying to repurpose the word "curried" doesn't serve the goal of communicating it.) – ruakh Feb 17 '15 at 03:38