Friday 13 February 2004 15:02, Dan Sugalski wrote:
>
> If you're *really* looking to get fancy, why not just allow the
> sort specification to be done with SQL? Comfortable,
> well-understood, already has a decade or so of stupid things welded
> into it [...]
>
> Heck, you could even unify map, gr
Viernes 19 Marzo 2004 13:08, Andy Wardley wrote:
> I'm so happy! I just found out, totally by accident, that I can
> type the « and » characters by pressing AltGr + Z and AltGr + X,
> respectively.
>
> Apologies if this is common knowledge, but it was news to me, and I
> thought I'd share this lit
Miércoles 14 Abril 2004 14:18, Juerd wrote:
> I propose to use ` as a simple hash subscriptor, as an alternative
> to {} and <<>>. It would only be useable for \w+ keys or perhaps
> -?\w+. As with methods, a simple "atomic" (term exists only in
> perlreftut, afaix, but I don't know another word to
erators) is way too big for its value. On the other hand,
a RFC 207-like notation adds a lot more power with a single
addition to the language.
Just my 5 cents ;-)
Angel Faus
[EMAIL PROTECTED]
language (I really hope so) and I can
choose which way to go I am happy.
The whole point was about economy of language constructs, but that's perl,
and in perl free will is more important than economy, isn'it?
---
Angel Faus
[EMAIL PROTECTED]
vLex.com
""
Description:
tors, and perl6 is doing a great job of taking the coolest things
of other languages and integrating them into a choerent design, so i do
have a hope. [:)]
This is of course related to Ruby's iterators, that take a somehow
opposite solution to solve a similar problem.
----
Sorry for the 4 times posts, i was testing a new mail program and it
didn't prove too good.
Now i feel so ashamed :-[
-angel
by_size =
@files.map -> $file { [$file, -s $file] }
.sort -> @a, @b { @a[1] <=> @b[1] }
.map -> @pair { @pair[0] }
--
Angel Faus
[EMAIL PROTECTED]
Simon wrote:
:> Have you an idea about what will be the 'final'
:> parser for the Perl 6 compiler ? (LALR(1), like Perl 5 ?)
:
:Yep, LALR1, probably yacc generated.
I recall reading somewhere that Perl6 was going to be parsed by something
very much like Parse::RecDescent, just that faster.
¿has
> my Complex $c = 3+4i;
> my Complex $d = 4i;
> my $plain = $c / $d;
>
> Does $plain (which is actually '3' after reducing) get promoted to
> Complex, or does the result from the division get demoted?
In a related matter, computer languages with Symbolic Mathematics
capabilities, like Mapple, le
>> my $plain = $c - $d : Math::Complex # 3.0 + 0i
>> sqrt(2 : Math::Integers) # -> exception or not-a-number
>Not a bad idea,. I beleive that the perl6 adjective operator
>(for functions) will be a semicolon, not a colon. I'm not
>sure how it is planned to apply it to operators.
>
>Its a
Hi,
I was reading Damian's new excellent diary entry in which he explains the
new currying syntax for Perl6.
(For the lazy ones it's reachable at
http://www.yetanother.org/damian/diary_latest.html)
This new feature allows to partially fill place-holder functions, such as:
my &div = {$^x / $^
Larry said:
> BTW, latest leaning is toward = rather than //= for parameter
> defaults, ...
Horray!
Sorry. Couldn't resist. :-)
-angel
"Simple men are happy with simple presents"
Hi,
Many thanks Michael, this is very useful, really. I had lost all the
OO discussion and this document is very helpful.
I really like the part of context transformations, I hope something
like this gets in.
Just a silly note:
> Recipe 1.9: Using Subroutines as Objects
>
> Problem:
> You w
> Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate
> in the set of rational numbers. The IEEE may say otherwise.
Mathematically, 1/0 is whatever you define it to be.
And it is perfectly correct to assume that operations happen in the
extended real line, and thus that 1/0 i
>
> > Mathematically, 1/0 is whatever you define it to be.
>
> Well, sure. That's as axiomatic as saying, "mathematically, the
> number one is whatever you define it to be." But a mathematical
> system that has a definition which is inconsistent with the rest of
> the system is a flawed one. If
>
> At the moment I like "like" the best, actually...
>
"like" is beautiful for old-style regex matching, but I find it
confusing for the new smart abilities:
$varlike Class:Foo # $var is instance of Class:Foo
$item like %hash # %hash{$item} is true
$digit like (0..10)
Speaking about macros, I renember reading somewhere something about
Scheme hygenic macros, but i didn't really understood it.
Do they solve the maintenance problems of Lisp macros? Would they be
applicable to perl?
Thanks for any tips,
-angel
> And maybe:
>
> A bitwise operator is just a logic operator scoped to a set of
> bits.
>
> That's why I can't accept a characterization of
>
> +&+|+X - bitwise operations on int
> +&= +|= +X=
>
> ~&~|~X - bitwise operations on str
>
LW said:
>
> :<...>- readline
>
> Iterate interator.
>
Couldn't we go the python way and assume that <..> is implicit in
"for" statments:
$fh = open(..);
for $fh { # instead of for <$fh>
print $_;
}
For explicit iteration, we could well do just with a ".next" me
Wednesday 30 October 2002 22:08, Michael Lazzaro escribió:
> On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
> > for @a; @b -> $x is rw; $y { $x = $y[5] };
>
> I agree that it's an eyeful. How many of your issues could be
> solved if the above were just written:
>
> for
> We started off with an intense RFC process. This produced many good
> ideas, not-so-good ideas, and ideas with potential but desperately
> needing polish. If you'd like a recap, you might try MJD's article
> on the subject (http://www.perl.com/lpt/a/2000/11/perl6rfc.html).
> One of the major thin
>1) We find a team of volunteers who are willing to "own" the
> task of converting each Apocalypse into a complete design. If
> nobody wants to write the Perl 6 user manual, then we might as well
> give up and go home now. So far we only need to find four, though,
> so it Might Just Work.
I w
Damian Conway wrote:
>
> The formulation of coroutines I favour doesn't work like that.
>
> Every time you call a suspended coroutine it resumes from immediately
> after the previous C than suspended it. *And* that C
> returns the new argument list with which it was resumed.
>
> So you can write th
Michael G Schwern wrote:
> and that's just entirely too much work. I'd love to be able to do
> it with a grep like thing.
>
> (@switches, @args) = seperate /^-/, @ARGV;
>
> seperate() simply returns two lists. One of elements which match,
> one of elements which don't. I think Perl 6 will
> I have to wonder how many people actually like this syntax, and how
> many only say they do because it's Damian Conway who proposed it.
> And map/grep aren't "specialized syntax", you could do the same
> thing with a sub with a prototype of (&block, *@list).
I have to say that I am not speciall
Damian Conway wrote:
> But large projects -- where typing will be most important --
> *can't* deal with that. That's the point of typing: to specify and
> enforce interface contracts. At compile-time if at all possible.
One quick question about this. If I write:
sub foo (Bar $f) {..}
my $x
Friday 14 March 2003 20:06, Michael Lazzaro wrote:
> 3) If an "untyped" var is used for a typed parameter, a simple
> dataflow analysis is used to determine whether the compiler can
> guarantee that, at that point, an "untyped" var will _always_
> contain values of a known, specific type. If so, t
> block. Perhaps we should just go with that:
>
> property $foo = 0;
>
> Or whatever word we choose, I don't care:
>
> prop $foo = 0;
>
What about:
prof $foo;
$foo = 0;
Is this equivalent to "prof $foo = 0"? If it is not, I would claim
this to be a major violation of the principl
29 matches
Mail list logo
