[Cup-Dev] Re: Hello ; some queries

[Keith J. <kja...@cr...>]

At 12:29 AM 8/31/2001, you wrote:
>Hello Keith,
>
>I have compiled the examples and executed them. It looks good to me.
>
>I have some questions:

I got some answers. However, I CC'd the mailing list, one, to point out 
this project isn't dead (-wink-, I've been busy...), and so these good 
questions are answered in the archives.

>1> is the Backus-Naur available for the Cup language. It's hectic to decode
>a file.y to find a grammar.

No. I honestly had never thought of doing a BNF format document up, mostly 
since Cup is still changing drastically. It would be changing. We are much 
closer to a final and complete syntax, but, there will probably be more 
additions and minor updates. It shouldn't be hard to get a BNF document 
drawn up from the grammar file, if anyone is interested in doing that, and 
I'm confident the syntax and semantics are 'production-level'.

>    Further, finite-state machine analysis of grammar would be easier[if at
>all it is being done].

I have to ashamedly admit my ignorance, though, rapid learning curve of 
this sort of thing. I'm still not completely sure what you mean by finite 
state machine. I'll touch on this in your 3rd question.


>2> Why C instead of C++ ? any special reasons. [ I am just curious]

Well, when i started Cup, all I wanted was a tiny little scripting language 
to do 1 or 2 things. I taught myself bison grammar, wrote a little 
grammar.y file and started toying with it. Originally, I tried to use bison 
to not compile the code, but to try and run it. Needless to say, it didn't 
get very far. Since Cup somewhat grew out of that original bison input, 
it's always just been C code, and I can't honestly say at any point did I 
say, 'Cup will be done in C'.

If I were to try and justify now why Cup is in C though, I'd list a few 
reasons:

*) Speed. (Blah, we can argue till we're blue in the face that C++ is no 
slower than C, and I'm not up for a flame war on this subject, but the 
truth is, instantiating and destroying classes makes it easy to have 
inefficient code, again, feel free to disagree, but, that's my opinion)

*) Cup itself isn't object oriented. The compiler side is completely 
linear, and I can see no advantage to trying to build C++ classes around 
it. The same mostly goes with the VM side. We are building a non-OOP 
language. There just isn't much I see that could be gained by C++.


Anyway, no one go get any radical ideas, I have no intention of making the 
Cup compiler/VM with C++. :)



>3> why not separate the Compiler from VM. Making a well-defined interface
>design of (Intermediate Language/binary code)
>    would surely help in modifications/upgrades.
>
>Further , what is the current action-plan. What parts are getting modified,
>currently. Any identified-pending job, which I can help.


Yes! Like I said above, due to the way cup has grown and the way it 
started, they've been getting slowly more and more separated. At the 
moment, the code in CVS doesn't compile, because I'm in the middle of doing 
even more separation between the two into physically different libraries. 
The VM is done, the compiler is not, and won't compile cuz it still depends 
on old shared stuff I'm eliminating. I just havn't had time as of late to 
finish this up, but, I will soon. I promise.

In the meantime, once that is done, Valentin is working on re-writing the 
compiler more or less, since currently it compiles too soon. I understand 
he's working on expression trees and so on. This will allow us to simplify 
the VM about 100 fold, since a more intelligent compiler can just produce 
conditional jumps for various loops and so on, versus how the compiler is 
at the moment, where it compiles loops into LOOP ... ENDLOOP bytecodes. 
Very ugly. The VM currently is too smart, and the compiler is too dumb. 
After we finish fully separating them, which I hope to have done soon here, 
Valentin will be making the compiler smarter, and then we'll strip the VM 
down to be dumber, so to speak.


>That's for now . I have just browsed thru the source.

Like I said, the current CVS source won't compile, because the VM and 
compiler are only halfway detached from eachother. :) And remember the VM 
is much more complicated than it will be when all is said and done. The VM 
has a huge amount of recursion, to handle looping and AND/OR order of 
execution and if blocks and so on. A more intelligent compiler will 
eliminate this by producing much more linear instructions.


>regds,
>Suresh.

Anyway, I'll say again, i didn't start Cup planning to write a language, it 
just ended up that way. I'm working on teaching myself a lot of these 
language design concepts and so on, and, Cup is making great strides 
towards some of these concepts as I learn more. So, bear with me. I didn't 
come into this having much experience with language design. :)

Keith