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 <[email protected] > <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 <[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/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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <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 [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/5c5eeba4-b53b-4ebb-ac1f-a9af22d30110%40googlegroups.com.
