OSDev.org

I guess my only other questions would be:

Do you have a well defined set of nodes for your AST?

It seems odd that you could return a null for structure sandwich (which I cannot deduce whether it is a null pointer to a sandwich or just an empty sandwich) unless sandwich is always a "pointer-to-sandwich" when given as a return value.

It is almost like everything is an object like in ruby... I presume you have some sort of RTTI going on?

And finally... if this is for an OS... at some point you will have to cast... so how do you cast in ExC?

The reason why I'm making ExC is for four reasons; one is that it support code organisation to a greater extent than C, by using packages rather than naming all your functions with prefixes, or using structs and function pointers, etc. The other two are:

- When I started learning C, I wan't a huge fan of the syntax, and how C worked sometimes. It's usable, yes, but sometimes it felt a bit off. For example, when you define an array in C, you put the square brackets next to the variable name and not the variable type, and also I don't like defining header files because it felt like I was repeating myself without good reason (if you've heard of DRY, you might know a bit what I mean, but admittedly if I wanted to eliminate header files I could have written my own C compiler which auto-generates them or something like that)

- At some point, I want my operating system to be self-hosting, which means I'll either want to port a compiler over to my OS (the boring way) or make my own (the fun/frustrating way). If I'm making my own compiler, then I have the option to choose which programming language to compile. C is good, but again, the syntax is different to what I'm used to. I could do C#, but that would increase the compiler's complexity and probably kill my motivation. So, having C but a more familiar syntax and a few extras is what I want, really, and that's ExC. Of course, this does mean I'm limiting who could contribute, as they'd have to know how to write ExC, but if I'm making an operating system and the programs on it, I want to be more comfortable writing the code. And anyway, if I make my own programming language, I know every single feature and can exploit every single feature for performance gains, smaller code files, etc.

- I want to make my own programming language for educational purposes, anyway. Since I usually work on higher-level programs, I never quite know how the lower-level stuff works. So, I started to learn osdev to learn about computers from the bottom up, rather than the top down. This would be aided by knowing how programming languages abstract lower level code, and how compilers work, since I've never had to write one.

[tl;dr i have reasons]

From considering these reasons, I've come up with some further reasons to answer "Why ExC, and not <programming language>?"

- If you want the functionality of C, but with alternate syntax/better baked in code organisation/more control over what other code files can access

- As a 'stepping stone' between higher level langs and C

- Personal preference

Really, whether you use ExC or not is your desicion entirely. I'm totally fine if nobody does; since that's not what I'm aiming for. Also, I'm experimenting with different syntax, if you're interested.

(also, you can cast like this: int variable = (int) somethingElse; )
(and you can return null instead of a struct, since internally structs are pointed to, and null indicates nothing to point to)

Just a note -- be aware that virtually any other language package you (or users of your OS) might consider for the future will expect C mechanics to be available, or require appropriate wrapping.

Simplest example, Perl. The interpreter offers C interfacing, and quite some scripts expect that to be working. Also the various modules are written in C... Now I know Perl is "old news", but you get the idea: C is the "lingua franca" of programming, so you'd be better off if your system programming language of choice allows "speaking C" in some way.

Edit: Post # 7000.

Elttob wrote: (also, you can cast like this: int variable = (int) somethingElse; )
(and you can return null instead of a struct, since internally structs are pointed to, and null indicates nothing to point to)

Thanks for answering....

And thus my confusion....
If structures are internally represented as pointers... does AA take the address of mysandwich? Or fail as a syntax error?

Does test2b() fail due to a syntax error?
Does test2c() succeed because of a cast?

Not trolling you but I am concerned with your ideas on l-value/r-value semantics.



Also you said

support code organisation to a greater extent than C, by using packages rather than naming all your functions with prefixes

however the code
Has exactly the prefixes you mentioned. Now I presume you just want code in the body of the package to tighter and easier to read... i.e. no prefixes. But at some point someone will come along and do this...

Now you have a bunch of code in the body of your package calling "SomeCode" but how do you differentiate between the three imported SomeCode's?

dchapiesky wrote:-snip-

Let's start with the casting.
This would not compile, as you cannot cast a struct to an int. You can, however, cast a struct's pointer ( *mysandwich ) to an int.
This would not compile, as the return type of test2a is sandwich, but the return type of test2b is int, and values are not cast implicitly. So if you were to cast them explicitly:
This would still not compile, as the return type of test2a is sandwich and you cannot cast a struct to an int. Again, you cast the struct's pointer, not the struct itself, though I could consider explicit casting of structs directly to ints in future.

As for this code snippet:
You'll be able to import code files under different names. So the code above would not compile, but the code below would compile, as long as the names you import them to are different:

I don't think implicit pointers are good for a kernel programming language.

From a maintenance perspective I want to find all references to SomeCode and now after the addition of b & c I will have to stop and look for SomeMoreCode and TooMuchCode as separate searches. Either a tool which understands your syntax and AST will have to do a complete search for me or this will just get too damn confusing.

Plus (*mysandwich) to take a pointer? what about (*AA) to take address of integer? Do I always have to put parenthesis around it to take a pointer? Otherwise BB *AA for multiplication get's confusing.

Bottom line, if you invent a new language to get rid of all the old problems, chances are you're going to introduce a whole lot of new problems.

Personally, I prefer old problems. You can google for them, if you don't know how to avoid them from experience in the first place.

In general you may be right, but this is specifically a forum dedicated to creating new problems.

Yeah, pointer syntax is still definitely wip. The joys of programming language design :p

Edit: Here's a draft of the new syntax;



Now declarations are public by default, and you can hide declarations in protected or private scopes. If statements, while loops and for loops no longer require brackets around the expression(s). Functions and variables are now explicitly defined using the function and var keywords.

Another change to the syntax which isn't shown here is direct importing; the ability to reference external functions, variables and structs directly. Suppose this is the source of AnotherFile.exc:
Normally, to call the doStuff() function, you would write:
However, by including the direct keyword at the end of the import statement, the file name and dot operator can be eliminated:
Also, what's your opinions on flat binaries? I may add it as an option in the compiler.

Elttob wrote:If statements, while loops and for loops no longer require brackets around the expression(s).

Why do you think that is a good thing?

Given the rest of the syntax, it appears rather inconsistent to me.

Solar wrote:

Elttob wrote:If statements, while loops and for loops no longer require brackets around the expression(s).

Why do you think that is a good thing?

Given the rest of the syntax, it appears rather inconsistent to me.

Yeah, I may readd them. The new syntax is spitballing right now; I'm finding what works better and what doesn't. Removing brackets was a definite experiment.

Edit: maybe only omit them for names of boolean variables?

I've decided to exclude pointers from ExC for now, they'll probably be added after arrays and structs. Also I'll start writing up some Backus-Naur to show the exact syntax of ExC. So, if you want any fundamental changes, now would be a good time

In my humble opinion -- admittedly never having "developed" a programming language myself -- you shouldn't be designing "by syntax example", adding some sugar here, some there.

You should sit down and create a list of features, goals and principles that you want to see implemented in your new language. Then write a formal syntax, and then implement a parser for that... (The parser, really, is the easy part of it, especially when based on a complete formal syntax. That much I know for a fact, because I am maintaining a parser for a non-trivial DSL...)

Solar wrote:In my humble opinion -- admittedly never having "developed" a programming language myself -- you shouldn't be designing "by syntax example", adding some sugar here, some there.

You should sit down and create a list of features, goals and principles that you want to see implemented in your new language. Then write a formal syntax, and then implement a parser for that... (The parser, really, is the easy part of it, especially when based on a complete formal syntax. That much I know for a fact, because I am maintaining a parser for a non-trivial DSL...)

I do have goals for ExC;

- I want it to be a programming language which promotes code organisation and modularity
- I want it to be a programming language suitable for both low level work and high level work
- I want it to be a programming language which is decently easy to write (i.e. it doesn't look like a massive regex like some esolangs)
- I want it to be a programming language which can compile to machine code to maximise portability
- I want it to be a programming language which doesn't require a run-time library or pre-existing memory management etc.

These are the features planned to be in ExC:

- function, variable, constant and structure definition
- package-based code management system with member hiding and remote referencing of functions, variables, constants and structures
- traditional if, while and for loops
- single or multi-dimensional arrays
- pointers

When I'm working on the syntax or taking suggestions from others, I keep these goals in mind, and look for the optimal way to implement ExC's planned featureset. At the moment, pointers are proving tricky, but I have a good idea what I want to do for the other features.