When the .Net platform came out I moved from VB6 to VB.Net, C# just seemed to difficult at the time.
Fast forward about 7 or 8 years, I had to take a couple Java classes when considering grad school. After those classes C# was no longer intimidating and I moved from VB.Net to C# and never looked back.
The point of that is that taking those Java classes was almost like taking C# classes, they are that similar.
As far as books for Compilers and Interpreters, I recently got a copy of "Writing Compilers & Interpreters" from Ronald Mak, so far it seems like a pretty good resource.
C.W.
C.W , may ,May I ask what was Your own reason for dropping VB.Net and moving to C# ? Since you already new VB and would be writing for the same platform .
edit: Im just playing around with VB.Net at the moment for nostalgic reasons, but there seems to be a bit of a push for C# over VB.Net ?
C.W , may ,May I ask what was Your own reason for dropping VB.Net and moving to C# ? Since you already new VB and would be writing for the same platform .
edit: Im just playing around with VB.Net at the moment for nostalgic reasons, but there seems to be a bit of a push for C# over VB.Net ?
Mostly due to the push you mentioned; there seems to be more example code in C# than VB.Net.
I also do a lot of javascript so by using C# I can stay in the "semi-colon and curly bracket" mindset.
For an example of a Basic interpreter written in Spin, have a look at FemtoBasic in the Propeller Object Exchange. It's a simple Basic interpreter that's extensible (easy to add new statements to). It scans each line after it's entered replacing keywords with a single byte for ease of processing later. It also scans off any line number and stores it as a 16-bit binary value. The statements are interpreted as they're executed. It's slow, but adequate for a lot of simple tasks. For example, the Stamp "Roaming with PING" program works very nicely in FemtoBasic.
I had asked one of my brothers about this compiler/language question ,seeing as he is a programmer, he told me he failed the subject of building a compiler there is a lot of security measures in his current job with the tax office. none of the machines he works on is online and also its all done in virtual machines as well, VM ware. rather than virtual box. he thinks he's surrounded by nerds that talk about computer games. the last computer game my brother used was Quake !
Im actually reading about tachyon , I know im off subject with this post, but its kind of related. PJ Doc's are well written but im finding that its still quite a handful. Jazzed, your continuing work on prop C are you not? I like it more now, especially as Im no longer in a rush to understand everything I read. Im also playing with CODE:BLOCKS and using a beginners C book. Tell me if im wrong but you can use different compilers with CODE:BLOCKS, even Prop C, though I don't know how that would be of greater benefit than simpleIDE ? I don't know what C im using in CODE:BLOCKS but I had to download a few dependencies even xterm to to the book examples... , just the common C, i'll have to google ANSI C as that seems to be someway different?
Dr_A raises an interesting point - "Sooner or later you are going to need to use brackets - for example a = 2 * (3 + 4)"
It's interesting because:
a) It's not true.
b) It is actually an interesting and very useful exercise.
Let's start with a)
Many languages don't use infix notation like that. In Forth you use post fix notation so you would write:
3 4 + 2 *
Like you do on RPN calculators from HP.
In Scheme you use prefix notation which might look like:
(+ 2 (+ 3 4))
Note: Scheme folks, sorry if I have the syntax wrong here.
Even with infix notation there are choices. Normally operators have precedence so "+" will happen before "*" so you might be able to write simply:
2 * 3 + 4
So, even before we start building a compiler for our own language we see that the simple common or garden expression has many ways to be tackled and many decisions to be made. These decisions can already effect the entire style and flavour of the language design in a big way.
They also effect how complex and large the resulting compiler will be. Forth is famed for being very simple and small. Most of the reason for that is that the language design uses postfix notation rather than infix.
The syntax you design will dramatically impact the amount of work you have to do to implement it even if your options look harmlessly similar. Like the expressions above.
Now let's look a b)
Most of us like expressions in the form Dr_A presented. Most modern languages do it like that.
If you are curious about learning how to write a compiler starting with simple expression evaluation like that is a very good place to start.
Not only that but even if you give up your study of compilers after mastering expression evaluation you will have learned some things that are very useful in a lot of other programming situations. For example you may want your program to read a configuration file. How do you parse the text of your config file? What syntax or format is best for your config file? How to deal with comments in the config file? And so on. Same applies to other data presented in textual formats.
Luckily those Crenshaw articles I linked to kick off with expression evaluation. Holding your hand from the most simple expression possible, say just a number "2".
Comments
Referring to CIL maybe?
An MCU sized intermediate language might be useful someday ... it could be written in froth.
C.W , may ,May I ask what was Your own reason for dropping VB.Net and moving to C# ? Since you already new VB and would be writing for the same platform .
edit: Im just playing around with VB.Net at the moment for nostalgic reasons, but there seems to be a bit of a push for C# over VB.Net ?
Mostly due to the push you mentioned; there seems to be more example code in C# than VB.Net.
I also do a lot of javascript so by using C# I can stay in the "semi-colon and curly bracket" mindset.
C.W.
haa
but since I am learning prop C , that dosent make a lot of sense ......
The interpreter has a classic parser in it. It's very useful to understand how code like that works.
I have a C interpreter based on Herb Schildt's implementation that runs entirely in Propeller memory.
These things can be fun, but require some programming "chops" and "kung-foo (sic)" ....
I googled ANSI C, very nice explanation !!!
a = 2 * (3 + 4)
and for that simple example, you need to do the brackets first. Sometimes there are nested brackets
a = 2 * ( 3 + ( 4 ^ 5))
and your compiler (or interpreter) is going to need to decode this. An explanation of how this is done is here http://en.wikipedia.org/wiki/Shunting-yard_algorithm
It's interesting because:
a) It's not true.
b) It is actually an interesting and very useful exercise.
Let's start with a)
Many languages don't use infix notation like that. In Forth you use post fix notation so you would write:
3 4 + 2 *
Like you do on RPN calculators from HP.
In Scheme you use prefix notation which might look like:
(+ 2 (+ 3 4))
Note: Scheme folks, sorry if I have the syntax wrong here.
Even with infix notation there are choices. Normally operators have precedence so "+" will happen before "*" so you might be able to write simply:
2 * 3 + 4
So, even before we start building a compiler for our own language we see that the simple common or garden expression has many ways to be tackled and many decisions to be made. These decisions can already effect the entire style and flavour of the language design in a big way.
They also effect how complex and large the resulting compiler will be. Forth is famed for being very simple and small. Most of the reason for that is that the language design uses postfix notation rather than infix.
The syntax you design will dramatically impact the amount of work you have to do to implement it even if your options look harmlessly similar. Like the expressions above.
Now let's look a b)
Most of us like expressions in the form Dr_A presented. Most modern languages do it like that.
If you are curious about learning how to write a compiler starting with simple expression evaluation like that is a very good place to start.
Not only that but even if you give up your study of compilers after mastering expression evaluation you will have learned some things that are very useful in a lot of other programming situations. For example you may want your program to read a configuration file. How do you parse the text of your config file? What syntax or format is best for your config file? How to deal with comments in the config file? And so on. Same applies to other data presented in textual formats.
Luckily those Crenshaw articles I linked to kick off with expression evaluation. Holding your hand from the most simple expression possible, say just a number "2".
Good luck, this is all fun stuff.