The S16: chown, chmod thread seems to be too unix-focussed.
Perl6 is being born in a world dominated by the internet. Whilst perl
was the glue for the internet when the internet was born, it was a unix
child. I learned perl from a Windows perspective and I found the
discussion of ownership and file tests odd. Moreover, there were things
I wanted to do with perl that seemed unduly cumbersome in Windows
because the paradigm perl used was a unix one, but adapted to Windows.
To be portable, the minimum assumptions need to be made about the
environment in which a program operates. Alternatively, the software
needs to be able to determine whether the environment it is operating in
meets a minimum set of conditions.
Where software is written for a specific environment, the developer
already knows more about the environment.
Thus I would suggest that the perl6 specifications should be written in
an abstract way, one not related to a specific operating system and in a
way that can be adapted by an implementor to specific systems.
Following the general perl6 philosophy, perhaps too there should be an
abstract definition for the language that is "core" and additional
modules that are specific to operating systems. Thus when generic
software is distributed, it comes with an installer that determines the
operating system chooses whether to use IO::Unix, IO::Unix::Gnome,
IO::MS::WindowsXP, IO::MS::Vista, IO::Apple, etc.
Maybe also IO::Internet::Http, IO::Internet::Ftp?
Thus, questions concerning ownership, chown, etc would be left to
modules. Modules for specific systems would make it easy to deal
naturally with those systems. Software written specifically for one OS
would explicitly "use" the appropriate module, and hence would be able
to rely on constructs natural for that system.
The interesting questions then would be what abstract concepts should be
core to perl6 and which ones should be left to
Do we continue to talk about a file, or do we talk about a resource or
datastream?
When considering internet resources, the concept of trust is more
important than the concept of ownership.
It would seem to me that a program should be aware of the continuing
ability of the datastream to operate, viz., supply / accept data, so
that a program doesnt hang waiting for data from a source that has been
disconnected.