Two pain-points with Futhark

[miestrode]

Hello! Obligatory section about me enjoying using the language aside, I'm currently suffering two pain points with Futhark, being:

• Parametric modules cannot take non-modules as input,
• and that module types cannot include declarations in them (defs).

Whilst I do understand Futhark attempts to be a relatively simple language that is less oriented towards this I feel like by including a module system, it should at least be relatively competent at expressing such things, even perhaps at some cost to the module type system.

I do understand that due to wanting to eliminate all modules in compile-time, unifying modules with the rest of the type-system likely won't work, but it seems to me that this can be done, even in a somewhat limited form whilst keeping this property (although of course, ditching the property and using inlining to optimize away modules some of the time seems fine).

Therefore, has this been considered before, perhaps with some kind of unification with record types?

[melsman]

tir. 1. aug. 2023 kl. 14.06 skrev Yoav Grimland ***@***.***>:

Hello! Obligatory section about me enjoying using the language aside, I'm currently suffering two pain points with Futhark, being: - Parametric modules cannot take non-modules as input,

What is a "non-module"? Are you suggesting that it should be possible to parameterise a module over a type spec or a value dec, as is possible in Standard ML via a derived form?

- and that module types cannot include declarations in them (defs).

OCaml supports so-called "value abbreviations", which turn out useful for optimisation purposes by allowing a module to inline such abbreviations; they are less useful in a language implementation that does module inlining...

…

Whilst I do understand Futhark attempts to be a relatively simple language that is less oriented towards this I feel like by including a module system, it should at least be relatively competent at expressing such things, even perhaps at some cost to the module type system. I do understand that due to wanting to eliminate all modules in compile-time, unifying modules with the rest of the type-system likely won't work, but it seems to me that this can be done, even in a somewhat limited form whilst keeping this property (although of course, ditching the property and using inlining to optimize away modules some of the time seems fine). Therefore, has this been considered before, perhaps with some kind of unification with record types? — Reply to this email directly, view it on GitHub <#2001>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI5DO5CGKOLV7ADXJWMXO3XTDWNDANCNFSM6AAAAAA27U7SEU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[athas]

Parametric modules cannot take non-modules as input,

Depending on exactly what you want (could you give an example?), this could be addressed using fairly simple syntactic sugar, as Martin mentions is actually possible in Standard ML. I'm a bit reluctant to add sugar that blurs the module/term division, because I find that the module language is already difficult to understand for programmers that do not have extensive Standard ML experience (there are a few of these, sadly).

and that module types cannot include declarations in them (defs).

I think I have an idea of what you mean, and I remember disliking the SML module system for similar reasons, but I eventually realised that it's a very crucial property of module types that they cannot contain definitions, as they must be entirely structural. It's not clear what definitions in a structural module type would mean.

I think that in most cases where you might want definitions in module types, what you actually want is a bunch of "default functions" that are defined in terms of the functions declared in the module type. That may be possible to do, but you can already do something very similar yourself through liberal use of parameterised modules. I am still reluctant to add features to the module sublanguage unless there is strong evidence it's a good idea, because it's already an alien part of the language, and I suspect many of the problems with it can be solved through documentation. After all, it's difficult to say whether the module sublanguage is bad when its users have so little experience with it (and no good learning resources for becoming better at using it).

So as far as I am concerned, I would prefer to study some concrete examples of pain points and figure out whether they can be solved within the existing module sublanguage, if only we had any documentation worthy of the name that actually discussed how to do so.

[miestrode]

Because I find that my main point is related very much to the other points here, I'll discuss it first.

I'd like to first ask, what's your opinion of a unified module and type-system by emulating modules using record types? The mapping being:

• Module types to fully-lifted record types
• Modules to records
• Parametric modules to regular functions
• open to a version of the ..record syntax, as seen in Rust for example

I feel like in the long-term this would reduce efforts by removing what is essentially feature duplication. Then the regular language for modules could be kept mostly the same. This could also bring some relatively simple answers to the other points:

It's not clear what definitions in a structural module type would mean

What do you exactly mean by that? It doesn't seem to be particularly problematic to me. You could for example choose to encode in your module types default implementations, by for example having a module type like { x: ..., y: ..., default z: ... }, where the defaults aren't terms but rather also types.

Alternatively use syntax sugar for using functions which would internally use ..record. Even without using sugar I'd argue this is more elegant than forcing you to create a module type for the non-default module items and then a separate parametric module that would turn this into the final module, and providing the implementations. This is what I also currently do, and it's inelegant and verbose.

I'm a bit reluctant to add sugar that blurs the module/term division

Making parametric modules be simply functions over records would solve this, for there will be no need for sugar.

As for concrete examples, I've encountered both of these issues, among others with the current module system whilst trying to create a deep learning library for fun (and learning).

Whilst I believe I understand Futhark isn't exactly designed to do this, as if I understand correctly from what I've read, which is not a lot sadly, Futhark is more designed for the building of efficient program subroutines and small programs, I believe that allowing you to easily use the language for the making of more complicated parallel programs and libraries is key for better performance and a better developer experience, as you wouldn't need to use FFI as frequently and therefore would save on the cost of transferring data between languages. Also, I think that it would be possible to reach a higher performance ceiling with the final product in this way, once the compiler matures further.

[miestrode]

Also as an aside, speaking of documentation, it would be nice if the discussions page on GitHub was more advertised in the repository or the website, alongside other methods of communication with the community and the project developers.

[athas]

I'd like to first ask, what's your opinion of a unified module and type-system by emulating modules using record types?

It's a cool idea and studied in the literature, but from what I know 1ML is the only language that does it, except for fully dependently typed languages that can encode modules in other ways. But realistically none of the existing Futhark developers have time to design or implement such a system - due to development resource constraints, we're usually quite conservative wrt. language design, and focus mostly on the compiler. I have a hunch that a unification of the term and module language might be the optimal design, but I also consider it an open language design research question how to do it. Realistically, we are in the short term limited to smaller improvements to the module system.

What do you exactly mean by that? It doesn't seem to be particularly problematic to me.

Module types are conceptually handled by substitution. The compiler in principle (and in some cases literally) just copies module type definitions everywhere they are used. What happens when they include value definitions? How often are those definitions actually emitted in the final program? In the 1ML interpretation where module types are just ordinary types, it's also very unclear what this would mean. What is a record type with a "default" definition?

Whilst I believe I understand Futhark isn't exactly designed to do this, as if I understand correctly from what I've read, which is not a lot sadly, Futhark is more designed for the building of efficient program subroutines and small programs

While this is true, I really do think a higher-order module system is also useful at Futhark's scale (or else we would not have added it). There is already a small deep learning library that is heavily modularised, although I think it perhaps went too far. The design is quite baroque.

[miestrode]

What is a record type with a "default" definition?

Did my answer of "function" not suffice? I mean, thinking of this in terms of current Futhark, the answer simply would be that it isn't a record type, it's it's own unique thing. Another answer to this would be extending records with a notion of derived-rows. I am unsure again if it is unclear.

Of course, whether it is clear or not isn't really relevant to the issue of actually implementing something like this in the language. Whilst I cannot really promise anything, I will say I am currently working on a programming language that will utilize the idea of "modules as data (records)", and might update this assuming it ever becomes complete enough, so as to evaluate this feature.

Anyways, it is unclear if it would be better to actually implement bodges (quick-fixes) to the issues described in my initial comment, or to wait until the more resources can be put into considering unifying modules and records, but I do think it would be worth it to at least consider the quick-fixes.