>>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 <brandon.bar...@gmail.com>
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 <brandon...@gmail.com>
>> 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 <gmh...@gmail.com> 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 ats-lang-user...@googlegroups.com.
>>> 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 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 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 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 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 
https://groups.google.com/d/msgid/ats-lang-users/CAPPSPLqVd2hcBf7hk34HCAGQrHReFUj8CH5odovEDmtJ620qZw%40mail.gmail.com.

Reply via email to