I don't understand what does this piece of code mean?

Pages: 12
You should have been given some direction in proper tokenization and transformations. An LL(1) language is simple enough not to trip students up too badly but need not be silly. For example, Object Pascal / Delphi is an LL(1) language.

I like a challenge, but saying “do your best” is not the best way to teach.
I did one of these on my own.. we had to write an assembler for a fake language ... test were a set of professor coded programs in the fake language...

I had to do that too. Coded a parser myself no problem to generate tokens for a fake language. It was actually fun and it didn't take too long. Though the professor seemed to be getting a lot of complaints that it was difficult for whatever reason.

The next compiler class was checking syntax and other nonsense - and that was not left up to us to do however we want. His way was crazy nonsense, I don't even understand what I coded, but I know it's awful and slow. I already hated Java, but these professors made sure I never touch it again.
For one of our CS Compiler exercises, we had to parse code in a given sub-set of Pascal (PL/0 from Wirth 'Algorithms + Data Structure = Programs' ) and then produce a properly formatted program using the given option-based rules. The test code consisted of several thousand characters with completely wrong white-space formatting -although a valid program. We had to produce the formatted code from this test using a given sets of options which we didn't know in advance of submitting our program - although we were given the rule for each option.
Last edited on
Compiler classes are just awful..

My professor said he was teaching the class for over 30 years, yet his OWN compiler solution didn't work properly for the final phase of the project. His compiler had several flaws that he apparently never noticed until my partner and I pointed it out to him..
Our CS lecturers were actually involved in writing proper compilers that were used within the dept. Most of the os, compilers, tools etc we used had been developed in-house - either by the lecturers or as BSc/MSc/PhD projects. Mine was a new OS for a DEC desktop computer.

I actually enjoyed my compiler lectures and did the optional advanced course along with the advanced os and languages courses.

What language was the professor's compiler for?

What book(s) were recommended? In my day they were:

Aho & Ullman - Principles Of Compiler Design (1st edition 1977). [The 'dragon' book]

The current version is:
https://www.amazon.co.uk/Compilers-Principles-Techniques-Alfred-Aho-dp-0321486811/dp/0321486811/ref=dp_ob_title_bk

Gries - Compiler Construction For Digital Computers (1971)
https://www.amazon.co.uk/Compiler-Construction-Digital-Computers-David/dp/047132776X/ref=sr_1_1
Last edited on
I liked my first compiler class. Going over tokens and simple stuff. Programming my own parser felt good too.

Second compiler class went downhill real fast.

The programming language's unique name would give away my university which I prefer to not do. But put simply, it was a Java Compiler written in Java. The programming language was pretty much just Java with a few extra bells and whistles.. I think? We never actually programmed in the language, but all the example programs our compiler had to work on looked like standard Java to me.

Creating your own compiler seems pretty useless for just an undergrad - so its hard to be interested when the professor is awful on top of that.


EDIT: Our book was written by the professor himself. Ugly, long, pointless - paragraphs explaining nothing. Didn't bother reading any of it. The book itself may have only helped in coding the compiler once.

Me and my partner did well and we even did the extra credit work which was to make the compiler even more flexible. But really, all stuff you forget real fast and didn't really learn anything from.
Last edited on
Knowing how to analyse text, build parse-trees, extract meaning etc etc are IMO very useful tools to know. I've certainly used them during my programming years far more than what I learnt from my Algorithm course (which was the only course I really, really, really... hated!) - which I think I've used 0 times....

I suppose some of it is to do with where your interests lie. Mine was always languages and Operating Systems.

I was employed by the CS dept for 2 summers before I graduated - working on assemblers and porting a Pascal compiler. I learnt nearly as much from that as from the courses themselves.

Even when I was still at school, I wrote a basic Fortran 'compiler' in Dartmouth Basic (HP TSB).
Last edited on
I've certainly used them during my programming years far more than what I learnt from my Algorithm course (which was the only course I really, really, really... hated!) - which I think I've used 0 times....

That's funny. I didn't much enjoy my algorithms classes either, but mostly because of the professors. I've learned algorithms on my own time and they're really interesting. I've been coding AIs and such, so I suppose it really does matter where your passion lies.

Knowing how to analyse text, build parse-trees, extract meaning etc etc are IMO very useful tools to know.

Sure, but we did all that before writing a full blown compiler. My first compiler class was informative and the professor was actually really good, when he wasn't talking nonsense about how he got to have lunch with the president LMAO.

I don't know. The 2nd compiler class also didn't connect theory with practical application at all. We were tested on theory, but the assignments were about actually making the compiler. It felt like I was taking two classes in one they were so disconnected.
Creating your own compiler seems pretty useless for just an undergrad - so its hard to be interested when the professor is awful on top of that.


bad prof aside, the exposure is good at undergrad level.
- maybe you really liked this stuff, and didn't know that until you got here?
- I am forever grateful for the parsing exposure. I have had to do any number of parsers over the years, and the class with the compiler stuff (It wasn't dedicated to that topic, I think it was an advanced topics in general class) helped. One takeaway was using the compiler compiler tools (lex, yacc, things like that?) just for their parsing capability. Most of them don't have to generate a program, it can also just do complex parsing for you and let you take it from the token side.

so no, I will likely never write a real compiler. But I learned useful stuff, including that I don't want to write compilers.
I had the same lecturer for both Compiler and Advanced Compiler courses. One followed from the other - the first one being more 'practical' covering parsing etc with the second much more theory orientated and covered code production etc. IMO he was very good and certainly knew his subject and how to lecture and hold interest.

My Algorithms lecturer I suppose was OK but it was very theoretical based upon the classic text Aho & Ullman "The Design and Analysis of Computer Algorithms" (1974). That course had no practical exercises - just proofs of theorems etc. One example - "Determine the upper and lower bounds on the number of vertices in an n-balanced tree of height h." It didn't help that although I liked Maths, I didn't like 'Discrete' Maths - I much preferred calculus, trig, complex etc. The compulsory maths course for CS students also didn't cover discrete maths but covered calculus, complex, series etc. Great - I enjoyed it, but of absolutely no use for any of the CS courses!
One takeaway was using the compiler compiler tools (lex, yacc, things like that?)


Although one of our Profs was involved in early work on compiler-compilers, as mere undergraduates in the 1970's we never used one...

including that I don't want to write compilers.


I never did write a full compiler. I wrote some assemblers, was involved in some work on existing compilers but got more involved in OS development. And then utilities for os's in between some application development before getting into data analysis.

Last edited on
I can't remember where the line was drawn because I picked up a math minor and took excess.
But I had to have calc X 4 (differentials|integrals|multi-variable|diffeqtns), discrete math (what a lame class, it was 95% common sense), proofs (for sure math and not CS requirement, this was one of the senior level classes), linear algebra 1 & 2, and numerical methods. I had to take another called engineering statistics which was moved out of math and into engineering, it was basically math's stats 1&2 at twice the pace. I had some sort of class on series too, also lame, you could spend 3 pages to figure out if a series converges or diverges, which you can figure out in 3 seconds with a calculator by plugging in numbers if you can't tell just by looking at it. Trig/adv geometry I had in high school (elite prep school).

Of all that, I have used a tiny bit of calc here and there, a ton of linear algebra (years of it), a good bit of numerical methods, discrete math just by nature of coding, stats (sorta, I coded up the main stats on a data set and its really all you need 99% of the time, std dev, median/mean/max/min/ and similar drive by stuff). The concepts of calc come into coding a fair bit, eg graphics and approximation of a curve with line segments I found some use there back when graphics were less sophisticated than today.
by the way, this tree structure is called «trie»
https://en.wikipedia.org/wiki/Trie
This is a late question, in the first post, I don't know why they have to make Tree* temp = root, why don't they use the original root and insert directly to it ?
Last edited on
Cause root is passed by ref so to avoid changing root, temp is used.

Why avoid changing the root ? Aren't you supposed to insert to the root ?
Last edited on
Insert starting at the root, but after root still points to root!

It's really a badly defined function!
Sorry but I'm too dumb to understand what's going on, I understand everything except that line of code....
It's simple. Imagine you had an original document. You don't want to alter the original document, but you still want to work on it!

So you make a copy of the document that you can work on so you can leave the original document untouched.

In this case, root points to the beginning of the tree. If you change root, you will LOSE access to the beginning of your tree! However, root is also the only way you can access the tree. So, you make a copy so you can access the tree, and you can change the copy without losing the original root pointing to the beginning of the tree.
@NormalUser1234

It is a recursive function, so the identity of variables gets a little muddy compared to a more iterative worldview.

The “root” is always the root of some branch of the tree, but...
it is NOT always the root of the entire tree itself.

When the user invokes the function, he passes the root of the entire tree.
But the function can work on individual branches of the tree by calling itself with a new “root” — the root of a branch.

For example, given the following tree:

                    ┌───┐
            ┌───────┤ A ├───────┐
            │       └───┘       │
          ┌─┴─┐               ┌─┴─┐
      ┌───┤ B ├───┐       ┌───┤ C ├───┐
      │   └───┘   │       │   └───┘   │
    ┌─┴─┐       ┌─┴─┐   ┌─┴─┐       ┌─┴─┐
    │ D │       │ E │   │ F │       │ G │
    └───┘       └───┘   └───┘       └───┘

The user will pass A in as the root of the whole tree.

But as the function refines its search, it may wish to work with the subtree having the new “root” starting at B. The actual root of the entire tree is not changed.

Hope this helps.

[edit] Hmm, the new forum CSS for mobile view does not respect fixed-width fonts...
Last edited on
Topic archived. No new replies allowed.
Pages: 12