[thethirdone]

I am not sure exactly what qualifies as ""look at how smart I am" bullshit", but as someone making a toy language, exploring how a concept taken to its extreme in a language re-contextualizes other features is the main purpose of making it.

I have made a fair number of decisions against ergonomics in favor of less objectively important ideals because I don't plan to support people working on real problems. However, I do plan to make a self-hosting compiler though so I will have to deal with any issues I do make.

> that authors of such projects seem unable to resist

It definitely is very tempting to add things beyond the scope of a useful language (at a toy scale). I restricted myself from most such things by requiring strict C compatibility. You can't have a fancy type system and interop with C strongly.

[caspper69]

> You can't have a fancy type system and interop with C strongly

ATS would disagree with this statement, strongly.

[thethirdone]

I haven't used ATS, but I don't think it interops strongly. Hows does calling a ATS function with fancy typed arguments from C work?

My idea of strong interop is not having to write any glue code at all and being able to call any function. I assume there are some types that don't interface with C well.

That said, thanks for mentioning it. I should keep it in mind as it does do some of the stuff I want my language to.

[TurboHaskal]

Grep for "Exporting Types in ATS for Use in C" in http://ats-lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML/...

[jcelerier]

    typedef
    struct {
       int atslab__0; void *atslab__1; 
    } int_and_string ;

very strong typing right there...

[caspper69]

I apologize for being ambiguous. You wouldn't gain the benefits of ATS by interfacing with its C bindings from C. You would gain safety and security in interfacing with unsafe C on the ATS side through the ATS type system.

I was speaking about interfacing in the opposite direction.

[thethirdone]

> I apologize for being ambiguous.

No need to apologize. I also should have been more clear about what I meant by strong interoperability.

> I was speaking about interfacing in the opposite direction.

I think that having really strong interoperability requires both directions, but the being called from C is the one that is more restrictive on fancy types.

[caspper69]

Unfortunately, C is C, and we all know what that means. Anything that achieves true type safety in both directions in going to be a monstrosity on the C side. Lots of boilerplate, marshalling of types, etc.

It all starts to look like COM, lol. Take care man.