You misinterpret the silence. If a suggestion is met with silence it's usually an indication that other people either think it's a nice idea or they aren't very interested (which is the case for me when it comes issue of a POSIX module). In either case, it usually means that it's ok to go ahead and implement it.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-03 17:52: Subject: argv[0]?
Johan, not one thing, please - I proposed creating a module called POSIX which would export those calls. This proposition was silently ignored... while I think it would be a really good solution.
/ Marek Habersack (Grendel)
in this case it would mean moving quite a deal of functions around - from their current locations to the module, so it's not that straightforward compatibility-wise.
/ Marek Habersack (Grendel)
Previous text:
2002-09-03 23:22: Subject: argv[0]?
You misinterpret the silence. If a suggestion is met with silence it's usually an indication that other people either think it's a nice idea or they aren't very interested (which is the case for me when it comes issue of a POSIX module). In either case, it usually means that it's ok to go ahead and implement it.
/ Martin Stjernholm, Roxen IS
Ok, so the point with this POSIX module would be not only to add it with a bunch of functions, but also to remove a bunch of functions elsewhere? Which functions would that be?
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-03 23:23: Subject: argv[0]?
in this case it would mean moving quite a deal of functions around - from their current locations to the module, so it's not that straightforward compatibility-wise.
/ Marek Habersack (Grendel)
basically those defined in the awkward POSIX, for example: chmod, chown, exec, crypt, sleep etc, but also things like abs, acos, ceil. The compatibility for those currently top-level ones would be provided by means of variables of function type, I suppose. In my opinion, such a module (and an accompanying WIN32, WIN64 etc. ones) would greately clean the namespace up while, automatically, providing a direct manpage/help/doc -> module mapping for a function sought by a programmer.
/ Marek Habersack (Grendel)
Previous text:
2002-09-03 23:31: Subject: argv[0]?
Ok, so the point with this POSIX module would be not only to add it with a bunch of functions, but also to remove a bunch of functions elsewhere? Which functions would that be?
/ Martin Stjernholm, Roxen IS
It's not all bad, but I don't think you will get many followers on dropping top level support for abs, acos, ceil and similar. While it might make sense to move them to Math (if we *really* want to clean up the top level), few would consider POSIX when doing maths. The modules you propose now would probably work well for very obviously system dependent syscalls that belong rather strictly to one OS/arch family.
Still, +1 on adding the Posix and Win32 modules. It's ideomatic enough for me at least for the cases described above.
/ Johan Sundström (risplockare)
Previous text:
2002-09-03 23:40: Subject: argv[0]?
basically those defined in the awkward POSIX, for example: chmod, chown, exec, crypt, sleep etc, but also things like abs, acos, ceil. The compatibility for those currently top-level ones would be provided by means of variables of function type, I suppose. In my opinion, such a module (and an accompanying WIN32, WIN64 etc. ones) would greately clean the namespace up while, automatically, providing a direct manpage/help/doc -> module mapping for a function sought by a programmer.
/ Marek Habersack (Grendel)
Out of curiosity, why has it always been suggested to move functions to the POSIX module? I think it would be better to have the POSIX module as some kind of META-module which contains all POSIX-things implemented in Pike, but as aliases for the proper pike functions when such are available. Eg. if the toplevel namespace is cleaned up, the most logical place to på math-function would be a Math module, but this does not imply that the functions cannot exist in the POSIX module too. The POSIX module should of course also include the non-portable POSIX stuff which ought only to exist in that module.
/ Mikael Brandström (ogg! ogg! ogg!)
Previous text:
2002-09-04 12:54: Subject: argv[0]?
It's not all bad, but I don't think you will get many followers on dropping top level support for abs, acos, ceil and similar. While it might make sense to move them to Math (if we *really* want to clean up the top level), few would consider POSIX when doing maths. The modules you propose now would probably work well for very obviously system dependent syscalls that belong rather strictly to one OS/arch family.
Still, +1 on adding the Posix and Win32 modules. It's ideomatic enough for me at least for the cases described above.
/ Johan Sundström (risplockare)
My guess: minimizing namespace pollution (the more names per function, class or module, the more polluted the system - in this respect). That is sometimes a sane attitude, but drawn too far it ends up worse (like those languages where you have to use import very much, or do lots of typing, no matter what basic things you try to do).
/ Johan Sundström (risplockare)
Previous text:
2002-09-04 13:01: Subject: argv[0]?
Out of curiosity, why has it always been suggested to move functions to the POSIX module? I think it would be better to have the POSIX module as some kind of META-module which contains all POSIX-things implemented in Pike, but as aliases for the proper pike functions when such are available. Eg. if the toplevel namespace is cleaned up, the most logical place to på math-function would be a Math module, but this does not imply that the functions cannot exist in the POSIX module too. The POSIX module should of course also include the non-portable POSIX stuff which ought only to exist in that module.
/ Mikael Brandström (ogg! ogg! ogg!)
of course, this is also another way - and a very good one. The top-level aliases should exist only in the compatibility mode, the abs/ceil etc. functions should be placed either in Math or in POSIX (as they belong logically to the former and are defined in the latter as the standard) and aliased to either of them. All of these provide a very comfortable environment to the user/programmer. And, of course, as you say the POSIX module should contain also the optional POSIX parts, as defined by the standard, which might not exist on every POSIX-compliant system.
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 13:01: Subject: argv[0]?
Out of curiosity, why has it always been suggested to move functions to the POSIX module? I think it would be better to have the POSIX module as some kind of META-module which contains all POSIX-things implemented in Pike, but as aliases for the proper pike functions when such are available. Eg. if the toplevel namespace is cleaned up, the most logical place to på math-function would be a Math module, but this does not imply that the functions cannot exist in the POSIX module too. The POSIX module should of course also include the non-portable POSIX stuff which ought only to exist in that module.
/ Mikael Brandström (ogg! ogg! ogg!)
sleep and abs in Pike has nothing in common with the corresponding POSIX functions except for the names. Those functions might have aliases in a POSIX module, but since they doesn't actually use the libc implementations it should be clearly stated that they're only aliases. (And I don't see any point in having other variants in a POSIX module that really use the libc implementations, since they only would work less well in Pike.)
acos and ceil belongs in a math module if anything. As above, they might be in a POSIX module too for completeness sake, but not only there. Besides, I actually don't see any real point in removing such functions from the top level since they are well known and have the same names and behavior in many languages.(*)
As for chmod and chown, I think they firstly belong in the Stdio module along with mv, cp (already there), symlink etc. Sure, they are riddled with platform specific idiosyncrasies but so is actually almost all the rest of the fairly low level filesystem routines in that module. They do exist even on FAT filesystems and do what they're supposed to as far as applicable. I'd like to have a higher level filesystem interface in the Filesystem module, and a cleaner file stream interface in, say, a Stream module.
exec would firsthand belong in the Process module, but it could also stay on the top level for similar reasons like acos and ceil above.
So among the examples you mentioned I only see that crypt should be moved and not copied to a POSIX module. I lump crypt together with getpwent, chroot, syslog and other miscellaneous OS routines which have some sort of standard through POSIX. So it'd be good to move them there and let the System module contain higher level functions like get_all_users instead.
*) I don't think that it's a goal in itself to have as few identifiers as possible at the top level. It's a very attractive namespace; it should be used with caution of course, but nevertheless it should still be _used_.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-03 23:40: Subject: argv[0]?
basically those defined in the awkward POSIX, for example: chmod, chown, exec, crypt, sleep etc, but also things like abs, acos, ceil. The compatibility for those currently top-level ones would be provided by means of variables of function type, I suppose. In my opinion, such a module (and an accompanying WIN32, WIN64 etc. ones) would greately clean the namespace up while, automatically, providing a direct manpage/help/doc -> module mapping for a function sought by a programmer.
/ Marek Habersack (Grendel)
note one thing - I never said they would ONLY be in the POSIX module. I think I've said it several times that they would be aliased from other places (I mentioned the top-level and other places too). If you'd feel better, copy abs/ceil anywhere you want and alias it in the POSIX module - I really don't care and the exact placement wasn't at all the subject of the idea. The idea was to create a clean namespace partitioning that makes it easy for people to find the functions they might need and which might be defined in this or that standard.
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 13:47: Subject: argv[0]?
sleep and abs in Pike has nothing in common with the corresponding POSIX functions except for the names. Those functions might have aliases in a POSIX module, but since they doesn't actually use the libc implementations it should be clearly stated that they're only aliases. (And I don't see any point in having other variants in a POSIX module that really use the libc implementations, since they only would work less well in Pike.)
acos and ceil belongs in a math module if anything. As above, they might be in a POSIX module too for completeness sake, but not only there. Besides, I actually don't see any real point in removing such functions from the top level since they are well known and have the same names and behavior in many languages.(*)
As for chmod and chown, I think they firstly belong in the Stdio module along with mv, cp (already there), symlink etc. Sure, they are riddled with platform specific idiosyncrasies but so is actually almost all the rest of the fairly low level filesystem routines in that module. They do exist even on FAT filesystems and do what they're supposed to as far as applicable. I'd like to have a higher level filesystem interface in the Filesystem module, and a cleaner file stream interface in, say, a Stream module.
exec would firsthand belong in the Process module, but it could also stay on the top level for similar reasons like acos and ceil above.
So among the examples you mentioned I only see that crypt should be moved and not copied to a POSIX module. I lump crypt together with getpwent, chroot, syslog and other miscellaneous OS routines which have some sort of standard through POSIX. So it'd be good to move them there and let the System module contain higher level functions like get_all_users instead.
*) I don't think that it's a goal in itself to have as few identifiers as possible at the top level. It's a very attractive namespace; it should be used with caution of course, but nevertheless it should still be _used_.
/ Martin Stjernholm, Roxen IS
Note that I in 8970567 explicitly asked for which functions that would be removed elsewhere. You responded with chmod, chown, exec, crypt, sleep, abs, acos, ceil.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-04 16:59: Subject: argv[0]?
note one thing - I never said they would ONLY be in the POSIX module. I think I've said it several times that they would be aliased from other places (I mentioned the top-level and other places too). If you'd feel better, copy abs/ceil anywhere you want and alias it in the POSIX module - I really don't care and the exact placement wasn't at all the subject of the idea. The idea was to create a clean namespace partitioning that makes it easy for people to find the functions they might need and which might be defined in this or that standard.
/ Marek Habersack (Grendel)
man, do you expect me to list ALL the functions I would like to see there? Also note that in my comment to your text I wrote "for example:" in the intention to give a sample selection of functions which _might_ be moved there. Want me to list all the ones I'd like to see there? Fine, I can do that, but it's gonna be a long post.
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 17:02: Subject: argv[0]?
Note that I in 8970567 explicitly asked for which functions that would be removed elsewhere. You responded with chmod, chown, exec, crypt, sleep, abs, acos, ceil.
/ Martin Stjernholm, Roxen IS
Sorry, but I can't make sense of what you write now.
My interest is not so much which functions that are added to a POSIX module, but which that are ___moved___ there, as in _copied_ and then _removed_(*) elsewhere. The only example you named that I agreed on in that regard is crypt. Then you said that you didn't want them removed elsewhere afterall, but now you again say that you want to _move_ them.
Believe me, I really do not intentionally try to misunderstand you or nitpick words here. You earlier said (8970535) that there would be compatibility issues with the POSIX module exactly because the functions added to it would be _moved_ there, which can only happen if they are removed(*) elsewhere. Then you said (8974606) that you never suggested that they should be removed(*). It's apparently a contradiction and not just a simple misunderstanding of what "move" means.
So what do you really mean? Should these example functions be removed outside the POSIX module or not? Note that whether they are left in compatibility mode or not is not the issue at all here (they obviously must be).
(And no, I don't expect a complete list. I never said so, but otoh I never said explicitly that I don't.)
*) Notwithstanding compatibility fixes that are activated with #pike or -V, of course.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-04 17:04: Subject: argv[0]?
man, do you expect me to list ALL the functions I would like to see there? Also note that in my comment to your text I wrote "for example:" in the intention to give a sample selection of functions which _might_ be moved there. Want me to list all the ones I'd like to see there? Fine, I can do that, but it's gonna be a long post.
/ Marek Habersack (Grendel)
ok, here's a recap:
1. All posix functions should be _moved_ to the POSIX module. That means: - they will not be available at their old, compatible location - old code which expects them at the old location will stop working
2. The functions moved in #1 can be aliased, in the compatibility mode, at their old locations thus removing the compatibility problem above.
3. The functions moved (as in the code sense and the namespace sense) to the POSIX module might be aliased from other spots in the namespace (like Math, for example) to make their location more logical from the usage standpoint. It can be done in the other directions - the functions code gets moved to, say, Math and it is aliased in the POSIX module.
The effect is that the functions are "physically" available in one module, the one named after the standard the functions are defined in (POSIX, WIN32, WIN64, BSD, whatever other standards we might find useful) and they are "virtually" available from other locations, which make more sense from the logical point of view. Now let's imagine a user migrating from C/C++ to Pike. They are used to use the manpages, they look at the chmod(2) manpage, and they read at the bottom:
CONFORMING TO The chmod call conforms to SVr4, SVID, POSIX, X/OPEN, 4.4BSD. SVr4 documents EINTR, ENOLINK and EMULTIHOP returns, but no ENOMEM. POSIX.1 does not document EFAULT, ENOMEM, ELOOP or EIO error conditions, or the macros S_IREAD, S_IWRITE and S_IEXEC.
They also read in the Pike docs that functions defined by the POSIX standard can be found in the POSIX module, so they know right away that they should use:
POSIX.chmod(...)
in their code.
Another scenario is where a programmer wants to use a math function. If the function is POSIX, they can use the above approach, but they can also read in the docs that the mathematical routines are found in the Math module, so they can use
Math.ceil(...)
Now, _where_ the functions are defined (in the source code sense) doesn't really matter from the programmer's POV, what matters is where they appear to them. Thus the proposition of the function aliases.
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 17:36: Subject: argv[0]?
Sorry, but I can't make sense of what you write now.
My interest is not so much which functions that are added to a POSIX module, but which that are ___moved___ there, as in _copied_ and then _removed_(*) elsewhere. The only example you named that I agreed on in that regard is crypt. Then you said that you didn't want them removed elsewhere afterall, but now you again say that you want to _move_ them.
Believe me, I really do not intentionally try to misunderstand you or nitpick words here. You earlier said (8970535) that there would be compatibility issues with the POSIX module exactly because the functions added to it would be _moved_ there, which can only happen if they are removed(*) elsewhere. Then you said (8974606) that you never suggested that they should be removed(*). It's apparently a contradiction and not just a simple misunderstanding of what "move" means.
So what do you really mean? Should these example functions be removed outside the POSIX module or not? Note that whether they are left in compatibility mode or not is not the issue at all here (they obviously must be).
(And no, I don't expect a complete list. I never said so, but otoh I never said explicitly that I don't.)
*) Notwithstanding compatibility fixes that are activated with #pike or -V, of course.
/ Martin Stjernholm, Roxen IS
Thanks for the clarification. Then my earlier comment (8973117) still applies regarding that some functions should not be removed from the top level (sleep, abs, acos, ceil, exec), and that it should be clear that functions like POSIX.sleep and POSIX.abs are only aliases that doesn't actually use the libc implementations.
I can point out that I also never touched the issue of where the function implementations should be. As you say, it really doesn't matter.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-09-04 18:03: Subject: argv[0]?
ok, here's a recap:
- All posix functions should be _moved_ to the POSIX module. That means:
- they will not be available at their old, compatible location
- old code which expects them at the old location will stop working
- The functions moved in #1 can be aliased, in the compatibility mode, at
their old locations thus removing the compatibility problem above.
- The functions moved (as in the code sense and the namespace sense) to
the POSIX module might be aliased from other spots in the namespace (like Math, for example) to make their location more logical from the usage standpoint. It can be done in the other directions - the functions code gets moved to, say, Math and it is aliased in the POSIX module.
The effect is that the functions are "physically" available in one module, the one named after the standard the functions are defined in (POSIX, WIN32, WIN64, BSD, whatever other standards we might find useful) and they are "virtually" available from other locations, which make more sense from the logical point of view. Now let's imagine a user migrating from C/C++ to Pike. They are used to use the manpages, they look at the chmod(2) manpage, and they read at the bottom:
CONFORMING TO The chmod call conforms to SVr4, SVID, POSIX, X/OPEN, 4.4BSD. SVr4 documents EINTR, ENOLINK and EMULTIHOP returns, but no ENOMEM. POSIX.1 does not document EFAULT, ENOMEM, ELOOP or EIO error conditions, or the macros S_IREAD, S_IWRITE and S_IEXEC.
They also read in the Pike docs that functions defined by the POSIX standard can be found in the POSIX module, so they know right away that they should use:
POSIX.chmod(...)
in their code.
Another scenario is where a programmer wants to use a math function. If the function is POSIX, they can use the above approach, but they can also read in the docs that the mathematical routines are found in the Math module, so they can use
Math.ceil(...)
Now, _where_ the functions are defined (in the source code sense) doesn't really matter from the programmer's POV, what matters is where they appear to them. Thus the proposition of the function aliases.
/ Marek Habersack (Grendel)
yep, it's purely a matter of namespace pollution. Such a set of "standard" modules makes things more clear, nothing else. The thing of physically moving the source is purely a matter of maintainability, of certain common things the functions might share, etc. etc. - nothing else :) I think that such a module is a purely organizational one, albeit very useful.
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 18:15: Subject: POSIX module
Thanks for the clarification. Then my earlier comment (8973117) still applies regarding that some functions should not be removed from the top level (sleep, abs, acos, ceil, exec), and that it should be clear that functions like POSIX.sleep and POSIX.abs are only aliases that doesn't actually use the libc implementations.
I can point out that I also never touched the issue of where the function implementations should be. As you say, it really doesn't matter.
/ Martin Stjernholm, Roxen IS
However, unless the pike-optimizer code has been changed since the last time I looked at it, it's not a good idea to move the simple math-functions to a module from the global scope.
/ Per Hedbor ()
Previous text:
2002-09-04 18:17: Subject: POSIX module
yep, it's purely a matter of namespace pollution. Such a set of "standard" modules makes things more clear, nothing else. The thing of physically moving the source is purely a matter of maintainability, of certain common things the functions might share, etc. etc. - nothing else :) I think that such a module is a purely organizational one, albeit very useful.
/ Marek Habersack (Grendel)
But that is a problem we ought to fix. If nothing else so that we can move int2hex and int2char from the global scope.
/ Martin Nilsson (Fake Build Master)
Previous text:
2002-09-04 18:20: Subject: POSIX module
However, unless the pike-optimizer code has been changed since the last time I looked at it, it's not a good idea to move the simple math-functions to a module from the global scope.
/ Per Hedbor ()
Yes, but I only wanted to point it out so that nobody goes moving things around right now. :-)
/ Per Hedbor ()
Previous text:
2002-09-04 18:25: Subject: POSIX module
But that is a problem we ought to fix. If nothing else so that we can move int2hex and int2char from the global scope.
/ Martin Nilsson (Fake Build Master)
that's fine - as long as they're aliased in the other places.
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 18:20: Subject: POSIX module
However, unless the pike-optimizer code has been changed since the last time I looked at it, it's not a good idea to move the simple math-functions to a module from the global scope.
/ Per Hedbor ()
pike-devel@lists.lysator.liu.se
-
Johan Sundstr�m (risplockare) ＠ Pike (-) developers forum -
Marek Habersack (Grendel) ＠ Pike (-) developers forum
-
Martin Nilsson (Fake Build Master) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mikael Brandstr�m (ogg! ogg! ogg!) ＠ Pike (-) developers forum
-
Per Hedbor () ＠ Pike (-) developers forum