From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 05:18 PM 9/22/00 -0500, Garrett Goebel wrote:
> > From: Ben Tilly [mailto:[EMAIL PROTECTED]]
> > > Garrett Goebel wrote:
> > > >
> > > > Can't a trademark be used to protect "Per
From: Tim Conrow [mailto:[EMAIL PROTECTED]]
>
> I don't know trademark law, but it seems unlikely that
> O'Reilly can trademark the concept of the camel, or all
> representations of the camel.
No. They can't trademark the "concept" of the camel. But they _have_
trademarked their camel logo and i
From: Peter Scott [mailto:[EMAIL PROTECTED]]
>
> As I said earlier, why don't we just define a syntax for
> *anything* to be used as an extension language, and let
> the, er, market decide?
Here, here!
Peaceful coexistance... what a concept.
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> (Though if someone comes up with a way to make the
> platform-dependent bits really small and isolated I'm all for it)
Hmm... I'm 99.9% ignorant on this subject, but doesn't this relate back to
past discussions of C--, the portable assembly language
From: David L. Nicol [mailto:[EMAIL PROTECTED]]
>
> I think pitching renames for "local" is at least as worthwhile
> as pitching code names. How about "Hold?" It isn't listed in
> Blackstone's RFC 19, and it focuses on the restore-later
> aspects -- put that variable on hold, like it is a phon
From: Garrett Goebel
> From: Dan Sugalski [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]]
> > (Though if someone comes up with a way to make the
> > platform-dependent bits really small and isolated I'm all for it)
>
[mention of C--]
>
> From: Dan Sugals
From: John Porter [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel wrote:
> >
> > I'm sure you won't be surprised by this, but I recall John
> > Porter as being a C-- fan. Now why is he being mysteriously silent?
>
> Nope, wasn't me. Never heard of it
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
>
> On Tue, Oct 24, 2000 at 12:54:26PM -0500, Garrett Goebel wrote:
> > Everyone seems to have their favorite laundry list of the
> > failings of C, and an accompanying list of complex and/or
> > fragile solutions.
>
From: David L. Nicol [mailto:[EMAIL PROTECTED]]
>
> Is there a way to determine if a word is defined as a command? (A few
> methods come to mind, including getting a list from the documentation
> and making a hash of it)
foreach my $func (qw(grep map die printf sprintf foo bar baz)) {
eval {
From: Sam Tregar [mailto:[EMAIL PROTECTED]]
> I'm a jerk, so I have to ask: do they exist? What platform are you
> talking about where there exists a JVM and where no C compiler can
> target the architecture? How did they write the JVM with no C
> compiler?
C was written in NB/B
NB was written
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> Screw Visual Basic, Perl should be the scripting language of
> choice for, well, everything! :)
Well... then someone needs to make it easier to dynamically access the Win32
API from Perl.
Visual Basic has been growing up too. And it's a whole l
From: Branden [mailto:[EMAIL PROTECTED]]
>
> I was reading RFC 271 and thinking about this pre/post
> handler thing. Why instead of having 2 subs, one for
> pre and other for post condition, and having to deal
> with things as strange as $_[-1], why don't we
> have only one handler that calls t
From: Branden [mailto:[EMAIL PROTECTED]]
>
> For example: suppose sub next_temp calculates a new
> temperature from an old temperature
[...]
>
> Suppose it only handles Celsius, and we want to be able to
> handle Fahrenheit and Kelvin also. We could do it by:
if you have a procedure:
sub nex
From: Branden [mailto:[EMAIL PROTECTED]]
>
> Well, with those inheritance semantics, I believe the example
>
> Damian Conway writes:
> :
> : pre read_file {
> : flock $_[0], LOCK_EX;
> : }
>
> looses all its mean. Suppose the class whose method read_file has
> this pre-handler is inher
From: Garrett Goebel
>
> This just in "Damian Conway writes":
> > the RFC has a glaring mistake: derived pre-conditions are
> > supposed to be tested *before*, not after inherited ones!)
Hmm. Would it still skip performing the inherited pre handlers if the
derive
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?
From: Simon Cozens [mailto:[EMAIL PROTECTED]]
>
> Never over-design. Never think "Hmm, maybe somebody would find this
> useful". Start from what you know people _have_ to have, and try to
> make that set smaller. When you can make it no smaller, you've
> reached one point. That's a good point
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
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
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: Edwin Steiner [mailto:[EMAIL PROTECTED]]
>
> Branden wrote:
> >
> > and the other thing is that creating a
> > vtable for another type would break all existing types.
> >
> > Example: suppose we want compiled regexes (qr/^xyz$/)
> > to have its own vtable so that we could inspect them
> >
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> No, you attach the magic to a value. Perl just doesn't copy
> magic when it copies data. Whether this is a good thing or
> not is up in the air. (Half the time I want it to, the other
> half I don't...)
Is there a good discussion of magic, copyi
From: Branden [mailto:[EMAIL PROTECTED]]
>
> try to define a method in package bar and try to call it
> from $bar, like $bar->foo. Won't work either, you have
> to ${$bar}->foo. Overloading should loose the magic
> in the same sense that the method should not be called.
No, $bar->asString and $b
From: Tim Bunce [mailto:[EMAIL PROTECTED]]
>
> On Tue, Feb 06, 2001 at 12:28:23PM -0500, Dan Sugalski wrote:
> >
> > At 11:26 AM 2/6/2001 +, Tim Bunce wrote:
> > >
> > > On Mon, Feb 05, 2001 at 05:14:44PM -0500, Dan Sugalski wrote:
> > > >
> > > > =head2 Core datatypes
> > > >
> > > > For eas
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. --
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: Nicholas Clark [mailto:[EMAIL PROTECTED]]
>
> On Thu, Mar 22, 2001 at 04:10:28PM -0500, Dan Sugalski wrote:
> > 1) All Unicode data perl does regular expressions against
> >will be in Normalization Form C, except for...
> > 2) Regexes tagged to run against a decomposed form will
> >
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 11:09 PM 3/23/2001 +, Simon Cozens wrote:
> >
> > For instance, chr() will produce Unicode codepoints. But
> > you can pretend that they're ASCII codepoints, it's only
> > the EBCDIC folk that'll get hurt. I hope and suspect
> > there'll be an
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: Damien Neil [mailto:[EMAIL PROTECTED]]
> On Mon, Mar 26, 2001 at 08:37:05PM +, [EMAIL PROTECTED] wrote:
> > >
> > > If ord is dependent on the encoding of the string it gets, as Dan
> > > was saying, than ord($e) is 0x81,
> >
> > It it could still be 0x81 (from ebcdic) with the encodin
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
[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: 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
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
[...]
> Well, I think that's all I have to say on the subject. Now
> I'd like to hear from you. Do this all make sense? Is it
> useful? Is it worth for Perl 6? Is it too clumsy? Are there
> things I didn't mention here?
I hope our more enligh
> > The equivalent of an AV should store an array of values rather
> > than variables.
>
> I disagree.
>
> $a = 1;
> @b = ($a);
> $c = $b[0];
oops I meant:
Wouldn't you like to preserve the possibility of allowing $c
get both the variable and value vtables of $a?
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
~ 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 ~==
: $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]>
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
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
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: 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
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: 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: 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: David L. Nicol [mailto:[EMAIL PROTECTED]]
> Russ Allbery wrote:
> >
> > a caseless character wouldn't show up in
> > either IsLower or IsUpper.
>
> maybe an IsCaseless is warrented -- or Is[Upper|Lower]
> could return UNKNOWN instead of TRUE|FALSE, if the
> extended boolean attributes all
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
[I'm hoping people'll refrain from making this a GPL thread]
Has anyone paid more than cursory attention to the recent announcements
about "OpenSource" alternatives to .Net? Would Perl 6 stand to benefit from
mindshare between these projects? Or are they just potential targets in the
same vein as
http://www.cminusminus.org/abstracts/c--con.html
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: Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]]
>
> Remember, the goal for Perl 6 is to allow several modules sharing
> the same name.
Don't you mean several modules sharing a common named interface?
Or are you refering to module, version, and author? Or something else?
From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
> On Tue, Aug 14, 2001 at 09:55:37AM -0500, Garrett Goebel wrote:
> > > There should be ONE calling style for each sub/method.
> > > Allowing this _will_ cause different people to use different
> > > calling styl
From: Graham Barr [mailto:[EMAIL PROTECTED]]
> On Mon, Aug 13, 2001 at 04:38:43PM -0700, Nathan Wiger wrote:
> > And allow flexible calling styles. For example, you might say:
> >
> ># import args() for argument validation
> >use Module::Interface qw/args/;
> >
> >sub my_func (@) {
>
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
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
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: 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: 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: 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: 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: Graham Barr [mailto:[EMAIL PROTECTED]]
> On Tue, Sep 04, 2001 at 03:03:04PM -0400, Dan Sugalski wrote:
> > At 01:58 PM 9/4/2001 -0500, Garrett Goebel wrote:
> > >From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > > > At 10:32 AM 9/4/2001 +0100, Piers Cawley wrot
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> The real question, as I see it, is "Should we look
> lexicals up by name?" And the answer is Yes. Larry's
> decreed it, and it makes sense. (I'm half-tempted to
> hack up something to let it be done in perl 5
> --wouldn't take much work)
No need,
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 10:32 AM 9/4/2001 +0100, Piers Cawley wrote:
> > > * Methods get their parameters passed in as a list in
> > > * PMC register 0, unless we can unambiguously figure
> > > * out their prototype at compilation time
> >
> >Will the subroutine know how
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]]
Subject: pads and lexicals
>
> Dave "confused as always" M.
>
I just wanted to say that I'm really enjoying this pad/lexical thread.
There's a lot of info passing back and forth that I don't believe is clearly
documented in perlguts, etc. I expect
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
st system not second.
And with a goal like he'll always have at least one voice screaming bloat
into the one ear, while someone else'll be asking for support for yet
another obscure language feature in the other. If list traffic is any
indicator, Dan's done a credible job navigating it
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
er
languages are second class citizens. But it would be nice to see the door to
the club house opened a little wider.
--
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]
" monitor (i think), which child
#1 had been using for games and web access. The SS5 has a debian linux
distribution installed and is available for a good home for the price of
postage.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Ree
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
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
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
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
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]
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
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
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
s performance degradation and in some
instances program failures.
And also interesting:
http://research.microsoft.com/users/jch/fftw-performance.html
Tuning 64-bit floating point code on x86 using gcc, Visual C, and Intel C
compilers
--
Garrett Goebel
IS Development Specialist
ScriptPro
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
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 [>*<]
--
; 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 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 '>>*'<<
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
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
hat it's
extensibility is a little cleaner and easier on the eyes. And that it is
less sensitive to whitespace.
So my humble advice would be to forget XXX, concentrate on the shortcomings
of POD, and perhaps merge whatever new extensible functionality you want,
like say support for cascadi
matic's: An Introduction to Testing
http://www.perl.com/pub/a/2001/12/04/testing.html
And there's the Perl QA sites:
http://qa.perl.org/
http://magnonel.guild.net/~schwern/cgi-bin/perl-qa-wiki.cgi
And Michael G. Schwern's:
http://magnonel.guild.net/~schwern/talks/Writing_A
Where the * signifies unordered, + ordered, > over, and < back? And if there
really is no reason to explicitly require the =back, then it'd look even
better:
*> level1
>> level2
+>>> level3
*>>>> level4
>>&g
Brent Dax wrote:
>
> Garrett Goebel:
> # =*> level1
> # =>> level2
> # =+>>> level3
> # =*>>>> level4
> # =>>> level3
> # => level1
>
> Too much punctuation, IMHO. If it ever does become
Andrew Wilson wrote:
>
> On Tue, Nov 12, 2002 at 12:16:53PM -0600, Jonathan Scott Duff wrote:
> > On Tue, Nov 12, 2002 at 12:06:13PM -0600, Garrett Goebel wrote:
> > > Or if the leading = really must be required:
> > >
> > > =*> level1
>
$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]
value. To illustrate this b101,
0101, 0x41, and 64:11 are all literal numeric integer representations of the
value more commonly represented in decimal notation as 65.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road
Stéphane Payrard wrote:
> On (14/11/02 14:29), Garrett Goebel wrote:
> >
> > It is interesting that no one has yet taken the time to
> > start defining the terms we're using.
> >
> > For instance what is a literal?
> >
> > Would everyone agree
Stéphane Payrard wrote:
> On (14/11/02 16:21), Garrett Goebel wrote:
> > Stéphane Payrard wrote:
> > >
> > > But when we say literal array, do we talk about the representation
> > > or the value?
> >
> > The representation of a fixed value.
prop/
> > taint/
> > array/
> > normal/
> > sized/
> > typed/
[...]
--
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]
From: Leopold Toetsch [mailto:lt@;toetsch.at]
> Garrett Goebel wrote:
> > From: chromatic [mailto:chromatic@;wgz.org]
> >
> >>Brent Dax had a nice suggestion for Perl 6 test organization.
> >>I like it tremendously.
> >
> > isn't it missing: t
1 - 100 of 233 matches
Mail list logo
