When using $UN.cast, it is helpful if you can provide a type argument.
For instance,
$UN.cast{int}(xyz), $UN.cast{double}(xyz), $UN.cast{List0(int)}(xyz), etc.
Otherwise, it can be difficult for the reader to figure out the type of the
result after
casting.On Wed, Apr 22, 2015 at 8:49 AM, Kiwamu Okabe kiw...@debian.or.jp wrote:
Hi all,
I wrote some ATS code to convert sample code of Book āGetting Started
with Arduinoā.
Yes, Java does not allow it, which I find to be very annoying.
That is why we urgently need atscc2java :)On Thursday, April 23, 2015 at 1:35:34 PM UTC-4, Brandon Barker wrote:
On Thu, Apr 23, 2015 at 1:09 PM, gmhwxi <gmh...@gmail.com <javascript:>> wrote:
On Thursday, April 23, 2015 at 12:26:18 PM UTC-4, Raoul Duke wrote:
Well, this can be a feature as well
Imagine the following scenario: #include āfoo.satsā // [delay] is already declared here
fun delay (ā¦): void = "mac#
A warning sounds reasonable. As I see it, the right place for
handling this is in some kind of IDE.
My knee jerk reaction is to disagree and still think it must be a
compile time error.
Well, the current handling of the issue is consistent with the principle
of lexical scoping. I assume that you have no objection to the legality
of the following code:
val x = 1
val x = 2
Then it is only natural to handle the following declarations similarly:
fun foo : int ā int
fun foo : (int, int) ā int
Yes, it is most likely that a mistake is made if some writes this kind of
stuff. But ā¦
Let us imagine that the code is automatically generated (instead of being
written
manually).
If it were stated in the C standard that a vacuous label is illegal, then
compiling into
C would have been a lot more difficult.
If I understand correctly, Kotlin and Scala and others all use the
convention that val is immutable and var is mutable, so that
val x = 1
val x = 2
would not compile. Additionally, there seem to be translators going from
Java to both of these languages that arenāt flawless but work fairly well -
still, I take your word for it, just wanted to point this out.
Now let us dream contexts where I might cave in. E.g. if thereās no
such thing as namespaces, then things are so bad already that we are
forced to do / allow otherwise insanely bad habits, I guess.
BTW is there an ATS lang spec somewhere? I could not find it in 2
minutes of looking on the web site. Iām a nerd and want that stuff
readily available.
fun sum (xs: List(int)): int
case+ xs of
| list_nil () => 0
| list_cons (x, xs) => x + sum(xs)
Yes, I can always write:
| list_cons (x, xs2) => x + sum(xs2)
But I consider it to be inferior. Shdowing xs prevents it from being
used by mistake.On Thursday, April 23, 2015 at 1:45:34 PM UTC-4, Raoul Duke wrote:
val x = 1
val x = 2
If those are in the same scope then they should at least generate a
warning. Personally I want those to be an outright error. Ditto having
a local var that is the same name as a function input name. Etc.
Shadowing is long-term bad. Even scoped shadowing is something I worry
about, quite seriously, although I donāt currently say we should
disallow it.
pseudocode:
{ val x = 1 { val x = 2; print(x); } }
is ethically very different than
{ val x = 1; val x = 2; print(x); }
in my mind.
Even if those are āvarsā instead of āvalsā per Scala et. al., I
generally consider shadowing to be badness/madness.
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.On Thursday, April 23, 2015 at 10:18:20 AM UTC-4, Kiwamu Okabe wrote:
Hi Brandon,
On Thu, Apr 23, 2015 at 10:46 PM, Brandon Barker <brand...@gmail.com <javascript:>> wrote:
I think the idea is that you will get a typechecking error if you now
try to use digitalRead2 on a write-only pin or vice versa for
digitalWrite2?
Yes. I think I understand it.
However I canāt imagine the application codeā¦
Well, this can be a feature as well
Imagine the following scenario: #include āfoo.satsā // [delay] is already declared here
fun delay (ā¦): void = "mac#
A warning sounds reasonable. As I see it, the right place for
handling this is in some kind of IDE.
My knee jerk reaction is to disagree and still think it must be a
compile time error.
Well, the current handling of the issue is consistent with the principle
of lexical scoping. I assume that you have no objection to the legality
of the following code:
val x = 1
val x = 2
Then it is only natural to handle the following declarations similarly:
fun foo : int ā int
fun foo : (int, int) ā int
Yes, it is most likely that a mistake is made if some writes this kind of
stuff. But ā¦
Let us imagine that the code is automatically generated (instead of being
written
manually).
If it were stated in the C standard that a vacuous label is illegal, then
compiling into
C would have been a lot more difficult.
fun delay(ms: ulint): void = āmac#ā fun delay(us: uint): void = āmac#ā
The second one overwrites the first one.
Try something like:
fun delay_uint (uint): void = āmac#ā
fun delay_ulint (ulint): void = āmac#ā
overload delay with delay_uint
overload delay with delay_ulintOn Thursday, April 23, 2015 at 7:21:08 AM UTC-4, Kiwamu Okabe wrote:
Hi Hongwei,
On Wed, Apr 22, 2015 at 9:59 PM, Hongwei Xi <gmh...@gmail.com <javascript:>> wrote:
When using $UN.cast, it is helpful if you can provide a type argument.
For instance,
$UN.cast{int}(xyz), $UN.cast{double}(xyz), $UN.cast{List0(int)}(xyz),
etc.
ā¦ However, following change will occur type errorā¦ Why?
$ git diff | cat
diff --git a/demo/06a_analoginput_blink/DATS/main.dats
b/demo/06a_analoginput_blink/DATS/main.dats
index 2ac2d57ā¦74e703f 100644
ā a/demo/06a_analoginput_blink/DATS/main.dats
+++ b/demo/06a_analoginput_blink/DATS/main.dats
@@ -11,7 +11,7 @@ implement main () = {
fun loop () = {
val w = analogRead (SENSOR)
val () = digitalWrite (LED, HIGH)
val () = delay ($UN.cast w)
val () = delay ($UN.cast{ulint}(w))
val () = digitalWrite (LED, LOW)
val () = delay ($UN.cast w)
val () = loop ()
$ make
āshipā
patsopt -o DATS/main_dats.c.tmp -d DATS/main.dats
/home/kiwamu/src/arduino-ats/demo/06a_analoginput_blink/DATS/main.dats:
314(line=14, offs=21) ā 331(line=14, offs=38): warning(3): the
constraint [S2Eeqeq(S2Eextkind(atstype_ulint);
S2Eextkind(atstype_uint))] cannot be translated into a form accepted
by the constraint solver.
/home/kiwamu/src/arduino-ats/demo/06a_analoginput_blink/DATS/main.dats:
314(line=14, offs=21) ā 331(line=14, offs=38): error(3): unsolved
constraint: C3NSTRprop(main; S2Eeqeq(S2Eextkind(atstype_ulint);
S2Eextkind(atstype_uint)))
typechecking has failed: there are some unsolved constraints: please
inspect the above reported error message(s) for information.
exit(ATS): uncaught exception:
_2home_2kiwamu_2src_2ATS_2dPostiats_2src_2pats_error_2esats__FatalErrorExn(1025)
ā¦/ā¦/Makefile.common:61: recipe for target āDATS/main_dats.cā failed
implement main () = {
fun loop () = {
val b = digitalRead (BUTTON)
val () = digitalWrite (LED, b)
val () = loop ()
}
val () = pinMode (LED, OUTPUT)
val () = pinMode (BUTTON, INPUT)
val () = loop ()
}
Clearly, digitalRead should only be called on an output pin.
So you may introduce an abstract type:
absvtype pin(int) // linear type // 0/1: input/output
Then do:
fun digitalRead2 (!pin(OUTPUT)): int = āmac#digitalReadā
fun digitalWrite2 (!pint(INPUT), int): void = āmac#digitalWriteā
It should now be clear where I am headed
The problem is that Arduino programs tend to be simple and small.
There is not a lot of motivation for using advanced types in ATS.On Wednesday, April 22, 2015 at 8:50:08 AM UTC-4, Kiwamu Okabe wrote:
Hi all,
I wrote some ATS code to convert sample code of Book āGetting Started
with Arduinoā.
But I consider it to be inferior. Shdowing xs prevents it from being
used by mistake.
I see what you mean.
As in all such things, damned if you do & damned if you donāt. With
shadowing we can have mistakes. Without shadowing we can have
mistakes. I do not know enough to know when to choose which, taking in
to consideration the full context every time: host syntax, target
syntax, etc.
And I do find Erlangās single assignment to be noisy, but on the other
hand I believe Iāve see enough damage from not doing that kind of
thing to respect Erlangās choice (though see e.g. Reia discussions).
Still, I would rather somebody (someday somewhere) try to see what
could be done instead of allowing shadowing like in your example. If
we donāt allow shadowing what could be done to manage / avoid /
prevent / detect any mistakes where we use xs instead of xs2? A
usability question.
Ah yes, thanks for the reminder (as I attempt to do functional programming
to the extent possible in Java). I do seem to recall Kotlin had to roll
their own TCO, but didnāt find the details.On Thu, Apr 23, 2015 at 6:13 PM, gmhwxi gmh...@gmail.com wrote:
By the way, Java 8 does not do tail-call optimization.
Very annoying.
On Thursday, April 23, 2015 at 2:16:52 PM UTC-4, gmhwxi wrote:
Yes, Java does not allow it, which I find to be very annoying.
That is why we urgently need atscc2java
On Thursday, April 23, 2015 at 1:35:34 PM UTC-4, Brandon Barker wrote:
On Thursday, April 23, 2015 at 12:26:18 PM UTC-4, Raoul Duke wrote:
Well, this can be a feature as well
Imagine the following scenario: #include āfoo.satsā // [delay] is already declared here
fun delay (ā¦): void = "mac#
A warning sounds reasonable. As I see it, the right place for
handling this is in some kind of IDE.
My knee jerk reaction is to disagree and still think it must be a
compile time error.
Well, the current handling of the issue is consistent with the principle
of lexical scoping. I assume that you have no objection to the legality
of the following code:
val x = 1
val x = 2
Then it is only natural to handle the following declarations similarly:
fun foo : int ā int
fun foo : (int, int) ā int
Yes, it is most likely that a mistake is made if some writes this kind
of stuff. But ā¦
Let us imagine that the code is automatically generated (instead of
being written
manually).
If it were stated in the C standard that a vacuous label is illegal,
then compiling into
C would have been a lot more difficult.
If I understand correctly, Kotlin and Scala and others all use the
convention that val is immutable and var is mutable, so that
val x = 1
val x = 2
would not compile. Additionally, there seem to be translators going from
Java to both of these languages that arenāt flawless but work fairly well -
still, I take your word for it, just wanted to point this out.
Now let us dream contexts where I might cave in. E.g. if thereās no
such thing as namespaces, then things are so bad already that we are
forced to do / allow otherwise insanely bad habits, I guess.
BTW is there an ATS lang spec somewhere? I could not find it in 2
minutes of looking on the web site. Iām a nerd and want that stuff
readily available.
On Thursday, April 23, 2015 at 12:26:18 PM UTC-4, Raoul Duke wrote:
Well, this can be a feature as well
Imagine the following scenario: #include āfoo.satsā // [delay] is already declared here
fun delay (ā¦): void = "mac#
A warning sounds reasonable. As I see it, the right place for
handling this is in some kind of IDE.
My knee jerk reaction is to disagree and still think it must be a
compile time error.
Well, the current handling of the issue is consistent with the principle
of lexical scoping. I assume that you have no objection to the legality
of the following code:
val x = 1
val x = 2
Then it is only natural to handle the following declarations similarly:
fun foo : int ā int
fun foo : (int, int) ā int
Yes, it is most likely that a mistake is made if some writes this kind
of stuff. But ā¦
Let us imagine that the code is automatically generated (instead of
being written
manually).
If it were stated in the C standard that a vacuous label is illegal,
then compiling into
C would have been a lot more difficult.
If I understand correctly, Kotlin and Scala and others all use the
convention that val is immutable and var is mutable, so that
val x = 1
val x = 2
would not compile. Additionally, there seem to be translators going from
Java to both of these languages that arenāt flawless but work fairly well -
still, I take your word for it, just wanted to point this out.
Now let us dream contexts where I might cave in. E.g. if thereās no
such thing as namespaces, then things are so bad already that we are
forced to do / allow otherwise insanely bad habits, I guess.
BTW is there an ATS lang spec somewhere? I could not find it in 2
minutes of looking on the web site. Iām a nerd and want that stuff
readily available.
Well, this can be a feature as well
Imagine the following scenario: #include āfoo.satsā // [delay] is already declared here
fun delay (ā¦): void = "mac#
A warning sounds reasonable. As I see it, the right place for
handling this is in some kind of IDE.
My knee jerk reaction is to disagree and still think it must be a
compile time error.
Well, the current handling of the issue is consistent with the principle
of lexical scoping. I assume that you have no objection to the legality
of the following code:
val x = 1
val x = 2
Then it is only natural to handle the following declarations similarly:
fun foo : int ā int
fun foo : (int, int) ā int
Yes, it is most likely that a mistake is made if some writes this kind of
stuff. But ā¦
Let us imagine that the code is automatically generated (instead of being
written
manually).
If it were stated in the C standard that a vacuous label is illegal, then
compiling into
C would have been a lot more difficult.
If I understand correctly, Kotlin and Scala and others all use the
convention that val is immutable and var is mutable, so that
val x = 1
val x = 2
would not compile. Additionally, there seem to be translators going from
Java to both of these languages that arenāt flawless but work fairly well -
still, I take your word for it, just wanted to point this out.
Now let us dream contexts where I might cave in. E.g. if thereās no
such thing as namespaces, then things are so bad already that we are
forced to do / allow otherwise insanely bad habits, I guess.
BTW is there an ATS lang spec somewhere? I could not find it in 2
minutes of looking on the web site. Iām a nerd and want that stuff
readily available.
Well, this can be a feature as well
Imagine the following scenario: #include āfoo.satsā // [delay] is already declared here
fun delay (ā¦): void = "mac#
A warning sounds reasonable. As I see it, the right place for
handling this is in some kind of IDE.
My knee jerk reaction is to disagree and still think it must be a
compile time error.
Now let us dream contexts where I might cave in. E.g. if thereās no
such thing as namespaces, then things are so bad already that we are
forced to do / allow otherwise insanely bad habits, I guess.
BTW is there an ATS lang spec somewhere? I could not find it in 2
minutes of looking on the web site. Iām a nerd and want that stuff
readily available.
I think the idea is that you will get a typechecking error if you now
try to use digitalRead2 on a write-only pin or vice versa for
digitalWrite2?On Thu, Apr 23, 2015 at 7:28 AM, Kiwamu Okabe kiw...@debian.or.jp wrote:
Hi Hongwei,
On Wed, Apr 22, 2015 at 10:20 PM, gmhwxi gmh...@gmail.com wrote:
Clearly, digitalRead should only be called on an output pin.
So you may introduce an abstract type:
absvtype pin(int) // linear type // 0/1: input/output
Then do:
fun digitalRead2 (!pin(OUTPUT)): int = āmac#digitalReadā
fun digitalWrite2 (!pint(INPUT), int): void = āmac#digitalWriteā
Sorry, not make sense.
Could you show some application code using the function
ādigitalRead2ā or ādigitalWrite2ā?
#include āfoo.satsā // [delay] is already declared here
fun delay (ā¦): void = "mac#
A warning sounds reasonable. As I see it, the right place for
handling this is in some kind of IDE.On Thu, Apr 23, 2015 at 11:59 AM, Raoul Duke rao...@gmail.com wrote:
You had:
fun delay(ms: ulint): void = āmac#ā
fun delay(us: uint): void = āmac#ā
The second one overwrites the first one.
why/isnāt that a compile time error, or warning at least?
If those are in the same scope then they should at least generate a
warning. Personally I want those to be an outright error. Ditto having
a local var that is the same name as a function input name. Etc.
Shadowing is long-term bad. Even scoped shadowing is something I worry
about, quite seriously, although I donāt currently say we should
disallow it.
pseudocode:
{ val x = 1 { val x = 2; print(x); } }
is ethically very different than
{ val x = 1; val x = 2; print(x); }
in my mind.
Even if those are āvarsā instead of āvalsā per Scala et. al., I
generally consider shadowing to be badness/madness.
