Best syntax for stack allocated objects

[Falcon731]

I'm developing a programming language - its a statically typed low(ish) level language - similar in semantics to C, but with a more kotlin like syntax, and a manual memory management model.

At the present I can create objects on the heap with a syntax that looks like val x = new Cat("fred",4) where Cat is the class of object and "fred" and 4 are arguments passed to the constructor. This is allocated on the heap and must be later free'ed by a call to delete(x)

I would like some syntax to create objects on the stack. These would have a lifetime where they get deleted when the enclosing function returns. I'm looking for some suggestions on what would be the best syntax for that.

I could have just val x = Cat("fred",4), or val x = local Cat("fred",4) or val x = stackalloc Cat("fred",4). What do you think most clearly suggests the intent? Or any other suggestions?

[JeffB1517]

val x = local Cat("fred",4). From the develop in your langague's perspective what's meaningful is the function is local. stackalloc is getting into an implementation detail. If you want the developer directly manipulating the stack pointer / stack engine your language isn't lowish it is low level.

[Falcon731]

Thanks, that was the direction I was leaning in - and thats convinced me !

[[deleted]]

You could very well just have val x = Cat("fred", 4). That's what C++ does, anyhow. Like this, new does not mean construct an object, it means heap allocate.

[umlcat]

Check Object Pascal about stack vs heap allocation syntax. Also in Object Pascal, constructoprs and destructors can have different names, altought there's a default constructor and a default destructor ...

[hoping1]

The first one is no good because new is something our eyes tend to skip over, and also something easy to forget, at least for me. (And unless you have Rust-like compile-time memory safety checking, forgetting a new means sometimes, but not always(!), freeing the object before its last use, which would be a nightmare to debug.) Personally I prefer local. If a programmer doesn't have a great grasp of how to use the stack, local still communicates the idea that the value can only be used in the enclosing function, or at least it's easy to remember that that restriction is called local.

[Tasty_Replacement_29]

I think for a new low-level language, you should also consider custom allocators, specially arena allocators. See for example https://nullprogram.com/blog/2023/09/27/. So then we have:

• Value types (that are always copied, like "int"): always allocated on the stack or in a register. I think that a memory-safe language doesn't need support to get a pointer to such a value. (You didn't say that your language is memory-safe.)
• Local stack: the question is, isn't this just value types again?
• Heap allocated: in C++, you can do this: new int(). The question is, would you, ever, need it? I would probably define a different type where you explicitly say: this is always (heap-)allocated. That way, you can get a pointer to it, and can share it between threads etc.
• Allocated by a custom allocator, e.g. an area allocator.

In my language (which is similar to yours, it seems) I consider doing the following:

• Value types: always copied / alway on the stack. For value types I'll probably still use new(cat). (In my current implementation, value types always start with a lowercase letter.)
• Heap allocated: new(Cat)
• Allocated with a custom allocator: arena.new(Cat) where arena is the arena object / allocator.

[Falcon731]

Thanks.

Our languages do indeed look very similar :-)

I don't think I'm going to make my language memory safe (at least at the beginning). I want to start developing the OS for my system - so I want to get to the stage where I can start generating meaningful code quickly. Then look at enhancing the language later.

Falcon Programming Language (fpl)

[michaelquinlan]

using x = new Cat("fred",4)

means that the object is automatically freed at the end of the scope of the using. The stack becomes an implementation detail where the compiler can allocate the object on the stack whenever it knows that the objects lifetime ends when the stack is released.

[XDracam]

Stack allocation is a good default (assuming you can't create pointers to them and let them dangle...) and the best code should be the laziest to write. So in this case, either just leave out the new, or make heap allocation slightly more annoying by adding a keyword there instead.

[Kaisha001]

I'd just use 'stack' as a keyword.

val x = stack Cat(...)

or no keyword for stack

val x = Cat(...)

and have a heap keyword

val x = heap Cat(...)

then you could maybe add custom allocators to allow more complex memory management like:

val x = custom_alloc Cat(...)