Thanks a lot! After looking at what you wrote I have changed some things:
redefined dataType as:
dataType => ("string" | "number" | <identifier>) ("[]")?
Where Identifier is used to look up the name of a struct
I also renamed "struct" to "object" as that seems a little less "c" like and sounds a little more high level. Purely an aesthetic choice.
Quote:* functions are not 1st class values,
* function nesting isn't supported,
* hence I assume that closures are not possible,
* co-routines are not supported.
I chose not to do function nesting and co-routines because I felt that those might be too complicated for someone that might be using this (Yes, this is just for fun, but if it does get used it will be by people who have never programmed in their life, and thus wouldn't even know when to use a nested function or coroutine.) Also, this is my first attempt at this, so I figured I could keep it a little simpler by not including those. But maybe in a later iteration.
As for making functions 1st class values, that might actually be useful. I'll have to think about that and how I can add it in.
Quote:I can't examine the exact type system. I see the types string, number, arrays of the former types, and structs. Is the type system weak or strict? Does type coercion happen in some way?
The three types would be string, number, and object. All type checking would be done at compile time. The only conversion that would be allowed is an implicit conversion of number to string for the purpose of concatenation.
Ex.
number a = 1, b = 2, c = 3;string position = "(" + a + ", " + b + ", " + c + ")";
would assign "(1, 2, 3)" to position
Quote:It seems me that structs cannot be nested. Is this correct?
Again for the sake of simplicity, no they cannot. However I did change my datatype definition to allow for recursive struct definitions, which were not possible before.
Quote:Nothing is said about the integration with the application.
Nothing is said about execution (although that need not necessarily be part of a language specification): E.g. source interpretation, bytecode interpretation, or what?
Nothing is said about supporting packages/libraries (although again not necessarily part of a language specification).
I guess I probably should go over some of that. I am programming it in c#, I am working on a windows form editor, where you can write/save/run the program and test its value. When you run it here it uses source interpretation. However, to integrate it with other things, the plan was to translate it into c#, and then use msbuild to compile it into a .dll.
Maybe this isn't the best way to do things, but both of those are things that I have wanted to mess around with for a while, so I figured I'd try to kill two birds.
For supporting packages/libraries, I was planning on just using a #include "filename" directive. That would just insert the text of the file at that spot in the code.
Thanks for the comments! That was exactly what I was looking for!