Hello, Again:

I'm not making an all new computer language, please hear me out. I'm simply against the idea of making an all new language for the Casio Prizm -- C is growing more wonderfully fun for me to code in as I delve deeper into it, and even though it's fun and all, there's not enough documentation of the Prizm to even attempt my own language for it yet. That's why I'm moving it all to the Computer Platforms of today ;D Specifically, windows to boot, I don't plan on getting Linux anytime soon.

Basically, it's a total movement over in platform, and few differences beside "Emerald" > "Verdant" (an unsuccessful language from the 80's already took the name Emerald, and it sounds like a total steal from Ruby) and "VixenVM" > "Vixen".

With that in mind, I'm much more open to suggestions than before, and I think I'll actually appreciate any help I can get, teaching-me-concepts and giving-advice wise. With that in mind, I have a few areas where I would like to see some views:

- What language should I write it in? This one will most likely turn out to be C, and that's fine, that's my idea too
- Compiled (hard), or Interpreted (Easier)? I'm thinking Interpreted.
- OO from the bottom up like Ruby/Python, or like Java or even C++? I'm thinking mostly OO based.
- What C compiler? I'm not actually sure myself, I was thinking GCC, but I've heard sayings like "LLVM is faster...", so any advice on this area is welcome.
- Changes in original syntax? I'm thinking of making it a bit more condensed.
- Changes in OOP design? Actually, I'm sticking with the weird object groups idea I came up with most likely.
- Anything else?

I want to do it the right way from the beginning, and I think I'm able enough to do a somewhat-simple Interpreted language that could be useful in ways. I know it won't be "Widely used throughout the industry to make Halo 5 dimensional games".

If you go for compiled, make your life easier and write the compiler in Python using something like PLY.

Interpreted is not easier, as it has to be powerful enough to justify its own overhead. I would recommend compiled. You can even take the lazy route C++ originally did and compile to C. So your language compiles to C where you then just invoke the existing C toolchain.



Uh, all 4 of those are "OO from the bottom up". What exactly are you considering?



Depends on what platform you are developing on. If Windows, use VC++, if OSX use XCode, if Linux use GCC.



Take a look at what Go (golang.org) did in regards to interfaces - that is a really, really cool pattern.

thanks for the help, I appreciate it.

By OO from the bottom up, I meant like the idea that 'Everything is a total object' instead of scalars and primitive in it.

The thing is, I have no idea where to start if I was doing a compiled language -- would I have to know anything about individual platform's assembly languages? Or am I completely overthinking it? Can you please give me an example of what I could use to actually compile the language, like chaining code to 'compile' to C code and run that through a compiler?

It's awesome I'm getting help from you, and obvious expert, and I thank you sincerely.

EDIT: actually when reading your post again, I realize you answered pretty much everything I asked. The question is, to invoke the C toolchain, I'm assuming all I would really have to do is just compile the .c program with a cross-platform compiler?

Java kind of has that (only Java did it wrong and screwed it all up). But primitives are a Good Thing, you want them. But even Ruby and Python mostly just fake it, which you can do. They still have primitives, they just pretend they are objects as well.



"cross-platform compiler" doesn't really exist. If you compile to standard C, you can use whatever C compiler you want to compile that. But target platform *always* matters when you are compiling, you need to accept and understand that now. Target one platform and work with that. What you write shouldn't care what the backend is, you just need to spit out valid C and the rest is easy. Or you can try something harder, like writing a front end to LLVM or GCC in which case you need to spit out whatever their respective intermediary forms are.

The thing is, you have great ideas, but to tell the truth I don't think I have the needed knowledge to conduct a compiled language -- you might find it easy, but I actually think it would be hard for me, I'n not nearly as experienced as you However, thanks for your tips, I really do appreciate them.

What Tanner suggested (and I really liked) is for now do a VM-Based interpreted language that compiles to bytecodes that are purely interpreted (I know, not a true VM) and when I get more knowledge on the matter, work my way up to having it be like the JVM.

So rather than writing just a compiler or just an interpreter, you want to write *BOTH*? How is that making things easier?

I probably won't transform it into a compiler for many a few years.

For now, it would just be a very integrated interpreter.

You still need a compiler to produce bytecode to then interpret...

I think he is planning on just testing it with ASM code written for his compiler. I hope he will be giving his op codes mnemonics so he doesn't have to write it in hEx.

I think it would be easier to compile directly to x86 asm, since then you wouldn't need to write an interpreter. It may be harder at first, but you'll see that it's a lot less work.

hmm, the arguments are pretty convincing for me to just simply do it compiled. I guess can trust your guy's opinions above my own, so I'll try to learn how to make a compiled language. While it just sounds harder, I like that idea kllrnohj said about compiling to LLVM or GCC IR (does GCC have an IR? I'm assuming it does). A few questions, then:

- would you suggest going to GCC or LLVM IR?
- which is more low level (and therefore harder to work with)?
- do you know where I could get started? I think that the actual compiling to interpreted bytecode may had been easier...
- if it's just another compiled language, how will it ever stand out against already good-enough languages like C++, Ada, and others?

I still think I would do best with an interpreter, I'm really hesitant on the compiled idea. I just think that compiling my source code to simple, familiar bytecodes I created myself would be easier and then the only hard part would really be the rest of the VM.

GCC most certainly has an IR, but once again, why not just make your compiler spit out C for GCC?

That would most likely be a bit far from optimized, but if you think it's a good idea...

however, I'm still really hesitant on the compiler idea, still. What do you suggest, Kerm?

I'd say that your primary concern would be designing the language, instead of worrying about making it go fast, which would mean picking the development and code-generation method that would be the least work for you, ie, generating compilable C. Once you had that working well, you could worry about generating IR instead.

I can see your point about the C code, but if I go that way, then I'll have to completely redesign my whole prospect of the language, and I'll have to see if that really is worth it if it gives me a bit less work and more speed.

Why? What part of the original design of the language that can't be described in C? Also, I could have sworn you already had a Verdant/Vixen thread...

C has all these horrible gotcha's and nearly everything results in undefined behaviour.. I wouldn't recommend it.
Outputting MSIL or java bytecode in text format is very easy, there is no undefined behaviour and it takes only minimal effort to convert an expression tree to stack-machine code (just output it in post-order)
The resulting code isn't going to be specially fast and in the case of java bytecode you may be limited in what you can do (MSIL has full support for unsafe pointers and value types and the like) but if speed is not a primary concern I'd go that way.

I don't really want to be rude, all these ideas are great, but I really don't think they are anything with what I really want to achieve. I'm not quite going for 'another compiled language' concept, going for speed or ease of creation on my part (I said differently at one point, but I've seen carnations of compiling to C code languages, and they always seem quite inferior and lame). Here's really what I would like to express in short words my concept:

A language that is entirely interpreted that can compile source code to bytecodes which aren't compiled but rather interpreted by an interpreter/VM written in C, somewhat like Python. This brings decent speed for an interpreted language (given the rest of my code grows pretty optimized) and is what I was truly after before this became a computer project.

The whole point of higher level languages is to ease development. Speed is secondary to features and syntax.



Not to be rude, but whatever you attempt in this regard you are almost guaranteed to fail. What we are trying to get you to do is to actually start with something feasible, something that you can get up and running quickly to then expand and grow upon. If you go the VM route, you will get very frustrated very quickly because progress will be *very* slow, especially in the beginning. If you go the "compile to C" route, you can have something up and running in a couple of days using tools like PLY for Python or Lex-Yacc for C or any number of compiler-building tools. Start simple and grow.

Compiling to C also has the very crucial benefit of being able to re-use existing libraries, which is the downfall of most languages. It doesn't matter how nice the syntax is if you can't do anything with it.



Uh, no it doesn't.



You are also completely limited to platforms that already have MSIL or Java bytecode VMs - which his target platform doesn't have. Also, if you are going to leverage existing VMs, you might as well just use the languages they already have, especially with MSIL which has the absolutely spectacularly good C#.

To re-answer an earlier question:

"use XCode" in this scenario means you have your choice of GCC or Clang (LLVM), since technically speaking XCode is an IDE (like Visual Studio or Eclipse or Code::Blocks) rather than a compiler (like Clang or GCC).

There are advantages to only having to write code for GCC (VC++ doesn't always make the same interpretation of your code), but you then have to setup MinGW or Cygwin on your Windows platform. Whether or not this is easier than installing Visual Studio and the MS SDK is debatable.