To me, this statement means: currently whack is not a properly designed programming language.
Proofs are an important part of programming! This is the most important part.
1. Try the declaration syntax
x Foo;
Foo x;
2. I think the way you're defining the AST types is a crapload of work. You should have had a bunch of dumb structs, all in one file.
Then you can see everything at once, and you aren't mixing AST representation with codegen logic. Sometimes that's a better way to do algebraic types in C or C++.
3. I don't know what "type Foo struct {...}" does but you'll save a lot of work if the type system only has names as types, nominative typing, without losing usability.
4. Personally I'd parse straight to the AST type you define and not use the mpc lib with its own AST implementation. I don't believe in parser combinator libraries, especially not in C. It's better to copy/paste those loops. Better than using a parser generator too. But since you have a parser already... not right now.
Edit: 5. Avoid looking at Zig, Myrddin, etcetera, if you can. There are obviously paths that any C-like language tends to go down in the 21st century, and the world would probably be better if you rethought the problems from a blanket slate.
I read the points above this one and cannot comment/disagree with them. However, I am very curious about (5).
- What would you classify as "etcetera" here? (ie what other languages would you list)
- What are the paths in question?
- With said blanket slate, what other mindset may be useful to keep in mind?
Thanks!
I don't know, it's a general problem of balancing the originality you might get from not looking at other people's work, with what you miss out from not looking at it.
"Etcetera" includes other low-level languages people've made. Like, I guess Go might even count. Honestly 5 is kind of stupid. No great reason not to ignore it. It's the sort of thing to do for 1 month, but not forever.
By "paths" I mean different features that different languages have and how they do them. You could just copy how these languages try to improve the ergonomics around error handling, for example, or you could decide how you'd like to do it. Thinking from first principles it's likely you'll end up walking into exactly the same decision other languages make, only with a different choice of operator. But it's possible you'd improve matters.
Other paths are questions like implicit conversions or how do explicit conversions happen. And what do you name the bitwise negation operator? Can you do pointer arithmetic? How do you handle pointers to array elements? Do you have a one-to-one mapping from indentifiers to indentificands?
How would you implement the Fibonacci sequence in whack? How might one organize a simple game of hangman?
If it's suitable for use as a tcp server/client, how about a "echo" client?
Things like that can really show off the stdlib and the syntax choices.
Relatively few people will read through the code, and even those that do will likely understand the code better if they start from "this is the syntax or idea that needs to be implemented" as expressed in example code.
Documentation is also, obviously, more coherent to read than implementation code, and you don't seem to have any documentation explaining what features whack has (other than a note that it doesn't have a comprehensive type system).
I recently did that for a language that i made, via instaparse. the flexibility and speed i gained was very big. my language isn't Turing complete, but it has functions, lookup tables, and some pattern matching.
I had this thought, so I used a parser combinator (mpc) to generate the AST from the grammar and source file, then extract useful elements from the AST for codegen.
JavaScript is dynamic and compiled (as are many other dynamically-typed JIT languages). Did you mean dynamically typed and optionally statically typed?
> Runs on a VM and on bare metal
JavaScript is also runs on a VM and bare metal (e.g. V8's Ignition interpreter will interpret JavaScript, but TurboFan will compile it to machine code).
The type system is 90% of programming language design effort.
This is like releasing a car without a 'comprehensively designed engine'.