The Hylo Group
-
What are the plans for Val and metaprogramming?In my time programming, I have ended doing a fair amount of metaprogramming (mainly using reflection and code generation in languages like Java and C#), as it is sometimes the only elegant solution to a problem, avoiding issues such as code duplication, multiple sources of truth*, or runtime introspection (potentially abysmal for performance). A powerful metaprogramming solution which is easy for developers to utilize can go a long way in letting a language outgrow its original scope (something like sqlx is a great example). On the flip side metaprogramming can lead to opaque code bases, or simply ones which are very hard to understand, or straight up new language dialects when metaprogramming goes as far as it can in lisp. I understand this may be a feature which is going to come much farther down the line, but early consideration could save effort and time, or lead to more powerful ergonomic metaprogramming system, and I was just wondering where the thought process is at now. * By multiple sources of truth I mean a situation like following: you have a data structure representing something which must be serialized. Without any metaprogramming you must define the serialization and deserialization routines separately from the data structure itself, and this leads to many programming mistakes and high effort for refactorization. This is solved by something such as serde. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 9 replies
-
|
You're right that it's a bit early; we have a lot of fundamentals to put in place first. We're not at all opposed to metaprogramming—I wrote a whole book about it—but we're not very happy with most of the language designs we've seen for supporting it, and we don't want to rush into adding specific metaprogramming features until we're sure we have the right design. About all we've decided is that we want to be able to run any ordinary Hylo code at compile time if the context demands it, without ceremony. But that only scratches the surface of a more complete metaprogramming picture. HTH. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that is what I assumed. Excited to hear this:
To me that is fundamental, and lends a language to have a powerful ecosystem. I like mutable value semantics, I like the decisions with the type system and concurrency, and so I want the language to be able to thrive in the future. That being said, some languages, like Go, pretty much don't have metaprogramming (afaik) but are very successful, but for something like Hylo which promises so much safety and structure it would be harder to overcome the areas of pain. V lang seems to have taken another potential approach: complex language features should simply be part of the language. They have added in support for sql and (de)serialization directly to the language. While this leads to some very elegant simple code, it is far less supportive of a community contributions (again, sqlx is a great example). |
Beta Was this translation helpful? Give feedback.
-
|
Have you thought about adopting dependent types? They are not only very conductive to meta-programming, but also enable further safety checks |
Beta Was this translation helpful? Give feedback.
-
|
Dependent types are not only useful for functional programming. Correctness can be proven when there are systems that verify mutability. This is the path ATS takes. Its a systems programming language with uses cases much like rust or hylo aims to have, but if i understand it correctly, it uses dependent types to prove a safe usage of general mutation and many kinds of user defined invariants. Besides, Hylo doesnt aim to prove correct usage of general mutation but instead model a whole/ part ownership system. ( which has an straightforward equivalence to functional programming* ) . This language could thus more closely reap dependent type advancements
|
Beta Was this translation helpful? Give feedback.
-
|
It definitely sounds interesting to me, but I don't know enough and haven't immediately got the time to find out more. If you can describe or point to examples of how dependent types could make Hylo programs better without overwhelming the reader with annotation, I'd love to hear more. As Dimi has said, though, we have an existing focus and mission, and plenty of work to do on that. It seems like mechanized proof and the dependent type system to support it would constitute a significant expansion of the mission, which would be a distraction from our existing work, so it's very unlikely to happen on the basis of a casual “you should look at idris2” recommendation. |
Beta Was this translation helpful? Give feedback.
-
|
Yes , Implementing dependent type systems Is currently a major undertaking. I still recommend hylo users to take a look at them since taking them into account early would make their hypothetical future inclussion much smoother As for examples, i should open a thread about that, when i have the Time. If i haven't done so in the near future please feel free to open one and ask me to elaborate |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good. Also, I must ask: what do dependent type systems have to do with the topic of this discussion? |
Beta Was this translation helpful? Give feedback.
-
|
@GunpowderGuy wrote:
|
Beta Was this translation helpful? Give feedback.
You're right that it's a bit early; we have a lot of fundamentals to put in place first. We're not at all opposed to metaprogramming—I wrote a whole book about it—but we're not very happy with most of the language designs we've seen for supporting it, and we don't want to rush into adding specific metaprogramming features until we're sure we have the right design. About all we've decided is that we want to be able to run any ordinary Hylo code at compile time if the context demands it, without ceremony. But that only scratches the surface of a more complete metaprogramming picture. HTH.