>>In the second case, then, I guess what I'm suggesting is that the same name shouldn't be allowed to bind more than once in the same scope.
This really a taste, I would argue. When coding in Java, I use a lot of 'final' variables. I find it annoying that two 'final' variables can not have the same name if declared in the same scope. Someone writing C may do: int x = 0; x = x + 1; But a functional programmer (e.g, myself) would do val x = 0 val x = x + 1 It is the compiler's job to allocate the same location or register for the two x's (because their use do not overlap). In Java, I would write final int x = 0 final int x = x + 1 // this one is not allowed!!! When C was invented, machines were simple and a programmer could do very well by allocating variables manually. These days, it is no longer the case. One needs compiler support anyway. A programmer should just write code in a functional style and let the compiler take over allocation of variables completely. On Sun, Mar 11, 2018 at 8:50 AM, Brandon Barker <[email protected]> wrote: > Ah, right, I'm still warming up to having "=" used for both assignment and > equality depending on placement, sorry for the mixup. > > In the second case, then, I guess what I'm suggesting is that the same > name shouldn't be allowed to bind more than once in the same scope. > > On Sunday, March 11, 2018 at 8:46:18 AM UTC-4, gmhwxi wrote: >> >> There are no assignments here. >> >> The following line binds '_' to the value 'true': >> >> val _ = xx = 2 >> >> xx = 2 is a boolean expression; it is not assignment. >> >> Also, the following line means creating a name yy for the >> value 1: >> >> val yy: int = 1 >> >> Again, no assignment. For assignments, you need to change >> 'val' to 'var'. >> >> >> On Sun, Mar 11, 2018 at 8:16 AM, Brandon Barker <[email protected]> >> wrote: >> >>> 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 >>> >>> implement >>> 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 <[email protected]> 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 >>>> > OUTPUT >>>> > >>>> > 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/ats-lang-users. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/ats-lang-users/4c40b2a5-f8ce-4580-8792-ad909502861a%40go >>> oglegroups.com >>> <https://groups.google.com/d/msgid/ats-lang-users/4c40b2a5-f8ce-4580-8792-ad909502861a%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/ats-lang-users. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/ats-lang-users/f7a9d068-4d5a-426c-b262-5d940957ea50% > 40googlegroups.com > <https://groups.google.com/d/msgid/ats-lang-users/f7a9d068-4d5a-426c-b262-5d940957ea50%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/ats-lang-users. To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAPPSPLqVd2hcBf7hk34HCAGQrHReFUj8CH5odovEDmtJ620qZw%40mail.gmail.com.
