I could have sworn that I’d answered this before, but a Live search on “bootstrap” didn’t turn up anything, so I guess not. Anthony asked:
Do you think you’ll ever get VB to the point where it’s compiler is written in VB? Isn’t that like the ultimate programming language Right of Passage?
I’m not sure whether every major language has gone to the length of compiling itself in itself, but it’s something that would be nice to achieve one of these days with VB. There’s no technical reason I can think of why we couldn’t build the compiler in VB, but since most of the compiler codebase is currently in C++, that’s a pretty big barrier to migration. We wouldn’t even consider trying to move the codebase unless and until there was some compelling reason to do so, and so far that reason hasn’t appeared.
The initial choice of C++, of course, was due to the fact that we didn’t have a working VB .NET compiler to bootstrap us up…
For what it’s worth, apparently the newest version of the VB compiler for the mono project is written in VB. I have not verified this myself, but since this information comes from Miguel de Icaza; I suppose I could take it as fact.
You could have also chosen C#. The JScript.Net guys managed that. Then it would have been a lot easier to convert the codebase to VB.Net using an AST-level conversion process.
Or did Cool still look too much like J# then….
I believe you once did address the question of what VB was written in.
A VB compiler in VB is more of a novelty than anything of actual value. VB is turing complete so it COULD do it as we’ve seen. In fact, somewhere – can’t find the link now I was reading about a C# compiler written in VB.NET. The author said he did it to piss some language elitists off.
The only value in a managed VB compiler would be using reflection to hack certain parts – a very open source sorta thing. Is it at least C++/CLI? Dunno why that interests me, I just like saying C++/CLI and want to see some C++/CLI applications written in… well you get the point.
As a final nod the the VB team. On a recent project I found myself accessing the Microsoft Dynamics CRM 3.0 SDK. And by SDK the mean a code generated web reference… it’s huge – like 50,000 lines long.
I don’t know if anyone has ever developed in VB with a 50,000 line code file (be it a web service or the typed dataset for the CRM DMF) but it’s not pleasant. VS falls out of sync with the VBC and programming becomes significantly less logical.
As a matter of survival I decided to put those in their own class libraries and in the future I’ll use mixed language solutions to deal with this. I don’t really like programming in C# but dumping basically static code into it for development productivity is certainly acceptable. I think VB scales well enough for code that you would write (the project itself was like approx. 800 lines) but the designer gens probably spit out more code than any of us would ever write (for which I am grateful).
Come to think of it, on another project I tried using the WMI Class gen and it also puts out heavy files. Though, its problem is not that the file is to big but rather that it doesn’t output valid compilable VB (that’s the RTM not the beta). It for some reason checks if references = Nothing rather than Is Nothing. I guess no one ever considered the odd possibility that VB users would ever need to access WMI.
So anyway, back to my nearly forgotten point. Speed is good so C++ is a great choice for the vbc – no complaints on that. But we need a way to shut off background compilation at the file level – I can’t work without it at the project level – that’s just… sick.
How does the VB team suggest I deal with this or rather what are your expectations of VB users in enterprise situations. Has it always been the plan to fall back on the CIL interoperability for these situations? If pushing large code gens out into their own .dlls is the way then you might want to get on that whole Friend assemblies thing. For the record, I find it… odd that C# uses the term "Friend" in this context.
As for a VB.NET compiler in C# … that’s where I draw my line, RichB
The new mono vb complier does compile itself. It as initially written in VB.NET and tested against itself until the codebase advanced far enough to allow it to compile itself. You can easily see for yourself by checking out the project using subversion.
It comes with project setup for 2003/2005 flavors of VB.NET and include a testsuite that has the self compile test.
Yes, I had heard that they’ve got a bootstrapping VB compiler in Mono, and that’s great! I’d love to take a look at it but, of course, from a legal perspective that would be *such* a bad idea… 🙂 Bummer.
VB is currently straight unmanaged C++, no CLI. Who knows what the future will hold? (We didn’t use C#, either, because of the same bootstrapping problem – there just wasn’t enough of the compiler there at the point at which we started to consider using it, either.)
The one thing that would be nice about a managed compiler would be opening up the services to other tools…
What about Phoenix? Doesn’t that have something to do with compilers and extensibility?
What would be the legal issue with looking at the mono source… you wrote the VB language spec after all so it would be more like a compliance review. Why publish a spec if you don’t want the world to take advantage of and write compatable tools/compilers?
How would having a managed compiler open up the services? Couldn’t the existing one expose these services too?
Anthony, I was the one who threatened to write a C# compiler in VB. Since I didn’t really want to piss anyone off, I ended up writing a compiler for a new language instead. In VB, of course.
Come to think of it, I could probably use my backend with Paul’s VBParser to quickly make a VB.NET compiler in VB.NET. Is that allowed, Paul?
Anthony: The biggest question in regards to looking at source code is the license that comes with the source code. I don’t know what license Mono uses for their source, but if some feature appeared in both Mono BASIC and VB in the future and I had looked at the Mono source code, it’s possible Microsoft would be open to a lawsuit over it because they could claim I saw the feature and violated their license.
Not being a lawyer in all, I don’t really know, so I could certainly choose to talk to our legal department about it and see if it was possible. However, it just isn’t worth it to satisfy my curiosity… 🙂
Raj: Sure, there is no reason why the unmanaged compiler couldn’t expose services (and it does). It’s just that if you want to expose those services to managed code, it’s going to be easier and more natural if the services are written in managed code…
And as long as whatever you do with my parser is consistent with the pretty liberal license in the code, you’re welcome to have at it!
Pingback: Panopticon Central