skaller wrote:
> 1. There is a new construction:
>
> open module X { ... }
>
> This is exactly the same as
>
> module X { ... }
> open X;Cool. > > 2. The following modules are now opened in the standard library, > I expect a couple of "horray!"s here: > > Bool > Tint, Utiny, Short, Ushort, Int, Uint, Long, Ulong, Vlong, Uvlong > Float, Double, Ldouble > Char, Wchar, Uchar > Unicode > String, Wstring, Ustring, > Array, > Varray more cool. > Cstdlib, > Stdout, Cstdio I got some complaints for this though. I'd prefer to not have the C/C++ specific stuff exposed by default. This would prevent backend portability. Now, to specifics. First off, Cstdlib only exports a random number generator, which would probably be better put in a "module Random". Perhaps we have the Random module call stuff from Cstdlib? Second, Cstdio currently only provides a "FILE" type, which nothing currently uses for an interface, so it's another thing that doesn't need exposure (in my opinion). Third, if we're going to go the route of copying the iostream library as our felix file/stream library, we ought to move ostream into it's own module. Ultimately, I think this section of the stdlib needs some attention. This leads me to some of the stuff I was thinking we could do with the language. Here's a couple of my ideas: 1. make the bit-ints the builtin, and tiny,short,etc the alias I know that int8, int16, and etc are a recent addition to the language, but I feel they should have been in there in the beginning, and char, short, and etc should have been typedefs to the more exact name (of course, there's n real standard runtime, but that's a separate issue). I'd prefer if felix takes this route. By setting things up this way, we make the size of the common names conceptually more fluid in interpretation (in my opinion). 2. create a felix_cpp.flx file to store all the C/C++ modules This is to prevent polluting pure felix programs with C/C++ modules. Of course, I can understand that some of the standard library would need to call C/C++ stuff (like the RTL), but it shouldn't be directly exposed to the user unless they request it. 3. creating a lib/backends/cpp to future-proof the std.flx Extending from (2), everything in the standard library that needs to call something in C/C++ should go through another layer to get to the functionality. This would mean something along the lines of this: lib/std.flx: ... typedef int16 = backend::int16; typedef int32 = backend::int32; ... lib/backends/cpp: ... pod typedef int16 = "short"; pod typedef int32 = "int"; and then we modify the compiler to somehow select which backend to use, since the compiler already needs intimate knowledge of what language it's targetting. Of course, I'd love to do this without having to build in paths into the compiler. Perhaps it could be something inside "flx", where it would call "flxg --backend=/lib/backends/cpp" or something? I think thats pretty good for now. What do you guys think? > The following MAY be opened, subsequent to cleaning up: > > Control -- needs cleanup Definitely. I can't tell what's moved into the compiler and this library, or the couple control macros we have. > List -- review (use sums?) > Assoc_list -- review I'm not crazy about Cons and Empty getting into the namespace. If we ever could come up with a nice sugar for them I'd be happier. > Arith_casts -- deprecate? yep. I think the _ctor_TYPE replaces the need for Arith_casts > Debug -- review Useful, but I don't think it should be opened by default. > Carray -- review, unsafe this would be another candidate for my "cpp.flx" > > The following probably won't be open: > > C_hack -- cause its ugly > Stl stuff -- not Felixified cpp.flx again > System -- program hacks, OS dependent > MixedInt -- unsafe? > Filename -- incomplete > Env -- program hacks, OS dependent this could be folded into an "os" like library, similar to python. Should there be an "os.flx" file for everything like this? > There are also probably resources missing, and, probably > some refactoring is requires. In addition there is an extreme > lack of useful data structures -- List and Array is about it. > Clearly we need a Set and a Map. And a hashtable/dict. > > > WE NEED COMPLAINING USERS BADLY! > Is that good enough? :) -e ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
