On Saturday 20 March 2010 at 12:23, Richard Hainsworth wrote:
In other words, I am suggesting a sort of mapping of the syntax of perl6
so that stable areas can us be used, perhaps avoiding instruments that
are not yet explicitly stable.
That assumes it's possible to know with sufficient
features.
For the curious, the Modern Perl Github repository has a book in progress; see
the tools/ directory for some hint of the necessary scaffolding:
http://github.com/chromatic/modern_perl_book/
(Writing a book isn't too far different from writing documentation; many
similar concerns
The Beyond and below are like a deep of ocean, and we the creatures
that swim in the abyss. We're so far down that the beings on the
surface -- superior though they are -- can't effectively reach us.
Oh, they fish, and they sometimes blight the upper levels with
points we
On behalf of the Rakudo development team, I'm pleased to announce the
December 2009 development release of Rakudo Perl #24 Seoul.
Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine
(see http://www.parrot.org). The tarball for the December 2009 release
is available from
On Saturday 24 January 2009 05:56:03 Nicholas Clark wrote:
And if left alone I can ramble that much, is anyone surprised
that chromatic can't manage to minute several people discussing it?
Amusingly, you were the one who didn't minute it; I wasn't on the call that
week.
-- c
On behalf of the Parrot team, I'm proud to announce Parrot 0.8.1 Tio
Richie. [1] Parrot is a virtual machine aimed at running all dynamic
languages.
Rat Creature #1: Comrade! We are about to feast! Quick, get your fat
carcass behind this bush and get ready!
Rat Creature
On Wednesday 20 August 2008 15:16:12 Aristotle Pagaltzis wrote:
It therefore seems necessary to me to specify dispatch such that
method calls in the Dog role invoke the original Dog role methods
where such methods exist. There also needs to be a way for a
class that assumes a role to
On Tuesday 05 August 2008 12:01:29 Larry Wall wrote:
I believe veto is giving the wrong idea here as something that
happens after the fact. What's the term for only allowing acceptable
candidates to put their names on the ballot?
disenfranchise
-- c
On Tuesday 05 August 2008 15:25:47 Bob Rogers wrote:
On Tuesday 05 August 2008 12:01:29 Larry Wall wrote:
I believe veto is giving the wrong idea here as something that
happens after the fact. What's the term for only allowing
acceptable candidates to put their names on the
On Sunday 01 June 2008 19:31:34 Paul Fenwick wrote:
Questions I'm seeking answers to are:
* Is there a document that describes the current p6l exception hierarchy?
My searching skills seem to be impaired today.
* Does anyone have any input they'd like to make before I start fleshing
out
They were walking to the Hemlock, the Rooster and the Mice, and the
Mice kept looking at one another, questioning.
We don't know what the future holds, do we? said Chauntecleer. The
Mice all shook their heads. They knew very little of anything. If,
said Chauntecleer, I
On Tuesday 06 May 2008 10:38:38 John M. Dlugosz wrote:
I have problems with a simple sum. The distance is artificially
inflated if you make lots of small derivation steps vs one large
change. The concept of derivation steps is ill-defined for
parameterized types and types that change
On Thursday 01 May 2008 06:35:12 John M. Dlugosz wrote:
chromatic chromatic-at-wgz.org |Perl 6| wrote:
This is why roles-as-types is so important: type inferencers can't infer
allomorphism because allomorphism relies on explicitly-marked semantic
meanings.
What is your nomenclature here
On Friday 02 May 2008 07:08:21 John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Then, since classes are open, the programmer can easily say
CGI does CGI::Simple;
That would be
class CGI is also { does CGI::Simple }
and means that CGI::Simple is a role,
On Friday 02 May 2008 11:55:54 Larry Wall wrote:
On Fri, May 02, 2008 at 11:15:34AM -0700, chromatic wrote:
: All classes imply the existence of a role of the same name.
If a role is derived from a class, it must of necessity be a snapshot
of the class, because roles are immutable, while
On Friday 02 May 2008 11:44:40 John M. Dlugosz wrote:
chromatic chromatic-at-wgz.org |Perl 6| wrote:
All classes imply the existence of a role of the same name.
Please justify that.
http://www.perlfoundation.org/perl6/index.cgi?perl_6_people
I could edit it into a Synopsis if you really
On Friday 02 May 2008 12:48:43 Larry Wall wrote:
On Fri, May 02, 2008 at 12:21:27PM -0700, chromatic wrote:
: I'm not sure which is best. Snapshotting at the time of first
: composition (or the first time someone says Hey, I provide that other
: class's role!) seems right though.
Or maybe
On Friday 02 May 2008 13:11:55 Larry Wall wrote:
On Fri, May 02, 2008 at 12:22:00PM -0700, chromatic wrote:
: I could edit it into a Synopsis if you really want.
Tweet! Foul on #17. Two shots!
What's the point of omnipotence if you can't swoop down from the rafters once
in a while
On Friday 02 May 2008 16:07:56 John M. Dlugosz wrote:
chromatic chromatic-at-wgz.org |Perl 6| wrote:
Why is there any difference in declaring classes and roles if a class
can be used as the target of either 'is' or 'does'?
You can't instantiate a role. You can instantiate a class.
When you
On Wednesday 30 April 2008 21:58:50 Brandon S. Allbery KF8NH wrote:
On May 1, 2008, at 0:53 , chromatic wrote:
correctness sense. Sadly, both trees and dogs bark.)
Hm, no. One's a noun, the other's a verb. Given the linguistic
orientation of [Perl 6], it seems a bit strange
On Wednesday 30 April 2008 08:56:24 Ovid wrote:
That was always my goal for roles in the first place. I'll be a
little sad if Perl 6 requires an explicit notation to behave correctly
here -- that is, if the default check is for subtyping, not polymorphic
equivalence.
I had initially
On Saturday 05 April 2008 17:10:57 Larry Wall wrote:
On Fri, Apr 04, 2008 at 09:41:26PM -0500, John M. Dlugosz wrote:
I suppose any object would do, it doesn't have to be but undefined, or
created using that Class{hash} syntax?
Possibly. Haven't really thought through the ramifications,
On Friday 04 April 2008 13:47:40 John M. Dlugosz wrote:
But, it is also stated that in derived and trusted classes, and even in
the class itself, $.a is an accessor call? As opposed to $!a which is
the direct access to the attribute. Is this accessor different from the
function form used
On Friday 04 April 2008 16:31:56 John M. Dlugosz wrote:
chromatic chromatic-at-wgz.org |Perl 6| wrote:
It shouldn't be.
So you are saying that...
I was talking about syntax.
In that case, why allow the variable-name form at all?
Because they're variables. Sure, they're instance
On Friday 04 April 2008 16:56:44 Audrey Tang wrote:
In other words, there needs to be no real hard attribute bar, no
matter if you call the bar method as self.bar(), $.bar(), or simply
$.bar.
That's what I was trying to say with uniform access principle, except that
Audrey's version is much
On Wednesday 26 March 2008 11:08:15 James Fuller wrote:
can I add a few unsolicited ruminations from a lurker;
* just release perl 6 now and move on
To what extent?
Larry just released Perl 5 some 13 and a half years ago, and there've been a
few patches applied to it in the past 24
On Wednesday 26 March 2008 12:26:35 James Fuller wrote:
I do not think that its right to release
perl6 for the language, but it might be 'right' to do for language
adoption no doubt cathedral / bazaar forces are in effect.
I don't follow this; can you elaborate?
-- c
On Tuesday 25 March 2008 10:50:15 Richard Hainsworth wrote:
What the perl6 language needs now is a systematic development plan, with
broad aims and clear goals that will lead to good quality software and
to the tools to enable ordinary programmers to use perl6 for a variety
of tasks.
Perl 6
On Tuesday 25 March 2008 10:50:15 Richard Hainsworth wrote:
What the perl6 language needs now is a systematic development plan, with
broad aims and clear goals that will lead to good quality software and
to the tools to enable ordinary programmers to use perl6 for a variety
of tasks.
Richard
On Thursday 21 February 2008 06:25:42 Joshua Gatcomb wrote:
Here is something to consider. Unless we can afford to fund an individual
full time with enough money for them to pay for their own health coverage
and other benefits, the amount of time they are volunteering is already as
much as
On Tuesday 05 February 2008 20:02:53 Mark J. Reed wrote:
Ah, macros, is there no problem you can't solve? :)
If my experience with the Perl 5 core is any guide, the problem of too many
macros.
-- c
On Saturday 26 January 2008 08:58:43 Larry Wall wrote:
That would cover most of the cases for English speakers using regular
nouns, but I wonder whether there's some kind of generalization that
would help for cases like:
say There was/were $o ox/oxen
That makes me wish for a
On Monday 07 January 2008 08:42:06 Trey Harris wrote:
Then we can have roles that describe cross-cutting behavior of various
OS's (like POSIX):
my trytolink;
give $?OS {
when OS::HasSymlinks { trytolink := *symlink; }
when OS::HasLinks { trytolink := *link; }
On Saturday 29 December 2007 13:35:00 Mark J. Reed wrote:
Ok, consider me duly chastised. Sorry for the sidetracking.
It's not a *bad* idea, but it's less important in my mind than getting useful
information on the wiki. Anyone who wants to pursue it can do so, but I'd
like to forestall a
On Thursday 13 December 2007 13:37:19 ispyhumanfly wrote:
Any questions? :)
Is it possible to see a list of tasks without the barrier of creating an
account, requesting an invite, or logging in? I understand that a little bit
of administrative overhead is useful, but I'd also like to see as
On Tuesday 11 December 2007 09:20:22 Paul Hodges wrote:
But on this general note, is there any current organization or location
where small problems are being parcelled out? I'd love to help, but my
time is as limited as everyone's If I could get small bites of work
to do, maybe I could
On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote:
I download pugs and parrot from
SVN repositories, written tests - one of which still hangs the
compilation of pugs. Indeed the test I wrote for pugs concerned the
ability of pugs to use existing CPAN modules. I have tried parrot
On Saturday 08 December 2007 06:50:48 Richard Hainsworth wrote:
Surely, some concentrated thought by the inventive and resouceful minds of
who lead this project should go into language utilisation and
popularisation.
My goodness, @Larry's pretty darn busy trying to build the core kernel of
On Thursday 29 November 2007 03:21:18 cdumont wrote:
By listening to you all, we shouldn't even think to implement file
access...
Please drop the sarcasm.
A programming language is made by humans and subject to the same evolutions
and bugs and in the end is alive and will die.
A
On Thursday 29 November 2007 07:07:18 James Fuller wrote:
I have been arguing that having some simple functionality, provided by
the core, would potentially harmonize usage across modules and promote
better understanding of code, in general, through consistent usage.
That didn't work for
On Wednesday 28 November 2007 10:59:30 James Fuller wrote:
I do not nec. agree with 'a particular grammer is not' part of the
core ... if that grammar is so common to every problem (like regex is)
then why not include it?
Because it's not necessary for getting and installing other extension
Jack had avoided looking into his sons' faces during this Oration, because he
reckoned they'd not wish to be seen with tears streaming down their faces.
But looking up at Jimmy now he saw dry eyes and a quizzical if impatient
phizz. Turning the other way, he saw Danny gazing distractedly at
On Monday 25 June 2007 00:57:18 Hakim Cassimally wrote:
Releasing a language without a useful, easily installable library bundle
could quite reasonably be construed as a stupid business practice.
Of course. Yet some dozen years later, the argument for keeping interfaces
such as File::Find
On Thursday 21 June 2007 15:23:38 Smylers wrote:
Has Larry yet decreed whether Web will be bundled with Perl 6?
I also like to proceed from the assumption that the only core modules should
be those required to install other modules.
-- c
On Friday 22 June 2007 11:07:35 Chas Owens wrote:
Please, god, no. Or at least make two distributions: Bare Perl 6 and
Perl 6. Many companies have a Only Core Perl policy. They refuse
to install CPAN modules because We don't trust them.
I think of this the same way I think of Do not drink
On Thursday 31 May 2007 17:36:40 Chas Owens wrote:
Except of course those poor schmucks who foolishly wrote code like
if (ref $arg eq 'HASH') { ... }
I know you're teasing, but it *would* be nice to see that sort of code just
magically go away.
-- c
As I sailed into Shadow, a white bird of my desire came and sat upon my
right shoulder, and I wrote a note and tied it to its leg and sent it on
its way. The note said, I am coming, and it was signed by me.
...
The sun hung low on my left and the winds bellied the sails and
On Monday 14 May 2007 04:28:15 Thomas Wittek wrote:
I'm not a friend of potential conflicts between built-in operators and my
identifier names (and especially the conflicts between scalar, aggregate,
type, and function names).
As I partially wrote Moritz, I
a) don't think that it's the
On Monday 14 May 2007 04:35:19 Thomas Wittek wrote:
BTW: Why do so much people say go away if you don't like it instead of
being open for ideas and discussing them from a neutral point of view?
Perhaps you're not a native English speaker, but running into the room and
saying Perl 6 doesn't
On Monday 14 May 2007 15:48:24 Thomas Wittek wrote:
But it should be no problem to put out a warning/error at runtime (or
maybe even at compile time) when a variable name clashes with a method
name.
Do you always know all of the method names in your entire memory space at
compile time?
-- c
On Sunday 13 May 2007 15:42:30 Thomas Wittek wrote:
What makes Perl hard to read is the excessive use of special characters
(/\W/).
It also makes Mandarin and other ideographic languages impossible to read. As
evidence I admit that, though I am very smart, *I* can't read them.
(Try to ignore
On Thursday 03 May 2007 03:06:43 Andrew Shitov wrote:
What is nedded is a very simple step:
Contributors.
-- c
On Tuesday 10 April 2007 18:51, Shlomi Fish wrote:
(Although it seems the most interesting promises made by parrot - fast
typeless code for example - are not going to be delivered, too).
Hmmm I haven't been closely following Parrot.
Despite this mention, this thread is off-topic for
On Monday 26 February 2007 11:29, Geoffrey Broadwell wrote:
Does Perl 6 on Parrot have Perl 5 connectivity?
Not until Perl 6 can use PIR code. After that, it depends on what you want to
do with the two.
If you can get Parrot::Embed compiled and running on your machine, Perl 5 can
have
On Saturday 24 February 2007 22:42, Richard Hainsworth wrote:
But while perl6 continues
its evolution, without a tangible end, few are going to dedicate time
and effort to write documentation for such as me. (eg. How out of date
are the Exegesis files?)
You could make a very similar argument
On Sunday 25 February 2007 12:56, Geoffrey Broadwell wrote:
As I mentioned in another thread, but didn't make clear in that email: I
don't need a finished spec. I need the *current* version of spec to
actually be mostly implemented.
The implementors want the same thing.
And if it's not
On Sunday 25 February 2007 13:57, Geoffrey Broadwell wrote:
I'm not trying to say that the implementors should rush either, nor am I
complaining about current status; I grok the dynamics of volunteer code.
I merely disagree with the spec is all-important crowd. I personally
have a preference
On Sunday 25 February 2007 12:40, Geoffrey Broadwell wrote:
What backends support packed native arrays at this point? And what's
the performance like?
Parrot does have ManagedStruct and UnManagedStruct PMCs for mapping complex C
structures. The syntax to define them is a little grotty, but
On Tuesday 20 February 2007 12:42, Larry Wall wrote:
'Course, if someone goes ahead and adds the Y combinator, one must
naturally begin to wonder what the YY combinator would be... :-)
Obviously it generates a function so anonymous that it can't even refer to
itself. I call it the depressed
On Saturday 28 October 2006 09:15, Larry Wall wrote:
My initial inclination is to say that where clauses in a signature
are only there for pattern matching, and do not modify the official
type of the parameter within the function body. However, on a subset
the where clause is there precisely
On Tuesday 03 October 2006 10:06, Aaron Sherman wrote:
Would there be such tools used in the core libraries? Maybe, maybe not,
we could discuss that. If they were implemented in the core libraries
would there be a universal no bondage flag that shut them off?
Probably, since that's something
On Wednesday 04 October 2006 01:05, jesse wrote:
One of the things that many shops have defected from Perl to Java for
is the additional handcuffs that Java provides for less-than-experienced
developers. Giving me the power to control what my team, or folks using
my language variant, do
On Wednesday 04 October 2006 12:09, jesse wrote:
Perhaps I'm misunderstanding what you mean by person writing the
program and person writing the libraries. In fact, I've _gotta_
be. I'd like to be able to put my strictures in a library rather than
forcing them into the main body of a
On Wednesday 04 October 2006 12:48, jesse wrote:
Ok. So, I think what you're saying is that it's not a matter of don't let
people write libraries that add strictures to code that uses those modules
but a matter of perl should always give you enough rope to turn off any
stricture imposed on
be able to turn the strictures back off.
chromatic, is that a fair paraphrase?
Yes.
I don't have any problem with that sentiment--if I were you and needed to
enforce some style on other programmers who work with me, I'd just tell
them to use my library and not unuse it. It's a human problem
On Monday 02 October 2006 08:58, Jonathan Lang wrote:
I wonder if it would be worthwhile to extend the syntax of roles so
that you could prepend a no on any declarative line, resulting in a
compilation error any time something composing that role attempts to
include the feature in question.
On Tuesday 29 August 2006 13:26, Jonathan Lang wrote:
Perl6 handles both object-orientation (through inheritance) and
role-playing (through composition).
What exactly does inheritance have to do with object orientation, except that
some OO systems support inheritance? Plenty of OO systems
On Friday 14 July 2006 00:30, Darren Duncan wrote:
This may go without saying, but ...
If $a === $b means what I think it does, then I believe that a
not-premature implementation optimization of === would be that it
always $a := $b if it was returning true, so that any future === of
$a and
Author: chromatic
Date: Sun May 21 14:11:09 2006
New Revision: 9305
Modified:
doc/trunk/design/syn/S06.pod
Log:
Minor typo fix.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod
On Thursday 11 May 2006 14:54, Smylers wrote:
What about :gappy, to indicate that there have to be gaps in the source
text at the points where there are gaps in the pattern?
I like this better. Forming a new compound word and then abbreviating it
seems confusing -- and I'm a native English
On Saturday 29 April 2006 21:50, Damian Conway wrote:
Is:
$antler. .bar;
$xyzzy. .bar;
$blah. .bar;
$foo. .bar;
really so intolerable, for those who are gung-ho to line up the method
names?
I'm still wondering what's awful about:
$antler.bar;
$xyzzy.bar;
On Saturday 29 April 2006 16:58, Yuval Kogman wrote:
On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote:
This would make the enormous semantic difference between:
foo. :bar()
and:
foo :bar()
depend on a visual difference of about four pixels. :-(
On Saturday 29 April 2006 18:29, Yuval Kogman wrote:
If dots looked like this:
then they would be invisible.
Use a laptop with a speck of dust in the wrong place in slightly wrong
lighting and the wrong four pixels might as well be invisible.
Precious few of @Larry deserve the nickname
On Wednesday 12 April 2006 00:06, TSa wrote:
Doesn't that discontinuity devalue the long dot? Its purpose is
alignment in the first palce. For a one char diff in length one
now needs
foo. .bar;
self. .bar;
instead of
foo .bar;
self.bar;
Or even:
foo.bar;
On Tuesday 07 February 2006 23:55, Yuval Kogman wrote:
Does this imply that we should think up this process?
Go ahead.
If I propose a concrete plan for the implementation of Perl 6 in a
layered fashion it will probably be even more overlooked.
I have no authority, and this is not something
On Tuesday 07 February 2006 13:28, Yuval Kogman wrote:
Right now the biggest problem in Perl 6 land is project management.
I disagree, but even if it were true, I don't think the solution is to add
more project management and design to partition the process into even more
subprojects of
On Tuesday 07 February 2006 14:17, Yuval Kogman wrote:
If we have more steps and clearer milestones for whatever is between
parrot and the syntax/feature level design implementation will be
easier.
Parrot has had such milestones for well over a year.
De-facto we have people running PIL on
On Tuesday 07 February 2006 15:56, Stevan Little wrote:
The Pugs project and the Parrot project have had very different goals
actually (at least Pugs did from the early days). Pugs aimed to be
able to evaluate Perl 6 code, as a way of testing the language
features and design. It did not
On Friday 20 January 2006 07:14, Rob Kinyon wrote:
I think this entire issue is rising out of the fact that very very few
people in this discussion are familiar with the design of the MOP.
Stevan and a few others are the primary movers and I'm lucky enough to
have been Stevan's sounding board
On Thursday 19 January 2006 21:53, Stevan Little wrote:
Okay, so when you say alternate storage then you mean that a class
like this:
class Foo {
has $.bar;
method new ($class, %params) {
$class.bless('p5Hash', %params);
}
method baz {
$.bar += 1;
On Thursday 19 January 2006 06:48, Rob Kinyon wrote:
Any practical programming language with structural subtyping will
probably let you create and use aliases for type names (so you don't
have to write the full form everywhere). However, the underlying type
system will only consider the
On Thursday 19 January 2006 13:10, Rob Kinyon wrote:
bless was a brilliant idea for Perl5. It's wrong for Perl6.
Perhaps you meant to write Tagging a reference with a package name worked for
Perl 5. It's wrong for Perl 6.
Certainly I can agree with that.
Yet this whole discussion feels like
On Wednesday 18 January 2006 20:02, Rob Kinyon wrote:
On 1/18/06, chromatic [EMAIL PROTECTED] wrote:
Answer me this then -- under your scheme, can I subclass a Perl 5 class
with Perl 6 code, instantiate the subclass, and use that object in Perl 5
code as if the subclass were Perl 5 code
On Thursday 19 January 2006 19:50, Rob Kinyon wrote:
Nothing. Just like it's not a problem if Perl6 uses one of the
Ruby-specific PMCs for storage. In fact, the alternate $repr idea is
specifically to allow for the use of foreign datatypes as storage.
Luke's excellent example is to use a
On Wednesday 18 January 2006 14:13, Stevan Little wrote:
Do we really still need to retain the old Perl 5 version of bless?
What purpose does it serve that p6opaque does not do in a better/
faster/cleaner way?
Interoperability with Perl 5 code.
Now if you want to write a p6opaque - Perl 5
On Wednesday 18 January 2006 17:57, Rob Kinyon wrote:
Well, for one thing, you can't write OO code in P5.
I'll play your semantic game if you play my what-if game.
I have a fair bit of Perl 5 code. Ponie works. I want to migrate my Perl 5
code to Perl 6 slowly. Everything new is Perl 6
On Wednesday 18 January 2006 19:11, Rob Kinyon wrote:
As for how that will be handled, I would think that it would be as follows:
- in Perl6, objects created in another language will be treated as
p6opaque (unless some other unbox is a more suitable $repr).
... and I specify this exactly
On Wednesday 18 January 2006 19:39, Rob Kinyon wrote:
No, you want to specify the $repr in CREATE(). But, p6hash will still
not be the same as a ref to an HV. Frankly, I think you're better off
letting Parrot mediate things the same way it would mediate Ruby and
Perl6 or Perl5 and Python.
On Monday 19 December 2005 05:06, Michele Dondi wrote:
Speaking of which:
| The connection between the language in which we think/program and the
| problems and solutions we can imagine is very close. For this reason
| restricting language features with the intent of eliminating programmer
On Friday 16 December 2005 22:25, Darren Duncan wrote:
At 10:07 PM -0800 12/16/05, chromatic wrote:
This is fairly well at odds with the principle that users shouldn't have
to bear the burden of static typing if they don't want it.
This matter is unrelated to static typing. The state
On Friday 16 December 2005 18:15, Darren Duncan wrote:
Therefore, I propose that the default behaviour of Perl 6 be changed
or maintained such that:
0. An undefined value should never magically change into a defined
value, at least by default.
This is fairly well at odds with the principle
On Mon, 2005-12-05 at 07:54 +, Luke Palmer wrote:
I wonder if there is a macroey thing that we can do here. That is,
could we make:
ok(1);
is(1, 1);
like(foo, /foo/);
Into:
ok(1);
ok(1 == 1);
ok(foo ~~ /foo/);
Can you do it without giving up the nice
On Wed, 2005-11-23 at 01:39 +0100, Leopold Toetsch wrote:
But my argument was: whenever you
start introspecting a call frame, by almost whatever means, this will
keep the call frame alive[1] (see Continuation or Closure). That is:
timely destruction doesn't work for example...
Destruction
On Thu, 2005-11-17 at 05:31 +0100, Daniel Brockman wrote:
This is a very valid concern, but the problem will not arise
unless people start mixing these two styles --- something
which is very obviously not a good idea.
That doesn't mean that people will avoid it, by accident or on purpose.
On Thu, 2005-11-17 at 07:27 +0100, Daniel Brockman wrote:
Yet you have the choice of where to put your braces, even
though the braces don't lend themselves to different tasks
depending on whether you put them on a new line or not.
You *don't* have the choice to use different types of braces,
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the
On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote:
I would prefer to use roles as they're closed by default, leaving
class to be my powertool, if I need the power.
I don't understand this desire; can you explain your reasoning?
(NB: closed here, as I use it, still *does not* correspond to
On Wed, 2005-10-26 at 19:22 -0600, Luke Palmer wrote:
But we find that many programmers make decisions that trade
readability and extensibility for an extra 1% of speed, even when they
are writing a command-line frontend to MPlayer[1]. If those people
are module writers, then we have a bunch
On Wed, 2005-10-26 at 14:52 -0400, Uri Guttman wrote:
LW == Larry Wall [EMAIL PROTECTED] writes:
LW One wants to coin a word like Qlass. Unfortunately qlass is
LW too easy to misread as glass. Oy veh, I'm getting notions of
LW the qlass is half empty for a partially instantiated
1 - 100 of 193 matches
Mail list logo
