Is there any reason this would fail to compile in a sats file?
It seems to want an = after the fun definition. Does the datatype not work
in a sats file?
datatype bus_type =
| SMBus of ()
| …
datatype smbus_type =
| Reset of ()
| …
fun get_frame_header (): (bus_type, smbus_type)
The code looks fine to me.On Wednesday, October 28, 2015 at 10:34:20 AM UTC-4, Mike Jones wrote:
Is there any reason this would fail to compile in a sats file?
It seems to want an = after the fun definition. Does the datatype not work
in a sats file?datatype bus_type =
| SMBus of ()
| …datatype smbus_type =
| Reset of ()
| …fun get_frame_header (): (bus_type, smbus_type)
By the way, why not use ‘bus’ for ‘bus_type’?
At least, do
typedef bus = bus_type
fun get_frame_header (): (bus, smbus)
People coming from C tend to use names like ‘bus_t’. This practice
is completely unnecessary in ATS as the ‘_t’ part is already known to
the ATS compiler. There should be very little concern of mixing one thing
for
another in ATS.On Wednesday, October 28, 2015 at 10:34:20 AM UTC-4, Mike Jones wrote:
Is there any reason this would fail to compile in a sats file?
It seems to want an = after the fun definition. Does the datatype not work
in a sats file?datatype bus_type =
| SMBus of ()
| …datatype smbus_type =
| Reset of ()
| …fun get_frame_header (): (bus_type, smbus_type)
I guess the question is how you tried to compile it.On Wednesday, October 28, 2015 at 10:34:20 AM UTC-4, Mike Jones wrote:
Is there any reason this would fail to compile in a sats file?
It seems to want an = after the fun definition. Does the datatype not work
in a sats file?datatype bus_type =
| SMBus of ()
| …datatype smbus_type =
| Reset of ()
| …fun get_frame_header (): (bus_type, smbus_type)
I see. It is a different kind of “type” :)On Wed, Oct 28, 2015 at 11:33 AM, Mike Jones proc...@gmail.com wrote:
In this code, bus_type does not mean ATS Type, it means another PHY that
is not I2C based.But the simplification probably still applies.
–
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 http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/cee834c1-a722-496a-a519-80175f6479f7%40googlegroups.com
https://groups.google.com/d/msgid/ats-lang-users/cee834c1-a722-496a-a519-80175f6479f7%40googlegroups.com?utm_medium=email&utm_source=footer
.
In this code, bus_type does not mean ATS Type, it means another PHY that is
not I2C based.
But the simplification probably still applies.
My rule of thumb is that one should be able to read out loud one’s code.
I am not against using long names as long as short aliases are created for
them.On Wed, Oct 28, 2015 at 1:13 PM, Barry Schwartz < chemoe...@chemoelectric.org> wrote:
gmhwxi gmh...@gmail.com skribis:
People coming from C tend to use names like ‘bus_t’. This practice
is completely unnecessary in ATS as the ‘_t’ part is already known to
the ATS compiler. There should be very little concern of mixing one thing
for
another in ATS.I do it both ways according to my whim.
And usually give static
variables the same name as dynamic variables with which they are
associated. The only time I have run into trouble is once accidentally
shadowing a type; and I think macros were involved in that.I like the OCaml practice of having lots of types all named ‘t’ but
the method is made possible by the module system.–
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 http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/20151028171352.GD8818%40crud
.
Being a newbie with ATS, I am finding the following:
But:
Overall, my commercial embedded work is a success. It will be interesting
to see how code reviews go with C programmers that are domain experts in my
area.
I hope someone will run a workshop at ICFP next year. I think it would be
very valuable. I may propose a topic for the commercial use program that
demonstrates use of ATS in a micro with a Haskell GUI talking over USB to
it. I just have to get some permissions from my company on what I can and
cannot reveal, but I have a fully working application.
Basically, I need ATS to thrive to use it commercially, as our products
live 10+ years. That said, I think the embedded world needs a new language
to replace C, and my experience so far is this is a very good alternative.
I like that I can move up and down processor levels and pick and choose
features. So on Atmega, no boxed types, and the compiler tells me when I
break that rule, and on something bigger I can malloc, and and on even
bigger GC, etc.
But like all new things, infrastructure sometimes matters more technical
greatness. Meaning, documentation, learning opportunities, community, and
dare I say, marketing
Anyway, cheers to all, and especially Hongwei Xi for the help and
toleration of dumb questions. Next trip to Boston and I’m definitely taking
him to dinner!On Wednesday, October 28, 2015 at 11:17:04 PM UTC-6, Barry Schwartz wrote:
Hongwei Xi <gmh...@gmail.com <javascript:>> skribis:
My rule of thumb is that one should be able to read out loud one’s code.
My rule of thumb is that aliases are bad. It’s just a rule of thumb,
though.