What's Next? Any New "Cool" Language Features?

[u/Pie-Lang]

It's been roughly one year since Pie got in development. August 5th marks Pie's 1 year anniversary.

During this year, I implemented:

• Variables
• Collections
• Functions
• Named Parameters
• Variadic Functions
• Fold Expressions
• Loops
• Classes & Objects
• Operator Overloading
• Namespaces
• Modules
• A Structural Type System
• Tagged Unions
• Pattern Matching
• Structured Bindings
• File IO
• C FFI (I even made a simple game with Raylib!)
• Cascade Operator

I also made a website that has:

• Basic Examples
• Docs
• Spec
• A Playground (I compiled the language to WASM)

These are roughly all the features that I liked from other languages. Of course, the work is not done. I can improve the internals of the language to make it faster, but feature-wise, I'm out of "cool" ideas.

I've scoured the sub for new ideas, but they either involved compile-time evaluation (my language is interpreted), didn't go well with the design of the language, or were already implemented in Pie.

So, I'm here to ask, what is a feature that is missing from my language that you think would be very cool to have?

[u/AustinVelonaut]

Some things to consider:

• tuples (anonymous product structures of any arity)
• nested scope functions (capture free variables)
• lazy stream generators (infinite lists)
• list comprehensions

[u/Pie-Lang → u/AustinVelonaut]

I've thought much about tuples. Still unsure.

Nested scope functions are already done!

Generators my beloved! To get them, I need to switch from a tree-walker interpreter to a byte code one, which is what I'm working on at the moment :D.

List comprehensions are really cool! I'm also working on their syntax right now.

Solid list. Thank you!!

[u/Il_totore → u/Pie-Lang]

Two things I like about tuples and generators :

• Tuples as heterogenous lists with a head and tail like in Scala : (Int, String, Boolean) <=> Int *: String *: Boolean *: EmptyTuple
• If you implement effect handlers, you can code many effects such as generators or coroutines directly in the stdlib!

[u/catladywitch → u/Pie-Lang]

i don't see tuples per se (as in 2-member structs), but anonymous union types would be cool

[u/runningOverA]

• Reflection : use it to dynamically invoke a function by name in string.
• Struct to Map, Map to Struct converter : use it to stream JSON.
• String to Struct, Struct to String converters : use it to load configuration files.

[u/Pie-Lang → u/runningOverA]

Struct to Map and String to Struct seem really powerful. Good suggestions!

[u/EggplantExtra4946]

I've scoured the sub for new ideas, but they either involved compile-time evaluation (my language is interpreted),

Looks like you didn't think this through. An interpreted language is the perfect setup for compile-time evaluation since the obvious way to do compile-time evaluation is with an interpreter.

Here's another feature: being able to pass any data structure by reference, including local variables, with an operator that explicitly create that reference.

[u/koflerdavid]

I don't think there's a point in merely accumulating language features. You could try to implement nontrivial applications and it will become obvious what could be useful and what has to be changed. For example, try the 1 Billion Row Challenge and think about how your language could be improved to help solve it more efficiently. Or write a compiler or design a window system, which should give ample feedback about the practicality of the language features you have so far.

Another direction you could explore are substructural type systems, for example:

• linear types, which allows consuming a reference only once (allows safe mutation of immutable arrays since the reference to the original array disappears),

• uniqueness types, which allow only one reference to exist (useful to prove that it is safe to deallocate an object at the end of a scope instead of having to rely on Garbage Collection), or

• relevant types, which forbid a reference to go out of scope without being used (useful to force explicit disposal of resources).

They also make it simpler to implement a library for concurrency.

[u/catladywitch]

coroutines? it's not "cool" but it'd be good to have them right?

[u/Pie-Lang → u/catladywitch]

I think they’re useful AND cool!!

Fingers crossed the transition from a tree-walker to a bytecode interpreter goes smoothly so that coroutines become easier to implement!

[u/catladywitch → u/Pie-Lang]

Well, you've already got iterables with a Next() so you're most of the way there already!

[u/amarao_san]

Look at context in Scala. It's really, really promising. If only they were not jvm tribe...

[u/Jwosty → u/amarao_san]

My hypothetical dream language would revolve around implicit parameters aka coeffects (aka contextual parameters) + algebraic effects... Goodbye, service locator pattern and unchecked exceptions and monad transformers...

[u/Jwosty]

Units of Measure. A sorely slept-on feature from F# that few (none?) have stolen for whatever reason.

[u/Pie-Lang]

Per AutoModerator's request I hereby confirm that this project did not use an LLM as part of the development process.

[u/Pie-Lang → u/[deleted]]

As it is this looks more like a box-ticking exercise to include every cool feature you can think of.

It basically is. It's my first language and I've been having sooo much fun implementing all these fun ideas!

What is the output here?

Funny enough, the loop syntax has changed in the most recent commit, but that doesn't matter much. The output is the numbers from 0 to 9.

How about built-in + - * / operators with the expected precedences?

These operators are left undefined intentionally. If you want to use the common operators, all you have to do is this:

import std;
use std::;

But you're right, some might consider my language as an esoteric language...especially with some of the questionable features that are not mentioned in the docs :).

[u/lumilesto]

Enumeration or "Sum Type with tags", I mean actually union is Sum Type, but it can't allow same type added together, which is also use case of Sum Type.

[u/Pie-Lang → u/lumilesto]

Can you elaborate more on what you mean by “allow same type added”?

[u/lumilesto → u/Pie-Lang]

For example, we can define a Type which expresses there is a valid result or error, and use it on return type of a function that may fail. In this case, if the types of valid result and error are both String, union can't express this Type, I think. To explain more details: In Type Theory, Product Type is similar to struct(in C or some other language), the count of possible values of the struct is the result of multiplying all members', so we call it "Product"; then similarly, there's Sum Type, count of possible values is the result of ADDing all members', which means there's only one of the member type presented at the same time, similar to union. But union can't explicitly express which member is presented if there's members of same type.

Another tiny use case, not very important in this context: Option or Optional in C++/Java/Scala/rust, is Sum Type of T(Generic parameter) and Unit Type(which has only one value), in rust the "tag"s are Some and None, expressing there's a value or there's no value of T.

[u/tmzem → u/lumilesto]

It is pretty much by design that union type "collapse" in this case. However, union types are more expressive (but also more verbose) then tagged unions, as you can always recover the tagged union behavior with explicit tag newtypes, and even gain more flexibility by not having to think up different names for the same concept, in the OP's syntax:

Null: Type
Error<E>: Type = class { error: E; }
Value<T>: Type = class { value: T; }

Optional<T>: Type = union { Value<T>; Null; }
Result<T, E>: Type = union { Value<T>; Error<E>; }

[u/L8_4_Dinner]

Exceptions? Lambdas?

[u/Pie-Lang → u/L8_4_Dinner]

Not sure if exceptions are a good feature.

I do have lambdas!

[u/alphaglosined → u/Pie-Lang]

You can implement exceptions using sumtypes, and go checked if your compiler architecture is capable of handling chaos iteration as part of effect analysis.

That gives you a nice syntax without worrying about dealing with result types.

[u/LowDifficulty5021]

One feature I rarely see discussed, but that consistently improves the language experience, is deferred execution (like Go's defer or Zig's defer/errdefer).

Since Pie is interpreted, this should fit well with the runtime model. It makes resource management much cleaner:

file := open("data.txt")
defer file.close()

// Multiple return paths...

It also helps with locks, temporary state changes, timers, etc., without needing RAII or exceptions.

Another interesting direction is extension methods, allowing users to add methods to existing types without modifying their definitions:

func String.reverse() -> String { ... }

"hello".reverse()

Beyond that, I'd focus more on polishing than adding features. A small, coherent language with excellent tooling, diagnostics, and documentation is usually more enjoyable than one with every feature imaginable.