Overclock.net › Forums › Software, Programming and Coding › Coding and Programming › Application Programming › Designing a programming language
New Posts  All Forums:Forum Nav:

Designing a programming language

post #1 of 48
Thread Starter 
OK, so I am designing a programming language. I haven't come up with a name for it, so I will call it L for convenience on this thread. I do not intend to write a compiler for it until I have finished with the language description. I am creating this thread so that I can ask the opinions of the other programmers on this forum about how to make it most convenient to use. I will post additional questions as I come to them, but I have a few right now. Remember, this is not about right and wrong, this is about opinions about how convenient a feature is to use.smile.gif

I am going to design it as a C-style language. It will resemble C, C++, C#, Java, and all those other ones that are originally based off C. All the familiar braces, parentheses, and semicolons will be in this language. It will include object-orientedness (so classes), delegates (instead of function pointers), namespaces, overloaded operators, and generics.

Question #1:

For Boolean operators, would people like to see the !, &, and | operators, or would they like to see the keywords "not", "and", and "or". If I go the verbose route, I would also include "nand", "nor", "xor", "xnor", and "implies".

Question #2:

I intend this language to facilitate mathematical calculations, although not to the degree that you would see in Maple or something like that. In specific, I would like to include an exponent operator, a root operator, and a logarithm operator. Would people like to see the symbols "P", "R", and "L" for those operators, or would they prefer some other sort of punctuation operators (such as "^" for the exponent operator)?

Question #3:

For ease in designing a compiler, I would like to add the keywords "function" and "routine". Would people like to see these keywords added to the language, or would they prefer to have the functions and routines look the same as they always have in C? If these keywords are included, would people prefer to use the keyword "routine" instead of "void function"? I myself do not like the "void" keyword, because I am strong in math and do not like the word "function" applied to what is really a routine. A function in calculus (and algebra) returns a value, which a routine does not. Think of "routine as my version of Visual Basic's "Sub".
Lightweight gamer
(11 items)
 
  
CPUMotherboardGraphicsRAM
AMD FX-8320 ASRock 960GM/U3S3 Sapphire Radeon HD 6670 Generic RAM from Ebay 
Hard DriveHard DriveHard DriveOS
Western Digital Caviar SE WD1600 Seagate Barracuda 7200.9 OCZ Vector Windows 7 Professional Edition x64 
PowerCaseMouse
Rosewill 500-watt PSU Rosewill REDBONE Logitech M215 Cordless Mouse 
  hide details  
Reply
Lightweight gamer
(11 items)
 
  
CPUMotherboardGraphicsRAM
AMD FX-8320 ASRock 960GM/U3S3 Sapphire Radeon HD 6670 Generic RAM from Ebay 
Hard DriveHard DriveHard DriveOS
Western Digital Caviar SE WD1600 Seagate Barracuda 7200.9 OCZ Vector Windows 7 Professional Edition x64 
PowerCaseMouse
Rosewill 500-watt PSU Rosewill REDBONE Logitech M215 Cordless Mouse 
  hide details  
Reply
post #2 of 48
First of all, I wouldn't worry about what other people would like since it's only you that's going to use this. I don't mean this in a nasty way and I'm not trying to belittle your abilities; but there's so many languages out there already that it would be unlikely that anyone would adopt a "homebrew" language when there's already established ones out there with stable APIs and busy communities.

As for your questions:

#1:
I couldn't care less. It makes almost zero difference which style of operators you choose. But to go back to a point you made before your questions, operator overload isn't a feature of object orientated languages and, in my personal opinion, it's definitely not an endearing quality of any programming language.

#2:
It's probably best to stick with established conventions here; such as ^ for exponentials.

#3:
Your point about "void" doesn't really make much sense. All "void" means is that function doesn't have a return value. And plenty of C-derived languages do have reserved keywords for defining a function:
Code:
# Perl
sub foobar() {
}
Code:
// Javascript:
function foobar() {
}
Code:
// Go
func foobar() {
}
Code:
// Rust
fn foobar() {
}


In all honesty mate, I wouldn't bother trying to reinvent the wheel here. Learn a few more languages and get a better feel for what's out there. In fact I'd probably suggest you learn a functional programming language like Common Lisp or Haskell since they closer follow the the mathematical paradigm you're trying to achieve here (you can still do object orientated programming in functional languages too).

But if you do still decide to write your own language, then it might be worth learning why certain conventions are chosen for certain languages. For example, semi-colons are only used as line terminators in many C-derived languages as it's a formatting tool for the pre-compiler. Which is why many languages (though not all) without semi-colons have stricter code formatting rules (eg Go and Visual Basic uses \n terminators), and Python is amongst the strictest for formatting since it does away with block terminators as well (closing braces, End If, etc).

Then there's the question of the type system you're going to use - that needs to be decided right from the start because it has a direct impact on the operators you use. For example Perl is loosely typed which means strings and integers are converted on the fly. However strings are compared with 'eq' (equals) and numerical data with '=='. Perl also has ne, gt, lt, ge, le for binary stringwise comparisons to compliment the usual !=, >, <, <=, >=. This is where the first of many issues of operator overload come into play, because if you have a loosely typed language and == is used for both string and numeric comparison, then you have a problem when you need to return false from "007" == 7, since the former is a string and the latter a number, but the type system is ignored for the match. This is where the treble equals was born: "007" === 7. You see this feature in Javascript and PHP; and frankly I think it's a complete mess. Obviously strongly typed languages do not have this issue since string("007") == int(7) would result in a type casting mismatch. Since you're attempting to place an emphasis on the mathematical side of things, I'd probably suggest you adopt a loosely typed model to avoid issues with casting between integers and floating point numbers.

If you're not opting for a loosely typed language, then you also need to ask yourself what the inbuilt types will be. Are you going to support null types (this can have security ramifications)? What about pointer management?

Then you have the question of your runtime. Is "L" going to be compiled AOT or JIT? Or are you going to compile to machine code and bypass the need for a static runtime? The easy option would be to have "L" fully interpreted (line by line) but that would be painfully slow to the point where there might not be much practical use to "L" aside being another shell scripting type language.

And what is your target purpose for the language? Is it a systems language? For web development? For building desktop applications? 3D modelling? While most languages can be used for a variety of purposes, if you don't have some kind of target then you would be hard pressed to answer the previous question about compilation.

This is only scratching the surface, there's questions about thread management (OS threads or virtual threads?) memory management and the various different methods of garbage collection....and so on. It's a massive undertaking smile.gif
post #3 of 48
The most convient thing for programmers is to use a syntax they know. So sticking with ,|| ,&&, !=, they are all things that come naturally. As for functions... why would you want to define one with a return and one without, two different things? I understand the whole function \ routine context, but think about how you use these functions. Yeah you can declare it with "routine Blahh()" , but when you call the "routine" in the code it's still Blahh() , leaving you with the question of is it a routine or function. In javascript they dont even define the type they return, so function Blahh() could return nothing or an object. I personally prefer adding the Types to the functions because it forces validation. If you do Boolean Blahh() , and if your not returning a boolean, then there is something wrong.


Im not sure what the point of a language is without a compiler. Basically you will just end up with a parser to another language, and the advantages will be minimal and could create conflicts.
Zev's Comp
(15 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-2500K Sandy Bridge 3.3GHz GIGABYTE GA-Z68X-UD3H-B3 LGA 1155 Intel Z68 HDM... GeForce GTX 750 Ti G.SKILL Ripjaws X Series 8GB 
Hard DriveHard DriveHard DrivePower
1TB HDD 64GB SSD (Used for SRT) 500 GB. Antec BP550 Plus 550W Continuous Power ATX12V V... 
Case
COOLER MASTER ELITE 335 RC-335-KKN1-GP Black S... 
  hide details  
Reply
Zev's Comp
(15 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-2500K Sandy Bridge 3.3GHz GIGABYTE GA-Z68X-UD3H-B3 LGA 1155 Intel Z68 HDM... GeForce GTX 750 Ti G.SKILL Ripjaws X Series 8GB 
Hard DriveHard DriveHard DrivePower
1TB HDD 64GB SSD (Used for SRT) 500 GB. Antec BP550 Plus 550W Continuous Power ATX12V V... 
Case
COOLER MASTER ELITE 335 RC-335-KKN1-GP Black S... 
  hide details  
Reply
post #4 of 48
Quote:
Originally Posted by Mrzev View Post

The most convient thing for programmers is to use a syntax they know. So sticking with ,|| ,&&, !=, they are all things that come naturally. As for functions... why would you want to define one with a return and one without, two different things? I understand the whole function \ routine context, but think about how you use these functions. Yeah you can declare it with "routine Blahh()" , but when you call the "routine" in the code it's still Blahh() , leaving you with the question of is it a routine or function. In javascript they dont even define the type they return, so function Blahh() could return nothing or an object. I personally prefer adding the Types to the functions because it forces validation. If you do Boolean Blahh() , and if your not returning a boolean, then there is something wrong.
Some languages do make a syntactic distinction between functions and sub routines:
Code:
' Visual Basic 6

Function foo(bar as string) string
    return "bar"
End Function

Sub bar(foo as string)
    msgbox(foo("foo"))
End Sub

' outputs "bar"
post #5 of 48
Thread Starter 
Well, thank you both, because you raised many of the issues that I knew I would have to deal with in the development. smile.gif To answer some of your questions and address some of your issues:

I agree with you about operator overloading, except in the case of adding strings and characters together, and in the operations on such numerical types as the .NET System.Numerics.BigInteger and Complex. Which has brought me to the conclusion that I will add an equivalent of those classes to the language libraries (whenever I get around to them) instead of adding operator overloading.

Because of convention, I will also add "void", since you and Mrzev are right; it's best to stick to convention. It's just an annoyance for someone like me who knows enough about math to see that the idea of a function is slightly different between the math and programming. However, I doubt that a majority of L's users would be mathematicians, so I will stick with what I know. Which leads me to the point that even if I use "^" for an exponent operator, I don't have any symbols that look enough like the root and log signs.

I will skip loosely typed languages because I have a better way of converting. I do not intend to use floating point types in L. I will have integer types, fraction types (with a numerator and denominator), fixed-point types (with a integer portion and a decimal portion), and complex types (a pair of fixed-point types). The conversions will be handled with functions rather than typecasting. Within each type of number there will be typecasting (such as between int32 and int64 or whatever), but not between different classes of numbers.

To prevent starting a flamewar on this thread, I will say only this: I will include pointers, and they will be implemented differently from most languages. I have seen too many flamewars full of C and C++ haters about pointers, so I am not even going to to get into it here. tongue.gif

The compiler will compile to machine language for efficiency reasons. Yes, I understand how hard it is to create a compiler, and yes, I am willing to do it anyway.smile.gif

@Mrzev

Seems to me that C actually had verbose boolean operators, but maybe I am wrong?

EDIT:

Plan9, I spent so long typing this reply I missed your last post. smile.gif
Lightweight gamer
(11 items)
 
  
CPUMotherboardGraphicsRAM
AMD FX-8320 ASRock 960GM/U3S3 Sapphire Radeon HD 6670 Generic RAM from Ebay 
Hard DriveHard DriveHard DriveOS
Western Digital Caviar SE WD1600 Seagate Barracuda 7200.9 OCZ Vector Windows 7 Professional Edition x64 
PowerCaseMouse
Rosewill 500-watt PSU Rosewill REDBONE Logitech M215 Cordless Mouse 
  hide details  
Reply
Lightweight gamer
(11 items)
 
  
CPUMotherboardGraphicsRAM
AMD FX-8320 ASRock 960GM/U3S3 Sapphire Radeon HD 6670 Generic RAM from Ebay 
Hard DriveHard DriveHard DriveOS
Western Digital Caviar SE WD1600 Seagate Barracuda 7200.9 OCZ Vector Windows 7 Professional Edition x64 
PowerCaseMouse
Rosewill 500-watt PSU Rosewill REDBONE Logitech M215 Cordless Mouse 
  hide details  
Reply
post #6 of 48
Quote:
Originally Posted by Algorithm View Post

@Mrzev
Seems to me that C actually had verbose boolean operators, but maybe I am wrong?

Nope, its the same as C++.

Are you doing this for school? I remember talking to my professor and he said that the vast majority of CS majors going for their PHD end up creating their own language and compiler for their thesis or whatever.


As for pointers, it all depends on what your trying to do. Flexibility, or simplicity. Pointers scare me, but i respect their purpose.
Zev's Comp
(15 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-2500K Sandy Bridge 3.3GHz GIGABYTE GA-Z68X-UD3H-B3 LGA 1155 Intel Z68 HDM... GeForce GTX 750 Ti G.SKILL Ripjaws X Series 8GB 
Hard DriveHard DriveHard DrivePower
1TB HDD 64GB SSD (Used for SRT) 500 GB. Antec BP550 Plus 550W Continuous Power ATX12V V... 
Case
COOLER MASTER ELITE 335 RC-335-KKN1-GP Black S... 
  hide details  
Reply
Zev's Comp
(15 items)
 
  
CPUMotherboardGraphicsRAM
Intel Core i5-2500K Sandy Bridge 3.3GHz GIGABYTE GA-Z68X-UD3H-B3 LGA 1155 Intel Z68 HDM... GeForce GTX 750 Ti G.SKILL Ripjaws X Series 8GB 
Hard DriveHard DriveHard DrivePower
1TB HDD 64GB SSD (Used for SRT) 500 GB. Antec BP550 Plus 550W Continuous Power ATX12V V... 
Case
COOLER MASTER ELITE 335 RC-335-KKN1-GP Black S... 
  hide details  
Reply
post #7 of 48
Thread Starter 
Quote:
Originally Posted by Mrzev View Post

Nope, its the same as C++.

Are you doing this for school? I remember talking to my professor and he said that the vast majority of CS majors going for their PHD end up creating their own language and compiler for their thesis or whatever.


As for pointers, it all depends on what your trying to do. Flexibility, or simplicity. Pointers scare me, but i respect their purpose.

No, I am in 11th grade. This is an "intellectual exercise" for me to get experience. And just maybe create something useful for other people as well.

I will work out how to make pointers easy to use and how to make them secure as well.
Lightweight gamer
(11 items)
 
  
CPUMotherboardGraphicsRAM
AMD FX-8320 ASRock 960GM/U3S3 Sapphire Radeon HD 6670 Generic RAM from Ebay 
Hard DriveHard DriveHard DriveOS
Western Digital Caviar SE WD1600 Seagate Barracuda 7200.9 OCZ Vector Windows 7 Professional Edition x64 
PowerCaseMouse
Rosewill 500-watt PSU Rosewill REDBONE Logitech M215 Cordless Mouse 
  hide details  
Reply
Lightweight gamer
(11 items)
 
  
CPUMotherboardGraphicsRAM
AMD FX-8320 ASRock 960GM/U3S3 Sapphire Radeon HD 6670 Generic RAM from Ebay 
Hard DriveHard DriveHard DriveOS
Western Digital Caviar SE WD1600 Seagate Barracuda 7200.9 OCZ Vector Windows 7 Professional Edition x64 
PowerCaseMouse
Rosewill 500-watt PSU Rosewill REDBONE Logitech M215 Cordless Mouse 
  hide details  
Reply
post #8 of 48
I don't mean to be blunt, but other people wont use it.

If you want my honest opinion, I think you're wasting your time. You'll gain far more experience by learning Lisp or Haskell. Since most of your knowledge is tied up with object orientated programming (and C-derived OOP at that), you could learn a great deal from a functional language.
post #9 of 48
Thread Starter 
Quote:
Originally Posted by Plan9 View Post

I don't mean to be blunt, but other people wont use it.

If you want my honest opinion, I think you're wasting your time. You'll gain far more experience by learning Lisp or Haskell. Since most of your knowledge is tied up with object orientated programming (and C-derived OOP at that), you could learn a great deal from a functional language.

Why do you say other people won't use it? If it's a good language, I'm sure that it could grow in popularity. (Not to be conceited. smile.gif I understand that there are many languages, most of which are not widespread at all, but some of them became popular.)

I will certainly research some functional languages. I have fooled around with an ancient QBASIC that was on an MS-DOS floppy I had once. I know a little bit about them.

You seem to have a lot of programming experience. If you don't mind my asking, what is your profession?
Lightweight gamer
(11 items)
 
  
CPUMotherboardGraphicsRAM
AMD FX-8320 ASRock 960GM/U3S3 Sapphire Radeon HD 6670 Generic RAM from Ebay 
Hard DriveHard DriveHard DriveOS
Western Digital Caviar SE WD1600 Seagate Barracuda 7200.9 OCZ Vector Windows 7 Professional Edition x64 
PowerCaseMouse
Rosewill 500-watt PSU Rosewill REDBONE Logitech M215 Cordless Mouse 
  hide details  
Reply
Lightweight gamer
(11 items)
 
  
CPUMotherboardGraphicsRAM
AMD FX-8320 ASRock 960GM/U3S3 Sapphire Radeon HD 6670 Generic RAM from Ebay 
Hard DriveHard DriveHard DriveOS
Western Digital Caviar SE WD1600 Seagate Barracuda 7200.9 OCZ Vector Windows 7 Professional Edition x64 
PowerCaseMouse
Rosewill 500-watt PSU Rosewill REDBONE Logitech M215 Cordless Mouse 
  hide details  
Reply
post #10 of 48
Quote:
Originally Posted by Algorithm View Post

Why do you say other people won't use it? If it's a good language, I'm sure that it could grow in popularity. (Not to be conceited. smile.gif I understand that there are many languages, most of which are not widespread at all, but some of them became popular.)
They because popular because they had a team of developers dedicate 2 years building the language and a large company pushing said language:
  • Go lang has Google
  • Rust has Mozilla
  • Scala has the Swiss Federal Institute of Technology in Lausanne
etc
Quote:
Originally Posted by Algorithm View Post

I will certainly research some functional languages. I have fooled around with an ancient QBASIC that was on an MS-DOS floppy I had once. I know a little bit about them.
QBasic isn't a functional language! You're thinking of Procedural Programming and that's basically just the precursor for OOP. Functional Programming (FP) is a different beast. If you've ever written your own Javascript jQuery modules then you've probably touched on FP.
Quote:
Originally Posted by Algorithm View Post

You seem to have a lot of programming experience. If you don't mind my asking, what is your profession?
At the moment, I'm a Linux / UNIX sysadmin. But I've held quite a variety of different jobs over the years and programming in a whole slew of different languages (many of which I'm glad to see the back of laugher.gif)
Edited by Plan9 - 10/24/14 at 8:46am
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Application Programming
Overclock.net › Forums › Software, Programming and Coding › Coding and Programming › Application Programming › Designing a programming language