>> >> No. That's not the point. It's hiding a C parser in a macro that I >> find 'curious' to say the least. >> >> After all, just because you can do something doesn't mean that you >> should. > > I don't see any fundamental difference between a "generator" and a > "macro", they both generate code,
At a Turing level, of course not. But at a practical level, it makes a big difference, in my experience. > >> [...] >> And that is not an issue of safety, but of clarity of the code. > > and since both produce code in the same way, they're both as clear. No, I disagree, unless the macro happens to be an absolutely trivial wrapper around the rest of the procedural code. > (And BTW, we did do a couple of steps in the last decade. Macros > might still require a license, but they're much more well behaved. > This is regardless of the risk of making code more difficult to deal > with.) You misunderstand. It's not how well behaved the macros are. It is how they obfuscate code. When it comes to macros, parsimony is a good policy. But again, there were two schools of thought about this 20 years ago, namely the 'MIT school' which viewed sharing code as sharing procedures, and macros as rarely used, and the 'Indiana school' which viewed sharing code as sharing macros (they were programming language researchers, by and large, while the MIT crowd largely was not). >>> Let me repeat it: the original bindings are "foo" and "Bar", since >>> this is all you have, you're likely to go for the simple >>> translation to `foo' and `bar'. Later on the library is extended >>> with a "FOO", and the produced code is no longer valid, since it's >>> missing a proper translation for an all-caps name. *Or* you make >>> the generator detect such cases and adapt -- in that case, the >>> generator saw no clashes before and gave you `foo' and `bar', and >>> now that there is one, it does some automatic tweaking -- thereby >>> breaking existing code. >> >> That assumes that the generator has no history. >> >> It is not hard to feed it its prior decisions, and only introduced >> oddities for new bindings, which, by definition, are not yet in use. > > Ah, well you're right that this does solve the problem, but it does so > at the expense of complicating the framework to support it. OK. So we've gone from "there is no solution" to "it complicates things". OK, I never claimed that the solution was as simple as just passing the identifier through. But that would have been obvious, or not? So it is a value judgement whether it is worth the effort or not. I'm not going to try to convince you of that one (it is not a technical issue), but likewise, please agree that there is no unsurmountable technical issue with having a case-insensitive language, and thus, for those of us who find that important (due to tradition, preference, or whatever), the technical arguments that have been raised are spurious, and, sorry to say, 'naive'. > The least > that you'll need (in practical cases at least) is to make sure that > this file is added to the repository, that the generator (macro or > not) will commit changes to the file when needed (which also implies > that everyone that uses this code better have the same version of the > library) > It will also need to communicate with some human to update > the documentation (for example, send an email -- because the tool > might run as part of a nightly automated build) -- or alternatively it > will need to generate the required bits to be used by the > documentation. If you look at industrial software systems, this kind of thing is bread and butter. > That is a *lot* of effort, and in *my* opinion making the language > case sensitive is far easier and more robust (in all aspects). (And > by a lot of effort I mean a wart -- one that is bigger than the > possible wart-ness of case-sensitivity.) But again, it is an issue of whether case-sensitivity is _necessary_ to solve some problems, which was your original claim. Now we are talking about convenience... A very different argument. > [I expect your opinion to be different here. My guess is that you'll > be fine with all of the above since it deals with a corner case that > you're unlikely to encounter. In contrast, I'm not fine with all of > the above, since if that's the way to deal with foreign code, then I'm > likely to be one of the people who will need to actually implement, > maintain, and use the above mess.] Sorry, but hiding a C parser inside a macro sounds like a worse mess to me. De Gustibus non est Disputandum, as Jonathan Rees used to say repeatedly. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
