[MLton-user] 'a ref for C programmers: a primer

[Wesley W. Terpstra]

On Feb 12, 2007, at 7:24 PM, Tom 7 wrote:
> Instead I'd concentrate on the concept of a value. Variables are  
> always bound to values. Some values are immutable and can never  
> change, like integers and lists of immutable values. Some values  
> can change, like arrays or open files. The same value may be bound  
> to multiple variables, or appear in other aggregate values (lists,  
> tuples, arrays). If a mutable value is changed and that same value  
> is accessible in multiple ways, they'll all see the change because  
> they're looking at the same value.

I was never comfortable with this explanation. When I first learned  
SML, I found it very confusing. I already knew C and assembler, and I  
couldn't see how this 'value thing' could work. While I agree it's a  
good explanation for a novice programmer, I think a more advanced  
programmer will demand answers about how this language relates to  
what he already knows.

What really bothers me about the 'value' explanation is that it  
completely dodges the issue of lifetime and sharing. Armed only with  
the value explanation, these appear to be magic.

> Of course, if you're interested in the run-time memory layout of  
> your program, then you need to know about the many ways that MLton  
> might choose to compile your program. It's true that this is  
> complicated, so I think it's a good reason to not involve it in the  
> understanding of the meaning of 'a ref and variable bindings, but  
> only as a pragmatic issue of writing efficient programs when it is  
> necessary to tune them at that level.

Yes, at some point a programmer needs to know what lives between his  
high-level code and the bare metal.

Is there an intermediate explanation between the 'value' one and the  
memory-layout one I described?