>> >> That's why you use a generator, which can examine all the names at >> once, use an algorithm for mapping them, and report any collisions, >> if any. > > In other words, you *can't* *automate* it.
Not true. It depends on your algorithm. For example, your algorithm can canonicalize case as long as there are no aliases. If there are aliases, it doesn't canonicalize case. It's automatic, perfectly predictable, and trivial to implement. Just unexpected if there happen to be aliases, which is why it tells you about it, even though it completes. But as everyone agrees, that is rather rare. Furthermore, you'd have the same problem if you ever want to link with a language that allows, say, spaces in identifiers. The moment that it is a different language, you have no guarantee that the rules are compatible. Yes, we can declare that Scheme must abide by C (or C++, or Java, or python, or whatever) rules. Then, obviously, you wouldn't have incompatibilities with the chosen language. Is that what you are asking for? > Describing your particular obfuscation algorithm is a wart; one that > the language should help you avoid instead of encouraging it. Changing your language to be compatible with, say C, is a wart all on its own. >>> http://lists.r6rs.org/pipermail/r6rs-discuss/2006-November/ >>> 001093.html >>> >>> interesting. (The poll results page is still there.) >> >> Again, look at the analogous argument for C. Why are Scheme users >> worth less? > > Please look at that URL; Scheme users are worth more -- most of them > wanted the change. No. Those who read and answered the poll. I wasn't one of them, for example. And I'm sure that there are others. And even a majority is a weak argument here. As people have said, breaking compatibility should have a different hurdle. >>> in the rare case that there is an identifier syntax that is not >>> allowed in Scheme, having a macro generate an identifier through >>> `string->symbol' will work as usual -- but I'll need to use |...| >>> to access that binding. But in practice, can you name a popular >>> language that is used to create dynamic libraries with identifiers >>> that are not allowed in Scheme? (And no, C++ obfuscation is not a >>> valid example.) >> >> C++ is valid. That's what a lot of industry uses. > > No, C++ obfuscation is invalid, because the obfuscation does not > happen at the language level. A Scheme interface to a C++ library > will need to reflect unobfuscated C++ identifiers. Good luck. >> And your problems seem to be one sided. >> [...] >> Most other languages ('-' denotes infix subtraction) do not. >> >> You have to mangle one way anyway, as these other languages >> don't have a quotation mechanism to add a non-standard identifier. > > Of course, but there's nothing to do about that (it's the elf/dll/etc > format that dictates what can go in). Sure you could. We could restrict Scheme identifiers to exactly the same rules as C. Why aren't you proposing that? >> So I guess you are only interested in importing things into Scheme, >> and not exporting them out. > > No, the only obstacle in exporting things out is being able to > generate dlls. But you have the identifier issue anyway. >> Yes, but you've quoted me out of context. I was teaching it to >> people who did not know English at all (a few did). But case >> folding was not a problem for them, as they were used to it. > > Right, so your answer was irrelevant to this thread. (Unless Sam was > just interested in general whether you taught people who are not > English speakers out of curiosity.) That's what the question asked. I answered the question as asked. If he wanted to hear the answer to something else, he should have asked something else. >>> It's not an issue of 'real' language vs. not. > > Yes, it's an issue of attitude. "American" was a demonstrational > tool. It demonstrated nothing to me. >>> Let me translate to the random pedestrian who suffered all the way >>> to this point: "Four people spent a number of years thinking how >>> to make a language that is easy to teach; I spent absolutely no >>> time doing the same; and yet I can conclude based on my 0-year >>> effort that the 4*N year design that they came up with is >>> misguided". >> [...] >> At any rate, you are using an argument based on 'authority', and I >> generally find those pretty weak. > > [Countering an authority argument with your own personal assumptions > is weaker.] No. It is no weaker. It ends up being the same thing. To a third party it is, in both cases, 'so and so says X'. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
