A number of potential proposals

[Qata]

Hello again!

I keep making detailed proposals for things where I either missed something or there's a good reason it can't work.
So I figured I should just do a rapid fire list and then things can easily be shot down without wasted effort.
If any of these strike you as potentially worth including, I can make a full proposal with pros/cons/considerations.

1. Making = optional in the definition of functions (or giving it a specific error message). Embarrassing to say but out of everything in the language, accidentally forgetting the = was what most tripped me up when I started writing Juniper.
2. A constraint keyword e.g. constraint ConstrainedType = { field : uint8 }, which would allow writing fun myExample(arg : a) : b where a : ConstrainedType.
3. Inline type annotation e.g. (float)0.0, allowing distinguishing between polymorphic constrained values, like the two floating-point types.
4. Function overloading, which I believe is allowed in C++ already.
5. Module extensions, e.g. extends module List.
6. Full dependent types
7. Unique types
8. Linear types
9. f and d suffixes for floating point literals.
10. A non-sized (linked?) list type
11. String interpolation e.g. let a = 10u32; "Value: \(a)" that compiles to use snprintf.

[calebh]

1. Juniper takes inspiration here from the ML family languages such as Haskell and F#, which do use an equal sign = to begin a function.
2. I agree that this is an annoyance. I was planning on calling this new feature interfaces, but constraint would be an okay name too. Alternatively we could pursue genuine row types instead of the structural type system.
3. You can already do this using expr : type, for example `let foo = (5.0 : float)
4. To add function overloading/ad hoc polymorphism we would have to add type classes. I looked into this briefly, and it would be a big lift to add this to the language. At a minimum we would have to modify the type inference algorithm, implement checking for overlapping typeclass instances, implement functional dependencies (necessary for the record system), typeclass chaining, etc. This is a big feature, and at the moment I do not have spare time to devote to Juniper (I am working on a gamedev project atm). Currently we have special case typeclass: for example, you can think of the num constraint as a typeclass inhabited by all the different numerical types.
5. I would like to move the module system to act more like namespaces. I would particularly like nested namespaces, rather than the single level namespace we currently have. The current module system was inspired by Erlang, which also does not have nested namespaces.
6. The problem with full dependent types is that there isn't a good story for transpiling to C++. The input arguments would be dynamically sized, which doesn't work with the philosophy of putting everything on the stack.
7. At some point if we add more of these advanced type systems, I have to ask what the difference between Juniper and Rust is. I have never used Rust before, so I don't know how ergonomic the use of these advanced type systems are.
8. See 7
9. You can already do this, example: 7.0f
10. We could add an option to Juniper to allow for recursive types. In this mode, any type that is recursive would be stored on the heap and reference counted. Note that in a purely functional language, it is impossible to construct cycles in the data graph. As long as we carefully check for data structures with nested ref cells, we should be able to keep this property.
11. String interpolation without printf seems like a good idea. The challenge with printf like functions is that the type signature changes depending on the format string value, which moves it into the realm of dependent types. F# has some compiler magic that inserts the correct type depending on the content of the format string. I don't think we would have this problem with string interpolation like you see in Python: f"Hello {myvar} world"

[Qata]

1. I am aware of the why of the equals sign, I was briefly a Haskell dev, but that was nearly a decade ago. Since it is vestigial rather than functional, it does act an unnecessary barrier of entry for those unfamiliar with the ML family. It doesn’t need to become optional, the alternative would be a precise error message that specifically tells the user “you forgot the equals sign,” whereas we currently have a generic error that someone new to an ML (or relearning it) will find confusing. Having both an equals and curly braces short circuited my mental parsing of the function signature.
2. I was originally going to suggest interface as the name, but I double checked the master doc before posting and saw you’d called the concept a constraint, so I figured it’d be better to be consistent than to mimic C++.
3. Awesome, I’d tried a few permutations of doing that, but not that one specifically. I’ll put that on the list of things that need documentation.
4. That does sound like a lot of work. Would you be open to making a roadmap document to Juniper 5 and making detailed broken down issues that I or others could work on? It’s been a while since I last worked on a compiler, but I do have it in me.
5. What would the syntax for that look like?
6. I like the philosophy of putting everything on the stack, but perhaps it should be evolved to putting as much on the stack as possible? Much more powerful microcontrollers with megabytes of RAM are available these days, for dirt cheap, you can get an ESP32-C3 on AliExpress for $2. Juniper currently fills a pretty small niche that’ll only get smaller as microcontrollers become beefier, but its target market would be massively broadened by having the ability to proof your code, as a language with such a low barrier of entry. Since microcontrollers are designed to interact with physical components, they feel to me like the easiest sell on proofing and strong typing. For example, I run an aquarium business and I’m using Juniper to control my evaporated water top up, auto water changes, nutrient dosing, etc. Faults in my program could financially ruin me. Another example, my father is building a flight sim 360° servo motor cage and wants me to write the program to connect it to the simulator. Logic faults could cause grievous bodily harm (so I’ve been testing out using Idris on an Arduino because it feels too serious not to proof). If you don’t want to move Juniper in this direction, I do understand, I just think it has incredible potential to sit in the middle of the ‘easy’, ‘fast’, ‘safe’ triangle.
7. Both unique and linear types have their strongest use-cases IFF dependent types are implemented, as they both allow for dynamically sized values without reference counting.
8. Rust doesn’t have linear types, they’re more of a Haskell/Idris thing.
9. Oops. I’d tried f32 and f64 without success, but when I wrote this I remembered that doubles are generally 32 bits on microcontrollers, and edited to f and d without checking if that was already implemented…
10. I like that. In Swift, the indirect keyword is used, but I think recursive would be a better keyword.
11. Awesome. As an aside, I’ve got some extensions to the printing functions I’ve been working on. I’ll make a PR soon, along with my extensions to other modules.

[Qata]

Oh I missed your point that there isn’t a good story for transpiling dependent types.

My assumption was that since Idris has a C backend, C++ would necessarily have as good of, or even a better capability for representing dependent types.

[calebh]

1. The curly braces are not actually necessary for cases where the function body is a single expression. See the blink function in the tutorial here: https://www.juniper-lang.org/tutorial-concurrency.html
4. I went ahead and made a roadmap in the discussion section here: Juniper 5.0.0 Roadmap #27. If you need a more detailed breakdown, let me know.
5. Syntax would remain largely the same, except with more colons separating the namespaces. The behaviour of the system would be more or less identical to C++ namespaces.
6. I agree, see the recursive datatype proposal on the roadmap. We could also add heap allocated arrays (with value level sizes) at the same time as we add the recursive datatypes. Note that right now it is possible to implement value size arrays via the C++ escape hatch.
7. I talked to a friend who has used Rust extensively to determine what benefits a borrow checker brings. I was primarily interested if there are any advantages (ie, has less bugs) than a traditional garbage collected language. His response:

Safety errors in single threaded code? Probably not. I'm not too sure about parallel/distributed code but I'm told the type system helps out there in terms of thread-safety/race-conditions.
There are other kinds of subtle bugs it can help with by bringing object layout/lifetimes to the forefront
For example, accidentally keeping large amounts of allocations alive because of a hidden reference or having unnecessary allocations

Overall I do not really see the benefits of adding a borrow checker or less powerful linear, uniqueness or affine types. I'm completely okay with paying the performance penalty for a reference counting system, especially if this gives the language the same feel as something like F#/Elm/ML family languages.

11. One thing I'm not sure about is unicode support. Ideally I would like to support UTF-8, however I don't know if that's feasible with a C++ compilation target.

Oh I missed your point that there isn’t a good story for transpiling dependent types.
My assumption was that since Idris has a C backend, C++ would necessarily have as good of, or even a better capability for representing dependent types.

I'm curious if the Idris output actually uses the C type system to represent everything, or if they essentially erase all the types and sling around void * everywhere. Juniper tries to output C++-like types and functions, to the point that there is a 1-to-1 mapping between a Juniper expression and an equivalent C++ expression. I would like to keep this philosophy if possible.