Omnimaga

General Discussion => Technology and Development => Computer Projects and Ideas => Topic started by: BlakPilar on August 14, 2011, 10:57:19 am

Title: The dawn of a new OOPL
Post by: BlakPilar on August 14, 2011, 10:57:19 am
SEE THIS POST (http://ourl.ca/12538/268157)
Spoiler For OP:

In case you haven't looked (or even glanced) at my signature, I'm writing an OOPL called Zenon. :D (In case you don't know what that means, it stands for Object-Oriented Programming Language.)

My only problem is: I'm terrible at coming up with syntax because I have no creativity :( The syntax I have right now looks cool, but it's impractical. It requires more unnecessary typing than I'd like.

This language will be .NET-based, so anything you can do in C# or VB, you'll be able to do in this. This includes designing forms, creating console-based applications, and probably libraries (.dll's) for use with other, non-Zenon programs. My request to you, the Omnimaga community, is to help construct a syntax for this language.

I guess the only thing I want you to keep in mind when suggesting syntax and whatnot is to try to make it fun to write in. Something you'd like to make a program or two with. The language can be simple, complex, or moderate, it can be completely original or it can combine elements of other languages together. But please, this will not be an esoteric language ;)

Syntax last updated: 4:24pm EST (GMT-5) on 19 Aug 2011.
Change with block comments and methods, etc.!!

Spoiler For Current syntax:

* - Indicates a change
+ - Indicates an addition
# - Indicates a removal
Since last edit, that is.
--
As in many languages, a semi-colon will mark the end-of-line.
--
Strings will be like every other programming language; beginning and ending with a (double) quote.
--
*Block comments will be [[ comment ]], single line comments will be "//comment"
--
Modifiers are the same as any .NET language. These include "public," "private," "sealed," and "abstract". However, "public" will be "global," "private" will be "internal," "sealed" will be "closed," and "abstract" will be "open".
--
Threads will be a built-in type for easier access. (yay)
--
#Moved arrays and matrices so they have their own mini-topic
--
Instead of using "." to access the methods of a variable, the colon (":") will be used. I.e. instead of "<var>.<method>;", it will be "<var>:<method>;"
--
Accessing the current application/class will be "current" instead of "this" or "Me".
--
Inheritance will be implemented.
--
"parent" will be used instead of "base" (like in C# or <insert other language that uses "base">) or "super" (like Java).
--
"break" (from C#, not sure on its equivalent in Java, etc.) will be "exit"
--
"quit" will be a general command to exit the program, unless in an infinite loop :P.
--
+Preprocessor directives will only be in the main file and will be denoted by '@'.

VARIABLES
Will be defined by "<type> <name> [= <value>];"
-Here is a list of current types (layout is "<type> : <declaration name> : <default value>")
  -string   : str  : ""
  -integer  : int  : 0
  -boolean  : bool : false
  -byte     : byte : 00

CONDITIONALS
Will be accessed by
 "if (<condition>) {
   <code>
  }
  elseif (<condition>) {
    <code>
  }
  else {
    <code>
  }"
You will also have the ability to use switch/case statements that will be used in a similar fashion.

METHODS / FUNCTIONS
Methods, since they don't return anything, are sub-procedures and therefore will be accessed by
 "<modifiers> sub <method name> ([<arguments>]) {
    <code>
  }"
Functions will be similar, replacing "sub" with their return type.
 "<modifiers> <type> <function name> ([<arguments>]) {
    <code>
    return <type>;
  }"

LOOPS
Will support 4 types of loops:
-While
 "do {
    <code to be executed until condition is false>
  } while (<condition>);"
-Until
 "do {
    <code to be executed until condition is true>
  } until (<condition>);"
---Both of the above loops can have the "test" (the "while" or "until" part) either before "do", or after the closing brackets like in the example.
-For
 "for (<int>[ = beginning], <end>[, increment]) {
    <code>
  }"
-For Each
 "foreach (<type> <var> in <collection [of type]>) {
    <code>
  }"
Thanks to calcdude for the idea of testing before and after.

CLASSES
Will be implemented in the same way that most languages (at least the ones I know) implement them.
 "<class name> <class var name> = new <class name>;"

ENUMS
An enum, in case you don't know what it is, is basically a group of numbers. However, in Zenon, they can be a group of anything. (If that can't be done, then a new group type will be added called Group)
-Declared:
 "<modifiers> enum <name> {
    <name> = <number>,
    <name2> = <number>,
    etc.
  }"
-Accessed:
 "<enum> <var name> = <enum>:<enum child>;"

+ARRAYS/MATRICES
As an example, here are declarations of a string array, matrix, and collections that have more that 2 dimensions:
-Array:  str# hello = new str#[0][1][2];
-Matrix: str# hello = new str#[[0][1][2],[3][4][5]];
-Multi:  str# hello = new str#[[0][1][2],[3][4][5],[6][7][8]];
Or, for non-specific declarations, one can do
-Array:  str# inf = new str#[];
-Matrix: str# inf = new str#[,];
-Multi:  str# inf = new str#[,,];

Title: Re: The dawn of a new OOPL
Post by: Ashbad on August 14, 2011, 11:10:24 am
Will this language be interpreted, or compiled?  If compiled, strong typing is good, and I even suggest you look into the typing system if Haskell; it's pretty awesome.  If compiled, I suggest a typing system similar to Ruby's or Python's.

For syntax, many people will say "keep it similar to other languages!" but I always found that it's cool to make up something a bit different.  One type of syntax I always liked was from my old language project, Verdant (http://ourl.ca/11300) and while the language design was highly flawed, the actual syntax was rather nice.

For a name, you could always just call it "Project Xenon" for now, and come up with an actual name later.

Good luck with this; most language projects here (80% of them were probably mine -- I made *many* attempts at creating programming languages before losing interest, but even still I'm secretly working on one all the time) usually die, but the ones that live to see the light of the world do fabulous.  Hope it goes well! :)
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 14, 2011, 11:31:58 am
Well right now the project name is Yanoopl (yet another object-oriented programming language), but for the name, the misspelling was intentional ;)

The language will be compiled until I figure out how to add some sort of debugging system like Visual Studio and its breakpoints (because I'd imagine there's some interpreting there.)

I don't think this will be dropped. It will slow down when school starts and pick up on breaks, but I think this is something that will definitely help with colleges and jobs in the future lol. Plus this is something I've been meaning to do for a while, and now I know how.

I'm not on a computer now, but I'll look at Haskell and your language when I am.
Title: Re: The dawn of a new OOPL
Post by: LincolnB on August 14, 2011, 12:35:57 pm
Is this going to be used with on-calc programming, or will it need to be compiled on a computer?
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 14, 2011, 01:01:36 pm
This has nothing to do with the calculator lol

EDIT: Damnit, wrong forum... Can someone move this? <_< (To here (http://www.omnimaga.org/index.php?board=164.0))
Title: Re: The dawn of a new OOPL
Post by: FinaleTI on August 14, 2011, 01:33:59 pm
This has nothing to do with the calculator lol

EDIT: Damnit, wrong forum... Can someone move this? <_< (To here (http://www.omnimaga.org/index.php?board=164.0))
Done.

This sounds like an interesting project. Can't wait to see how it turns out.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 14, 2011, 03:08:01 pm
Thank you!

Until I get some syntax down, really the only thing I can work on is the environment and maybe some compiling :/
Title: Re: The dawn of a new OOPL
Post by: LincolnB on August 14, 2011, 06:57:20 pm
This has nothing to do with the calculator lol

EDIT: Damnit, wrong forum... Can someone move this? <_< (To here (http://www.omnimaga.org/index.php?board=164.0))

Got it, I was a little confused :)
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 14, 2011, 07:21:43 pm
Lol, sorry about that fredkin.

Anywho, I've added some beginning syntax to start things off. :D
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 14, 2011, 11:58:59 pm
Umm. A couple of things. I think you should make strings be able to be in single our double quotes, just because so many people are so used to that. Also, instead of the @ symbol, PLEASE PLEASE PLEASE use escape characters ("\n"=newline "\t"=tab "\\"=\ "\0"=null "\""=" "\'"=' etc.)
They are used for every computer language I've seen. (Python, Java, C++, C, Groovy, C#, Javascript, PHP, etc.)
Finally, methods can return a value. If they don't want to, then the return type is void.
Title: Re: The dawn of a new OOPL
Post by: fb39ca4 on August 15, 2011, 12:59:04 am
Umm. A couple of things. I think you should make strings be able to be in single our double quotes, just because so many people are so used to that. Also, instead of the @ symbol, PLEASE PLEASE PLEASE use escape characters ("\n"=newline "\t"=tab "\\"=\ "\0"=null "\""=" "\'"=' etc.)
They are used for every computer language I've seen. (Python, Java, C++, C, Groovy, C#, Javascript, PHP, etc.)
Agreed. I think the C style of quotes, where single quotes are for a single character, literally replacing it in the program with the ASCII constant, and double quotes for strings, works better, rather than not differentiating between the two, though.
Title: Re: The dawn of a new OOPL
Post by: Scipi on August 15, 2011, 01:12:40 am
I think single line comments using "//" would be nice. I know I usually just use that for all my commenting.

You seem to use a lot of brackets, what if things like arguments were separated by brackets instead of commas, say:

Code: [Select]
MyFunc([arg1][arg2][arg3])

{{or}}

int [var1][var2][var3];

{{or even}}

int array1[5] = [[1][2][3][4][5]];

{{[] == null}}

Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 15, 2011, 09:34:40 am
Umm. A couple of things. I think you should make strings be able to be in single our double quotes, just because so many people are so used to that. Also, instead of the @ symbol, PLEASE PLEASE PLEASE use escape characters ("\n"=newline "\t"=tab "\\"=\ "\0"=null "\""=" "\'"=' etc.)
They are used for every computer language I've seen. (Python, Java, C++, C, Groovy, C#, Javascript, PHP, etc.)
Finally, methods can return a value. If they don't want to, then the return type is void.
Going in order:
-I suppose I could use both, but it's just hitting the key associated with both once easier quicker than holding shift then hitting it? (Basically, isn't it easier quicker to just type a ' than a ")
-I'll use the escape character for the single quote, but I had already planned to implement it for other characters like tab, line feed, etc.
-I've never seen something like "private void something() { /*code*/; return void; }". To me, methods and functions are different. "private void" would be a method, and "private <any type other than void>" would be a function.

Agreed. I think the C style of quotes, where single quotes are for a single character, literally replacing it in the program with the ASCII constant, and double quotes for strings, works better, rather than not differentiating between the two, though.
But honestly, how often do you use a char literal? (I'm not being a smart-ass, I really want to know :P) I might implement the char type for shiggles, but I don't even know how often it's used.

I think single line comments using "//" would be nice. I know I usually just use that for all my commenting.

You seem to use a lot of brackets, what if things like arguments were separated by brackets instead of commas, say:

Code: [Select]
MyFunc([arg1][arg2][arg3])

{{or}}

int [var1][var2][var3];

{{or even}}

int array1[5] = [[1][2][3][4][5]];

{{[] == null}}

Well, when I wrote something like "([arguments])", I meant that the "arguments" part was optional, but I like that idea :). The only thing I'd change would be the array part. It's going to be like VB (without the ability to change index numbers :P), so it would be "int array1(5) = ([1][2][3][4][5]);" I'll also put in single line comments with "//".
Title: Re: The dawn of a new OOPL
Post by: Scipi on August 15, 2011, 10:09:19 am
Also, global variables could have a symbol, like $[var] and could be defined with <>

int [regvar]<globalvar>
/me wonders if there could be a command that allows the programmer to include other .NET languages within the code

Hmm. Like:

Code: [Select]
{{Zenon code here}}

|<C#>
/*
C# code here
*/
|

{{More Zenon code here}}

Title: Re: The dawn of a new OOPL
Post by: Ashbad on August 15, 2011, 10:21:13 am
Umm. A couple of things. I think you should make strings be able to be in single our double quotes, just because so many people are so used to that. Also, instead of the @ symbol, PLEASE PLEASE PLEASE use escape characters ("\n"=newline "\t"=tab "\\"=\ "\0"=null "\""=" "\'"=' etc.)
They are used for every computer language I've seen. (Python, Java, C++, C, Groovy, C#, Javascript, PHP, etc.)
Finally, methods can return a value. If they don't want to, then the return type is void.

^ agreed with all of that

Since is is probably intended to be a bit higher level of a language than C/C++, can ENUMS be composed of algebraic data types instead of just aliases for numbers?

Another thing: the subroutine thing has little point if it *takes* arguments but doesn't return anything.  The function thing is on the right path, though I think you should just stick with the function thing but call it a sub instead (so that way if you in the future decide to add real functional aspects to the language, you don't have to completely re-invent everything)

Also, having something like "var" for declaration of any type and "string" for declaration of a string is a bit mixed up, since if you're going to have a var declaration you should just make it solely "var" or make them type in the type of the declared variable beforehand (the latter is like most statically typed languages, the former is more like dynamic declaration because a variable is never bound to a declared type)

Also, if this is an object oriented programming language, classes are a *must* for any initial release.  Without classes, it's not real object oriented programming, it's more of a struct-defined language, with no firm backbone for objects and no way for users to declare their own slew of object frameworks.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 15, 2011, 12:15:23 pm
@HOMER, if that'd be easier to help identify if vars are global or internal, sure, I'll add that. As for the other-language thing, again, nice idea. I think if I did that, though, I would probably have the other-language code be on its own page and have "#imports <file name>;" or something similar at the top.

@Ashbad, for enums, do you mean something like this?
Code: [Select]
int hello = 5;
private enum Test [[
  Times2 = hello * 2,
  Plus2 = hello + 2,
  etc.
]]
As long as the variable used to modify the values is local, I'm sure it wouldn't be too hard to implement. If I can't do that, though, would something like an enum but called a "typegroup" (name off the top of my head :P) that can do that be sufficient? As for "var" I just thought that would be nice because I know that's something people who use Python really like about it. But, if it's redundant, I'll remove it. And I know classes are a must, but are namespaces?
Title: Re: The dawn of a new OOPL
Post by: Ashbad on August 15, 2011, 12:44:41 pm
No, algebraic data types so that the elements of an enum like is:

Code: [Select]
enum colors {
  red,
  blue,
  green,
}

So that red, blue, and green are different values, and don't just correspond to an integer type.  Of course, checking between data types would be done mostly at compile-time.  This is just a little part about how algebraic data types work (different ways to construct them and treat them based on used value constructors, etc.) but it makes things safer and less error prone.

Also, namespaces are good.
Title: Re: The dawn of a new OOPL
Post by: SirCmpwn on August 15, 2011, 12:53:16 pm
What is your goal with this language?  There are already plenty of good object oriented languages out there for .NET.  I don't mean to be discouraging, I just don't want you to be disappointed at the end of this project.  C# and VB.NET have hundreds of developers working on them :/
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 15, 2011, 12:59:10 pm
@Ashbad, alright, I think I understand and can probably implement that.

@SirCmpwn, the goal is just to be a usable OOPL. I know other .NET languages are more widely used, but I just think it'd be neat to have a language to call my own ;D
Title: Re: The dawn of a new OOPL
Post by: Spyro543 on August 15, 2011, 05:12:24 pm
I should post about my project of making a programming language...
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 15, 2011, 05:27:21 pm
I should post about my project of making a programming language...
You should.

Also...
Another thing: the subroutine thing has little point if it *takes* arguments but doesn't return anything.  The function thing is on the right path, though I think you should just stick with the function thing but call it a sub instead (so that way if you in the future decide to add real functional aspects to the language, you don't have to completely re-invent everything)

I disagree. You can have a subroutine that takes arguments yet does not return anything. Especially if you use that subroutine over and over.

For example, before I started using SharpDevelop's TextEditor, I attempted to make my own. In that, I had a subroutine called Reset, and it looked like this.
Code: [Select]
private void SetCurrent(Color highlight, int pos, int len) {

    this.SelectionStart = pos;
    this.SelectionLength = len;
    this.SelectionColor = highlight;

}

I could use that whether I was highlighting a word, or just setting the colors back to normal to resume typing.

Keeping "sub" and "<any type other than sub>" will also help with organization and readability, in my opinion.
Title: Re: The dawn of a new OOPL
Post by: Scipi on August 15, 2011, 06:52:32 pm
I think you should take the C++/C#/Java/Etc way of things and have a modifier if the function doesn't return anything. Also, I thought methods and functions were the same thing more or less and were used interchangeably.

But I think it would add confusion if there was a separate command for void functions than regular functions.

Perhaps:
Code: [Select]
null func1()
[[
{{Code here}}
]]

And I don't think void functions are just subroutines. I've used them for taking objects passed to them via address and modify them directly. Like displaying images to a Window and whatnot. Though idk, would sub make them lighter and faster than just a different data type for a function?
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 15, 2011, 08:13:31 pm
How would having a "separate command" add confusion? C# has "null" and "void" which are essentially the same thing. The only difference (between methods and functions) is in voids, nothing is returned because it doesn't take "void" or "null" as an actual type definition.

When I was taught programming in school, I was told that a subroutine could or could not be passed any number of items and it could choose to directly modify those items or use them to modify something else within the program, and a function could or could not take arguments but returned some kind of value whose type was not null or void, but it could be null in value.
So this would be a subroutine (NOTE: in the class that I took, we used VB6; I'm just applying my learning to C#):
Code: [Select]
private void RoutineName(<any number of modifiers>) {

    //do stuff, but don't return anything

}
And this would be a function:
Code: [Select]
private <any type that's not null or void> FunctionName(<any number of modifiers>) {

    //do stuff

    return <variable that is the same type as that specified in the function definition>; //This was the key difference between a function and a subroutine; this actually returned something

}
That's what I mean when I talk about that.
Title: Re: The dawn of a new OOPL
Post by: Scipi on August 15, 2011, 09:12:06 pm
Oh I see. I thought there would be a different way of defining a subroutine and a function other than data type so that threw me off a bit.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 15, 2011, 09:16:32 pm
Nah, it's more of my bad because I assumed that that was how those were generally defined. But, you know what they say about assuming ;)
Title: Re: The dawn of a new OOPL
Post by: XVicarious on August 15, 2011, 09:25:19 pm
I don't know if someone already responded to you about the whole " vs ' thing yet (I skimmed after a few posts), but for programmers now typing a " for a string is second nature. Making it easier. If it is someone who is learning to program than IDK maybe it is.
Its just my opinion because I am just so used to pressing Shift-' to make a string.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 15, 2011, 09:31:21 pm
Yeah, I agree now. I tried making a few sample dummy codes and I constantly typed " before ', so I'll just leave strings to be what every other programming language does. If I do implement chars, though, I'll make it similar to C# and use 's to define char literals.

Also, DERP on my part. I forgot about loops <_<
Title: Re: The dawn of a new OOPL
Post by: Scipi on August 16, 2011, 07:22:01 pm
/me wonders if there could be a new kind of loop that could be useful to add.

I can't wait to try this language. Hopefully it will catch on. :D
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 16, 2011, 07:51:04 pm
Hey, if you can think of a new loop and at least it's equivalent in VB or C#, I'll do my best to implement it :)

And I can't wait to try it out either, and hope it catches on too, but I need to at least get the layout finalized and get the compiler ready for a couple of controls :/
Title: Re: The dawn of a new OOPL
Post by: Spyro543 on August 17, 2011, 08:06:32 am
Add Darl181s to this language!!!
Spoiler For what I'm talking about:
Add Gotos. What did you think I was talking about? <_<
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 17, 2011, 11:11:56 am
Add Darl181s to this language!!!
Spoiler For what I'm talking about:
Add Gotos. What did you think I was talking about? <_<
Hmm... Why?
Title: Re: The dawn of a new OOPL
Post by: Spyro543 on August 17, 2011, 01:07:33 pm
Well...some people (me) could use gotos (which are nice). Sometimes a while or for loop just doesn't cut it...
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 17, 2011, 01:53:00 pm
Sometimes a while or for loop just doesn't cut it...
What about a subroutine? Or function?

Spoiler For settling the debate about what I mean about that -_-:
Here's the definitions in the AST:
Code: [Select]
        //Method: same as a function, it just doesn't return anything
        //[modifiers] sub [name] ([arguments]) [[ {{ code }} ]]
        public class Method : Stmt {

            public Stmt[] Modifiers;
            public string Name;
            public Stmt[] Args;
            public Stmt[] Code;
       
        }

        //Function
        //[modifiers] [return type] [name] ([arguments]) [[ {{ code }} ]]
        public class Function : Stmt {

            public Stmt[] Modifiers;
            public Type Return;
            public string Name;
            public Stmt[] Args;
            public Stmt[] Code;

        }
Title: Re: The dawn of a new OOPL
Post by: Scipi on August 17, 2011, 02:14:15 pm
I have an idea for a loop.

What about a loop, that can spawn other loops running in their own threads like:

Code: [Select]

parent While (x)
[[
{{code}}
]]

child for()
[[
{{more code}}
]]

parent and child runs at the same time and parent will wait for child to end if it reaches the end first.
Title: Re: The dawn of a new OOPL
Post by: Spyro543 on August 17, 2011, 03:14:12 pm
That sounds awesome :D

I can think of many different applications for it!!!


...


...
ok maybe not right now...but later!
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 17, 2011, 03:40:01 pm
So like... Nested loops that aren't nested?
Title: Re: The dawn of a new OOPL
Post by: Broseph Radson on August 17, 2011, 03:54:40 pm
How about loops that can manipulate or wait for each other regardless of where they are? Maybe have them have a name as well as a type and arguments...possibly make them public or private...or even allow them to be treated entirely like objects?
Title: Re: The dawn of a new OOPL
Post by: Scipi on August 17, 2011, 03:55:54 pm
Almost. Basically two or more loops that run at the same time using multithreading.
Title: Re: The dawn of a new OOPL
Post by: Broseph Radson on August 17, 2011, 03:58:03 pm
I like that idea. They could be public to all threads or private and could be referenced as [thread id].[loop name]
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 17, 2011, 04:01:49 pm
Lemme take another shot at it... A type of thread that is basically a group of loops that can manipulate/"talk to" each other?

EDIT: Broseph, I'd have to make a class inside the compiler, but I might be able to treat loops like objects.
Title: Re: The dawn of a new OOPL
Post by: Broseph Radson on August 17, 2011, 04:03:59 pm
Edit: derp I didn't read that right

Yeah basically ;D
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 17, 2011, 04:11:33 pm
Hmm... I'd have to check about the "manipu-thread" (catchy, eh? ;)) thing and the loops-as-objects thing. I have an idea for the object one, but I'd have to wait until the compiler gets more complete to test it out :/
Title: Re: The dawn of a new OOPL
Post by: Broseph Radson on August 17, 2011, 04:12:23 pm
Good luck!
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 17, 2011, 06:11:41 pm
we definitely need Synchronization keywords.
Code: [Select]
sync(object)
[[
{{code}}
]]
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 17, 2011, 06:52:41 pm
What would synchronization do?
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 17, 2011, 07:23:11 pm
It would make it so that 2 threads couldn't access the same resource at the same time, as that would mean that each thread could have the possibility of accessing some part of the object while the other thread is changing that part. That would be BAD.

EDIT: Btw, I am almost done with an awesome Command Line Parser (CmdLineParser is the actual class name). It's highly customizable and supports flags, options, and args. After that, I'll come up with something else to work on.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 17, 2011, 07:55:45 pm
Do we need a sync, or can we just implement that at compile time?
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 17, 2011, 08:08:43 pm
It's basically the same thing as C#'s lock keyword.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 17, 2011, 08:20:57 pm
Alright, sure, if it'll help.
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 17, 2011, 10:59:54 pm
Status update:
The command line parser is DONE!
I am working on a tokenizer.
Also working on a regex handler.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 18, 2011, 07:12:53 am
EDIT: Nvm, I'm thinking of a scanner ;D
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 18, 2011, 08:52:34 am
What? So I shouldn't do the regex handler? Or the Tokenizer? Or both?
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 18, 2011, 09:13:19 am
No, you can keep them, I was just thinking of something completely different. So the command line parser is kind of like what Python does?
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 18, 2011, 09:16:15 am
I don't know. But this allows you to set up a bunch of possible flags, options(flags with values), and the number of params allowed. Then give it the array of strings you receive as the only arg to the Main() method. It will parse them, and you can query it for stuff lie to see if a certain flag was passed on the command line.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 18, 2011, 09:21:18 am
Oooohh, okay. Nifty! :D

Anyway, the way I learned/understand it, a compiler has four main parts: the AST, the scanner, the parser, and the code generator. The code generator will take the longest, but should be fairly easy if we break it down into separate classes (which I plan to do). I've gotten the scanner and AST done as far as the language goes (by that I mean "the completeness of the language"), and the parser can parse expressions and I'll be working on the statements part today. Then we only need to make the code generator :D
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 18, 2011, 09:25:14 am
Okey dokey. What does AST stand for anyways?
Title: Re: The dawn of a new OOPL
Post by: Scipi on August 18, 2011, 09:36:14 am
So what is the ETA of when the first iteration of this language going to be finished? Or is it still too early to tell?
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 18, 2011, 10:01:08 am
@Binder, it stands for "Abstract Syntax Tree", which is why in my sig I say that it's progress is the same as the syntax's.

@HOMER, um... Well... I'll say that the first version will be out by Christmas at the latest (sound good, Binder?). Though, I'm not sure how many controls it will be able to support on first release. Labels, textboxes, and buttons at least.

EDIT: Also, Binder, I have a little UI for the console because I got bored last night and I was too tired to work on the scanner. I'll send you the project so far.
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 18, 2011, 11:02:09 am
Agreed. First version out by Christmas at the LATEST. I'm really thinking more like 2 months if we keep it up at this rate.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 18, 2011, 12:13:19 pm
Agreed. First version out by Christmas at the LATEST. I'm really thinking more like 2 months if we keep it up at this rate.
Yay :) and yeah, we're doing pretty good so far progress wise.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 19, 2011, 12:33:08 pm
UPDATE It's been 24 hours, so this double post is allowed
My scanner and parser are now done in a simple sense. By that I mean that they can recognize arithmatic operations, some keywords, the four current modifiers, and non-dimensional variable declarations (as well as errors!). I'm going to be changing the way arrays/matrices are setup, though, basing it off of HOMER's suggestion.

One step closer :D
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 19, 2011, 12:56:38 pm
I didn't get much done as I spent the whole of yesterday evening making Mineopoly on my Minecraft server with my friend. Lol.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on August 20, 2011, 11:50:44 pm
UPDATE
Alright, I've been working on this for the last three hours because I dun goof'd a lot and I had many of the destructive "brain-farts", but classes definitions are now parsed correctly! :D By that I mean "global class hello {}" is now a valid statement.
Title: Re: The dawn of a new OOPL
Post by: Binder News on August 21, 2011, 02:59:09 am
Oh. Yay. Well, I got a Tokenizer done, which I can use, and a Logger framework started, which will llow for variable level of debug information to be displayed, depending on a command line flag probably.

EDIT: Uploaded Finished tokenizer and unfinished Logger framework.
Title: Re: The dawn of a new OOPL
Post by: Scipi on September 18, 2011, 01:18:56 pm
What's the progress on this? Is this still alive?
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on September 18, 2011, 01:28:48 pm
Yeah, it's still being worked on on my part, but I haven't really had much time to do much what with school starting and everything. Plus we had a movie theater open near me sooo... lol

I ran into a snag with strings not processing correctly the last time I worked on it, but integers work for the most part.
Title: Re: The dawn of a new OOPL
Post by: Binder News on September 24, 2011, 10:34:12 am
Here. I've been busy as well, but I could still take a look at it.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on September 24, 2011, 01:16:32 pm
Alright. I've attached what I have so far and a sample code file I've been working with. Strings are fine until you throw in an escape character (i.e. \n, \t, etc.) and integers don't register for some reason. I haven't really gone in-depth with the debugging, so I'm not entirely sure what it is. I might be able to work on it for a bit later today/tonight.
Title: Re: The dawn of a new OOPL
Post by: Binder News on September 24, 2011, 04:14:32 pm
BlakPilar, in the file Scanner.cs, line 108. Change input.Read() to input.Peek(). With the read, you were consuming it twice (meaning that you ended up consuming the character after it as well, without reading it).

EDIT: Post 701! I'm an Addict! Oh, that kinda sounds weird, doesn't it? Well, I'm Level 8!
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on September 24, 2011, 04:19:49 pm
Oh, duh haha. And maybe it was bytes not getting read correctly... I'll check it later and see if I have any more .Read()/.Peek() errors. (That is, unless you beat me to it ;))

EDIT: Yeah, I know the difference between Read and Peek lol. I was probably just not thinking at the time. And congrats! :)
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on November 29, 2011, 05:18:54 pm
Okay, so, I'm starting to work on this again, but it's not going to be getting my full attention. I'm thinking about possible syntax changes to make it a little easier to code in, because I want this to be an easy and powerful language. I'll be going through all of the suggestions mentioned before in this post and will listen to any future ones. I'll also need to brush up on my System.Reflection.Emit (http://msdn.microsoft.com/en-us/library/system.reflection.emit.aspx), so that will take some time, but hopefully not much. So yeah... this is the announcement of a slow reboot, I guess!

EDIT: In my spare time, and when I get frustrated with BexIDE, I'll be working on an EBNF (http://en.wikipedia.org/wiki/EBNF) definition for the language. I'll upload it when it is sufficiently complete for my liking.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on December 03, 2011, 06:53:54 pm
UPDATE
First thing's first: I've decided on a name change. The new name for this OOPL is now Alpha.NET. HOMER-16 (http://www.omnimaga.org/index.php?action=profile;u=898) and I have also written a complete (well, mostly complete) EBNF which will help with understanding syntax. I might change one or two things, maybe some keywords (I just realized I need to define all reserved words...), but otherwise this will stay the same. I'm going to be rewriting what I had from my previous compiler because I'm pretty sure I did some things wrong, and it was very... static. So I guess this is becoming my second primary project. :)

Spoiler For EBNF:

<stmt>  := [<modifier>] <type> <ident> [ = <expr> | (<expr>)]
      |  <ident> = <expr>
      |  <compound_stmt>
      |  <jump_stmt>
                |  <stmt> ; <stmt>
      |  <ident> (<expr>);
      |  [<ident> = ] <ident>, ‘.’, <method>() [, ‘.’ <method>() ...]
      |  <ident> = <ident>[, ‘.’, <ident>]
      |  <ident_block_call>
<expr>  := <type.value>
      | <arith_expr>
      | <ident>
<type>  := str | int | dbl | flt | byte | bool | char | class | enum | struct |  void | auto
<arith_expr>    := <expr> <arith_op> <expr>
<arith_op>      := + | - | * | / | % | ^ | ++ | -- | += | -= | *= | /= | %=
                |  ^= | >> | << | <bool> ? <stmt> : <stmt>
<ident> := <letter> [,<alpha_numeric>*]
<alpha_numeric> := <letter> | <digit> | ‘_’
<int>   := <digit>+
<digit> := 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<dbl>   := <digit>.<digit>*[d | D] - 15 max
<flt>   := <digit>.<digit>*[f | F] - 7  max
<byte>  := 0x<hex> | $<hex> | <hex>h | <binary>b
<hex>    := ‘0’ | ‘1’ | ‘2’ | ‘3’ | ‘4’ | ‘5’ | ‘6’ | ‘7’ | ‘8’ | ‘9’ | ‘A’ |
           ‘B’ | ‘C’ | ‘D’ | ‘E’ | ‘F’ | ‘a’ | ‘b’ | ‘c’ | ‘d’ | ‘e’ | ‘f’ |
<binary>:= ‘0’ | ‘1’
<bool>  := true | !0 | false | 0
<char>  := <any ASCII equivalent: 0 - 255>
<str>     := “ <string_elem>* “
<string_elem>   := <any char including escape chars>
<escape_chars>  := \a | \b | \f | \n | \r | \t | \x | \\ | \” | \’ | \0
<class> := [<modifier>] class <name> [: <class>* | <struct>*, <interface>*] <compound_stmt>
<struct>:= [<modifier>] struct <name> [: <class>* | <struct>*, <interface>*] <compound_stmt>
<modifier>      := public | private | static | sealed | abstract | virtual
<loop>  := for [<ident>] (<numeric_ident>; <numeric_ident> <comparison> - '==' <numeric_ident>; <numeric_ident> <arith_op>) { <stmt> }
      | do [<ident>] { <stmt> } while (true)
      | while [<ident>] (true) { <stmt> }
<numeric_ident>:= int | flt | dbl | byte
<comparison>   := < | > | <= | >= | == | !=
<enum>  := [<modifier>] enum <name> { <enum_list> }
<enum_list>    := <ident> [‘,’] | <ident> = <expr> [‘,’]
<name>  := ident
<letter>:= ‘A’ | ‘a’ | ‘B’ | ‘b’ | ‘C’ | ‘c’ | ‘D’ | ‘d’ | ‘E’ | ‘e’ | ‘F’
      |  ‘f’ | ‘G’ | ‘g’ | ‘H’ | ‘h’ | ‘I’ | ‘i’ | ‘J’ | ‘j’ | ‘K’ | ‘k’
      |  ‘L’ | ‘l’ | ‘M’ | ‘m’ | ‘N’ | ‘n’ | ‘O’ | ‘o’ | ‘P’ | ‘p’ | ‘Q’
      |  ‘q’ | ‘R’ | ‘r’ | ‘S’ | ‘s’ | ‘T’ | ‘t’ | ‘U’ | ‘u’ | ‘V’ | ‘v’
      |  ‘W’ | ‘w’ | ‘X’ | ‘x’ | ‘Y’ | ‘y’ | ‘Z’ | ‘z’
<compound_stmt>:= ‘{’, <stmt>*, ‘}’
<control_line> := ‘#’, ‘def ’, <ident>
          |  ‘#’, ‘undef ’, <ident>
          |  ‘#’, ‘if ’, <ident> (* ident must have been declared using #def *)
          |  ‘#’, ‘if ’, <const_expr>
          |  ‘#’, ‘elif ’ <ident>
          |  ‘#’, ‘elif ’ <const_expr>
               |  ‘#’, ‘else ’ <ident>
               |  ‘#’, ‘endif’
               |  ‘#’, ‘bldt ’, <build_type>
<build_type>   := console | form | lib
<const_expr>   := any “hard coded” expression resulting in <bool>
<jump_stmt>    := break | cont | ret | lbl | goto
<switch_block> := case <ident> {<type>: <stmt>}
<if>    := if [<ident>] (true) {<stmt>}
<logic_expr>   := && | ‘||’ | ‘!|’ | !
<self>  := this
<void>  := NULL
<ident_block_call>   := <ident>,'<',<numeric_ident>,'>'
<method>:= [<ident>,'.' | <self>,'.'] <name>(<params>)
<params>:= <type> <ident>*


Project Summary
AST.............90%
Scanner.........10%
Validator........0%
Parser...........0%
IL Generator.....0%
IDE..............0%
=-=-=-=-=-=-=-=-=-=
Overall.........17%
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on December 06, 2011, 04:35:20 pm
Well, nothing really to update as of yet, but I have a question. Would it help to have something like $428F automatically converted to an array like {$42, $8F} or an integer/double (17,039 in this case)? So you could do something like byte[] arr = $428F; //arr == {$42, $8F} or int b = $428F; //b == 17039. It's not a guarantee that it'll work, but I figured it'd be helpful. Also, possible minor syntax changes so I can call the language my own.

But thanks to anyone still following this :) I have yet to go through this topic again, but if you have one, please share suggestions with me!

EDIT: Also, when I have everything but the IL Generator done, I'll be uploading my source. Hopefully by then I'll have my website all setup and running.


Project Summary
AST............100%
Scanner........100%
Validator........5%
Parser...........0%
IL Generator.....0%
IDE..............0%
=-=-=-=-=-=-=-=-=-=
Overall.........34%
Title: Re: The dawn of a new OOPL
Post by: Scipi on December 06, 2011, 07:21:32 pm
For '{}' could they be "[[]]" instead? So:
Code: [Select]
while(Arg)
[[
//Code
]]
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on December 06, 2011, 07:25:51 pm
Of course! Easily done! :)
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on January 08, 2012, 01:17:59 am
As I get time, I'm going to be looking at Mono.Cecil to see about IL generation. I don't think I can use it directly to compile non-C# code, but it will be very useful in testing to see what I can and cannot due (though, I'd imagine if you can do it in VC++, you can do it in IL). I watched a video about Microsoft's Roslyn project, and it gave me a couple ideas; most importantly to create an explicit syntax tree. That would make everything very easy after lexical analysis and dead-code removal and whatnot.

EDIT: just thought I'd give that little update :)

EDIT2: I've also decided to possibly include all of the data types .NET offers.
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on April 21, 2012, 04:20:15 pm
So, yet again I am starting this from scratch! I have something I'm working on with HOMER-16, but this is different. I really want to try to do this by myself (well, the coding part).

As of right now, the name of the language (and I guess its yet-to-be-designed IDE) is Hadean, which is also the earliest time period of Earth. I want to have support for pointers*, but keep in mind that this will be a high-level, .NET based language. I think some kind of library system would be helpful too. I'd also like to know what other people would like to see in a programming language, so if you have an idea or syntax request, please let me know. :)

* Looking at some IL generated from "unsafe" C# code, it looks like only pointers to data types would be allowed, but not to arrays. I'm not entirely sure about lists or dictionaries, though I'd imagine they'd be allowed.
Title: Re: The dawn of a new OOPL
Post by: Scipi on April 26, 2012, 12:56:50 am
Hadean... I like that name :D

I don't know if you could say I'm working on it with you, since I really have been useless save for ideas, perhaps. x.x

How is the project going thus far though?
Title: Re: The dawn of a new OOPL
Post by: BlakPilar on May 01, 2012, 04:40:43 pm
So far so good! I have my scanner mostly done (at least it's good enough for now), and my parser is all set up to start building an AST :D