Hi Eli, > I think it's important to share my experience here, ... > The problems I describe are not theoretical, I actually bumped into > them when porting Guile 2.0.x.
Ah, I wasn't aware that you were describing a problem. What was the problem that you encountered with Guile? You say: > It defines symbols based on LC_MESSAGES and exposes them > to Scheme. What was the problem with that? Since guile is based on the platform's runtime + gnulib, not the platform's runtime alone, what issue actually arose? > There were also other issues. One of them, AFAIR, was that > LC_MESSAGES was defined to a large arbitrary value, but LC_MAX was not > updated to cover that LC_MAX is not a macro that should be visible to Guile users, since it is platform-dependent. > Instead, applications that > need these facilities should adapt according to their needs by using > the Windows native facilities. There is and will always be a debate whether a language implementation (like Guile, but the same applies to C and CLISP) should tend to offer APIs closer to the platform's particularities or closer to platform- independent standards like POSIX. As you can see, my opinion is on the "closer to platform-independent standards" side. Bruno
