Re: Some ATS code for Book "Getting Started with Arduino"
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 > 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
>>> 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 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 digit
Re: Some ATS code for Book "Getting Started with Arduino"
>>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
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
>> 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 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
>>>
Re: Some ATS code for Book "Getting Started with Arduino"
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 > 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 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
>>
>>
>> .
>>
>
>
--
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.
Re: Some ATS code for Book "Getting Started with Arduino"
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
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 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-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/4c40b2a5-f8ce-4580-8792-ad909502861a%
> 40googlegroups.com
>
> .
>
--
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/CAPPSPLogjsn6FpSo_R2WqX%2B-0XQ35x4fLVgQqAJUNk9iUSh4gw%40mail.gmail.com.
Re: Some ATS code for Book "Getting Started with Arduino"
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 >
> 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-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/4c40b2a5-f8ce-4580-8792-ad909502861a%40googlegroups.com.
