list, but "return" is a strong contender.
Additionally, any predicate form cannot be a "normal function". You
might be able to define an &infix:, but getting to where you don't
need the {}'s on the LHS block, and getting a proper list on the RHS
gets rather abnormal.
Something that crossed my mind while writing this: Does
for { say } <== @a;
Work?
-- Rod Adams
al $WARNING = 0;
print "Windoze\n" or die "Can't print: $OS_ERROR";
}
Not exactly a fair comparison, since it's common to not "use English"
due to the $& issue.
I suspect that if that was not the case, it would be used more.
-- Rod Adams
it.
It's been established before that getting at _which_ values in a
junctions made the evaluation turn one way or the other is _not_
something that will be readily supported.
-- Rod Adams
Luke Palmer wrote:
Rod Adams writes:
Perhaps the easiest way to explain the difficulty here is to note that
executing a relational op (i.e. returning a boolean) value on a junction
argument returns a junction of boolean values.
Is that so? Does Perl6 have some fundamental law of
single interpreter should be more than
sufficient.
-- Rod Adams
t I'd like to see some examples.
FWIW, I believe that Patrick's example of the PGE returning matches
could be written with given/take (if it was being written in P6).
-- Rod Adams
John Macdonald wrote:
On Wed, May 04, 2005 at 03:02:41PM -0500, Rod Adams wrote:
If there are good uses for coroutines that given/take does not address,
I'll gladly change my opinion. But I'd like to see some examples.
FWIW, I believe that Patrick's example of the PGE returning
mizer. Or more likely, makes MMD
optimization a lot more important. But that's a p6i problem, not a p6l one.
Another way to interpret this post is "When is SMD preferred over MMD?
And is that enough to make it the default?"
If I'm missing something basic feel free to correct me.
-- Rod Adams
Larry Wall wrote:
In general it's probably a lousy idea to rely on #!/usr/bin/perl6 to
select language since you want the version number to select the
version of Parrot you're running, not the version of Perl.
One thing that occurred to me over the weekend is that we could fix all
the one-liners u
Luke Palmer wrote:
Admittedly, if you use == for everything, you can force string or
numeric comparison this way:
if +$a == +$b {...} # numeric
if ~$a == ~$b {...} # string
Hmm.
In my head, I would expect == to have implicit numification on the
operands (unless user-overloaded to some
Luke Palmer wrote:
Oh, sorry, wasn't clear. That's *if* eq was eliminated and == became a
polymorphic operator.
You're correct in terms of the current (and hopefully continuing) state
of things.
Went back and re-read your first post, and that is indeed what you were
saying, I just read it too
Smylers wrote:
Gabriel Ebner writes:
Joe Gottman wrote:
The zip operator is now the Yen sign (¥).
How are those without a US keyboard supposed to type this?
On Windows you can probably press Alt Gr then type in some number.
Close. AltGr-Minus. If you're using the US-Interna
s. If, however, you remap your keyboard (easily
doable in X and Win32, I'd assume Macs can as well), then the common
Unicode characters are an AltGr away. Thus, « one shifted keystroke
(AltGr-[), << is two shifted keystrokes (Shift-, Shift-,).
-- Rod Adams
Come the glorious age of Perl6, will hash slices be enhanced to allow
things like the following?
[EMAIL PROTECTED]'expected'} = [EMAIL PROTECTED];
Specifically, having the slice be something other than the last element.
This likely dictates having {} be able access a list of of hashrefs, not
jus
Brent 'Dax' Royal-Gordon wrote:
David Storrs wrote:
Well, at least that's a nice simple explanation. Why couldn't anyone
have explained it to me that way before? Unfortunately, it means that
continuations are a lot less useful than I thought they were. :<
Actually, I think you're underestimatin
Austin Hastings wrote:
--- Rod Adams <[EMAIL PROTECTED]> wrote:
A guess from my current understanding:
You're wanting to play with a database. You take a continuation. You
see
if have a database handle open and good to go, if so you do your
thing.
(can you then dismiss the conti
txt" :excl );
Not that having wrapper classes for file handles is a bad idea, it just
doesn't relate to what I saw being discussed.
Oh, and "TextFile" should be spelled "IO::File::Text", IMHO.
-- Rod Adams
Dave Whipp wrote:
"Rod Adams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Uhm, my impression was that most of the "huffmanization" discussion was
centered around declaring a file handle to be read only, write only,
read-write, exclusive, etc. Masking
s
available to open as arguements seems a much better idea to me. It's
"Open a file with these specifications", not "Open a file, and then
apply these specifications to it".
I do admit there is merit to your abstraction system, but IMO, it
belongs in a library.
-- Rod Adams
Austin Hastings wrote:
--- Rod Adams <[EMAIL PROTECTED]> wrote:
I think part of the "mental jam" (at least with me), is that the
read/write, exclusive, etc, are very critical to the act of opening
the file, not only an after the fact restriction on what I can do
later.
Bu
at to foo up."),
Quux::Xyzzy $xyzzy :doc("Xyzzy to foo bar with"),
+$verbose,
+$foo
} returns Array | undef {
# real code here
}
-- Rod Adams
;d want to be able to construct my own map like functions,
and have creating them with pipeline performance in mind to be easy.
Just a thought, since with the creation of ==> and <==, pipelining is
bound to become an even more common construct.
-- Rod Adams
Randy Sims's test case:
Aaron Sherman wrote:
On Mon, 2004-08-30 at 16:34, Rod Adams wrote:
@x = @y ==> map lc ==> grep length == 4;
I would think you actually want to be able to define grep, map, et al.
in terms of the mechanism for unraveling, and just let the optimizer
collapse the entire pipeline dow
Larry Wall wrote:
On Fri, Sep 03, 2004 at 05:45:12PM -0600, John Williams wrote:
: What happens when the Pascal programmer declares
:
: my int @ints is shape(-10..10);
:
: Does it blow up?
No.
: If not, does @ints[-1] mean the element with index -1 or the last element?
The element with ind
Larry Wall wrote:
I'm still thinking A is the first one and Z is the last one. Someone
talk me out of it quick.
I had thought about A and Z before my previous post. I dismissed it for
two reasons:
1) Using Alphas as an index for something that should be numeric can be
very confusing. Especially
Luke Palmer wrote:
Jonadab the Unsightly One writes:
Rod Adams <[EMAIL PROTECTED]> writes:
One solution I see to this would be to have a "lazy return" of some
kind, where you can send out what results you have so far, but not
commit that your execution is over and sti
for it, though I
suspect it may be lacking in the Impatience department.
(I need more sleep)
-- Rod Adams
e "Core support" needed
would already be there (I may be wrong.).
But it doesn't need to be core. A friendly side project, possibly
mentioned in the core documentation as a learning tool, would do the job
nicely. And it doesn't need to be discussed on p6i, p6l, or p6c, at
least not for a very long time.
Or we could just burn a RE parser into everyone's brain, as you
mentioned. That'd also work.
-- Rod Adams
nly don't want the language to loose the internal cohesiveness that
all languages need, and am suitably scared of "design by committee"... but
I'd like to think that there's something that could be done to help matters.
Comments?
Suggestions?
-- Rod Adams
PS -- I'm willing to commit several hrs a week to the effort.
At 10:40 PM 11/14/2003 -0800, chromatic wrote:
I'd really like to see people start turning the existing design
documents into story cards and programmer tests for Perl 6. That'll
make it much easier to implement the thing.
So basically go back through the existing Apoc/Exeg's and break it down
in
At 04:40 PM 11/24/2003 -0800, Michael G Schwern wrote:
I definately agree that this is used rarely enough that it should be a word
and not a single character.
"then" sounds too much like "if/then" which is confusing. Its exactly
the opposite from what you're trying to convey.
It also doesn't conve
Luke Palmer wrote:
Joe Gottman writes:
- Original Message -
From: "Jonathan Lang" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, December 20, 2003 3:41 PM
Subject: [perl] Re: Object Order of Precedence (Was: Vocabulary)
Larry Wall wrote:
If DangerousPet doesn't define a
PerlDiscuss - Perl Newsgroups and mailing lists wrote:
When the official release of Perl 6 is released and I start to write some
Perl 6 programs using Perl 5 modules, will I get any errors? How will this
be handled? Will all of the Perl 5 modules have to be ported over and
converted to Perl 6 code?
Dan Sugalski wrote:
They'll live. Python and Ruby both have a single global interpreter lock
and nobody much cares.
People won't move to parrot because of signal or thread support, or
because we give them a cookie. People will move to parrot because it
runs perl 6, or because it gives them cro
Uri Guttman wrote:
"RA" == Rod Adams <[EMAIL PROTECTED]> writes:
that is not the only way as i have pointed out. it is just a way that is
promoted heavily (like java). events if done correctly are generaly
faster than threads and use much less ram (no stack context created for
e
Uri Guttman wrote:
"RA" == Rod Adams <[EMAIL PROTECTED]> writes:
Except then the client wanted it to work under Win32, where I've
never trusted any of the pseudo-forks that perl did (esp with
Network I/O going on). So I rewrote the whole thing in a language
that supported th
Luke Palmer wrote:
Austin Hastings writes:
I think you guys may be talking at cross purposes. Robin, I think, is
talking primarily about coding, while Damian talks of reading.
Perhaps Damian's solution is a Unicode2Ascii perl script that emits formal
names, combined with the implementation in P
Austin Hastings wrote:
From: Rod Adams [mailto:[EMAIL PROTECTED]
Question in all this: What does one do when they have to _debug_ some
code that was written with these lovely Unicode ops, all while stuck in
an ASCII world?
That's why I suggested a standard script for Unicode2Asc
Here's my stab at a sort syntax, pulling syntax over from REs:
@out
<== sort key:ri($_->[2]), key:s($_->[4])
<== @in;
Basicly, you have a list of RE syntax like C values, whilch take
various modifiers to say how to play with that key, and then an expr on
how to generate the key given element $
generate a sortkey. Albeit considerably rare.
Also, I think there is utility in have a compare sub supported so that:
1) porting P5 code is easier. (a minor design rationale, but it exists)
2) people used to thinking in terms of compare subs (from C, P5, and
points of the programming universe) can still think that way.
3) most importantly to me, so that There's More Than One Way to Do It.
-- Rod Adams
::= Code(Any, Any) returns Int;
become
type Comparator ::= Code(Any, Any) returns Int
| '!' Code(Any, Any) returns Int;
where the '!' sets the reverse/descending trait?
So we could get things like:
@out = sort {!~ $_} @in;
@out = sort {!+ -M} @in;
@out = sort {! &complex} @in;
Overall, Damian's proposal looks very good.
Yeah Damian!
-- Rod Adams
PS -- Only pure and utter insanity would lead someone to not make string
the default sort comparator, and I don't think I've heard anyone here
mention they are in favor of doing anything else.
Damian Conway wrote:
Richard Nuttall suggested:
An alternative is to have "fill rightmost gaps" and "fill leftmost
gaps" on
alternate lines. This produces more balanced looking columns, so
they don't all look heavier on the left.
That's a *very* interesting idea. What do people think?
The Ve
Larry Wall wrote:
On Fri, Mar 05, 2004 at 06:45:58PM -, Rafael Garcia-Suarez wrote:
: Of course :) the main problem is not that CHECK blocks are executed
: late (just at the end of the compilation phase); it's that they're
: executed too early, notably in some persistent environment, notably
:
201 - 243 of 243 matches
Mail list logo
