ExC: Custom programming language

[Elttob]

Hi! I'm currently working on an operating system with it's own new programming language, called ExC.

ExC is a programming language which is meant to be a decent replacement for C. It won't require any pre-existing runtime environment to run, but if you want to do any serious development with it you'll probably want to make some code libraries for printing and such. The syntax currently looks a bit like this:



(subject to change, and pls don't kill me for how I placed that bracket near the struct declaration)

The syntax is similar to higher-level languages, and there are features such as function/variable hiding, packages and importing, and, of course, inline assembly. I chose to do packages instead of file paths because of three main reasons:

- Separate from directory structure (though good directory structure is definitely advised)
This is good because you can move files around without having to rewrite a thousand import statements. #getorganised

- Packages don't have to contain files
Which basically means you don't need a stdio.exc file to provide a stdio interface, which might be useful if you're doing fancy stuff with VMs.

- I like packages better, anyway
That's probably not a real reason, but Java was the first language I learned, if that helps explain why.

When you import another code file, you can reference any accessible variables and functions by specifying the file name and then using the dot operator to access the variable/function from inside the file:

Code: Select all

package a.test.file.Example;

import a.test.file.SomeCode;

public int main()
{
    return SomeCode.aVar;
}

When I say "accessible variables and functions", I'm talking about function/variable hiding. There are two keywords dedicated to this, public and private.

- Private variables are only accessible from inside the file in which they are defined.
- Public variables are accessible from all other files.
- If a function or variable does not declare itself as public or private, then it is accessible from other files that are in the same package, or a subpackage.

Some notes:

- No, this isn't C#, but yes, it's quite similar. I expect that as development continues it'll become more distinct.
- Yes, it'll be suitable for osdev, I'm designing it with low level stuff in mind.
- Possibly, I might even make an ExC compiler in ExC. You probably wasn't curious, but it'll be possible, and it'll be a pretty large scale test of the language.

So yeah. This is the first time I'm ever making a real, general-purpose programming language. It's both fun and educational to make, and, if I remember to, I'll keep you updated on it's development. What are your thoughts and/or opinions?

[hannah]

This seems to be C# but with packages.

[matt11235]

Code: Select all

private string[] goGetSomething(int myVar)
{
    return [...] "eggs and flour";
}

"eggs and flour" doesn't look like an array of strings to me

[dozniak]

Which basically means you don't need a stdio.exc file to provide a stdio interface, which might be useful if you're doing fancy stuff with VMs.

huh, wtf?

[dchapiesky]

is this a compiled language or interpreted language or an compiled into bytecode on a VM language or what?

public/private for a package?

And not to troll but why the tertiary operator when that makes your lexer/parser to much more difficult?

[Elttob]

This seems to be C# but with packages.

Not quite. ExC isn't object-orientated, and, like C, compiles to machine code. Also unlike C#, ExC is designed to do lower level stuff, hence you can make an operating system using ExC (basically what I intend to do). You wouldn't want to do the same with C#, due to the fact manipulating lower level stuff becomes more difficult, and the end result would likely not be optimal (probably you would end up with a slightly better JavaOS). And yeah, if the syntax is too similar (probably the case here lol) then I'm not really making a new programming language. Again, the syntax is subject to change, and I could probably change some syntax to make it easier for the compiler, but only marginally harder to write (e.g. adding a 'protected' keyword and requiring an access modifer wouldn't be too hard, but would simplify the variable and function code, since most of the time you'll probably be using public/private anyway)

is this a compiled language or interpreted language or an compiled into bytecode on a VM language or what?

public/private for a package?

And not to troll but why the tertiary operator when that makes your lexer/parser to much more difficult?

1. Compiled language, no VM's required but you could if you wanted to.

2. I'm not sure what you mean by that. I'll assume you're talking about hiding packages, which could be useful. I'll consider it :p

3. I like the tertiary operator personally, and yes, that makes my compiler more complex, but I'll be able to manage (hopefully) since I'm implementing more core features first (i.e. functions and variables) before working on other, less required features (i.e. arrays, structs and the tertiary operator ofc :p )

Which basically means you don't need a stdio.exc file to provide a stdio interface, which might be useful if you're doing fancy stuff with VMs.

huh, wtf?

I'll give an example since I acknowledge this wasn't really clear. In some languages you can access certain functions and variables which you can't actually write yourself. For example, in Lua, the print() function doesn't exist as a Lua function, instead the call is passed to the Lua VM to output stuff, meaning you can't write the print() function yourself. Hope that helps!

Code: Select all

private string[] goGetSomething(int myVar)
{
    return [...] "eggs and flour";
}

"eggs and flour" doesn't look like an array of strings to me

Nice catch! I was probably half-asleep while writing this :p

[Solar]

ExC isn't object-orientated...

Code: Select all

TestTwo.publicFunc( ... )

[Elttob]

ExC isn't object-orientated...

Code: Select all

TestTwo.publicFunc( ... )

Yeah, that's the only arguable part of it. Personally, I would still argue ExC isn't object-oriented as the only OO-like features ExC implements are member hiding and, of course, the way you reference functions and variables from other files could be considered OO-like. However ExC does not have classes, inheritance, abstraction etc.

In reality ExC is probably only object-oriented to a small degree, but I may be wrong since I'm practically self-taught and only learned of programming paradigms in the last 5 months or so.

[Kevin]

ExC isn't object-orientated...

Code: Select all

TestTwo.publicFunc( ... )

This is valid C code if TestTwo is a struct and publicFunc a function pointer. Does that make C object oriented?

I think the most important concept of OO is not the syntax of function calls, but inheritance and polymorphism, and this is completely missing.

[Solar]

How can you tell?

[Sik]

This is valid C code if TestTwo is a struct and publicFunc a function pointer. Does that make C object oriented?

That was the whole idea behind COM, to be fair.

[Solar]

To be completely fair, "object orientation" is about how much a language supports that programming style. Function pointers in structs are one step. Information hiding by public / private is another. Inheritance is the next. Polymorphism the next, and so on.

There is no cut-and-dried border at which there are "OO" languages on one side, and "non-OO" on the other. But ExC is further down the road than C is (though not as far as C++ is).

----

Generally speaking, though, I consider either creating a feasible OS or creating a feasible programming language to be a more-than-one-man-sized endeavor. And I don't really see that much of a niche for a system programming language between C and C++. There are a lot of languages who've made an attempt at that niche, among them quite successful ones like D or Rust.

So. Why ExC instead of C, C++, or Rust? Give me the elevator pitch.

[Roman]

How does "return null" work? Does it return a null pointer? If yes, then why doesn't the return type mention that a pointer is returned?

Why is it better than C++ and Rust?

[Schol-R-LEA]

There is no cut-and-dried border at which there are "OO" languages on one side, and "non-OO" on the other.

<well-actually mode="pedantic yet of questionable validity">
There is, but it isn't a useful one as it rules out pretty much everything except Smalltalk, Self, and a handful of toy languages, and if followed strictly would hamstring efficiency.

Most of the characteristics Alan Kay defined for OO in the old days were in fact consequences of the actual defining aspect of OO, namely that all communication between objects is done through message passing - by which I mean, the object would be passed a data structure with the name of the method (or a hash of same) and the invocation arguments, which the object's resolver/mini-interpreter would parse, and then look up the matching method for in a table.

The dot notation used in most later OO languages (starting with C++, though it was itself taken from Simula, which was one of the inspirations for both Kay and Stroustrup) was meant to mimic this, while avoiding the inefficiency of actually sending messages to independent objects which would then have to interpret them and match them to a given method (which would itself be made up of messages, drilling down until you hit primitives).
</well-actually>

[Solar]

This is the point of "well, actually..." where The Mighty Jingles of Youtube fame usually edits in a soundbit of a rifle being cocked and fired.

But let's return to the elevator pitch. Why ExC, and not C, Rust, C++? Is ExC something you do "because you can", i.e. for no particular reason (which would be fine for me), or do you think ExC is bringing something of actual value to the table?