datatypes in sats file

[Mike Jones]

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)

[gmhwxi]

The code looks fine to me.

[gmhwxi]

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:

[gmhwxi]

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:

[Mike Jones]

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.

[Hongwei Xi]

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.

[Barry Schwartz]

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.

[Hongwei Xi]

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.

--
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.

[Barry Schwartz]

Hongwei Xi <gmh...@gmail.com> 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. :)

[Mike Jones]

Being a newbie with ATS, I am finding the following:

- The books are good, but not searchable and would love a pdf, really really

- The books would benefit from extension if the goal is to grow the user base and let people self serve wrt learning

- Overloading is very confusing for a learner, as it makes it hard to read aloud 

- Kinds are confusing, I would love a chapter int he book to walk through some numeric type from A-Z to make all these definitions more clear

- Error messages from C compiler are harder to deal with than the ATS compiler

- Lack of transparency of what happens in C is a bit scary when it comes to potential promotions and casting

But:

- My embedded code does not have pointer bugs or overrun any size boundaries, which is a big deal when it happens

- My embedded code runs almost as fast as a previous C version, probably just excepting any copying from casting that I don't yet understand if and when it happens

- Dependent types has saved me from a bug at least twice so far and makes intent very clear and I think a maintainer is less likely to break my code

- It allows me to think functionally with embedded code, very very nice, and let's me sleep well

- The FFI is so easy without a bunch of marshaling code, big big win for me

- Ability to get help getting over initial mistakes and misunderstands is golden

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!