Q: string_bitwise
With ICU installed we have now a rather complete support for unicode
string manipulation (byte, codepoint levels).
Still todo is string_bitwise_{or,and,xor}.
What should happen, if charsets, or encondings don't match, if encoding
is utf8 or utf16/ucs2, ...
I think there are basically two options:
1) throw exceptions *)
(which combinations are valid?)
2) just do it and mark the resulting bit mess as binary
*) any allowed operations would still produce binary strings (except
maybe latin1 latin1 -> latin1).
Any thoughts?
leo
Re: What's the latest on Iterators?
Larry Wall a écrit :
| On Fri, Nov 11, 2005 at 08:42:44AM -0500, Joe Gottman wrote:
| : Do functions like map and grep, which in Perl5 return lists, return
| : Iterators in Perl6?
|
| A list may contain iterators. Lists don't eagerly flatten in Perl 6.
|
| : Can an Iterator be passed to a function (like map and grep again)
| : that requires a list as an input?
|
| Certainly. You can pass as many iterators as you like. The range object
| is your prototypical iterator, and you can say:
|
| @results = grep {...} 0..9, 20..29, 40..49;
|
| The list that grep is returning can also function as an iterator, so
| @results isn't necessarily "all there" after the statement executes.
|
How can Perl6 can consistently cope with side effects if it is not
specified when evaluation is lazy or strict? Is there a trait to say
that a function (here the grepping predicat) does not have
side-effect or is also really functional (so as to permit various
optimizations)?
Ate they pragma to say, "from here every function that will be defined will
by default functional" or "every parameter evaluation will be lazy":
use fun;
use lazy;
sub foo {$a } { ... } # functional and lazy
sub notfunctional($a) isnot fun {...) # can we unset a default attribute?
no fun; # use strict has another meaning btw.
...
use fun, lazy; # also can we do use bundling?
More generally I am worried of the mix of lazy and strict behavior in
the presence of all sorts of side effects that would happen in a random
order depending of the parameter evaluation order.
btw, for strict functions, is the left to right evaluation of
parameters guaranteed?
|
| Larry
|
--
cognominal stef
Parrot Fink build
A visitor on #parrot just asked if we had a fink build (which we don't). Before I bother the fink folks directly, is there anyone listening here who can help us put a fink build together?
[perl #37664] [TODO] created autogererated files read-only
# New Ticket Created by Leopold Toetsch # Please include the string: [perl #37664] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37664 > Not the first time I or somenone else ran into the problem of editing an autogenerated file. Creating these files r/o would prevent from accidental changes. Thx, leo
Re: What's the latest on Iterators?
On Sat, Nov 12, 2005 at 03:05:53PM +0100, Stéphane Payrard wrote:
: Larry Wall a écrit :
: | On Fri, Nov 11, 2005 at 08:42:44AM -0500, Joe Gottman wrote:
: | : Do functions like map and grep, which in Perl5 return lists, return
: | : Iterators in Perl6?
: |
: | A list may contain iterators. Lists don't eagerly flatten in Perl 6.
: |
: | : Can an Iterator be passed to a function (like map and grep again)
: | : that requires a list as an input?
: |
: | Certainly. You can pass as many iterators as you like. The range object
: | is your prototypical iterator, and you can say:
: |
: | @results = grep {...} 0..9, 20..29, 40..49;
: |
: | The list that grep is returning can also function as an iterator, so
: | @results isn't necessarily "all there" after the statement executes.
: |
:
: How can Perl6 can consistently cope with side effects if it is not
: specified when evaluation is lazy or strict?
It is my conjecture that it is not necessary to be totally consistent
about that most of the time, as long as people learn that list
context is consistently lazy by default (though the granularity of
that laziness is unguessable), and as long as we try to minimize
unnecessary side effects in the design of the rest of the langauge.
But people are already used to dealing with lazy evaluation of
things like file handles in Perl 5, and can know when they are
unsure of the order of evaluation, and install sync points to
compensate. That's really all a close is, after all. Or a
slurp, for that matter.
So Perl 6 has a standard for either the caller or callee to turn
off laziness, and in both cases it's the "steamroller" operator **.
It basically installs Perl 5 semantics for the rest of the list.
For example, this is guaranteed to have the side effect of running
out of memory before it starts to print anything:
print **1...;
: Is there a trait to say
: that a function (here the grepping predicat) does not have
: side-effect or is also really functional (so as to permit various
: optimizations)?
The "lazy" trait is the presence of an ordinary (non steamroller)
slurpy array in the signature. If I recall, Pugs already makes use
of an "is pure" trait that specifies no side effects, but it's also
the case that "is cached" implies pure functional behavior. On the
other hand, it's probably something the compiler should be figuring
out anyway, since it will probably be more honest than a person about
when it's guessing.
: Ate they pragma to say, "from here every function that will be defined will
: by default functional" or "every parameter evaluation will be lazy":
:
: use fun;
: use lazy;
:
:sub foo {$a } { ... } # functional and lazy
:
:sub notfunctional($a) isnot fun {...) # can we unset a default attribute?
:
: no fun; # use strict has another meaning btw.
: ...
: use fun, lazy; # also can we do use bundling?
Such pragmas are certainly possible, but the default of scalar context
being nonlazy and list context being lazy feels about right to me, as
long as we provide easy ways to override. The ** in list context will
force evaluation of lazy arguments, while in scalar context, junctions
and hyperoperators implicitly declare that ordering doesn't matter
for that particular operation.
: More generally I am worried of the mix of lazy and strict behavior in
: the presence of all sorts of side effects that would happen in a random
: order depending of the parameter evaluation order.
Welcome to the world of parallel programming, and remote objects,
and software transactional memory, and virtual timelines. The entire
universe runs on side effects happening in random order. We'll have to
learn how to balance out determinism with efficiency, and unfortunately
we don't know of any efficient way to be deterministic except in
certain specific cases.
: btw, for strict functions, is the left to right evaluation of
: parameters guaranteed?
Yes, for some definition of "evaluation" that may or may not imply
final resolution of all side effects. You still probably shouldn't
depend on
print $i++, $i++;
working any particular way, despite the fact that it works consistently
in the one and only implementation of Perl 5.
And if I'm wrong about all this, it'll still be easy to add a pragma
that implies ** on every list.
Larry
Re: Parrot Fink build
I use fink for ease of installing dependencies(imagine the annoyance of trying to install gimp when you don't have any of it's dependencies and don't know which ones you need), and I could try making an info file for parrot. One problem that I can already see is the tree that parrot creates for installing. You can specify the prefix, but nothing else for all the other directories, which can things messy to install them into /sw. I don't even install parrot into my path, but I do alias to it. On Nov 12, 2005, at 8:37 AM, Will Coleda wrote: A visitor on #parrot just asked if we had a fink build (which we don't). Before I bother the fink folks directly, is there anyone listening here who can help us put a fink build together?
Re: [perl #36407] [BUG] imcc - register allocation
Jerry Gay via RT wrote: please take another look at this ticket, as the new scheme is now in effect. The bug is more unlikely now but else nothing has changed. ~jerry leo
Re: Parrot Fink build
If there are changes that are required to make Configure.pl more flexible, I'm sure we can address those. If you give me a list of what you need, I can work on the configure changes to make it happen. I almost always work out of the svn sandbox, so I don't normally touch this. Thanks! On Nov 12, 2005, at 1:16 PM, Joshua Isom wrote: I use fink for ease of installing dependencies(imagine the annoyance of trying to install gimp when you don't have any of it's dependencies and don't know which ones you need), and I could try making an info file for parrot. One problem that I can already see is the tree that parrot creates for installing. You can specify the prefix, but nothing else for all the other directories, which can things messy to install them into /sw. I don't even install parrot into my path, but I do alias to it. On Nov 12, 2005, at 8:37 AM, Will Coleda wrote: A visitor on #parrot just asked if we had a fink build (which we don't). Before I bother the fink folks directly, is there anyone listening here who can help us put a fink build together?
Re: Parrot Fink build
On Nov 12, 2005, at 15:37, Will Coleda wrote: A visitor on #parrot just asked if we had a fink build (which we don't). Before I bother the fink folks directly, is there anyone listening here who can help us put a fink build together? You forgot to mention that parrot is already debianzed (thanks to rafl), which may probably help supporting fink. leo
Re: Parrot Fink build
Well I've noticed a couple things. The initial make install installs more files than is needed... I recommended file structure for fink is documented at http://fink.sourceforge.net/doc/packaging/fslayout.php?phpLang=en so it's mainly just being able to have Configure.pl adhere to it. But I have been able to get a fink info file written up that will compile and test successfully, with gmp, gdbm, and icu. I haven't tested an install, in part because of the installation directories. On Nov 12, 2005, at 12:42 PM, Will Coleda wrote: If there are changes that are required to make Configure.pl more flexible, I'm sure we can address those. If you give me a list of what you need, I can work on the configure changes to make it happen. I almost always work out of the svn sandbox, so I don't normally touch this. Thanks! On Nov 12, 2005, at 1:16 PM, Joshua Isom wrote: I use fink for ease of installing dependencies(imagine the annoyance of trying to install gimp when you don't have any of it's dependencies and don't know which ones you need), and I could try making an info file for parrot. One problem that I can already see is the tree that parrot creates for installing. You can specify the prefix, but nothing else for all the other directories, which can things messy to install them into /sw. I don't even install parrot into my path, but I do alias to it. On Nov 12, 2005, at 8:37 AM, Will Coleda wrote: A visitor on #parrot just asked if we had a fink build (which we don't). Before I bother the fink folks directly, is there anyone listening here who can help us put a fink build together?
Changing Default STDOUT/STDERR Filehandles for PIR Code
Hi there, I'd like to change where print output and warnings and errors go within a section of PIR code, like you can change them in C and Perl by closing and reopening the file descriptor or localizing the typeglob, respectively. This is important for the pure-PIR Parrot::Test. I've looked at the ParrotIO PMC and I can't immediately see anything useful. I've also read the code for the print opcode and don't see a good hook there. Are there any other ideas or suggestions? -- c
[perl #37665] [BUG] compile warning on win32
# New Ticket Created by jerry gay # Please include the string: [perl #37665] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37665 > the following output is snipped from parrot's build output with msvc-7.1: ... classes\env.c env.c classes\env.pmc(26) : warning C4273: '__p__environ' : inconsistent dll linkage D:\usr\local\perl\bin\perl.exe build_tools\pmc2c.pl --c classes\env.pmc ... normally, i'm able to squash all compiler warnings, but i'm having trouble tracking this one down. this, by the way, is the *final* compiler warning with msvc, so the person who fixes this bug gets the 'clean windows' award :) ~jerry
[perl #37667] [TODO] Update docs/pmc/subs.pod
# New Ticket Created by Will Coleda # Please include the string: [perl #37667] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=37667 > * leo please remind me to update docs/pmc/subs.pod in regards to 'newsub'. Enjoy ^_^
RFC: Test::JSON
Hi all, For all of my harping about testing, I've never actually written a test module (though I've submitted patches). I just uploaded my first module, Test::JSON. (JSON is "JavaScript Object Notation", http://www.crockford.com/JSON/). As it's not hit the CPAN yet, I've attached a copy. Feedback welcome. Internally it uses the following: 'JSON' => 1.00, 'Test::Differences' => 0.47, 'Test::Simple' => 0.62, 'Test::Tester' => 0.103, Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ Test-JSON-0.01.tar.gz Description: 130210938-Test-JSON-0.01.tar.gz
PDD20: An idea: Call frames as PMCs
{ First, let's have a little applause for Leo for implementing the new
lexical scheme in, what, a week? He says it was only a half-day's
work, too. Nice work, dude! }
First some background for those of you who haven't read pdd20:
* Read pdd20.
But if you don't have time:
* LexPads are PMCs that provide a hash-like interface to lexical
variables.
* Each call frame may optionally have a LexPad.
Now, on to the idea:
HLLs need introspection on call frames and their lexicals. I figure
the easiest way to support HLL introspection of call frames is to make
call frames be PMCs. They would have METHODs like:
get_sub()# returns the subroutine being executed
get_lexicals() # returns the LexPad, or Null if none
get_caller() # returns the parent call frame
etc. We'd probably only need one new opcode, if that: something like
$P0 = callframe
to return the current call frame, which could then be walked with
get_caller(). I suppose we could toss it a version that takes an
INTVAL like:
$P0 = callframe 1
to walk up that many frames.
(Also, incidentally, Continuations would have METHOD get_frame().)
Now on to the questions, mostly for Leo:
(1) If this were implemented naively, would it be a significant
slowdown?
(2) How about hacks/cheats to make it fast?
(2a) For example, what if the internal call frame structure remains
its current non-PMC self, and the C opcode actually creates
a _wrapper_ PMC? The only downside to that I could see is that PMC
identity would not callframe identity, and I could live with that if
it kept things fast.
(2b) Or maybe the PMC could be created on demand - only when the user
asks for it - and then cached in the low-level call frame structure,
so that would only need to be created once? This seems like the best
choice, assuming GC issues are manageable.
--
Chip Salzenberg <[EMAIL PROTECTED]>
