As it stands, though, perl6-internals isn't about perl, but Parrot ...
so of the two lists, language is arguably more appropriate...
On Sun, 5 Sep 2004 22:37:04 -0400, Matt Diephouse [EMAIL PROTECTED] wrote:
I may be completely off base here, but I think this whole discussion
would be better
On Sat, 2004-09-04 at 17:59, John Siracusa wrote:
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,
On Mon, 6 Sep 2004 11:48:59 +, Herbert Snorrason [EMAIL PROTECTED] wrote:
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
On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote:
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
On 9/6/04 12:13 PM, Nicholas Clark wrote:
On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote:
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
[EMAIL PROTECTED] (John Siracusa) writes:
there's an official way, you'll certainly see less wheel reinvention than in
Perl 5. This is a good thing.
That is only true if you accept the fundamentalist principle that one should
never reinvent wheels. If that were true, then we wouldn't be
John Siracusa writes:
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
John Siracusa [EMAIL PROTECTED] writes:
On 9/3/04 6:45 PM, Damian Conway wrote:
John Siracusa wrote:
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
On Sat, Sep 04, 2004 at 08:17:36PM +0100, Piers Cawley wrote:
: John Siracusa [EMAIL PROTECTED] 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
On 9/4/04 5:38 PM, Larry Wall wrote:
On Sat, Sep 04, 2004 at 08:17:36PM +0100, Piers Cawley wrote:
: John Siracusa [EMAIL PROTECTED] 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.
On Sat, Sep 04, 2004 at 05:59:18PM -0400, John Siracusa wrote:
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
On 9/4/04 6:58 PM, Nicholas Clark wrote:
On Sat, Sep 04, 2004 at 05:59:18PM -0400, John Siracusa wrote:
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
[EMAIL PROTECTED] (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
John Siracusa wrote:
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
On 9/4/04 7:31 PM, Simon Cozens wrote:
[EMAIL PROTECTED] (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
Synopsis 4 says:
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
On Fri, Sep 03, 2004 at 04:35:56PM -0400, John Siracusa wrote:
: Synopsis 4 says:
:
: 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
On 9/3/04 6:03 PM, Larry Wall wrote:
On Fri, Sep 03, 2004 at 04:35:56PM -0400, John Siracusa wrote:
: Synopsis 4 says:
:
: 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
John Siracusa wrote:
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?
On 9/3/04 6:45 PM, Damian Conway wrote:
John Siracusa wrote:
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
20 matches
Mail list logo
