A few odd proposals

General
1

I am a retired electronics technician who learned Pascal and a bit of C 30 years ago. My real interest is in creating radically atypical new systems of symbolic logic. My typing is ten times slower that normal due to developmental dyspraxia. I have two requests for the Odin team. It would be for the best if the groundwork to support the requested features would be in place prior to the official release.

The first request is for the creation of a static source code analysis tool. Before feeding the code into the compiler you run it through this analysis tool, which returns a text with a list of the history of every pointer, variable, array, etc. — everything that bears a name or a type. Then you just read down a numbered list that displays every line where a named item is allocated, accessed, modified, freed, etc. It could even be enhanced to detect errors. The analyzed code would need to be line numbered. When I line-number my notes I use base 8, not base 10. ‘Seven’ is written ‘7’ and ‘eight’ is written ‘10’. Thus when I need to interpolate a note between ‘5’ and ‘6’ I always write ‘5.4’ since 4/8 = 1/2; and there is no ambiguity when I need ‘5.2’. The benefits a amazingly numerous. I can delete note ‘5’ and still retain note ‘5.4’, for example. Perhaps this could make Odin just as safe as Rust?

My second request is for a high-level version (maybe ‘Odin-Hi’). This would be a high level subset of complete Odin (maybe ‘Odin-Cpl’) that, for example, could automatically allocate extra memory for large values, perhaps provide a bit of syntactic sugar, etc. This might require an expanded run-time system, although I distrust large run-time systems. A static source code analysis tool would allow for retention of manual memory management. I hope it would be compatible with complete Odin. The Nim language has this great feature. Maybe I’m just a foolish one who just proposes odd things.

1 Like
2

What makes you prefer Odin over Nim, if Nim already has one of your two requests?

I suppose that static analysis tools for data flow would be really cool to have though. Not sure if some of valgrind tools would allow that for odin, but there seems to already be some core valgrind support in Odin so maybe that could be paired with some metaprogramming to get read,write,etc on variables?

3

I have also thought a GC subset of Odin would be nice.

It would basically be a Go competitor with all the niceties and easy integrations with Odin. There may be some creative allocator setup to get close to this without much work.

Subset languages in general are very interesting to me, though I don’t have much time to think about them or develop the expertise required to pursue any. I think Odin isn’t quite big enough for the team to pursue this type of work right now either.

4

Odin with a GC would be a completely different language with a different type system.

I think what you’d want is a modification to Go instead with some new additions instead.

2 Likes
5

If you carefully read my ‘A few odd proposals’ post (and not what others have commented) you will observe that I never proposed the introduction of garbage collection. I only proposed a high level subset of ‘complete Odin’, and that a static source code analysis tool would allow for retention of manual memory management in the high level version. I don’t much of anything about Rust, but it looks like Rust has essentially integrated a static source code analysis tool into its compiler, instead of using a source code analysis tool prior to sending code to the compiler — which appears to be causing a lot of confusion.

6

I wasn’t replying to you. For some reason the reply functionality didn’t work.

As for your odd proposals, the answer is sadly no to al of it, sorry.