Hi Ed, I originally thought the the extra argument to file-reader/writer was going to be a pain but now I'm warming to the idea. I've come across two places in my code where I thought I'd be using a utf-8 encoding but actually I need to load using binary and then do the conversion later.
My vote is for leaving Dan's API for a month or two before making a decision. If making the encoding explicit alerted me to a potential encoding problem now then it might help me again. One of the things I'm loving about factor is its ability to change implementation direction on a sixpence. I don't know how long this can last, but for now it's a massive plus for the language. The Gambit Scheme folks are missing a big trick trying to move to a cpan style library system too early rather than just encouraging everybody to dump their code into the distribution and managing via dvcs. Cheers, Phil Eduardo Cavazos wrote: > Guys, > > No matter what, this is a fact: we are going to have a world-class unicode > implementation. I know this because Dan knows his stuff and I trust him to > solve problems like this. > > However, there's the implementation and then there's the api. > > I just wanted to point out and emphasize in case someone is confused, I'm > arguing, strongly, confidently, vehemently, and relentlessly, about the api, > not the backend design or implementation. > > Nobody, and I mean nobody, has mastered Factor and therefore designing api's > and stack effects is still an art. So in this particular part of the problem, > since nobody is an expert, all the experienced Factor coders should weigh in > if they have an opinion. > > There is no way I would ever argue with Dan about the technical details of > how > to implement unicode. > > But when it comes to stack effects and Factor library design, if I see a > problem, I'm going to speak up. If I see a way to make an improvement, I'm > going to speak up. > > Dan has two responsibilities. He has the first one taken care of: implement > the unicode standard in a competent manner. His other responsibility is to > provide an api which makes us, the programmers, productive and happy. I'm > trying to help him with that part. If he can pick a design which kicks ass > and satisfies us as programmers, then that's a very good thing. This is > attainable. > > If you give up short of that attainable goal, simply because you made > decisions early on and want to stick to them, even in the face of legitimate > criticism, it will truly be a shame. > > In the end, Dan is the one who should get all the credit for this important > step forward in Factor's evolution. > > Ed > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
