Re: Why do users need FileHandles?
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> writes:
>> hopefully without dependencies on external non-Perl things like gcc).
>
> Don't think it'll be possible for modules that have C components,
I'm really hoping Perl6 will be sufficiently powerful that C
components won't be needed or wanted.
>> Oh, and here's me resisting the urge to suggest that use ought to
>> automatically install from the CPAN anything that isn't present, as
>> a core behavior right out of the box.
>
> Security nightmare.
*shrug*
Running untrusted code (Perl or otherwise) on your system that you
haven't examined first is inherently a security nightmare. If it
wants to download things from wherever and install them it can
(assuming that you're running under an account that has privileges to
install or at least has its own install location just for that
account), and that's not all it can do, not by a longshot.
Or did you mean that someone might compromise the CPAN in order to
compromise all the systems downloading stuff from it? Again, that's
already true now, in theory. (More likely, a single mirror would be
compromised. One would hope it would be discovered quickly.)
However, I wasn't serious about making use automatically install.
Well, not altogether serious. CPAN.pm or something like it is really
almost good enough, and what it lacks can be added in without any
change to the behavior of use. Installing once before you use is
really not a very large burden in the scheme of things.
I was, however, very pleased to hear that we won't have to reinstall
half the contents of the CPAN every time we upgrade Perl or Parrot.
Definitely looking forward to that improvement.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"[EMAIL PROTECTED]/ --";$\=$ ;-> ();print$/
Re: This week's summary
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> writes:
[surreal numbers]
> Care to explain what those are, O great math teacher?
Surreal Number theory was an attempt in the latter half of the
twentieth century to unify several existing sets of numbers (including
the complex numbers, generalized epsilon numbers, and cardinalities)
into a single notation and define addition and multiplication
operations on them that would be isomorphic to the standard addition
and multiplication on the complex numbers. Knuth's book on them is
very interesting and a good read.
I don't know whether surreal numbers ever really caught on in the
mainstream mathematics community or lead to any real advances in
number theory. Most undergraduate math curricula don't seem to teach
them as near as I can tell, except perhaps in the collateral reading.
One problem with them is that the notation is rather unwieldy. They
are interesting conceptually, however, despite their apparent lack of
practical usefulness, and serve as a proof of concept for the notion
of a unified number theory, although in practice the group theory of
modern algebra seems to unify things better, IMO.
Hey, you asked.
Surreal numbers in Perl would be way more cool than practical.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"[EMAIL PROTECTED]/ --";$\=$ ;-> ();print$/
Re: String interpolation
David Green wrote: I was also going to say something tongue-in-cheek about Unicode quotation marks, but curly-quotes could actually be quite useful. Reasons not to use them as anything but synonyms for normal double quotes: 1) They look too much like each-other. 2) They look too much like normal quotes. 3) Some editors will give you one when you want the other. - David ³wondering how likely curly-quotes are to come out right² Green 4) Many people think they're in Latin-1, but they aren't, they're only in Microsoft's perversion of Latin-1. -=- James Mastros
Re: This week's summary
On Mon, 26 Jul 2004 10:29:15 -0700, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: > The Perl 6 Summarizer wrote: > > The infinite thread > > Pushing onto lazy lists continued to exercise the p6l crowd (or at > > least, a subset of it). Larry said that if someone wanted to hack > > surreal numbers into Perl 6.1 then that would be cool. > > Care to explain what those are, O great math teacher? > > *ducks* Just for those following along from home: http://www.amazon.com/exec/obidos/tg/detail/-/0201038129/qid=1090866301/sr=1-1/ref=sr_1_1/103-7396197-3600620?v=glance&s=books - Kurt
Re: This week's summary
On Mon, Jul 26, 2004 at 10:29:15AM -0700, Brent 'Dax' Royal-Gordon wrote: > The Perl 6 Summarizer wrote: > > The infinite thread > >Pushing onto lazy lists continued to exercise the p6l crowd (or at > >least, a subset of it). Larry said that if someone wanted to hack > >surreal numbers into Perl 6.1 then that would be cool. > > Care to explain what those are, O great math teacher? Disclaimer, I am no math theacher. :) This is a very interesting class of number that can be used to modelize games. It has designed by the _other_ Conway, the one of game of life fame. The expression "surreal number" was coined by Knuth. For more info, the wikipedia is your friend: http://en.wikipedia.org/wiki/Surreal_number For the full story, read the book "Numbers and Games". I have ordered it a few days ago so I can't comment on it. > Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> -- stef
Re: This week's summary
The Perl 6 Summarizer wrote: The infinite thread Pushing onto lazy lists continued to exercise the p6l crowd (or at least, a subset of it). Larry said that if someone wanted to hack surreal numbers into Perl 6.1 then that would be cool. Care to explain what those are, O great math teacher? *ducks* -- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Why do users need FileHandles?
Larry Wall wrote: Sounds like you're confusing #3 with #4. Larry Could be. Does 3 mean at install time, you down load the latest of the 'supported' packages from the CPAN alike or is it more like versioned snapshots? (Possibly yet to be decided?) It's the idea of a standard library being open to daily change that scaring me most at the moment. If that's not likely, then me other concerns, well, aren't. Dan
Re: String interpolation
On 7/21/04, Brent 'Dax' Royal-Gordon wrote: >Amen. Please don't steal unnecessary metacharacters in qq() >strings--although I still think we should keep it, @ causes a lot of >problems. That's why my suggestion would be to use a character that already has a special meaning in double-quoted strings: ". Well, we probably need a bit more than that, so maybe "~ and ~" for scalar context or ", and ," for list context, or some such. No new metacharacters and you could put just about anything -- hashes, subs, small island nations -- inside the "~...~"! Actually, I've been pondering this incessant urge to interpolate -- I have to admit, I suffer from it as much as anyone, but when I ask myself why, I can't come up with a good answer. Being able to stick a simple $foo in a string is great, but sometimes I catch myself interpolating when, uh, extrapolating would not only be much more readable, but occasionally it would even mean less typing. At any rate, I'm leaning more and more to the sparse, simple proposals (the ones that I might actually be able to remember). Normally, I'm all for cramming everything into The Core(TM) up to and including Sinks::Kitchen on the grounds that if you don't like it, you don't hafta use it. However, this doesn't apply to the rules for interpolation because even if I decide that I'll never interpolate anything anywhere, I still have to remember what all the rules are so I don't forget to escape the right things. Hm, every time I go to post this, I think of something else. Now I'm recognising that I've been labouring under a false dichotomy: we don't have to have simple rules for interpolation OR complex rules. This is Perl, why can't we have both ways to do it? q// -- no interpolation qq// -- moderate interpolation: $foo, @bar[$none], %bat«man» qqq// -- ultimate interpolation: anything not A-z0-9 has a special meaning =) Except it's probably qi instead of qqq, or maybe qq does lots of interpolation and the new guy does less. And q, qq, qqq, ', ", <<, etc. are probably all just abbreviations for "quote :various :interp :adverbs" anyway. I was also going to say something tongue-in-cheek about Unicode quotation marks, but curly-quotes could actually be quite useful. They're a twistier, more complex version of plain old straight quotes, but most interestingly they come in left-handed and right-handed versions. So you might nest them to indicate alternating literal and interpolated values. Erm... or maybe not. But I'm sure there's some way to put them to good use. - David ³wondering how likely curly-quotes are to come out right² Green
Re: Why do users need FileHandles?^H^H^H^H^HCore modules?
On 7/23/04, Luke Palmer wrote: Not necessarily. Glop, on which I'm doing a presentation at OSCON (have to plug it sometime ;-), "Game Language on Perl, you say? Goodness, what's that??" Sorry. Got tired of English. =) There's a lot of stuff like that. Way too much to include in a distribution. That's why we're going to distribute close to nothing with Perl 6 in order to force vendors to install a decent module suite. It's likely that CPAN will have a Bundle::EYEWTIBWATA. [1] Well, it certainly makes sense to me to have perl itself as minimal as possible, as long as there's an "official" bundle so that you can make reasonable assumptions about what "everyone" has. I think with a sensible auto-inclusion system (really, they're quite nice--if it can be done at compile time), we'll be able to keep things out of core and still make them feel like they're in core. There's something to be said for modules like that. Yup, something very good. And there's our second system syndrome. Fortunately, Perl is embracing its second system syndrome. Works for me. Anyway, Perl already got a complete rewrite for P5, right? So this would actually be Third System Syndrome, and thus we've nothing to worry about. (I'm not worried, anyway.) -David "impatient, maybe, but not worried" Green
Re: xx and re-running
Larry Wall wrote: The rand function may be a bad example, since it's by nature a generator, and you should maybe have to work harder to get a single value out of it. We haven't really said what <$fh> xx 100 should do, for instance. I guess the real question is whether xx supplies a list context to its left argument (and whether rand pays attention to list context). These might produce very different results: @foo = (rand); @bar = (+rand); On the other hand, history has rand producing a scalar, so arguably we should stick with that. One supposes that it's not entirely unreasonable to have rand in list context produce an infinite (lazy) list of random numbers, successively drawn from the generator. The results of @foo = *(rand); (if the syntax is right) in that case would of course be in the 'enough rope to hang yourself' category. But it might be handy to be able to say my ($rand1, $rand2, $rand3) = (rand)[4..6]; although I'm sure some would argue that this is needlessly obfuscated, and that my ($rand1, $rand2, $rand3) = (rand, rand, rand); would be better. Maybe it would. This random thought was brought to you by the demons of lunchtime idleness.
This week's summary
The Perl 6 Summary for the week ending 2004-07-25
Monday morning, all's well, and Piers sits down at his desk to bash out
another in his ongoing series of Perl 6 Summaries.
I've just realised that I missed noting the second anniversary of my
writing these summaries. It came up a month ago. On my last anniversary
I hoped I wouldn't be celebrating many more of them before we have a
real, running Perl 6; I'm still hoping. It looks like we may well have a
real, running Python interpreter on Parrot before Perl 6.
But we won't have it this week. Read on.
Pie-thon!
First, the bad news. Dan's conceded.
Now, the good news. Dan and Leo still got an awful lot done in a
surprisingly short time; who knows where we'd be if Dan hadn't been
stuck without a working laptop for most of June. In 5 weeks, we went
from nothing at all running to having four out of seven running, and 3
of those running faster than Python. Leo estimated that, once everything
was done, Parrot should be averaging about twice the speed of Python.
Next week (or possibly the week after) should see some post mortem
documentation from Dan and Leo discussing what they've learnt from the
exercise, and what needs to be done to get a 'proper' python
implementation up on Parrot.
So yes, Dan's going to get a pie in the face and be out a round of
drinks. If you're at OSCON, you might like to drop in on the Python
lightning talks and watch.
http://xrl.us/ciwi
Cygwin JIT problems
Joshua Gatcomb pointed out that JITted programs were dumping core on
Cygwin. Again. He and Leo tracked down a problem with the flags used on
the cygwin version of GCC. Joshua made a plea for experienced Cygwin
programmers to help out with issues of getting various things working on
the Cygwin parrot. He also called himself a 'bumbling idiot' but none of
us (apart, possibly, from his wife) believed him.
The whole and everything
Leo and Dan had a long discussion about a proposal of Leo's that Dan had
rejected without commenting on. Leo's not exactly happy about Parrot's
subroutine call speed and had proposed something which he thought would
make things go faster. Dan disagreed, and pointed out that it was
actively thread dangerous (there's a difference between not optimizing
for threads and not making threading possible).
In a lighter hearted part of the thread, Larry suggested embedding
python in Parrot as a way to get all the pie-thon tests running at least
as quickly as python. Leo hacked something up which piped the Python
code to python itself. But we're too honest to do that at OSCON.
http://xrl.us/ciwj
Parakeet 0.1
Michel Pelletier announced the release of Parakeet 0.1, a small Parrot
language which he hopes will eventually expose all of the OO features of
the Parrot VM. Judging by the description he posted, it's a fascinating
Forth like language. Kudos to Michel.
http://xrl.us/ciwk
http://xrl.us/ciwm
Meanwhile, in perl6-language
The infinite thread
Pushing onto lazy lists continued to exercise the p6l crowd (or at
least, a subset of it). Larry said that if someone wanted to hack
surreal numbers into Perl 6.1 then that would be cool.
Do users need FileHandles?
Remember Dave Whipp's proposal to get rid of user visible filehandles in
favour of something like tied scalars? It sparked a good deal of
discussion this week. A few people were pro, a few anti, with Larry
seeming to position himself somewhere in the middle.
http://xrl.us/ciwn
The mathematics summary
Austin Hastings made me laugh when, following my announcement that I'm
off to train to be a maths teacher, he wrote a spoof 'Mathematics
summary'. Thanks Austin.
http://xrl.us/ciwo
String Interpolation
The string interpolation subthread of last week broke out into it's own
first class thread this week. Larry said that he was seriously
considering incrementing the Ruby-o-meter some more by saying that the
*only* interpolators in double quotes would be
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{ EXPR }
where the last provides a list context to "EXPR". Damian thought that
the current solution with "$(...)" and "@(...)" was still the best way
to go. He didn't relish having to escape every "{" double quoted strings
(code that writes code for execution by "eval" is hard enough to read
without a whole bunch of *extra* quoted characters being required).
As is usual with p6l, the discussion was wide ranging and touched on a
whole bunch of other entertaining subjects. He who must not be
capitalized, chromatic brought up curried and first class roles, and
Larry shied away from allowing the (IMHO) eminently sensible
$foo does $bar
Where do we stand now? Well, I can safely say t
Re: String interpolation
Damian Conway <[EMAIL PROTECTED]> writes:
> I can't say I'm keen on making {...} special in strings. I felt that the
> $(...) and @(...) were a much cleaner and more general solution. The
> prospect of backslashing every opening brace in every interpolated
> string is not one I relish.
Maybe we could write macros to provide a Lispish 'metaquoted'
environment for when one is writing template code which wouldn't
interpolate *anything* unless it was in C<$(...)> or C<@(...)>.
Re: String interpolation
Larry Wall <[EMAIL PROTECTED]> writes:
> On Tue, Jul 20, 2004 at 11:00:39PM -0700, chromatic wrote:
> : On Tue, 2004-07-20 at 19:35, Luke Palmer wrote:
> :
> : > The New Way (tm) to do that would probably be sticking a role onto the
> : > array object with which you're dealing:
> : >
> : > my @foo does separator('//') = (1,2,3,4,5);
> : > say "[EMAIL PROTECTED]"; # 1//2//3//4//5
> :
> : Shh, no one's let slip the idea of curried roles yet! I'm not even
> : certain A12 mentioned parametric roles, let alone first-class roles.
>
> Well, A12 did talk about parametric roles, but I glossed over the
> first-class roles a bit. I didn't want to scare people with
>
> $foo does $bar
>
> though, of course, there's no reason in principle you shouldn't be able
> to do that as a run-time operation. You just can't instantiate a role
> object. The murky area in the middle is, of course, how you specify
> an initial value aimed at the attributes of a particular role without
> creating a "real" object containing just those values. Passing around
> lists of pairs is probably good enough for that, as long as you can
> keep straight which list of pairs is intended to initialize which
> roles.
I really hope you change your mind about this; the sooner I can get
that wild and crazy list of pairs nicely stashed in their appropriate
role objects, the happier I'll be about the resilience of my code.
