> Rejigging NCI to use the ffcall library
> Nick Glencross wondered about rejigging NCI, the parrot Native Call
> Interface to use the ffcall library. In fact he went so far as to offer
> up a proof of concept implementation. Apparently the ffcall approach
> makes it much easier to write callba
Autrijus Tang wrote:
> > Luke Palmer wrote:
> >
> > And it would be a shame to disallow the use of $_ in map.
>
> Err, wait, I don't think we are discussing whether $_ is to
> be outlawed in map {}.
Perhaps we should consider making $_ readonly in map and grep?
sed implementation of Perl 6 regex syntax in Perl 5. It
implements most, but not all of Perl 6 regex syntax due to limitations of
Perl 5.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Miss
I found Luke Palmer's Synopsis 3 on perl.com at
http://www.perl.com/pub/a/2004/03/18/synopsis3.html but didn't see it out at
http://dev.perl.org/perl6/synopsis/.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road
Sam Vilain wrote:
>
> On Thu, 06 Mar 2003 05:10, Garrett Goebel wrote:
> > Several people have mentioned a desire to see Perl6
> > and Parrot facilitate object persistence. Should
> > such issues be tackled in Parrot?
>
> Not necessarily. Just be friendly to objec
Obviously the OMG's UML and family of specifications deal with these
issues. What other practical approaches exist?
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds RoadMain: 913.384.1008
Mission, KS 66202 Fax:
tion is whether it is still
accurate in the _context_ of Perl6 ;)
> But is it OK for a list to be silently promoted to an array when used
> as an array? So that all of the following would work, and
> not just 50% of them?
>
> (1..10).map {...}
> [1..10].map {...}
>
anyone see any changes in perl6 to invalidate that
> separation of lists and arrays?
Immediately thereafter, Larry left room to imply list may actually be
spelled a-r-r-a-y...
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road
Michael Lazzaro wrote:
> On Friday, January 31, 2003, at 09:40 AM, Garrett Goebel wrote:
> >
> >
> > I'm disappointed that The Perl Foundation (TPF) has been so
> > quiet and unresponsive on support for our core language
> > designers and architects. I drop
From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > $idx_of_foo = $queue['foo']; # named lookup
> > $nth_foo= $queue[600]; # ordered lookup
> >
> > One is SvPOK the other SvIOK...
> >
> &
From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > And what's to prevent that collection object from handling:
> >
> > my $queue = SomeQueue.new;
> >
> > $queue.push('foo&
Piers Cawley wrote:
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > What was the reason again which Larry rejected unifying the
> > syntax for array and hash indexing? As Piers said, we know
> > whether $a is an array or hash reference when we do:
> >
&
Apologies in advance for beating this dead horse...
Damian Conway wrote:
> Garrett Goebel wrote:
>
> > What was the reason again which Larry rejected unifying the
> > syntax for array
> > and hash indexing?
>
> Because some things have both, and do different thing
Joseph F. Ryan wrote:
> Stéphane Payrard wrote:
> >
> >I think that arrays and associative tables are very
> >different entities for two reasons:
> > -type of keys. array keys are integers
> > -cost of insertion and deletion operations: O(n) and
> > lower for associative table ( O(1) if you do
From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Garrett Goebel:
> # Brent Dax wrote:
> # >
> # > This is also a problem with using want().
> # >
> # > If we don't provide wants_scalar/wants_list, someone will
> # > build it with want(), so we might as well
> (probably by specifying which one should be the default).
Where "special value" is a junction: 'scalar' | 'list'?
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
ble to match last years' contribution.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
any
> given class are so low that we'd probably be better off
> leaving it as a DIY project.
I thought we wanted to be able to guarantee a unique identifier across the
life of the object? -Objects may outlive processes... I'd rather trust the
implementation than DIY'ers.
UUID: Universal Unique Identifier (DCE)
http://www.opengroup.org/onlinepubs/9629399/apdxa.htm
GUID: Globally Unique Identfier (EFI)
http://ulita.ms.mff.cuni.cz/pub/techdoc/ia64/EFISpec_092.pdf
(page 319)
Of the 2, usage of "GUID" seems to be more common IMHO. Both of the above
are id
John Siracusa wrote:
> On 12/12/02 12:55 PM, Larry Wall wrote:
> > As for namespace pollution and classes that use .id in Perl 5, I
> > don't think it's going to be a big problem. Built-in identifiers
> > do not have a required prefix, but they have an optional prefix,
> > which is C<*>. I think
en&lr=&ie=UTF-8&selm=Pine.LNX.4.44.021031
1952540.18773-10%40london.wall.org
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
pacts, ideological
ax grinding, etc. so that p6l can refer people to the old arguments instead
of wasting ever more time on them.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
$foo.run;
do?
Invoke the run method against all of the object-eigenstates? And if not in a
void context, return a junction containing their results?
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
me properties.
> >
> >From E2: a C will never have attributes or promote to an object.
>
> Attributes aren't properties.
I thought:
'attributes' :Perl5 == 'properites' isa Perl6
Can someone point me to Perl6 definitions for both terms?
--
Garrett
Angel Faus wrote:
>
> So, while we all wait for Larry to wait the design, is there any
> reason not to start working in the documentation?
Any chance of getting a wiki setup at:
http://dev.perl.org/perl6/cathecism/
Say using a wiki which uses pod for markup like:
http://search.cpan.org/auth
in here?
>
> I know I'm just another sample point in a sea of samples
Can't we have our cake and eat it too? Give ASCII digraph or trigraph
alternatives for the incoming tide of Perl6 Unicode?
Allow both >>*<< and »*«?
Or something similar '>>*'<<
; I could see using backtick as the "escape" code for things
> like `<< or `>> which would turn into what some benighted
> soul called "girly" angles.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
In the quest for keys anyone can reach on any keyboard...
instead of «*» why not: (>*<), <)*(>, >)*(<, [>*<], or [)*(]
Which stands out best?
@a «*» @b
@a (>*<) @b
@a <)*(> @b
@a >)*(< @b
@a [>*<] @b
@a [)*(] @b
IMHO [>*<]
--
ators".
Great minds think alike. Or in this case even me ;) I was just describing
superpositions as set operations to one of our developers...
I'm left wondering what the relationship between Perl6 and relational
databases will be. Where one will leave off and the other will be
ance).
In your superposition example (Class|Dog), am I'm assuming correctly that
you could invoke that method with an instance of any object that IS-A Dog?
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.3
Michael G Schwern:
> Garrett Goebel wrote:
> > Michael G Schwern:
> > > shouldn't we have private invariants and conditions?
> >
> > no.
>
> Ummm, why?
Maybe I'm just grinding an ax...
If you allow an interface's post conditions and in
John Williams:
> Reaction #2: Inheritance would automatically delegate all those
> methods, so again, in what way does inheritance _not_ solve
> the problem?
What about when you want to be able to dynamically swap the objects to which
you're delegating?
--
Garrett Goebel
Michael G Schwern:
> Garrett Goebel wrote:
> > A derived interface can loosen input constraints... so
> > it must be able to either satisfy all inherited pre-
> > conditions _or_ its own pre-conditions.
>
> Looking around, this seems to be regarded as something of a
e to
preclude the code block?
Also if you rely on attributes to hang conditions... you're ruling out the
ability to reference things in the lexical context of the code block.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
NDs.
>
> As expressions in Perl run a tad beyond simple boolean logic,
> could you give a concrete example?
all inherited pre-conditions pass
or
class' own pre-conditions pass
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds
Garrett Goebel:
> Michael G Schwern:
> > But I don't want my subclasses to be constrained by that.
> > It's just an implementation detail that I only wish to
> > enforce upon ATV and not it's children.
implementation details don't belong in interfaces
not it's children. So they're
> private.
>
> Makes sense, no?
No. Per DBC, pre-conditions are satisfied if either the inherited
pre-conditions _or_ its own pre-conditions are satisfied. Thus allowing the
loosening of input constraints which I believe is what you're af
d admittedly, I don't have a firm grasp on how lvalue assignment would be
mapped to object methods... but wouldn't the following statements also be
identical?
$date = 'June 25, 2002';
$date->STORE('June 25, 2002');
So what again is wrong with:
my
Allison Randal wrote:
> Garrett Goebel wrote:
> >
> > I guess the next question in the context of the following is:
> >
> > Larry Wall wrote in Apocalypse 4:
> > >
> > > It should be possible to make user-extensible syntax look
> > > just lik
From: Allison Randal [mailto:[EMAIL PROTECTED]]
> On Wed, Feb 27, 2002 at 04:24:48PM -0600, Garrett Goebel wrote:
> > From: Allison Randal
> >
> > Not just some value external to the switch, but the value in $_.
> >
> > I now see the DWIM aspect. Thanks BTW.
&
Dang... why isn't you see so many more obvious errors, the moment after you
click send?
From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
>
> or without the special case:
>
> $hi = 'hello';
> $x = 'burt';
> for $hi -> $y {
> given {
> wh
From: Allison Randal
> Garrett Goebel wrote:
> >
> > Why does C's EXPR pay attention to the topicalizer
> > regardless of associated variable?
> >
> > Why introduce the special case?
>
> Why? Because it's oh-so dwim. Think about it, if y
From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Garrett Goebel:
> # Larry Wall in Apocalypse 4 writes:
> # > this special rule only applies to constructs that take a
> # > block (that is, a closure) as their last (or only) argument.
> # > Operators like sort and map are unaf
From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> Speaking of which, you forgot your trailing semicolon for the
> C expression's final closure/block.
s/expression/statement/
Larry Wall in Apocalypse 4 writes:
> this special rule only applies to constructs that take a
> block (that is, a closure) as their last (or only) argument.
> Operators like sort and map are unaffected. However, certain
> constructs that used to be in the statement class may become
> expression co
Larry Wall wrote:
> I think the switch statement will have to recognize any
> Class::Name known at compile time, and force it to call
> $!.isa(Class::Name).
Don't you mean the case/when statement? Wouldn't you want the following to
work:
for @obj {
when Dog { ... }
when Cat { ... }
}
From: Austin Hastings [mailto:[EMAIL PROTECTED]]
>
> for @A {
> for @B -> $x {
> when /a/ $_ -> $a { s/a/b/; ... $a ...; }
> }
> }
>
> Once we get inside the curlies, $_ is aliased to the localized var for
> the C (in this case, $x).
I went back and read the Apocolypse 4: RFC 022. I may
From: Melvin Smith [mailto:[EMAIL PROTECTED]]
> At 01:52 PM 1/28/2002 -0600, Garrett Goebel wrote:
> >From: Brent Dax [mailto:[EMAIL PROTECTED]]
> > > Aaron Sherman:
> > > #
> > > # I think the first guy that gets hired to maintain Perl6 code,
> > >
From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Aaron Sherman:
> #
> # I think the first guy that gets hired to maintain Perl6 code,
> # and think "hey, I know Perl, no sweat" will disagree with
> # you.
>
> I disagree. He'll see stuff he doesn't understand and try to
> consult perldoc on it, at wh
From: Larry Wall [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel writes:
> : And this is just looking at it in the simple case. When
> : multiple-dispatch comes into the picture, then we'll
> : have different invokations of the same method being
> : dispatched to di
From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
>
> > So maybe your point was that when you replace a method from a
> > base class that you only have 1 subroutine for that method,
> > the replacement one, because there
From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
>
> Graham Barr wrote:
> > But the base class may be just an interface class. And thus
> > by inheriting the pre conditions you are enforcing the API.
> > So I can see a use for it, but I can also see where you
> > don't want it too.
>
> So if th
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> > "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> Larry> I think our terminology is getting sloppy here. What
> Larry> do you mean by "inherit from that method"? If the
> Larry> derived method overrides the base method, it will
From: David Whipp [mailto:[EMAIL PROTECTED]]
> Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
> > This is all very sensible, and I completely agree with it.
> > However, don't we
> > need some restrictions on what can go in PRE and POST blocks
> > to ensure that they are still valid in inherite
From: Me [mailto:[EMAIL PROTECTED]]
>
> > The problem I see with inheriting subblocks such as
> > FIRST/LAST/etc, is that they are tied in with the logic
> > ... of their enclosing block...
>
> Surely this is an argument *for* it being pretty odd
> *not* to inherit them.
>
> Let's say you add a
From: David Whipp [mailto:[EMAIL PROTECTED]]
>
> Apo4, when introducing POST, mentions that there is a
> corresponding "PRE" block "for design-by-contract
> programmers".
>
> However, I see the POST block being used as a finalize;
> and thus allowing (encouraging?) it to have side effects.
It m
Piers Cawley writes:
: Damian Conway <[EMAIL PROTECTED]> writes:
: > Of course, that's not to say that the particular C that's returned on
: > failure-to-numerify mightn't have a property set that indicates the problem
: > was not-a-numeric in nature.
:
: Having more than one 'undef' value sound
Piers Cawley writes:
: If currying magic works in subroutine parameter strings then you can
: just do
:
: sub assert_with_func (&^sub is constant, $^expected is constant,
: $^got, $message)
: {
: &^sub($expected, $got) or die $message || $default_message
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> Here in the 10-step Perl 6 program we don't talk about
> resolution. We just learn to cope with change. ;)
;) I'm still working to grok the changes. I thought I was getting generally
clued in after reading the Apocalypses/Exegesises... but discussions
From: David M. Lloyd [mailto:[EMAIL PROTECTED]]
> On Thu, 1 Nov 2001, Garrett Goebel wrote:
> > On Wed, 31 Oct 2001, David Nesting wrote:
> > > On Tue, Oct 30, 2001, Aaron Sherman wrote:
> > > : Yep, but in Perl5, this was never very clean or obvious
> > > :
On Wed, 31 Oct 2001, David Nesting wrote:
> On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote:
> : Yep, but in Perl5, this was never very clean or obvious to the
> : casual programmer. Constants have been coming of age in Perl,
> : and they're kind of scary if they're not constant.
>
>
From: Sam Vilain [mailto:[EMAIL PROTECTED]]
>
> It would be a bit like Class::Contract merged with
> Class::Tangram, but if Class::Contract is going into
> the core then it's a feature I'd like to see...
I'd like to see Class::Contract play nicely with Class::Tangram,
Class::Multimethods, etc.
Piers Cawley has written a nice article entitled: "Perl 6 : Not Just For
Damians".
If the hair on the back of your neck rises when thinking about Perl 6, or
even if it doesn't... give it a read.
http://www.perl.com/pub/a/2001/10/23/damians.html
Thank you.
For those who aren't yet busy reading, you can find it at:
http://www.perl.com/pub/a/2001/10/03/exegesis3.html
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> I think we have a language question... What should the following
> print?
>
> my $x = 1;
> my $y = \$x;
> my $z = 2;
> %MY::{'$x'} = \$z;
> $z = 3;
> print "$x, $$y, $z\n"
>
> a. "2, 1, 3"
> b. "2, 2, 3"
> c. "3, 1, 3"
> d. "3, 3, 3"
> e.
From: Ken Fox [mailto:[EMAIL PROTECTED]]
> Dan Sugalski wrote:
> >
> > I think you're also overestimating the freakout factor.
>
> Probably. I'm not really worried about surprising programmers
> when they debug their code. Most of the time they've requested
> the surprise and will at least have a
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> "Bryan C. Warnock" <[EMAIL PROTECTED]> mused:
> > Consider it like, oh, PATH and executables:
> > `perl` will search PATH and execute the first perl
> > found, but 'rm perl' will not. It would only remove
> > a perl in my current scope..., er, dire
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
>
> If there is to be a %MY, how does its semantics pan out?
>
> for example, what (if anything) do the following do:
>
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
> }
IMO: Sets the value of the lexical $x i
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> Can we have an example of why you want run-time
> symbol table manipulation?
How about being able to dump and restore subroutines and closures along with
their lexical environment?
Perhaps this next example doesn't have to fall under the runtime cate
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
>
> On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
> > The third value is a "peek" value. Do the runtime
> > checking, but don't do any magic variable stuff. As a
> > matter of fact, don't run any user-code at all. Simply
> > re
From: Nicholas Clark [mailto:[EMAIL PROTECTED]]
> On Thu, Aug 30, 2001, Brent Dax wrote:
> > From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
> > # On Fri, Aug 31, 2001, Bryan C. Warnock wrote:
> > # > Access to the source code.
> > #
> > # Already got that.
> > #
> > # use Fcntl qw(:seek);
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> > You forgot the other example that someone raised:
> >
> > { my $x = 'X'; *h = sub { $H = sub {pr $h} }}
> > h(); $H->();
> >
> > Which prints:
> >
> > Z
>
> Did you mean this?
>
> { my $z = 'Z'; *h = sub { $H = sub {pr $z} }}
> h(); $H->();
>
>
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> Ken Fox <[EMAIL PROTECTED]> wrote:
>
> > You're speaking in Perl implementation terms. I've already told you
> > that if Perl acts the way you say it does, then Perl has buggy
> > closures. You don't need to explain a bug to know that one exists!
>
From: Ken Fox [mailto:[EMAIL PROTECTED]]
> Michael G Schwern wrote:
> > Any time you want to implicitly pass @_, you can just as easily
> > *explicitly* pass it or use goto.
goto does screw up caller... so I wouldn't say *anytime*
> I never thought of using goto actually. "goto &$method;" actua
Any word from on high whether subroutine signatures will apply to methods in
Perl6? There's RFC128 and RFC97... but they both mostly dodge the issue of
methods.
The absense of method signatures for specifying required, optional, and
named parameters... not to mention type-checking for validation
And also on the introductory level:
Art of Compiler Design, The: Theory and Practice
http://www.amazon.com/exec/obidos/ASIN/0130481904
Constructing Language Processors for Little Languages
http://www.amazon.com/exec/obidos/ASIN/0471597546
From: Stuart Rocks [mailto:[EMAIL PROTECTED]]
>
> Both the following would work:
>
> with($foo){
>print "I am not a $foo\n";
> # or:
>print "I am not a ";
>print;
> }
Okay... I've been mostly ignoring this thread. But can someone reiterate the
difference between the above and
for
From: David L. Nicol [mailto:[EMAIL PROTECTED]]
> "Mark J. Reed" wrote:
>
> > But you're opening a big can of worms if you make such a
> > change. The biggest impact would be in the way methods are defined.
> > Instead of just being members of a package, they would have to be
> > associated with
From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
>
> Before anyone gets the wrong idea, I don't think the solution is a
> drastic scaling back in Perl's flexibility. I just don't know what
> the solution is yet. Maybe it should be possible for a class to
> completely seal off its namespace to
From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]]
> On Tue, May 22, 2001 at 10:10:55AM -0500, Garrett Goebel wrote:
> > What is UNIVERSAL::can($foo, 'new') going to return if
> > there is a variable and/or value property 'new' set
> > on $foo?
>
From: Graham Barr [mailto:[EMAIL PROTECTED]]
> On Tue, May 22, 2001, Damian Conway wrote:
> > > if so, then wouldn't it be safer to put properties
> > > inside a special object associated with each object
> > > (the 'traits' object) so there would be little
> > > namespace collision?
> >
> > We
From: Carl Johan Berglund [mailto:[EMAIL PROTECTED]]
>
> Other than that, I think I like Larry's idea to have one variable_is
> and one value_is method. I would also very much have Data::Dumper
> built in as 'dump', so that I could say
I would rather the bike shed be painted:
@var_prop = keys
1) It looks like properties proposed will introduce an inconsistency in
naming conventions. In OO-Perl programmers are advised to use leading
lowercase for object methods and leading uppercase for class methods.
Properties are lowercase for built-ins and uppercase for user-defined. Don't
we need t
From: Larry Wall [mailto:[EMAIL PROTECTED]]
> Richard Proctor writes:
> : In Apocalypse 2, \Q is being used for two things, and I
> : believe this may be ambiguious.
> :
> : It has the current \Quote meaning admitibly \Q{oute} it is
> : also being proposed for a null token disambiguate context.
From: Buddha Buck [mailto:[EMAIL PROTECTED]]
> At 03:00 PM 05-04-2001 +0100, Michael G Schwern wrote:
> >On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote:
> > > And btw . . . Wouldn't
> > >
> > > $thing has property
> > >
> > > make more sense than
> > >
> > > $thing is pro
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> At 05:22 PM 5/3/2001 -0400, John Porter wrote:
> >David L. Nicol wrote:
> > > is sandboxing something a language should support
> > > at all, or is it best left to the OS to provide
> > > a solid chroot facility?
> >
> >IMHO this is one of those t
: $foo = "foo" + "$foo" + foo + foo()
o easy to differentiate string and numeric ops
o doesn't spill over into other syntax changes... (i think)
From: Stephen P. Potter [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel <[EMAIL PROTECTED]>
: $foo = "foo" + "$foo" + foo + foo()
o easy to differentiate string and numeric ops
o doesn't spill over into other syntax changes... (i think)
From: Stephen P. Potter [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel <[EMAIL PROTECTED]>
~ looks like a string to me Larry sycophant that I am.
, also looks a little like a string. And is keyboard friendly.
Its doubtless naive to suggest it, but why not:
Perl 5 Perl 6
--- ---
-> .
+ +
. ~+
eq ~==
From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> David M Lloyd <[EMAIL PROTECTED]> writes:
> > On 24 Apr 2001, Russ Allbery wrote:
> > >
> > > It seems relatively unlikely in the course of normal Perl
> > > that you're going to end up with very many references to
> > > objects.
> >
> > Well, right
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> On Thu, Apr 05, 2001 at 10:10:47PM +0100, Michael G Schwern wrote:
> >
> > I think he's saying that its annoying to have to write any
> > sort of tag that says "Hey, I'm starting a new Perl 6 program
> > here!" at the top of every single program, mu
[Note: This a plain text repost. The original came across as HTML...]
> [25]RFC 73: All Perl core functions should return objects
[...]
> I'm thinking that the solution is better abstract type support
> for data values that happen to be represented internally by C
> structs. We get bogged dow
From: John Porter [mailto:[EMAIL PROTECTED]]
> Dan Sugalski wrote:
> >
> > :contained. Or possibly :irrelevant, since generally
> > speaking most people won't use it and the optimizer
> > will have to infer whether it's safe to not execute
> > the function every time...
>
> It shouldn't necessar
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> > So the results of ord are dependent on a global setting for
> > "current character set" or some such, not on the encoding
> > of the string that is passed to it?
>
> Nope, ord is dependent on the s
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote:
> >
> >The RFC project should be ongoing and more adaptive.
>
> It's my understanding that this is, in fact, the plan. The
> only reason things have paused (and it is a pause, not a
> stop) is that
From: Steve Simmons [mailto:[EMAIL PROTECTED]]
> Paul Johnson wrote:
>
> > Has anyone considered the problems associated with XS
> > code, or whatever its replacement is?
>
> Pardon my ignorance, but what's XS code?
Extra code is. Which knack had you obfuscation
for could left out have been. --
Dave Storrs <[EMAIL PROTECTED]> writes:
>
> On Fri, 2 Feb 2001, Garrett Goebel wrote:
>
> $Foo::VERSION eq 1.00
> |
> | $Foo::VERSION eq 2.00
> | |
> Bar Baz
> \ /
> My::Module
>
> Ideally, it should be perfectly legit to have multiple
&
From: James Mastros [mailto:[EMAIL PROTECTED]]
>
> Speaking of contract names, is Damien about?
In Class::Contract... the package name is the unique identifier.
Piers Cawley has been working on Interface::Polymorphism
http://search.cpan.org/search?dist=Interface-Polymorphism
Perhaps he has som
Dan Sugalski wrote:
>
> It's the explicit exporting that I'm concerned about.
> Perhaps I'm being overly worried, but it strikes me that
> if all a module needs to do to get on the autoload list
> is have an @EXPORT_AUTO declaration at the top (or
> something similar) we're going to see it abus
Discussion of RFC 271 and 194 on pre and post handlers for subroutines
reminded me of Larry's desire for Perl 6 to support the coexistance of
different versions of modules.
Besides http://dev.perl.org/rfc/78.pod, are there any RFC's which directly
or indirectly relate to this?
1 - 100 of 141 matches
Mail list logo
