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 <brandon...@gmail.com
>> 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> wrote:
>>> > Instead of treating a pin as a number, we can treat it as a linear
>>> > 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:
>>> > fun pinMode(!pin(n, i) >> !pin(n, j), mode: int(j)): void // for INPUT
>>> > OUTPUT
>>> > fun digitalRead (!pin(n, 0)): int //  for INPUT
>>> > fun digitalWrite (!pin(n, 1), data: int): void //  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
>>> 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
>> To post to this group, send email to ats-lan...@googlegroups.com
>> Visit this group at https://groups.google.com/group/ats-lang-users.
>> To view this discussion on the web visit
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit