S4: Can PRE and POST be removed from program flow?
John Siracusa
"PRE and POST must return boolean values that are evaluated according to the
usual Design by Contract rules."
Do "the usual Design by Contract rules" include the ability to "turn off"
(i.e. remove from program flow) PRE and POST blocks for performance reasons
in production, or is than an anathema to the DBC crowd? :)
I know you can do debug-assertions-like things with macros, but then you
have to decide how expensive your pre/post checks are. The very expensive
checks have to go into macros that you can "turn off" in production. But
the cheaper stuff can stay in PRE/POST blocks (assuming they can't be turned
off). Seems like an odd split...or am I over/under-thinking this?
-John
Larry Wall
I don't see how we could prevent someone from clobbering the global
definitions of PRE and POST to be no-ops if they wanted to. Seems to
me that the whole point of putting the program in charge of its own
compilation is to let it be in charge of its own compilation, n'est pa?
Larry
John Siracusa
Hm, okay, but there'd still be the "call" (or whatever) to the overridden
versions. I guess that is "no-op"ing them, but they're still technically in
the program flow, unlike "disappearing macros" or #defines in C or whatever.
Any facility for totally nuking them?
-John
Damian Conway
>>I don't see how we could prevent someone from clobbering the global
>>definitions of PRE and POST to be no-ops if they wanted to. Seems to
>>me that the whole point of putting the program in charge of its own
>>compilation is to let it be in charge of its own compilation, n'est pa?
>
>
> Hm, okay, but there'd still be the "call" (or whatever) to the overridden
> versions. I guess that is "no-op"ing them, but they're still technically in
> the program flow, unlike "disappearing macros" or #defines in C or whatever.
> Any facility for totally nuking them?
macro PRE (&block) {""}
macro POST(&block) {""}
Damian
John Siracusa
Ah ha, I didn't realize macros could override/replace existing control
structures. Okay, ship it! :)
-John
Piers Cawley
Larry Wall
: John Siracusa <sira...@mindspring.com> writes:
: > Ah ha, I didn't realize macros could override/replace existing control
: > structures. Okay, ship it! :)
:
: They'd be no fun if they couldn't.
There is one caveat, of course. Precompiled modules won't see the
change, so you'd have to precompile your own set of modules if you
want the startup speed of precompilation.
Larry
John Siracusa
The precompiled what now?
Actually, the other day I was thinking about how I tend to create any useful
perl program that I plan to distribute in the form of a big, monolithic
script. Take the distribution out of the equation and I'd write a series of
generic modules, blah blah, the usual nicely factored design. But the
headaches of trying to get users to install modules before they can run my
wonderful program always leads me to "flatten" it all into a tradition Big
Honkin' Script (ah, the days of Perl 4...)
Anyway, it'd be nice if Perl 6 supported some sort of equivalent to Mac OS
X's application wrappers: a dir tree containing all the files needed to run
Your Wonderful Perl Program. To execute it, either run "YourApp.pmx/run" or
some standard path, or run "perl YourApp.pmx" and perl would know what to
do. In both cases, there'd have to be some automatic @INC changes, etc.
The next step is "precompiling" that dir tree into a single executable file
(bytecode?), but it'd be nice to have the Plain Old Dir of Source Files
option too.
-John
Nicholas Clark
> Anyway, it'd be nice if Perl 6 supported some sort of equivalent to Mac OS
> X's application wrappers: a dir tree containing all the files needed to run
> Your Wonderful Perl Program. To execute it, either run "YourApp.pmx/run" or
> some standard path, or run "perl YourApp.pmx" and perl would know what to
> do. In both cases, there'd have to be some automatic @INC changes, etc.
What of this doesn't PAR on Perl 5 give you today?
Nicholas Clark
John Siracusa
Well isn't that a well kept secret :)
Anyway, what it'll give me is "official" support for this type of thing. In
particular, the Perl 6 executable itself should know what to make of such a
specially formed dir tree" how to adjust @INC automatically for me, what to
run, etc.--in the same way that Perl 5 knows to look for Foo/Bar.pm in @INC
when I use Foo::Bar. It's just nice to have some things built-in to avoid
too much tedious bootstrapping.
-John
Simon Cozens
> Anyway, what it'll give me is "official" support for this type of thing.
Call me a crazy man, but I *like* the lack of official support.
I actually count it as a Good Thing that perl can be made to do cool stuff
without Larry having to explicitly declare that it's OK.
--
Do you associate ST JOHN'S with addiction to ASIA FILE?
- Henry Braun is Oxford Zippy
Luke Palmer
> Anyway, what it'll give me is "official" support for this type of thing. In
> particular, the Perl 6 executable itself should know what to make of such a
> specially formed dir tree" how to adjust @INC automatically for me, what to
> run, etc.--in the same way that Perl 5 knows to look for Foo/Bar.pm in @INC
> when I use Foo::Bar. It's just nice to have some things built-in to avoid
> too much tedious bootstrapping.
Basically what you're saying is that "official" support for this will be
better than PAR in some way, since it's official. I'm hearing a lot of
this "offical" and "core" tossed around, so I thought I'd just remind
everyone of something:
Perl 6 is a community project. If you yell out "I want feature X", you
have to expect someone in our community to implement it. In the case of
PAR, someone in our community did implement it (quite well might I add).
Making it "core" just takes the power out of Autrijus's hands and puts
it in the core designers' and implementors' hands, which may not be
where it ought to be.
In this case, I don't see any reason for this to be "core". It has no
effect on the way the rest of the language will go, it introduces no
idioms, it has nothing to do with the language at all. If you can
adjust @INC like you can in Perl 5, you can do everything you need to do
to support this in a module.
And it's best that we let the community write that module, because the
more extraneous features that we put on the 6.0.0 design list, the
longer it will take for 6.0.0 to finish, and the longer it will be
before people feel like they can seriously write modules for it.
Basically, if we put something on the 6.0.0 design list that doesn't
need to be there, it will take longer for that thing to arrive.
Luke
John Siracusa
> sira...@mindspring.com (John Siracusa) writes:
>> Anyway, what it'll give me is "official" support for this type of thing.
>
> Call me a crazy man, but I *like* the lack of official support.
>
> I actually count it as a Good Thing that perl can be made to do cool stuff
> without Larry having to explicitly declare that it's OK.
On 9/4/04 7:32 PM, Luke Palmer wrote:
> Basically what you're saying is that "official" support for this will be
> better than PAR in some way, since it's official. [...]
>
> In this case, I don't see any reason for this to be "core". It has no
> effect on the way the rest of the language will go, it introduces no
> idioms, it has nothing to do with the language at all. If you can
> adjust @INC like you can in Perl 5, you can do everything you need to do
> to support this in a module.
This gets back to my lone Perl 6 RFC. (Remember those? Ah, we were so
young and foolish then...) To paraphrase: Yeah, it was cool that Perl 5
could be used to do OO programming in a nearly limitless variety of ways
(see Damian's book), but it was most definitely not an ideal situation.
In Perl 6, Larry made some decisions about how OO was going to work. You
can still go your own way (even more so, in fact) but Perl 6 will definitely
benefit from having an "official" way to do objects and classes. And when
there's an official way, you'll certainly see less wheel reinvention than in
Perl 5. This is a good thing.
The "use" and "require" directives are another example. They're standard,
and useful enough that there is very little call for for weird alternatives.
A lesser language would simply provide "require" (or even just #include :)
and leave more complex semantics to "the community." Then you'd end up with
50 different "use"-like thingies, and reading anyone's code would have to
start with deciphering how their "used" or "with" or "import" directives
work. And those would all have to be bootstrapped with the anemic built-in
features anyway, making everything uglier.
Getting back to Perl 5 OO, it's in the same boat. Before reading anyone's
OO Perl 5 code, you're almost certainly in for a trek into whatever pet OO
"helper" system he's using: "use base"? "use fields"? Class::MethodMaker?
Params::Validate? Class::Contract? All of the above? None of the above?
The standardized "class", "method", "submethod", and so on in Perl 6 will be
an absolute breath of fresh air.
To bring it home, I think packaging and distribution is important enough to
warrant a standard, core-supported implementation. Yes, it's great to be
able to roll your own solution, but forcing the issue by providing nothing
but the most basic features required to bootstrap a custom solution leads to
too much variety and confusion. For some features, familiarity and
standardization are more important.
Furthermore, every "non-core" implementation will necessarily be uglier than
the built-in system. Only through a built-in can you simply run "perl
MyApp.pmx" (where "MyApp.pmx" is a directory) and have things Just Work(tm).
No non-core, community solution is going to be able to pull that off.
Again, it's like use() and require(), or OO in Perl 6 -- provide a good,
common, standardized set of features and the community won't waste its time
re-implementing it over and over and over. But fail to provide it and you
end up with a bazillion different Ways to Do It. Sometimes that's
good--survival of the fittest and all that--but sometimes it's not an
overall win. Pulling the Larry quote from the RFC:
"Although the Perl Slogan is There's More Than One Way to Do It, I hesitate
to make 10 ways to do something."
I think the "specially structured dir of files" and its single-file packaged
(and precompiled) variants are important enough to be standardized, or
"core", or whatever you want to call it. I also think that the official
implementation will have significant advantages in terms of simplicity,
since no one else can change what's in the perl executable itself. (Well,
they can, but forking perl itself is a bad thing, right? Yet another
example of when having a standard is more important that community diversity
and TMTOWTDI :)
Finally, platform independent execution of any packaged or precompiled
single file will *require* cooperation (core support) from the perl
executable itself. PAR is neat, but it doesn't even match up that well with
JAR, which allows the same file to work everywhere Java works. I just don't
see a way to achieve this level of transparency and elegance without core
support.
-John
Chromatic
Without commenting on the issue of single-file bundling...
> To bring it home, I think packaging and distribution is important enough to
> warrant a standard, core-supported implementation.
> I think the "specially structured dir of files" and its single-file packaged
> (and precompiled) variants are important enough to be standardized, or
> "core", or whatever you want to call it.
... you can find almost anyone arguing this point for almost any
feature. I'm inclined to distrust it.
> I just don't see a way to achieve this level of transparency and
> elegance without core support.
That's a much better gauge for whether a feature should go into the
core. I don't know how this particular case fares with that metric, but
it's one of the right questions to ask.
-- c
Luke Palmer
> I think the most important question was at the end of my last message:
> is something even *possible* without core support? Taking a set of
> scripts and libs and making single-file, compiled (or "precompiled"
> bytecode or whatever) executable that will run on all platforms that
> merely have a perl6 executable installed is something that *requires*
> core support, as far as I can see.
So have you, um, seen PAR?
Luke
John Siracusa
PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
and runs. It's closest to item #2 in my feature list, but it's something
very different than compiling down to bytecode.
Within the realm of what it does, PAR is pretty amazing. But the internals
are (necessarily) very ugly and fragile. I suspect the PAR author would
love to list the things he needs in the perl 6 core to implement "PAR6" in a
reliable, straight-forward manner.
As for making bytecode packages and cross-platform single-file executables,
maybe that's within the realm of the Parrot people. But the perl 6
executable would still to understand such things.
-John
Matt Diephouse
would be better suited for perl6-internals. A packaging system would
not be a feature of the language itself, but of its implementation.
Don't confuse Perl and perl.
--
matt
Simon Cozens
> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
> and runs.
It *could* do this, but loading bytecode in Perl 5 is slower than loading
and compiling source, so there's not really much point. What's so magic
about bytecode, anyway?
> Within the realm of what it does, PAR is pretty amazing. But the internals
> are (necessarily) very ugly and fragile.
In what way? How have you managed to break it?
--
I would have more respect for Ruby if its docs were not in ALL YOUR BASE
format.
- Dennis Taylor
Herbert Snorrason
so of the two lists, language is arguably more appropriate...
--
Schwäche zeigen heißt verlieren;
härte heißt regieren.
- "Glas und Tränen", Megaherz
Aaron Sherman
> Actually, the other day I was thinking about how I tend to create any useful
> perl program that I plan to distribute in the form of a big, monolithic
> script. Take the distribution out of the equation and I'd write a series of
> generic modules, blah blah, the usual nicely factored design. But the
> headaches of trying to get users to install modules before they can run my
> wonderful program always leads me to "flatten" it all into a tradition Big
> Honkin' Script (ah, the days of Perl 4...)
Actually, I think at least 80% of your concern melts away with Perl 6,
not for any technical reason, but because the culture is GOING to
change.
Right now, compilation isn't really seen as a step for Perl programs,
and that's why people expect to be able to just "go".
Come Perl 6, if your Makefile.pl can (perhaps as a configurable option
like "MONOLITHIC=1") build a single byte-coded program that includes
everything as well as seperately installing your modules, then the user
can make the call as to how they want to use it. Heck, you could include
a pre-built monolithic compiled version that would get replaced if the
user compiled it themselves.
So, while the rest of this thread is useful, I'm not sure it's as
pertinent as you thought.
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Matt Diephouse
> As it stands, though, perl6-internals isn't about perl, but Parrot ...
> so of the two lists, language is arguably more appropriate...
perl6-internals is about perl the implementation (which is parrot).
perl6-language is about Perl the language.
perl != Perl
Code packaging is a matter of perl, not Perl, I believe.
--
matt
John Siracusa
> sira...@mindspring.com (John Siracusa) writes:
>> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
>> and runs.
>
> It *could* do this, but loading bytecode in Perl 5 is slower than loading
> and compiling source, so there's not really much point. What's so magic
> about bytecode, anyway?
Don't you think it's preferable to temp-expanding and compiling at runtime?
I'd rather not have to write files to disk just to launch...
>> Within the realm of what it does, PAR is pretty amazing. But the internals
>> are (necessarily) very ugly and fragile.
>
> In what way? How have you managed to break it?
The slides about the internals do start with "Here begins the scary part"
and claim that "PAR invokes four areas of Perl arcana", some of which were,
or still are, undocumented. As for breaking it, I suppose all I'd have to
do is try to use it on a platform that has perl but is not supported by PAR.
Don't get me wrong, PAR is a great, impressive collection of code. But part
of the reason that it's so impressive is that it's not easy to get Perl 5 to
do this type of thing without a lot of clever tricks. I'd like it if this
kind of thing doesn't have to be quite so clever in the Perl 6 age :)
-John
Nicholas Clark
> Finally, platform independent execution of any packaged or precompiled
> single file will *require* cooperation (core support) from the perl
> executable itself. PAR is neat, but it doesn't even match up that well with
> JAR, which allows the same file to work everywhere Java works. I just don't
I'm confused here - specifically what can cause a PAR file not to run
anywhere? The only reason I can think of is that it contains bundled up
platform-specific shared libraries. Which means non-core C code. As long
as perl lets you link in C code it's going to have to be pre-compiled for
your platform. I can't see how JAR could avoid this problem if JAR were
used for anything other than pure Java bytecode.
Nicholas Clark
Nicholas Clark
> 3. The single-file, platform independent, non-source executable (P6exe).
> This is bytecode or some other platform neutral representation of the SDoF.
> I just don't see how to do this at all without core support. (Well, I
> suppose it could try to #! boostrap as well, but then you'd have to inline a
> bytecode interpreter or find some way to feed the bytecode to the right part
> of perl 6, which seems like it also leads to some sort of core support.)
There is core support for this in perl5.
use ByteLoader puts a source filter module in place that reads the rest of
the file in as perl5 bytecode. But as Simon says in another message, this
bytecode is bigger and slower to load than perl source.
> needed to unzip/untar/whatever the rest of the stuff in the package file
> before execution. Trying to inline pure perl unzip/untar at the header of
> each SDoF Package file doesn't seem elegant to me, but it could be
> technically possible to bootstrap that way using only the perl 6 executable.
Or in perl 5.
> The B:: family of modules in Perl 5 are fun, but Perl 6 is supposed to do
> this better. The perl 6 core needs to be designed with this type of stuff
> in mind.
Parrot is being designed with this stuff in mind. This is far more a parrot
issue. Parrot has directly serialisable bytecode, and can run bytecode from
disk.
> I think packaging has the same characteristics. But unlike CPAN, packaging
> does require some minimum amount of core support to meet what I consider to
> be the minimum standard of elegance.
I think that this is true. I'm not sure what the minimal list is, and I
suspect that really it's more a parrot issue than a perl 6 syntax issue.
Nicholas Clark
John Siracusa
I guess its kind of apples and oranges since Java has all its own libs,
whereas Perl tends to piggyback on existing C libs (or include its own C
parts) for certain things.
-John
John Siracusa
>> I think packaging has the same characteristics. But unlike CPAN, packaging
>> does require some minimum amount of core support to meet what I consider to
>> be the minimum standard of elegance.
>
> I think that this is true. I'm not sure what the minimal list is, and I
> suspect that really it's more a parrot issue than a perl 6 syntax issue.
Hm, well, features of the perl6 executable itself aren't really fodder for
the parrot lists (are they?)...although I forget where they've been
discussed in the past. Anyway, the long-suffering internals guys are still
hashing out whether or not to have a STRING type or use PMCs for that, yada
yada, so I think this is an issue to save for a bit later on... :)
-John
Nicholas Clark
> Hm, well, features of the perl6 executable itself aren't really fodder for
> the parrot lists (are they?)...although I forget where they've been
> discussed in the past. Anyway, the long-suffering internals guys are still
> hashing out whether or not to have a STRING type or use PMCs for that, yada
> yada, so I think this is an issue to save for a bit later on... :)
I think that that problem comes down to a lack of Rule 1 for Dan.
Nicholas Clark
Autrijus Tang
On Sun, Sep 05, 2004 at 08:49:20PM -0400, John Siracusa wrote:
> PAR doesn't compile or precompile to bytecode, it packages, temp-expands,
> and runs. It's closest to item #2 in my feature list, but it's something
> very different than compiling down to bytecode.
Minor nitpick: "pp -f Bytecode" does precompile to bytecode. But as we know,
Perl5 bytecode is platform-dependent, slow, and somewhat fragile.
> Within the realm of what it does, PAR is pretty amazing. But the internals
> are (necessarily) very ugly and fragile.
Well, PAR largely depends on the @INC-hook mechanism to do what it does,
although in the pure "exe-only" mode it could also do without that, depending
on extracting to temp and adding the temp dir to @INC instead.
> I suspect the PAR author would love to list the things he needs in the perl 6
> core to implement "PAR6" in a reliable, straight-forward manner.
Well, having a core inflate() (or maybe the whole Archive::Zip API) would
be a very good start. Compiling Zlib into core is perhaps a Parrot problem
instead of a Perl6 one.
Co-existence of multiple versions of loaded modules on the same machine.
This is probably already in Perl6.
Core support for reading (and seeking) HTTP/FTP sources would be pretty cool,
but not required.
Thanks,
/Autrijus/
Simon Cozens
> Don't you think it's preferable to temp-expanding and compiling at runtime?
Not if it's slower, no. The choice was made not to go with bytecode because
of a deficiency in Perl. If that deficiency wasn't there, then sure, go
with bytecode.
But you're missing the point, so I'll say it again: IT DOESN'T MATTER.
> The slides about the internals do start with "Here begins the scary part"
For heaven's sake. Have you even *seen* the Perl 5 internals? If you don't
trust things which are self-declared scary hackery to be stable, you probably
shouldn't be using Perl until Perl 6 comes out. And probably not until then.
Look, we're not going to agree on this. Should we just drop the subject?
--
"Though a program be but three lines long,
someday it will have to be maintained."
-- The Tao of Programming
Dan Hursh
> For heaven's sake. Have you even *seen* the Perl 5 internals? If you don't
> trust things which are self-declared scary hackery to be stable, you probably
> shouldn't be using Perl until Perl 6 comes out. And probably not until then.
Um, on a somewhat unrelated note, having tried to get a department of
mine to switch over to perl from csh and REXX of all things, I have
co-workers I hope never see this.
> Look, we're not going to agree on this. Should we just drop the subject?
I know I've seen more than I wanted to.
Dan
Simon Cozens
> Um, on a somewhat unrelated note, having tried to get a department of
> mine to switch over to perl from csh and REXX of all things, I have
> co-workers I hope never see this.
They may need to write their own operating system if they want to avoid the
dodgy software rot entirely. :)
--
If you give a man a fire, he'll be warm for a day. If you set a man on fire,
he'll be warm for the rest of his life.
James Mastros
> 1. The special dir of files (SDoF). Ignoring, for now, the argument for a
> standard way to do this, all the core needs to do to bootstrap an entire
> ecosystem of app packagers is support some standard starting point. Maybe
> it's a file names main.pl inside a *.pmx dir, or whatever. But there needs
> to be something, otherwise every SDoF system will have to bootstrap itself
> using some executable other than perl (e.g. PAR/parl) I think that's much
> less elegant.
We can, and I think should, write a one-paragraph documentation,
one-screenful implementation of this that's in perl core:
As a special case, if the "filename" argument to perl is a directory,
and the directory contains a file named "main.pl", then the directory
is prepended to @*INC, and main.pl is run.
> 2. The single-file, packaged version of the SDoF (SDoF Package). Too
> boostrap this, the core needs to know what to make of such a file. Maybe
> nothing needs to be done if a #! line and some plain old perl code at the
> start of the file is sufficient. But something tells me that a bit more is
> needed to unzip/untar/whatever the rest of the stuff in the package file
> before execution. Trying to inline pure perl unzip/untar at the header of
> each SDoF Package file doesn't seem elegant to me, but it could be
> technically possible to bootstrap that way using only the perl 6 executable.
We can support this in several ways. We can say that core perl also
supports the above if the file is a gzipped tar file, and contains a
main.pl (including adding the archive to @*INC). We can ship a script
with perl, and have the user use the #! mechinisim to run it, with the
actual file being specified to be a #! line, ending with some
combination of CR and LF, then a tarball.
This is probably a lot more work for perl core, but would be quite nice.
> 3. The single-file, platform independent, non-source executable (P6exe).
> This is bytecode or some other platform neutral representation of the SDoF.
> I just don't see how to do this at all without core support.
Parrot supports this well enough that it will be hard for perl6 to mess
it up. Parrot, indeed, already supports...
4. The single-file, platform dependent, machine language executable
(realexe). This is a plain old executable, that does not particularly
indicate it was generated by a "scripting" language. It requires no odd
handing vs a normal executable for the target platform, because it /is/
a normal executable for the target platform. It may be staticly or
dynamicly linked to the necessary libraries.
> Based on the little I know of JAR, the three features listed above seem to
> extend a bit beyond JAR in both directions, and each either require or
> should have some amount of core support, even if only to bootstrap community
> implementations.
Mostly, though, they require fairly minimal support from the core. Only
1 requires C<perl> support, and that support is very minimal. The
others require standard-library support, but all the major bits are
things that should already be in the standard library (because a
front-end to C6PAN should come with, and that means extracting some sort
of .tar.gz files -- calling out to external utilities doesn't cut it too
often).
-=- James Mastros
PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's
and postfix:'th? It's 80s and postfix:th!
John Williams
> PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's
Maybe "in the 80's" is like "at the Jones's". Not that I care, mind you.
> and postfix:'th? It's 80s and postfix:th!
Probably to help separate the term from the postfix operator.
$foo = 3;
@array[ $foo'th ];
Juerd
> > and postfix:'th? It's 80s and postfix:th!
> Probably to help separate the term from the postfix operator.
Maybe what I'm saying now is a really bad idea, because it doesn't make
sense, but can't we just have an adverb that changes an integer into an
ordinal?
4 :th
$foo :th
Obviously, the : should be optional for literal integers:
4th
3th
Juerd
John Williams
> John Williams skribis 2004-09-07 11:37 (-0600):
> > > and postfix:'th? It's 80s and postfix:th!
> > Probably to help separate the term from the postfix operator.
> > @array[ $foo'th ];
>
> Maybe what I'm saying now is a really bad idea, because it doesn't make
> sense, but can't we just have an adverb that changes an integer into an
> ordinal?
>
> 4 :th
> $foo :th
No. Adverbs modify verbs (operators or functions), not terms like 4 or
$foo.
> Obviously, the : should be optional for literal integers:
>
> 4th
> 3th
Yes, because 3 and th parse as different tokens.
Juerd
Thomas Seiler
> We can, and I think should, write a one-paragraph documentation,
> one-screenful implementation of this that's in perl core:
>
> As a special case, if the "filename" argument to perl is a directory,
> and the directory contains a file named "main.pl", then the directory
> is prepended to @*INC, and main.pl is run.
> Only [this] requires C<perl> support, and that support is very minimal.
I Agree.
This is much simpler than what i came up during the recent discussion
about app packaging:
I touhght that it be nice to let module writers somehow associate their
module with a file extention.
This could also be useful for Modules that change the standart Perl 6
Syntax. The module that contains these macros could associate itself
with a extension (e.g. *.klingonpl / *.kpl)
In that way, its immediately clear that some macros are at work.
Maybe this helps in other cases aswell, where the header is somehow
predefined and its not possible to add some shebang magic or a use-
clause to indicate some special treatement...
Would such a feature be useful at all ?
Thomas Seiler
Juerd
> I touhght that it be nice to let module writers somehow associate their
> module with a file extention.
Most worlds don't use file extensions, except for humans. In the Windows
world, file extensions do matter, because it decides which program to
use to run the file, how to extract the icon from the file and often
even whether to scan it for viruses or not.
In my world (Linux, commandline), I only use ".pl" to remind me to use
the file with perl. I could just as well have used ".sh", ".c", ".exe"
or even ".+!!!@#C:\>%% ~*?#$
@$^%". In fact, it does not need an extension at all, because the .
isn't special. I can use any character except \0 and /. If I want, I can
use _ to separate "base name" from "extension", because my operating
system has no idea that the . that some files have, has a special
meaning to me.
I have many text files without any extension, many executable files with
extensions. I have some text files ending in ".txt" and many executables
with no extension at all.
Even if perl wanted to associate a module with a file extension, I doubt
there would be any way to make this work with all platforms it's going
to run on. In fact, I don't doubt that perl will work an platforms
without a filesystem :)
Juerd
Jonathan Lang
> John Williams wrote:
> > > 4 :th
> > > $foo :th
> > No. Adverbs modify verbs (operators or functions), not terms like 4 or
> > $foo.
>
> Then perhaps a method? Number::th?
>
> 4.th
> $foo.th
Again, with a bit of magic where the dot is optional when the object in
question is an integer literal: 4th =:= 4.th - and probably with special
synonyms for th when the literal is any of (1 or -1, 2 or -2, 3 or -3) -
Number::st, Number::nd, and Number::rd, respectively. Mind you, these
wouldn't _really_ be methods, since they would only be valid when used
within the arguments of a list's postcircumfix:[] operator.
And while I like the notion that 0th has a valid meaning and that its
meaning fits into a scheme that parallels the wraparound behavior of
standard lists (i.e., perl 5's 0-based contiguous lists), I can see the
arguments for both 1st referring to the first element and -1st referring
to the last argument (which, if both are accepted, would leave 0th out in
the cold). Of the two, "1st =:= first" is the more compelling argument;
and if one of the two arguments has to be rejected, I'd rather it be the
"-1st =:= last" one.
So we've come up with two mutually exclusive schemes for ordinal indices,
depending on which of 0th or -1st refers to the last element of a list.
There's a third option where the last element isn't given an ordinal at
all; but I doubt that anyone would prefer this, even as a second choice.
The pros and cons of each approach have now been discussed at length, and
it appears that we've reached an impasse of sorts. So let me just
summarize the positions, and ask for Larry's thoughts on the issue.
"0th =:= last": Lists using this type of ordinals would behave exactly
like a perl 5 list, except that [$n.th] would correspond to [$n-1] rather
than to [$n]. You'd read non-positive ordinals as offsets from the last
element, which isn't quite symmetric with the way that positive ordinals
would be read.
"-1st =:= last": This type of ordinal index maintains a symmetry between
positive and negative indices, treating the sign of the ordinal as an
indication of which end of the list to start at. C<0th> would be
undefined, which makes some intuitive sense; but you'd have to watch out
for such things as (1 + $n).th, which would throw an error if $n was -1,
and would work differently for $n < -1 and $n > -1.
Either way, I'd be in favor of being able to use C<last> as a synonym for
the ordinal corresponding to the last element in a list (and, for
symmetry, C<first> as a synonym for 1.th or 1.st); it's at worst one
character longer than the ordinal in question, and its meaning is clear
and unambiguous. The only problem with it is when you're dealing with
sparse arrays: [last - 1] won't neccessarily do what you want it to,
depending on what you want it to do. To avoid confusion in the
discussion, let's look at the other end (where we're pretty much agreed on
the meaning of 1st and first): if we want to look at the next existing
element, we can say (1 + 1).th; if we want to look at the element whose
index is one higher than the first index, we can say 1.st + 1. With
C<first>, we can do the latter but not the former.
=====
Jonathan "Dataweaver" Lang
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
Juerd
> Again, with a bit of magic where the dot is optional when the object in
> question is an integer literal: 4th =:= 4.th - and probably with special
> synonyms for th when the literal is any of (1 or -1, 2 or -2, 3 or -3) -
> Number::st, Number::nd, and Number::rd, respectively. Mind you, these
> wouldn't _really_ be methods, since they would only be valid when used
> within the arguments of a list's postcircumfix:[] operator.
Why would they be invalid outside? Ordinals as real possible values make
sense to me.
Say, you have an array @foo, that starts counting at 5, and @bar that
starts counting at 10. Both have 5 elements. Wouldn't this be handy?
for 1 .. 5 {
... @foo[.th] ... @bar[.th] ...
}
# or maybe even:
for 1st .. 5th {
... @foo[$_] ... @bar[$_] ...
}
$nth = 1st;
say @foo.resolve $nth; # 5 # could be useful
# In normal situations, one would of course use:
# for @foo Y @bar -> $foo, $bar { ... }
# but that is besides the point.
> So we've come up with two mutually exclusive schemes for ordinal indices,
> depending on which of 0th or -1st refers to the last element of a list.
> There's a third option where the last element isn't given an ordinal at
> all; but I doubt that anyone would prefer this, even as a second choice.
I used to think I wanted 0th to be the 0th (one before the first),
because 1nd + $foo could logically only mean (1 + $foo)th. However, if
th is a method of Number, you can just use literally (0 + $foo).th, and
there is no need for a 0th in this anymore.
Still, though -1st seems more logically to me, especially since +1st
isn't 0-based either.
> if we want to look at the next existing element, we can say (1 +
> 1).th; if we want to look at the element whose index is one higher
> than the first index, we can say 1.st + 1.
I read this three times, but don't get it. Can you please explain what
the difference is between the element after the 1st and the element
whoso index is one higher than the 1st's?
Juerd
Nicholas Clark
> 4. The single-file, platform dependent, machine language executable
> (realexe). This is a plain old executable, that does not particularly
> indicate it was generated by a "scripting" language. It requires no odd
> handing vs a normal executable for the target platform, because it /is/
> a normal executable for the target platform. It may be staticly or
> dynamicly linked to the necessary libraries.
Which parrot can already do. (Or at least could, but I don't think that
anyone's been checking on it recently)
This work was completed as a result of a TPF grant that Daniel Grunblatt
received last year:
http://www.perlfoundation.org/gc/grants/2003_q2.html
> Mostly, though, they require fairly minimal support from the core. Only
> 1 requires C<perl> support, and that support is very minimal. The
and as you say all this really isn't about perl 6 the language.
Nicholas Clark
Michael Homer
>Jonathan Lang skribis 2004-09-07 14:12 (-0700):
>
>
>>if we want to look at the next existing element, we can say (1 +
>>1).th; if we want to look at the element whose index is one higher
>>than the first index, we can say 1.st + 1.
>>
>>
>
>I read this three times, but don't get it. Can you please explain what
>the difference is between the element after the 1st and the element
>whoso index is one higher than the 1st's?
>
I think (correct me) what he's getting at here is a sparse array 1=>a,
3=>b, 4=>c where 2nd is 'b' (the second item) but 1st+1 is undefined
(there is no index 2). I don't know how well that scheme works from a
comprehension point of view though, it seems a little confusing.
-Michael
Juerd
> I think (correct me) what he's getting at here is a sparse array 1=>a,
> 3=>b, 4=>c where 2nd is 'b' (the second item) but 1st+1 is undefined
> (there is no index 2). I don't know how well that scheme works from a
> comprehension point of view though, it seems a little confusing.
Oh my, sparse arrays. Isn't that what we have hashes for?
Juerd
Jonathan Lang
In theory, yes; but there are some aspects of sparse arrays that hashes
simply don't capture - the most notable being that the elements of a
sparse array are implicitly ordered, whereas the elements of a hash are
implicitly unordered (you have to explicitly coerce them into an order
whenever you want that factor).
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
James Mastros
> On Tue, Sep 07, 2004 at 06:07:24PM +0200, James Mastros wrote:
>>4. The single-file, platform dependent, machine language executable
>>(realexe).
>
> anyone's been checking on it recently)
decided my verbiage was horrible and rewrote it. (There's a reason I
don't post often.)
>>Mostly, though, they require fairly minimal support from the core. Only
>>1 requires C<perl> support, and that support is very minimal. The
> and as you say all this really isn't about perl 6 the language.
Exactly -- most of this sort of thing is about perl's standard library,
which I think is a discussion for much, much later, and a discussion
(one that, for the most part, is finished) for perl6-language (the part
of the list that should be renamed to parrot).
-=- James Mastros
Jonadab the Unsightly One
> Most worlds don't use file extensions, except for humans.
You exaggerate their lack of importance. File extensions don't matter
to most operating system *kernels*, but they are nevertheless
important for more than just Windows:
* They are of critical importance on Apache-based webservers.
* They instruct command-line tab completion for some shells. This
IMO is a biggie, and would be even bigger if more shells were
smarter. (eshell has a leg up here.)
* They matter somewhat to many *nix applications, such as Emacs and
Gimp. When I say "matter somewhat", I mean that the app
understands what the extension means, and so in the absense of the
extension you have to give the app additional information to
compensate.
* They matter to most GUI file managers in the *nix world. I
personally don't use GUI file managers, but some people do.
* They matter somewhat in the VMS world, though not as much as under
Windows I think.
* They matter in the OS/2 world, if anyone is still using that. Also
DOS, with the same caveat.
* On Mac OS X the extension matters for files that don't have
filetype/creator codes attached to them yet (unless the file is
coming from a source that supplies content-type, such as from a web
server or as an email attachment, in which case the content-type
instructs the addition of filetype/creator codes).
The only OS I know of where file extensions are *totally* not used is
Archimedes. It doesn't allow them at all, from what I understand.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/
Juerd
> * They are of critical importance on Apache-based webservers.
They are not. See mod_mime_magic.
> * They instruct command-line tab completion for some shells. This
> IMO is a biggie, and would be even bigger if more shells were
> smarter. (eshell has a leg up here.)
And this is not something to write home about. They're giving extensions
meaning in a world that doesn't really have extensions. Gzip does this
too, but at least that is limited to the application. The shell tries to
match up other applications with file extensions.
Yesterday, because I couldn't tab-complete an .iso file for use with
mplayer at all, I decided to finally get rid of this kind of tab
completion.
> * They matter somewhat in the VMS world, though not as much as under
> Windows I think.
The real point is that file extensions decide whether a file is
executable in Windows, that associations are all organized in one
location. Many other platforms don't work like this, and if they do,
it's nearly impossible to get this to work well portably.
> Archimedes. It doesn't allow them at all, from what I understand.
It probably doesn't disallow file extensions, but the dot that most
people think is the only way to separate base name from extension.
It's all about heuristics, and I'd hate to have perl behave differently
when the filename is different. Perl shouldn't have to care about the
given file name at all. perl < $file and perl $file should work the
same.
Juerd
John Macdonald
> Juerd <ju...@convolution.nl> writes:
>
> > Most worlds don't use file extensions, except for humans.
>
> You exaggerate their lack of importance. File extensions don't matter
> to most operating system *kernels*, but they are nevertheless
> important for more than just Windows:
>
> * They are of critical importance on Apache-based webservers.
>
> * They instruct command-line tab completion for some shells. This
> IMO is a biggie, and would be even bigger if more shells were
> smarter. (eshell has a leg up here.)
>
> * They matter somewhat to many *nix applications, such as Emacs and
> Gimp. When I say "matter somewhat", I mean that the app
> understands what the extension means, and so in the absense of the
> extension you have to give the app additional information to
> compensate.
"make" is an important example here
Jonadab the Unsightly One
> Jonadab the Unsightly One skribis 2004-09-17 10:46 (-0400):
>> * They are of critical importance on Apache-based webservers.
>
> They are not. See mod_mime_magic.
Magic, as far as I know, only works for filetypes that have known byte
sequences.
>> * They instruct command-line tab completion for some shells.
>
> And this is not something to write home about.
I consider it enough of a killer feature that I won't use a shell that
doesn't have at least halfway decent support for it. My biggest gripe
with bash is that it doesn't do a good enough job of this.
>> Archimedes. It doesn't allow them at all, from what I understand.
>
> It probably doesn't disallow file extensions [per se], but the dot
Could be. I haven't used it personally.
> It's all about heuristics, and I'd hate to have perl behave differently
> when the filename is different.
Oh, I'd hate to have Perl behave differently when the filename passed
to it as an argument is different, but I don't see how that is
necessary for what the OP was talking about:
As a special case, if the "filename" argument to perl is a directory,
and the directory contains a file named "main.pl", then the directory
is prepended to @*INC, and main.pl is run.
Here the real operative issue is that the argument is a *directory*,
rather than a regular file. Currently AFAIK Perl doesn't do anything
very useful when the argument is a directory. As far as 'main.pl',
that's a special case of a magic filename in a specific circumstance,
much like MIRRORED.BY with CPAN.pm -- it's a file Perl goes looking
for under special conditions (namely, in Mastros' proposal, when the
argument to Perl is a directory).
> Perl shouldn't have to care about the given file name at all. perl <
> $file and perl $file should work the same.
I don't disagree with that, but I don't think it implies that Perl
can't know anything about extensions or make any use of them ever.
Jonadab the Unsightly One
> As a special case, if the "filename" argument to perl is a
> directory, and the directory contains a file named "main.pl",
> then the directory is prepended to @*INC, and main.pl is run.
I think it would be useful if the "directory" could also be an archive
in certain common and widely-supported formats (gzipped tarball and
PKWare ZIP being the most important ones to support IMO; probably
should go for bzip2ed tarball also and maybe disk images containing
ISO filesystems if a suitably unencumbered extant code library can be
found for reading them).
Adam D. Lopresto
> James Mastros <ja...@mastros.biz> writes:
>
> > As a special case, if the "filename" argument to perl is a
> > directory, and the directory contains a file named "main.pl",
> > then the directory is prepended to @*INC, and main.pl is run.
>
> I think it would be useful if the "directory" could also be an archive
> in certain common and widely-supported formats (gzipped tarball and
> PKWare ZIP being the most important ones to support IMO; probably
> should go for bzip2ed tarball also and maybe disk images containing
> ISO filesystems if a suitably unencumbered extant code library can be
> found for reading them).
The question is whether any of that needs to be core, and I'm starting to
strongly think it doesn't. I was about to say that perl should only go trying
to figure out that the file is an archive if you pass it an appropriate
command-line argument, but then I realized that argument could well be -MPAR
(or such). Then the module would have to do some magic to see how it's being
called and analyze the parameters, look for archives, etc, but the perl
executable itself wouldn't need anything special (which feels a lot nicer,
since presumably updating the PAR module installed would be a lot easier than
updating perl to support a new archive type). -MPAR could also handle the
directory case, removing any special casing whatsoever from perl.
--
Adam Lopresto
http://cec.wustl.edu/~adam/
"Just once, I wish we would encounter an alien menace that wasn't immune to
bullets."
--The Brigadier, "Dr. Who"
Richard Proctor
> >> Archimedes. It doesn't allow them at all, from what I understand.
> >
> > It probably doesn't disallow file extensions [per se], but the dot
>
> Could be. I haven't used it personally.
The name should be Risc-OS - the Archimedes is one of the computers that run
it. Risc-OS has the concept of filetype, but it is not as part of the
name, but a separate property of the files.
Having said that, In converting from a filename with an extension from
another system, a ".ext" is often converted to a "/ext" as "." is the native
directory symbol. Thus in converting between unix style file names and
riscos style file names is roughly tr#/.#./# (there are some caveats).
Richard
(Using Risc-os on an RPC)
--
Personal Ric...@waveney.org http://www.waveney.org
Telecoms Ric...@WaveneyConsulting.com http://www.WaveneyConsulting.com
Web services Ric...@wavwebs.com http://www.wavwebs.com
Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Jonadab the Unsightly One
> On Sat, 18 Sep 2004, Jonadab the Unsightly One wrote:
>
> The question is whether any of that needs to be core, and I'm
> starting to strongly think it doesn't. I was about to say that perl
> should only go trying to figure out that the file is an archive if
> you pass it an appropriate command-line argument, but then I
> realized that argument could well be -MPAR (or such).
If by "core" you mean language core, and if the module in question
would be in the core distribution, then I can mostly go along with
that (with one caveat, below). And on some platforms the Perl
installer could associate certain extensions (perhaps .par) with
"perl -MPAR" or whatever so that launching the thing Just Works.
Since most of the point of such a mechanism would be to allow people
who "just" have Perl installed to automagically run these
programs-in-an-archive that include all the modules they use in their
nice neat package, it would be unfortunate to require something extra
to be installed to make that work. Thus, this module should go in the
core distribution, along with the new and improved CPAN.pm equivalent.
So in one sense I would consider this "core functionality", in the
sense that it's something Perl needs to be able to do out of the box,
but I can agree that it doesn't need to be in the _language_ core.
Except that the module will be prepending the contents of the archive
to @INC, which implies that @INC needs to be able to contain more than
just directories on the system-level filesystem -- it needs to be able
to contain tied "directories" that are simulated by modules, or
something along those lines. The core might have to have some hooks
for that.
Michele Dondi
> to @INC, which implies that @INC needs to be able to contain more than
> just directories on the system-level filesystem -- it needs to be able
> to contain tied "directories" that are simulated by modules, or
(Unless I've not really understood what you mean) this should not be a
major problem since @INC already, i.e. in (recent) Perl5(s) can contain
"more than just directories", e.g. coderefs.
HTH,
Michele
--
Ask about it in alt.folklore.computers. Somebody over there will know;
they know everything or know somebody who does ;-).
- Found somewhere in USENET