I still find this behavior to be a bit surprising:

#include "share/atspre_staload.hats"

fun immval(): void = let
 val xx: int = 1
 val _ = xx = 2
 val yy: int = 1
 val yy: int = 2
in (
 println!("xx is ", xx);
 println!("yy is ", yy)
) end

main0 () = immval()

The result of running this is

xx is 1                                                                     
yy is 2   

I'm not against scope-based shadowing either as in the pattern match 
Hongwei showed above, but personally would prefer if neither of the 
examples I list were possible; for instance, Scala allows the kind of 
shadowing we see in the pattern match as the interior of a match case 
introduces a new scope. But, it doesn't allow the two variants I show. The 
first assignment (xx) seems to do nothing I can tell, so ideally would be a 
typecheck error to let the user know something isn't quite right with what 
they are attempting. The second case (yy) is what we already discussed, and 
seems even more blatant. This could be fixed by having a separate concept 
for immutable values, perhaps. Either call it e.g. "ival" for immutable 
value or, again, ideally just "val" and keep the current functionality in 
something called "mval" that allows this form of shadowing (or possibly, in 
place of the shadowing, prefer the explicit mutation in the case of (xx) 
for "mval" assignments).

On Friday, April 24, 2015 at 5:43:52 AM UTC-4, Kiwamu Okabe wrote:
> Hi Hongwei, 
> On Fri, Apr 24, 2015 at 12:09 AM, gmhwxi <gmh...@gmail.com <javascript:>> 
> wrote: 
> > Instead of treating a pin as a number, we can treat it as a linear 
> resource: 
> > 
> > absvtype pin(int(*n*), int(*i/o*)) 
> > 
> > fun pin_take(int(n)): pin(n,~1) // get the resource 
> > fun pin_return(pin(n, i)): void  // return the resource // ~1: 
> uninitialized 
> > 
> > fun pinMode(!pin(n, i) >> !pin(n, j), mode: int(j)): void // for INPUT 
> or 
> > 
> > fun digitalRead (!pin(n, 0)): int // [0] for INPUT 
> > fun digitalWrite (!pin(n, 1), data: int): void // [1] for OUTPUT 
> > 
> > This probably looks too heavy handed. My original intent is to use the 
> > interface to 
> > teach linear types. 
> Thank's for your advice. 
> Totally I have less experiment on absvtype. 
> I should try more simple example in "Introduction to Programming in ATS". 
> Thank's, 
> -- 
> Kiwamu Okabe at METASEPI DESIGN 

You received this message because you are subscribed to the Google Groups 
"ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ats-lang-users+unsubscr...@googlegroups.com.
To post to this group, send email to ats-lang-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit 

Reply via email to