- how to get random value - 1 Update
- neos - 6 Updates
- M_PI (possible g++/clang++ bug)pu - 1 Update
| Ike Naar <ike@sdf.lonestar.org>: Feb 28 11:04PM > printf("value : %d \n",n); > return n; > } What's the use of having a for loop when it always returns during the first iteration? |
| "Öö Tiib" <ootiib@hot.ee>: Feb 28 07:47AM -0800 > > with a considerably reduced line count compared with a normal Ada > > compiler, then that would be impressive. > The implementation time / line count saving stems from the fact that you only have to implement a (generic) semantic concept once which can then be used across multiple languages. So overall there wouldn't be a saving if only one language was implemented: the saving stems from the fact that multiple languages can be described by a combination of an RJSON file and semantic concepts implemented in C++ in concept plugins. When I ship 1.0 the predefined semantic concepts should be quite rich due to me tackling Ada first. Despite all use cases of all programs are same from uppermost concept (input)->(processing)->(output) the details are always different. Let's say for example that C preprocessor takes about 3.5 months to write. Let's say Ada has about 13 times more details in it. If to assume that tinkering with every detail takes about same time in average then Ada translator takes about 4.5 man-years to write based on amount of details. Actually that is not so linear since the details interfere with each other and complicate it up the more detailed and complex the whole thing is the worse, but let's ignore that. Now let's imagine that we have already written Ada translator. Can we reuse much of it to produce a C preprocessor somehow faster than with 3.5 months? I doubt that since the details are still there and are different than those with Ada. |
| Bart <bc@freeuk.com>: Feb 28 06:39PM On 28/02/2019 15:47, Öö Tiib wrote: > reuse much of it to produce a C preprocessor somehow faster than > with 3.5 months? I doubt that since the details are still there and are > different than those with Ada. As described the project doesn't sound viable, not if the only input for each new language is a data file. It needs to be code. In other words, you have to write a new compiler front-end for each language. Perhaps some elements such as lexers can be reused, or driven from grammar descriptions, but as you say something like C is going to be different from any other language because of the peculiar way its preprocessor works. And every language will have its own quirks. The OP mentioned a semantic module in a way that suggested code plug-ins for each language. That's another way of saying you need a separate compiler for each. Maybe all these disparate compilers can be made to fit into a common framework, but that then doesn't sound much different than using a make-file to build mixed-language projects. The advantage of a universal compiler, if it tries to do anything cleverer than just invoking a dedicated compiler for each language, is then less obvious. But then we get to the fact that all these languages will have the same target, some VM, but it would need to be a VM that can cope with both highly dynamic languages and very static ones. Or perhaps (I don't know how it works), it's a more static VM for which certain dynamic languages will require an extra layer of code, that does the job of interpreter. So it might be that there will still be a need for compilers and interpreters, but in some different form. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 28 09:41PM +0200 On 28.02.2019 20:39, Bart wrote: >> different than those with Ada. > As described the project doesn't sound viable, not if the only input for > each new language is a data file. I think you all have misinterpreted Mr. Flibble's intent. He said his universal compiler will support Ada, Python, C, etc. How everybody interpreted this was that what is supported is the union of all these languages, so that one would get the hard real-time multithreading from Ada, all fancy deep learning stuff like NumPy+tensorflow from Python, etc. I guess what he really had in mind was the *intersection* of languages, so you can write a program for adding 2+2 in Ada, Python, C, etc, and it would work the same. |
| Bart <bc@freeuk.com>: Feb 28 09:54PM On 28/02/2019 19:41, Paavo Helde wrote: > I guess what he really had in mind was the *intersection* of languages, > so you can write a program for adding 2+2 in Ada, Python, C, etc, and it > would work the same. No, I assumed that the universal compiler would work with either language X or Y or Z, always one at a time, with the output always being the same VM language. I think I did ask about whether mixed source was allowed (one source file containing a mix of languages, presumably requiring special directives to tell you what was what), and I also asked about interfacing between language X and language Y. However, the whole thing is still a bit of a mystery. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 28 10:09PM On 28/02/2019 21:54, Bart wrote: > No, I assumed that the universal compiler would work with either language > X or Y or Z, always one at a time, with the output always being the same > VM language. Correct although theoretically my universal compiler can handle translation units written in different languages much like a traditional linker can link object files compiled from different languages. > containing a mix of languages, presumably requiring special directives to > tell you what was what), and I also asked about interfacing between > language X and language Y. No you cannot mix languages within the same translation unit but see above. > However, the whole thing is still a bit of a mystery. I like a good mystery. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 28 10:31PM On 28/02/2019 22:09, Mr Flibble wrote: >> directives to tell you what was what), and I also asked about >> interfacing between language X and language Y. > No you cannot mix languages within the same translation unit but see above. Actually I might allow files with a .mix file extension. A .mix file would allow individual translation units to be specified within the same source file using special directives as you say. This would be a nice feature but not essential. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 28 11:55AM -0800 > Under Cygwin, which uses a different library implementation, the > problem doesn't occur with g++ (though it does occur with clang++). > I'll submit a bug report. I think the problem is not in the library headers but in the translators themselves. After doing a bit of detective work, I found that these commands g++ -x c++ -std=c++11 -pedantic -U_GNU_SOURCE m-pi.c -o g++-m-pi clang-5.0 -x c++ -std=c++11 -pedantic -U_GNU_SOURCE m-pi.c -o clang-m-pi will compile the source without complaint, and produce executables that behave as expected, but if the -U_GNU_SOURCE option is left off then there are compilation errors, like what you reported. (Which version of C++ standard is used seems not to matter. The environment is a ubuntu 16.04 distribution.) |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment