Maybe now isn't the time, but perhaps (in ATS2 or ATS3) there could be 
scope-based or project-based overrides for certain linting. For instance, 
the following library is a build plugin and a normal 
library: http://www.wartremover.org/doc/install-setup.html

In the first sense, as a build plugin, it does project-wide handling of 
certain "warts",

However, as a library, you can use Java-like annotations to supress errors 
and warnings.

I suspect it is probably easier to support something like this at the 
compiler level (which, I believe, dotty intends to do for "Scala 3").

On Sunday, March 11, 2018 at 9:06:13 AM UTC-4, gmhwxi wrote:
>
>
> >>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...@gmail.com 
> <javascript:>> 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/msgid/ats-lang-users/4c40b2a5-f8ce-4580-8792-ad909502861a%40googlegroups.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-user...@googlegroups.com <javascript:>.
>> To post to this group, send email to ats-lan...@googlegroups.com 
>> <javascript:>.
>> 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/5c5eeba4-b53b-4ebb-ac1f-a9af22d30110%40googlegroups.com.

Reply via email to