1) I noticed that hello.zu is generating a 726-line hello.c (under Windows XP). gcc compiles that file and produces an executable of 118,764 bytes. Is this a permanent attribute of zimbu or do you have expectations that refinements will reduce these sizes?
2) In the early days of C++, there were no native compilers and all we had was cfront. I recall the frustration of interpreting compiler warnings and errors. I'm concerned that zimbu might prove to be similarly challenging. Your language design goal of easy-to-read code is one I endorse 100%. But I have doubts about how a programming environment (IDE) can cope with the mapping between zimbu and C sources.
Please don't consider this as criticism. If you have addressed these earlier, could you point me where to look?
> 1) I noticed that hello.zu is generating a 726-line hello.c (under > Windows XP). gcc compiles that file and produces an executable of > 118,764 bytes. Is this a permanent attribute of zimbu or do you have > expectations that refinements will reduce these sizes?
This can be improved. Over time the dependencies have become too complicated. E.g., I now include Zalloc() always.
Some of the lines are not code, e.g. typedefs. Those don't really count and are not worth omitting when not needed.
We need are more sophisticated dependency mechanism. A manually build graph should work well now. Eventually it would be done automatically, but that's complicated.
One thing that I haven't done yet is including the IO module only partially. Currently if any IO method is used the whole module gets included, and it has grown quite a bit. Not sure how to do this in a nice way. It will help a lot, also the tables with code positions will be a lot smaller.
> 2) In the early days of C++, there were no native compilers and all we > had was cfront. I recall the frustration of interpreting compiler > warnings and errors. I'm concerned that zimbu might prove to be > similarly challenging. Your language design goal of easy-to-read code > is one I endorse 100%. But I have doubts about how a programming > environment (IDE) can cope with the mapping between zimbu and C > sources.
The error messages only give positions in C code when there is a problem in the compiler. The normal error messages are very accurate.
For debugging it will be tricky. It's possible to add positions for the Zimbu code in the C code, like the C preprocessor does.
I'm considering making the possibilty to include C code for low-level operations a feature. It's impossible to get the efficiency of C without the drawbacks of pointers and manual memory control. Using a little C code where it matters can be a solution. Unfortunately this does mean the conversion to C can't be omitted.
-- ARTHUR: If you do not open these doors, we will take this castle by force ... [A bucket of slops land on ARTHUR. He tries to retain his dignity.] "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
> > 1) I noticed that hello.zu is generating a 726-line hello.c (under > > Windows XP). gcc compiles that file and produces an executable of > > 118,764 bytes. Is this a permanent attribute of zimbu or do you have > > expectations that refinements will reduce these sizes?
> This can be improved. Over time the dependencies have become too > complicated. E.g., I now include Zalloc() always.
> Some of the lines are not code, e.g. typedefs. Those don't really > count and are not worth omitting when not needed.
> We need are more sophisticated dependency mechanism. A manually build > graph should work well now. Eventually it would be done automatically, > but that's complicated.
Perhaps Golang directed graph compilation technice could help you. You could implementing an inspiration version of that. In my opinion, perhaps it's included more than it's needed. In helloworld example more bytes added.
I'm not expert, but surely it could be reduced.
Another question: why you use C as intermediate language and not C++. I think pass Zimbu to C++ were more easyly ought to O-O features of C+ +, isn't?
> One thing that I haven't done yet is including the IO module only > partially. Currently if any IO method is used the whole module gets > included, and it has grown quite a bit. Not sure how to do this in a > nice way. It will help a lot, also the tables with code positions will > be a lot smaller.
> > 2) In the early days of C++, there were no native compilers and all we > > had was cfront. I recall the frustration of interpreting compiler > > warnings and errors. I'm concerned that zimbu might prove to be > > similarly challenging. Your language design goal of easy-to-read code > > is one I endorse 100%. But I have doubts about how a programming > > environment (IDE) can cope with the mapping between zimbu and C > > sources.
> The error messages only give positions in C code when there is a problem > in the compiler. The normal error messages are very accurate.
> For debugging it will be tricky. It's possible to add positions for the > Zimbu code in the C code, like the C preprocessor does.
> I'm considering making the possibilty to include C code for low-level > operations a feature. It's impossible to get the efficiency of C > without the drawbacks of pointers and manual memory control. Using a > little C code where it matters can be a solution. Unfortunately this > does mean the conversion to C can't be omitted.
> -- > ARTHUR: If you do not open these doors, we will take this castle by force ... > [A bucket of slops land on ARTHUR. He tries to retain his dignity.] > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Xan wrote: > On Apr 1 2010, 11:26 am, Bram Moolenaar <B...@Moolenaar.net> wrote: > > Dave wrote: > > > A couple of observations:
> > > 1) I noticed that hello.zu is generating a 726-line hello.c (under > > > Windows XP). gcc compiles that file and produces an executable of > > > 118,764 bytes. Is this a permanent attribute of zimbu or do you have > > > expectations that refinements will reduce these sizes?
> > This can be improved. Over time the dependencies have become too > > complicated. E.g., I now include Zalloc() always.
> > Some of the lines are not code, e.g. typedefs. Those don't really > > count and are not worth omitting when not needed.
> > We need are more sophisticated dependency mechanism. A manually build > > graph should work well now. Eventually it would be done automatically, > > but that's complicated.
> Perhaps Golang directed graph compilation technice could help you. You > could implementing an inspiration version of that. In my opinion, > perhaps it's included more than it's needed. In helloworld example > more bytes added.
> I'm not expert, but surely it could be reduced.
Sure, the idea is simple. Implementing it will be a bit of work though. Also, the dependency graph needs to be made for generated C and JS code separately.
> Another question: why you use C as intermediate language and not C++. > I think pass Zimbu to C++ were more easyly ought to O-O features of C+ > +, isn't?
C++ is a very complicated language and not available everywhere. E.g. for embedded systems often only C is available. Therefore I prefer the compiler itself to be converted to C, so that it can be run nearly everywhere.
It would be possible to write a C++ backend. I am currently working on separating the generation code out from Generate.zu. Since Zimbu already supports producing Javascript, which supports classes, C++ would be a mix of the C and Javascript backends.
-- DEAD PERSON: I'm getting better! CUSTOMER: No, you're not -- you'll be stone dead in a moment. MORTICIAN: Oh, I can't take him like that -- it's against regulations. The Quest for the Holy Grail (Monty Python)
