Re: [svn:perl6-synopsis] r13543 - doc/trunk/design/syn
On Mon, Jan 29, 2007 at 10:39:27AM -0800, [EMAIL PROTECTED] wrote:
+Because Cgather evaluates its block or statement in void context,
+this typically causes the Ctake statement to be evaluated in void
+context. However, a Ctake statement that is not in void context
+gathers its arguments Ien passant and also returns them unchanged.
+This makes it easy to keep track of what you last took:
+
+my @uniq = gather for @list {
+state $previous = take $_;
+next if $_ === $previous;
+$previous = take $_;
+}
What does it mean for take to be evaluated in void context?
What are the gathered values here?
take 1, 2; # easy. flattened 1 and then 2, right?
@x = take 1, 2; # same thing?
$x = take 1, 2; # same thing? [1, 2]?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: [svn:perl6-synopsis] r13543 - doc/trunk/design/syn
On Mon, Jan 29, 2007 at 10:01:08PM +0200, Gaal Yahas wrote:
+Because Cgather evaluates its block or statement in void context,
+this typically causes the Ctake statement to be evaluated in void
+context. However, a Ctake statement that is not in void context
+gathers its arguments Ien passant and also returns them unchanged.
+This makes it easy to keep track of what you last took:
+
+my @uniq = gather for @list {
+state $previous = take $_;
+next if $_ === $previous;
+$previous = take $_;
+}
What does it mean for take to be evaluated in void context?
What are the gathered values here?
take 1, 2; # easy. flattened 1 and then 2, right?
@x = take 1, 2; # same thing?
$x = take 1, 2; # same thing? [1, 2]?
In fact, $x = take 5;# if this were Perl 5, I might expect
# either 1 or [1] here!
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: [svn:perl6-synopsis] r13543 - doc/trunk/design/syn
On Mon, Jan 29, 2007 at 10:08:34PM +0200, Gaal Yahas wrote:
On Mon, Jan 29, 2007 at 10:01:08PM +0200, Gaal Yahas wrote:
+Because Cgather evaluates its block or statement in void context,
+this typically causes the Ctake statement to be evaluated in void
+context. However, a Ctake statement that is not in void context
+gathers its arguments Ien passant and also returns them unchanged.
+This makes it easy to keep track of what you last took:
+
+my @uniq = gather for @list {
+state $previous = take $_;
+next if $_ === $previous;
+$previous = take $_;
+}
What does it mean for take to be evaluated in void context?
What are the gathered values here?
take 1, 2; # easy. flattened 1 and then 2, right?
@x = take 1, 2; # same thing?
$x = take 1, 2; # same thing? [1, 2]?
In fact, $x = take 5;# if this were Perl 5, I might expect
# either 1 or [1] here!
Ugh, sorry, I meant either 1 or [5].
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: [svn:perl6-synopsis] r13545 - doc/trunk/design/syn
On Mon, Jan 29, 2007 at 02:06:51PM -0800, [EMAIL PROTECTED] wrote:
+The Ctake function essentially has two contexts simultaneously, the
+context in which the gather is operating, and the context in which the
+Ctake is operating. These need not be identical contexts, since they
+may bind or coerce the resulting captures differently:
+
+my @y;
+@x = gather for 1..2 { # @() context for list of captures
+my $x = take $_, $_ * 10; # $() context for individual capture
+push @y, $x;
+}
+# @x returns 1,10,2,20
+# @y returns [1,10],[2,20]
XXX = gather {
YYY
take f();
ZZZ
}
sub f () {
return want.Scalar ?? 42 !! 54;
}
Which of XXX, YYY, and ZZZ influence whether the taken value is 42 or
54? Please confirm there's *no way* that f is entered twice here :-)
(If I'm following correctly, then take's args are basically evaluated
in list context. If YYY is something like $scalar = that list gets
Captured, but there's still a list there.)
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
single named param
I was writing tests for signatures and came across this ambiguity: :(:$x) Does this mean a single named parameter called $x, or a default invocant and a single required positional named $x? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: single named param
On Tue, Sep 12, 2006 at 06:46:50PM +0800, Audrey Tang wrote: Does this mean a single named parameter called $x, or a default invocant and a single required positional named $x? A default invocant prolly doesn't make sense there... There's nothing to default to. :-) What invocant is constructed in this signature then? method foo ($just_a_named_param) Is the signature for foo really the same as that of bar? sub bar ($just_a_named_param) I was sort of assuming you could tell by a signature if it was for a method or a sub. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Unpacking tree node parameters
sub traverse ( BinTree $top ( $left, $right ) ) { ... }
LS06/Unpacking tree node parameters has two infelicities I wanted to
fix with a patch. The first is that this style of unpacking is really
syntactically a Signature, but most the examples in this section
abbreviate out the optional colon. (The above is more formally spelled:
sub traverse ( BinTree $top :( $left, $right ) ) { ... } # or even...
sub traverse :( BinTree $top :( $left, $right ) ) { ... }
I'm ignoring the final version here.)
The paragraph explaining this point, however, uses for its justification
an example from the variable declaration world:
You may omit the top variable if you prefix the parentheses with a colon
to indicate a signature. Otherwise you must at least put the sigil of
the variable, or we can't correctly differentiate:
my Dog ($fido, $spot) := twodogs(); # list of two dogs
my Dog $ ($fido, $spot) := twodogs(); # one twodog object
my Dog :($fido, $spot) := twodogs(); # one twodog object
Unless I'm mistaken, this doesn't cast back to subroutine signature land
very well:
sub f1 (Dog ($fido, $spot)) { ... }
sub f2 (Dog $ ($fido, $spot)) { ... }
sub f3 (Dog :($fido, $spot)) { ... }
f1(twodogs()); # really a list of two dogs?
f2(twodogs()); # one twodog object
f3(twodogs()); # one twodog object
Unless Audrey's latest S03 patch pertains here as well, and Dog
distributes; in that case it would be as if the programmer had written
sub f1 ([Dog $fido, Dog $spot]) { ... }
as described in the preceding section, Unpacking array parameters. If
this is *not* the case, then f1 is not ambiguous!
Please clarify, so I can clean up the confusing paragraph and introduce
the optionality of the colon less jarringly.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Two Signature questions
:($x where {...} is elk)# ambiguous auxillary
Is this legal? does the 'elk' trait pertain to $x or to the where-block?
:($x is ro is rw) # conflicting traits
Is this legal? Is $x ro or rw?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Pair of lists = list of pairs?
On Wed, Aug 23, 2006 at 05:43:48PM -0400, Mark J. Reed wrote: But is there an easy way in Perl6 to do it all in one go? Should this work? my %h = @k [=] @v; You want a zip: my %h = @k ¥ @v; my %h = @k Y @v; # ASCII fallback my %h = zip(@k, @v); # or maybe zip(@k; @v) this week? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: designing a test suite for multiple implementations
On Sat, Aug 12, 2006 at 02:06:27PM +0800, Agent Zhang wrote:
is $got, $expected, todo :pugs6.2.13, :p6p50.110;
Happily, Audrey has already implemented the $?PUGS_VERSION variable,
which can ease the implementation of such todo subs:
I've added a %?CONFIGperl_compiler variable which I propose
each implementation support. Pugs says 'pugs'. Also, there's a
%?CONFIGpugs_versnum so there's no need to parse $?PUGS_VERSION.
pugs %?CONFIG{%?CONFIGperl_compiler ~ _versnum}
6.2.12
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
[patch] S04: CATCH blocks
(This paragraph may need some more treatment but I won't attempt it until I grasp the content better.) * agentzh++ noticed confusing language regarding two kinds of scope in S04. --- design/syn/S04.pod (revision 10465) +++ design/syn/S04.pod (working copy) @@ -456,7 +456,7 @@ of the CCATCH block. Handled exceptions break out past this implicit rethrow.) -A CCATCH block sees the lexical scope in which it defined, but the +A CCATCH block sees the lexical scope in which it is defined, but the dynamic scope in which it is called, that is, as if it were called from the dynamic location that threw the exception. That is, the stack is not unwound until some exception handler chooses to -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Scans
On Mon, May 08, 2006 at 04:02:35PM -0700, Larry Wall wrote: : I'm probably not thinking hard enough, so if anyone can come up with an : implementation please give it :) Otherwise, how about we add this to : the language? Maybe that's just what reduce operators do in list context. I love this idea and have implemented it in r10246. One question though, what should a scan for chained ops do? list [==] 0, 0, 1, 2, 2; # bool::false? # (bool::true, bool::true, bool::false, bool::false, bool::false) ? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Scans
On Tue, May 09, 2006 at 11:23:48AM +0100, Smylers wrote:
So I have the list generated by the scan. And? What do I do with it?
I can't think of any situation in my life where I've been wanting such a
list.
Scans are useful when the intermediate results are interesting, as well
as when you want to cut off a stream once some threshold condition is
met.
item [+] 1 .. 10; # 10th triangular number
list [+] 1 .. 10; # 10 first triangular number
first { $_ 42 } [+] 1 ..* # first triangular number over 42
If you have a series whose sum yields closer and closer approximations
of some value, you can use a scan to efficiently cut off once some
epsilon is reached.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Scans
We have a very nifty reduce metaoperator. Scans are a counterpart of reduce that are very useful -- they are the (preferably lazy) list of consecutive accumulated reductions up to the final result. But I can't think of a convenient way of expressing scans in Perl 6. I'm probably not thinking hard enough, so if anyone can come up with an implementation please give it :) Otherwise, how about we add this to the language? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Scans
On Mon, May 08, 2006 at 04:44:51PM +0200, Juerd wrote:
To make sure I understand what you mean, not as a proposed
implementation:
my @input = (...);
my @scan = map { [op] @input[0..$_] } [EMAIL PROTECTED];
Is this what you mean?
Hm, could that be written as:
my @scan = [op] @input[ 0 .. ([EMAIL PROTECTED]) ]
Yes, except that interim results need not be recalculated. (Indeed,
they are not in Haskell; implementing this feature on the .hs pugs
runcore should be straightforward.)
(Is there special sugar to make @input be the last index when used in a
range, or did you mean ..^ ?)
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: A shorter long dot
I don't think it's ugly. It's not any less tidy. $xyzzy.foo() $xyzzy.foo() $fooz.:foo() $fooz.:foo() $foo._:foo() $foo. :foo() $da.__:foo() $fa. :foo() My variable names aren't so long that I'm likely to have foo.___:bar, and $foo.__:bar is clean. But it doesn't work across lines: $xyzzy.foo() $fooz.:foo() $foo. :foo() $fa. :foo() $and_a_long_one_I_still_want_to_align. :foo() $etc. :foo() -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
split on empty string
While cleaning up tests for release:
.split(':')=
()# Perl 5
(,) # pugs
Which is correct? It doesn's seem to be specced yet.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
facades, use_ok, and lexical export
Consider use_ok from the test system. Essentially, it should be
require $module; $module.import; pass load $module;
in its caller's context. But now that exportation is lexical, how can
use_ok be implemented? It must divert the symbols installed by import
and have them installed in the caller site. Can that be done in pure
Perl? Even before that: can import be written in pure Perl?
This obviously won't work:
sub use_ok($module) {
eval package {caller.package}; require etc.;
}
because the installation work happens at the wrong lexical scope, and
because pads can't be changed at runtime.
More generally, how does one write friendly facades that mix in some of
the functionality of their real modules? (Eg., IO in Perl 5 that loads
many IO::* modules) I am not sure Role composition will always be strong
enough to do this. For example if a module one wishes to pull in isn't a
Role :)
There are over a hundred use_ok in the Pugs test suite; we are about
to work around the problem by changing them to use+pass, but that's
obviously the Wrong Thing. Is there a better workaround / a better
design we could use?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: import/export and module configuration
On Fri, Dec 16, 2005 at 01:05:21PM -0800, Larry Wall wrote:
I think we can certainly let the module specify the default when
someone says
use Module $hownow;
rather than
use Module :my$hownow;
I suspect the notation for setting default on the module end is simply
to allow tag pseudo-sets that specify it:
my $hownow is export(:state); # override implicit :my default
Would uppercase work better to avoid clashes with user-defined tagsets?
I.e. :STATE :LET :TEMP :ENV :MY :OUR :GLOBAL. Except I'm not sure what
some of these mean as exportables.
If I export a var from one scope to another, that's fine; the caller
gets a differently scoped alias to the same memory. But what about
closed lexicals? What does this mean:
sub make_tag {
my $tag is export = shift;
{ $tag{ @_ }/$tag };
}
Audrey suggested that perhaps only top-level lexicals should be
exportable.
: Second, where does a module consumer communicate configuration requests
: to the module?
: (e.g., 'use Test::More no_plan'),
Well, there's a lot to be said for ad-hoc, but yes, it would be good
to get control of the various forms of adhocracy so we know which
ones are necessarily ad hoc and which ones are that way accidentally.
A straightforward and Huffmanly unoptimized protocol would be to
stipulate an explicit configuration argument. import can receive it as
a named arg.
use Test::More conf = no_plan;
Alternatively disallow implicit my importation specs and treat everything
to the right of the module name syntactically as arguments to import,
with the parser picking out things it recognizes as imports and passing
everything else through.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Obsoleting require 'Some/Module.pm'
Can we make this work? my $mod = Some::Module; require $mod; It's a very simple patch to pugs. While we're at it, does anybody see a compelling reason to leave in the Perl 5 semantics of require $file? We could follow the heuristic of the very sane Module::Load, and try *either* a file *or* a module, but I'm wondering if it isn't a good time to clean up how we look at modules of code and say that anything loaded via use or require is named Perlishly only. %*INC keys would thus be uniformly Perlish names, and their values can be an interesting structure containing the relative and actual absolute path of the resources loaded. (In fact, this is what recent pugs does :). I know some code does require 'foo.ini', but can't that be relegated to a module and use a different store than %*INC? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Fully-qualified symbols and exportation
What should this mean?
package Foo;
sub Bar::baz is export { ... }
The problem is in how callers request this export.
use Foo baz;
Looks weird, as this demonstrates:
package Foo;
sub baz is export { I am Foo::baz }
sub Bar::baz is export { I am Bar::baz }
Clearly, if this is allowed at all, the use line should import Foo::baz.
But this looks wrong:
use Foo Bar::baz
In fact the only way this makes sense to me at all is if Bar::baz had
already been exported by Bar, and now Foo wants to change the meaning of
that sub. The is export trait is just for formal signature matching /
documentation purposes then. What is the scope of this override?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
import/export and module configuration
S11 stipulates: * modules can decorate exports with tagsets * module users are the ones who control which imports are allowed, and what scoping to give each import. The default is always lexical. There are a few pieces missing in the puzzle, I think. First, can a module not suggest a scope for the consumer? If a module relies, for example, on setting up a 'state' variable in the caller, it would be tedious for the caller to have to request that kind of var every time. (If modules have no business demanding certain scopes from their callers, why should the caller even have the standard way of setting such scope?) Second, where does a module consumer communicate configuration requests to the module? In Perl 5, the 'use' arguments have often been used for this purpose in an ad-hoc manner (e.g., 'use Test::More no_plan'), and while I agree it's good to make this more regular, that shouldn't mean it has to happen at runtime. Supposing there is an IMPORT hook we can use, it needs some speccing so that we don't go ad-hoc all over again. I don't have a proposal for how this would look like, but it shouldn't conflate import directives (that say something about how the caller sees the module) with other configurations (that say something about the demands made by the caller to the module). -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Flunking tests and failing code
There's a bikeshedding question of some visibility: now that we have a Cfail builtin, what do we do with CTest::fail? There's plenty of code out there that uses fail as an exported function from pugs' Test.pm or Perl 5 testing modules. We want to keep Test primitives exported and fun to use, to encourage people to use them a lot; so requiring a fully qualified call would go against the grain. But the builtin has even more of that concern: it should become the more common, too. If one is to be renamed, it looks like is the Test one, despite existing legacy code. Discussion on #perl6 brought up flunk as a candidate name. Its merits, including its, uh, dropout cuteness, are many; it rings well against fail, alludes to tests, can probably be backported to the Perl 5 test modules, etc. What say? [++] dduncan autrijus -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
dis-junctive patterns
In pugs, r7961: my @pats = /1/, /2/; say MATCH if 1 ~~ any @pats; # MATCH say MATCH if 0 ~~ any @pats; # no match So far so good. But: my $junc = any @pats; say MATCH if 1 ~~ $junc; # no match say MATCH if 0 ~~ $junc; # no match Bug? Feature? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
given too little
I know why the following doesn't work:
given $food {
when Pizza | Lazagna { .eat }
when .caloric_value $doctors_orders { warn no, no no }
# ...
}
The expression in the second when clause is smart-matched against $food,
not tested for truth like an if. So currently the right way to code this is
something like
DINER: given $food {
when Pizza | Lazagna { .eat }
if .caloric_value $doctors_orders { warn no, no no; leave DINER }
# ...
}
(Or whatever the way to address labels is.)
I'm a little bothered that this is consistent but (to me, at least)
unintuitive. Testing methods on the topic is something people may want
to do often: is there a way to hide away the control logic? I'm tempted
to propose that when a .method is seen in the when expression, the
whole thing should become a terminal if. Inconsistent but possibly what
people want.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: given too little
On Thu, Nov 10, 2005 at 07:23:15AM -0700, Eric wrote:
I'm pretty sure i've heard this discussed but checking S04/Switch
Statments doesn't make any mention of it. If it has been settled
could we get some doc updates?
I looked again more carefully at S04 and saw that Any ~~ Code$ and
Any ~~ Code do in fact have definitions in the smartmatch table.
Any Code$ scalar sub truth match if $x($_)
Any Codesimple closure truth*match if $x() (ignoring $_)
What is Code$ and Code? Closures accepting a single scalar and no
arguments?
If so then my and Eric's wishes are answered:
when { $_ 5 } { ... }
when { .caloric_value $doctors_orders } { ... }
This isn't implemented in pugs yet, but I guess it can be once this is
clarified.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Default values for instance variables
Wouldn't it be nice to be able to supply default values for instance
variables right in the attribute declaration?
class Jabberwock {
has $.jaws = bite;
has $.claws = catch;
}
my $scary = Jabberwock.new;
my $wimpy = Jabberwock.new(jaws = chew, claws = tenderly comb);
S12/Roles/Roles may have attributes implies that this kind of thing is
okay in roles. Is there any reason not to allow it as in the above too?
This replaces the need for an explicit BUILD in many cases, which I
think is useful.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Default values for instance variables
On Tue, Nov 08, 2005 at 07:07:42PM +, Luke Palmer wrote:
class Jabberwock {
has $.jaws = bite;
has $.claws = catch;
}
That is legal Perl 6. The fact that it is not legal pugs is pugs's problem.
:-)
Noted. Perhaps it'd be worth foregrounding this feature in the Synopsis? I
was just about to add tests -- but I found they already existed, with
a comment
# These tests are not specified by p6l, But these should be right...
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Re(vised): Proposal to make class method non-inheritable
On Wed, Oct 19, 2005 at 04:03:54AM -0700, Larry Wall wrote: : This one is new to me. I'm not sure I understand what it's used for. Is : there already some documentation about it? It's in my copy of S06, which I haven't checked in yet. Is there an AES commit feed available somewhere? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Translating (or at least parsing) Java interface definitions
On Mon, Aug 08, 2005 at 10:25:26AM +0100, Tim Bunce wrote: Anyone done any work on parsing Java interface definitions? And, ideally, translating them into roughly equivalent Perl 6? I wrote something that did this with Parse::RecDescent. Unfortunately, I don't own the code. For my purposes I needed to parse several hundred interface files and build Perl 5 classes (with hierarchy) on the fly from them. The files in practice only used a subset of the possible Java syntax available in an interface, but more than a trivial subset. The grammar (together with interspersed to buildcode) came out at about 120 lines. It was fast enough for me after the initial Parse::RecDescent startup hit. The Java language spec contains a few grammars that helped me. I found I couldn't use autotree because I can't control the base for the resulting namespace: I have a patch to Parase::RecDescent somewhere that fixes that, or you could use Class::Rebless which I wrote initially because of this problem -- though I ended up doing the blesswork inside the code sections manually as it made much more algorithmic sense. Hope this helps. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
say's return value
What do print and say return? fail would be great on errors. On success, they return 1 now, which doesn't look very useful. How about returning the printed string? Unless called in void context, of course. (This introduces a potential semipredicate problem when looking at the return value of a printed 0 or while not using fatal, but the code can use a defined guard.) -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: say's return value
On Sat, Jul 30, 2005 at 09:36:13AM -0700, Larry Wall wrote: I don't see any reason to return the string at all. It's almost never wanted, and you can always use .= or monkey but. So: fail on failure bool::true on success? Pugs currently returns bool::true. Is there a way to tag a sub as failable? Should there be one? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
module init hooks and pragmas
What gets called for me when someone uses my module? What gets called when someone nos it? LS11/Importation stipulates a standard syntax for import lists, and that's probably a good thing, but then how do you pass other compile-time requests to code that's being used? Perhaps in light of LS04/Closure traits, we can make use and no activate TURNON and TURNOFF blocks? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: What do use and require evaluate to?
On Tue, Jul 12, 2005 at 12:15:30PM +, Ingo Blechschmidt wrote:
In Perl 5, %INC maps the partial path names of the modules
loaded to their absolute ones. What should the keys and values
of %*INC be in Perl 6?
Conceptually, the Perl 5 %INC maps from what to which. It also imposes
a coupling with the filesystem which makes things like require $module
awkward. The hook mechanism in values breaks consistency, unless you
think of string values as shorthand for sub { slurp path }.
I propose to throw away the filesystem coupling, and map from a more
general name of the bit of code we are requiring to a more general
description of which instance of it we actually got. Once modules return
interesting values, it might be useful to keep a copy of that value
somewhere on the value side of %*INC: or else turn it inside out and
stipulate that a standard field in the Module object is where you got
this particular module. Probably, %*INC values should be weak references.
On the key side, I think we should allow more than just strings.
`use Bar` and `require Bar` invoke the module loader on a
ModuleName.new(Bar). Passing a straight string performs this promotion
automatically. Path separators and '.pm' need never seen outside the
module loader. You can also ask to use/require a File or a URI, but
those requests are only honored if you have appropriate entries in the
module search path. In the case of URIs we could allow, for example,
only modules from a particular domain or even under a particular path.
Examples:
%*INC = (
# weak references
ModuleName.new(Bar) = Module.new(name= Bar,
version = 0.0.7,
author = BarCom,
path= /usr/lib/perl6/Bar.pm,
loaded_classes =
(::Bar, ::Bar::Internals),
),
URI.new(http://codeIZus.com/perl/randommodule.cgi;) =
Module.new(name= Acme::emcA, ...),
$an_open_file = ...
);
@*INC = (/usr/local/lib/perl6,
URI.new(http://codeIZus.com/perl/;),
URI.new(http://;), # this would mean allow loading code from ANYWHERE.
);
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Time::Local
I've added localtime to pugs (r5233, 5236), to address Dave Rolsky's needs
for DateTime; but I'm noticing S29 doesn't spec this and nearby builtins
yet. I'd like to raise the questions I encountered / stipulations I've
made. Please let me know if I'm in error or update S29 if I am not.
Regarding Time::Local fields, it's an object now, so the order of things
matters less now than it did in p5. The fields I've made available
naturally follow GHC's CalendarTime type[1]. The important deviations
from p5 are:
* .year is the Gregorian year, no 1900 offeset or anything like that.
(Haskell doesn't promise accuracy in the readable version of
pre-Gregorian dates, which I think is okay for us as well, as long
as the opaque internal representation remains consistent. That's part
of where libraries such as DateTime can help.)
* .month and .wday are one-based. Sunday == 1. Haskell has them as
enums which avoids off-by one confusion completely; I made them like
I did because that's like humans think of them.
* .picoseconds - we don't promise this granularity is available by the
system, but I don't suppose we'll ever need anything finer than that
:-)
* Once we sort out context and want in pugs, I can return a List when
one is expected, instead of an object. Then the order of fields
becomes important and I'm inclined to go with year first, like the
Haskell module, so that least significant things come last. This is the
reverse of p5 Time::Local. When timelocal and timegm are implemented,
they will of course use whatever order their inverses use.
As for the function signatures:
multi sub localtime(Rat $?when = time) returns Time::Local { ... }
multi sub localtime(Int $sec, Int ?$pico = 0) returns Time::Local {...}
The first form uses the second, but might be less precise.
[1]
http://haskell.org/ghc/docs/latest/html/libraries/base/System.Time.html#t%3ACalendarTime
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Time::Local
On Tue, Jul 05, 2005 at 08:16:54AM -0700, Larry Wall wrote:
I don't think either of those are good human engineering. I would
like the preferred Perl 6 form to simply be:
multi sub localtime(Num $?when = time) returns Time::Local { ... }
Done.
I take it that the rest is okay? If so I'll submit a doc patch to S29.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Time::Local
On Tue, Jul 05, 2005 at 11:41:23AM -0500, Dave Rolsky wrote: Regarding Time::Local fields, it's an object now, so the order of things Should that be Time::localtime? In P5 there are Time::localtime Time::gmtime, which are thin OO facades over the language builtins. Then there's the module Time::Local, which is entirely different. Hmm, I agree. I used Time::Local because that's what the draft Synopsis put them in, but Time is a better fit. All of those provide useful functionality, and probably Time::Local should be part of the language, _or_ localtime gmtime should be in a library. Not my call, but I think we can add timelocal and timegm soon. They're mostly cleverly-caching facades to Time.new anyway, no? Drop by on #perl6 if you want to hack on the Prelude side of this. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
caller with no sub scope
In Perl 5, caller EXPR returns undef if the caller is top-level code. If
you need it, you can still get file, line, and package information
(this last is important for import subs) by using caller with the
EXPR-less form.
How do you do that in Perl 6? I'd been working with this presumed
signature:
multi sub caller (Class ?$kind = Any, Int +$skip = 0, Str +$label)
returns Control::Caller is primitive is export is safe { ... }
And an implementation which *always* expected a VCode frame (to check
$kind against). Obviously, this leaves no way to peek at frames with no
?SUB, i.e., the top level.
The hacky way to solve this is to stipulate that kind=Any actually
means something so general that it matches things that are not VCode
at all. The cleaner way in terms of formalism is to allow $kind to be
undef (actually, *default* to it), in which case it functions as that
wider-than-Any qualifier.
I'd go with the second way, since I think it leaves us with DWIMmy
usage. This will start working, which is good:
sub import() { # (do we still have that?)
die I'm not speaking with you! if caller().package ~~ Rival;
...
}
Anyone spot any problems?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Ignoring parameters
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say Hello, FooClass!;
}
AFAIK, this is the only signature that would work for making greet a
class method; but note that I'm not using $class, and I'd expect the
compiler to issue a warning in such a case.
The same problem exists with methods in classes fulfilling a role,
but which want to ignore a parameter in a required method.
What do you say about this proposed syntax?
method greet(Class undef: ) { ... }
# the interface calls for a floor as 1st arg
method bereaucracy(Int undef, Int $office_number) { ... }
I'm not sure how this works for named fields, but for positional ones
it should do well, and is similar to ($a, undef, $c) = LIST syntax.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: sub my_zip (...?) {}
[Sent off-group by mistake. On #perl6 the impression was that now Pipe is becoming a Role for things that can lazily be read from; and thus any filehandle or lazy list fulfills them. Larry, please help us understand if this is the case.] On Thu, Jun 16, 2005 at 08:53:41AM -0700, Larry Wall wrote: The semicolon operator no longer builds a list of lists, but a list of pipes, which are specially marked Lazies that know they came from pipe operators (including semicolons as a kind of pipe operator). When bound to an ordinary splat array (or in fact any splat array whose type isn't Pipe), the Pipes flatten as if they were comma separated. When bound to an array of type Pipe, each pipe stays discrete. I thought the class Pipe was reserved for what the result of open-foo| is in Perl 5? That's what we call it in Prelude.pm at least; if it needs to be renamed maybe IPC could work. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Ignoring parameters
On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say Hello, FooClass!;
}
Aside from the fact that I don't think this is the right way to
specify class methods...
What do you think is the right way to specify them?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: caller and want
On Wed, Jun 08, 2005 at 12:20:57PM -0700, Larry Wall wrote:
: I'm not sure how this selection mechanism is meant to be used.
The skip is meant to be applied after filtration. Don't filter out
things you want to see later, in other words.
Okay, caller done as r4555. Without :label for now, because we don't
have that yet.
: - AES does not enumerate the complete member set. We can use that now :)
Um. That's something I wouldn't mind delegating to whoever is slogging
it out on the ground.
That's fine for caller, but half the examples for want imply things that
aren't available in Pugs' exisitng want yet (count, rw), and I think they
might not be straightforward to add. If there are other things come to
mind they'll probably be easier to add all at once.
[.sub - .subname ; .sub returns coderef]
That's the direction we're going with ?SUB and $?SUBNAME, so I don't
see why it couldn't apply here too.
Done.
It would be nice if the interfaces were similar where they try to do
similar things.
But then, it might be nice to copy over the :nth($n) interface from
pattern matching too, somehow or other. Right now our selectors don't
have a way to generalize that. You almost want to be able to say
something like caller(3rd(Sub)), which causes ~~ to match Sub, but
only on the third thing that could be construed as a Sub, presuming
~~ is treating the other argument as some kind of iterator. But up
till now we've been treating such iterators as external to ~~, with
the args matched one at a time. One could imagine seeing things like:
given =$IN {
when 1st(/foo/) {...}
when 2nd(/bar/) {...}
when 3rd(/baz/) {...}
}
but the semantics of such a construct are more than somewhat problematic.
Is caller so time-critical that saying 3rd(caller(Sub)) is too bad?
FWIW, this is how I interpreted caller(Sub, :skip2), as the third
sub. And unless I'm wrong, caller(Block, :skip2, :labelmoose) would
mean, once you get to the third Block, look on for one labeled moose.
So we don't have a way to skip three methods and then look for a labeled
block, but if the user really wants that, let them grovel over a
complete call chain themselves.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
caller and want
A06 and S06 are in disagreement about the caller builtin, and I need
help understanding either one.
A06 [plus updates] stipulates this signature for caller:
multi *caller (?$where = ?CALLER::SUB, Int +$skip = 0, Str +$label)
returns CallerContext { ... }
In S06 it's (I infer):
multi *caller (Class ?$kind = Code, Int +$skip = 0, Str +$label) { ... }
I'm assuming S06 is the more correct; A06 said that $where says where
to stop when scanning up the call stack but it only makes sense to me
if it says where to *start* scanning.
In the Synopsis version, does $kind imply a filtering condition on *all*
stack frames it encounters, or just on where the first one is? That is,
if we have this contrived example:
subp() { caller(Sub, :skip1).sub.say }
method a() { p() }
subb() { a() }
method c() { b() }
subd() { c() }
Does this start looking upwards for a Sub, find b, skip one caller and
print c? Or does it find b, skip one *Sub*, and print d?
I'm not sure how this selection mechanism is meant to be used.
Other questions:
- A06 stipulates CallerContext but to be more in line with the latest
S29 draft, we've used Control::Caller. Okay to use that?
- AES does not enumerate the complete member set. We can use that now :)
- S06 stipulates the method for sub name is sub. I find subname to
be more appealing. Okay to use that?
- Perhaps caller.sub could be made to return the code ref itself, which
given introspective capabilities can be a fun thing. At the very
least, we want to be able to call .arity on the result of a caller,
but if that, why not also get the signature information, and while
we're at it -- the actual runtime parameters (if still available, and
if this doesn't turn out too hard to implement)?
S06's want is much simpler than A06's. Can it for now be considered
complete? (I'm asking because A06 links want intimately to caller
and that appears to no longer be the case.)
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Musing on registerable event handlers for some specific events
On Wed, Jun 08, 2005 at 12:29:33PM -0700, Larry Wall wrote: There will certainly be an event manager for all sorts of events floating around in Perl 6. The main trick will be to hide this from the people who aren't interested. The other trick will be to actually spec it, since up till now I've assumed that it should be specced by the people who are actually into that sort of thing. Looks like you're one of them. :-) There's the touchy issue of what minimum compatibility level we're promising to deliver on all platforms. This is an issue in pugs already, where Windows GHC isn't compiled with POSIX libraries so we're stumped on the interface for even relatively basic things, such as how (or whether) File.open might offer O_EXCL. Is part of the vision something like the explicit cross-platform nature of Java? Will I be able to write Perl6 code with a certain flag that possibly limits my choice of modules/builtins, but which promises me identical behavior on all supported platforms? To take a notorious example, you mentioned fork() -- if this event manager becomes part of Perl6, does that mean we're required to emulate fork() on win32? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
returns and context
How do I specify the signature of a context-sensitive function?
sub foo() returns (what?) {
return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
}
If it were two subs, one would is returns Int and the other List of
Sheep. The draft S29 uses things like Int|List to express this kind
of thing but that looks weird to me (how would you return a typed
junction?). S06 and E06 don't raise this issue.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Unicode Operators cheatsheet, please!
On Fri, May 27, 2005 at 10:29:39AM -0400, Rob Kinyon wrote: I would love to see a document (one per editor) that describes the Unicode characters in use and how to make them. The Set implementation in Pugs uses (at last count) 20 different Unicode characters as operators. Good idea. A modest start is at docs/quickref/unicode . -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Overriding/redefining p6 built-in functions
On Sun, May 08, 2005 at 07:20:04AM -0700, Larry Wall wrote: Absolutely everything is overridable in Perl 6, except the fact that the program is parsed as Standard Perl up till the first declaration (which might, of course, occur before the program file in a switch.) On that note, http://perlnomic.org/ . -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: stdio
On Wed, May 04, 2005 at 11:44:58PM -0700, Larry Wall wrote: : How do I open a file named -? Um, depending on what you mean, and whether we continue to support the '=' pseudofile, maybe: $fh = io(-); $fh = open -; $fh = $name eq '-' ?? $*IN :: open $name; My concern is again with magic control. I've no gripes with the first or last of those, but I think the second should not be allowed by default. There has to be a safe mode for opening a file and knowing that's what you're opening: not a pipe, not stdio (hence there are places I can't permit myself to use #1). But as your third example suggests, never allowing open - will make unixish tools tedious to write, so maybe we need something like getopt(...); $fh = open $in, :allowstdio; (only named more eloquently). : How do I open stdout (and the other standard handles)? Maybe something like: $fh = open file, :w:c:usefd(1); $*OUT.reopen(file,:w:c); reopen $*OUT: file, :w:c; give or take a few options. What does 'file' do in these examples? If we take your trailing-args suggestion from the Open and pipe thread, the filename could be optional. How to make this --friendly? If my earlier suggestion is okay, then by symmetry: $logfile = -; open $log, :a:allowstdio; -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: stdio
On Thu, May 05, 2005 at 01:32:56AM -0600, Luke Palmer wrote: On 5/5/05, Gaal Yahas [EMAIL PROTECTED] wrote: getopt(...); $fh = open $in, :allowstdio; Maybe the opposite: $fh = open $in, :literal; One of the nice things about the magical - behavior is that people are writing more versatile, accepting scripts without realizing it. That was one of the things that made me really like Perl when I first started learning it. A few of the little utility / filter scripts that I wrote already accepted - on the command line, and I didn't even know it (and they still worked perfectly when you used -). Yeah, you and me both. And I don't think arguing in the name of security for the default case is going to buy us anything. Security doesn't come in scripts in any language for free; you have to walk through every line that sees the outside world and ask is there any way somebody could exploit this?. And a - handler would be one of the things you'd have to routinely write, just like making sure they're not opening ; rm -rf /. Why are you scare-quoting something I never said? I wasn't talking about security, I was talking about basic least-surprise. Opening ; rm -rf / with my perl5 does not do anything bad. Opening - potentially causes a script to hang. But I don't think a :literal flag or whatever will be a problem. Yes, I like your proposal, though I don't know which way should be the default. I'm not looking for sysopen (I know where to find it), I'm looking for an easy way to control magic. You can also open a file named -, in the absence of a literal option, like this: my $fh = open ./-; I'd say fine, except that this isn't portable. I think he misunderstood you (and if not, then I misunderstood you :-). You're asking about how to get a filehandle to stdout, he's telling you how to redirect stdout to a file. I think - will do the trick. Ah, yes, then again the question is how to conveniently choose whether to do e.g. log-to-stdout or write to a file named -. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Signatures and option specs [was: Open and pipe]
On Mon, May 02, 2005 at 09:52:35PM +0200, Juerd wrote: I already suggested a syntax like '+$write|w' for having multiple ways to say the same thing. I don't like an explicit :mode. Let Perl figure that out based on passed named arguments. I'd like to see this specced. What you're suggesting is that sub signatures have something as powerful as a good getopt library; things that spring to mind at this prospect are: * canonical representations (eg, :w in your example should probably set $write) * mutually exclusive options (for open modes, :write should exclude :append) * computed options (if by let Perl figure that out $mode you didn't mean let perl's open figure it out with explicit code). How would you suggest formalizing these? (By the way, we need a spec for perl's command line, too. So far we've been emulating perl5's in an ad-hoc manner.) -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Open and pipe
On Wed, May 04, 2005 at 08:47:17AM -0400, Aaron Sherman wrote: I would expect open to be a bit of an anachronism in P6, but still used fairly often. For the most part, I would expect that: my IO $read_fh = '/some/path' = 'r'; # Get an IO::File (is IO) my IO $write_fh = '/other/path' = ''; # Get IO::File my IO $pipe_fh = 'program args' = $IO::ReadPipe; # Get IO::Pipe my IO $sock_fh = 'http://www.perl.org/' = $IO::URI; # Get IO::Socket would just DWIM. But, perhaps I'm expecting too much... Ah yes, that's another thing I was wondering about: what does opening a pipe return. If it's a one-way pipe, okay, this may be a single handle; but for bidirectional opens, we need $in, $out, and $err handles; and even in the simple unidirectional case, where does the Process handle go?[1] In the glorious OOP version of these builtins, IO can encasulate the three handles, plus the process handles. But if we are to provide a pipe1 builtin, it can return a single handle (and not the pid, unless we return a list or use OUT variables (yech)). Should we provide further procedural interfaces for pipe2 and pipe3? [1] Process handle encapsulates unix pid / win32 process handle. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Open and pipe
On Wed, May 04, 2005 at 04:59:21PM +0200, Juerd wrote: Ah yes, that's another thing I was wondering about: what does opening a pipe return. If it's a one-way pipe, okay, this may be a single handle; but for bidirectional opens, we need $in, $out, and $err handles; and That'd be tridirectional, then. Bi and up. A normal filehandle can already handle bidirection. Yes, but to exploit that would be something of a perversion: the in and out handles are very separate as far as everybody else is concerned. I think the following solution suffices in a clean way: $h = open a pipe; Now, $h.in; $h.out; $h.err; $h.print(foo); # use $h.out $l = $h.readline; # use $h.in Yes, if $h is the not-very-primitive version of IO. Surely the type of $h.in is not the same as $h itself? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
stdio
How do I open a file named -? How do I open stdout (and the other standard handles)? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Open and pipe
Here's a basic proposal for the open and pipe builtins. It was discussed on #perl6 today and seemed okay to the people there. I'd like to hear your comments, since the internals side of much of this is ready and is looking for an interface. module Prelude-0.0.1; class IO; has Handle $:read_h; has Handle $:write_h; has Handle $:err_h; has Process $:process_h; multi sub open ( Str ?$filename = $?CALLER::_, Str ?$mode = '', Str ?$encoding = 'auto') returns IO; multi sub pipe ( Str ?$command = $?CALLER::_, Str ?$encoding = 'auto', +?to, +?from, +?skip_shell) returns IO; Notes / questions: Perl5-style open file is no more.[1] An earlier discussion about open here brought up URI open, but I think there was no final word, and it looks to me that the basic open should always mean file open, unless explicity modified. E.g., open could be used as a facade for pipe, open 'ls', '|-'; # or even open 'ls', :pipe = 'from' This pipe as it is can automatically do open2/3 if both :from and :to are given. I don't know if this is a good thing. Is it sane to have handle members when half of the time most of them are undef? (E.g. in ro open) One suggestion for the 'auto' encoding was to honor a BOM if it is present but default to ASCII otherwise. Or should we UTF-8 otherwise? Or what's in the environment...? And what about IO layers? :) What else belongs here? dirhandles, sockets? How are they specced? I was looking for a happy medium between overdwim and underlying library primitives level. [1] Should this be Perl(..5) style? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: alarm() and later()
On Wed, Apr 20, 2005 at 10:11:35AM -0700, Larry Wall wrote:
We will certainly be pushing all the time interfaces of Perl 6 toward
using floating-point time values. The only question is whether alarm()
is the right name for one of the interfaces, and whether we even need an
interface whose *default* behavior is to send a signal, ugh. We should
probably be encouraging timed callbacks instead. We could even force
people to define their own alarm if they want one. Assuming we
rehuffmanize kill to sendsignal or some such, we have:
(FWIW, this is called signalProcess in Haskell.)
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.cue(:delay($secs));
}
Though I suppose people really mostly just want something like
sub alarm ($secs) {
{ sendsignal $*PID, Signal::ALARM }.delay($secs);
}
The actual verb/adverb names are negotiable, but they need to handle
relative vs absolute times intuitively. Different words have different
connotations in that regard. delay is definitely relative, while
after tends toward absolute, though can be used relatively too.
at is definitely absolute time, but maybe too overloaded with
positional meanings. later is unfortunately completely ambiguous.
We also want repeat events; I can think of two ways to do it. Either
require everything to be explicit with adverbs, or have the closure's
return value determine whether to keep calling back or to quit. GLib
does the latter, and there's a cleanliness in how the closure itself can
control when to stop, but the former means you can schedule arbitrary
code without changing it.
Is there anybody from the perl-loop gang around here? I'm sure they've
thought about these things a lot.
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
alarm() and later()
Two things popped up while implementing a demo version of alarm() today. 1. In perl5 and in most underlying libraries, alarm() has 1 second granularity (and a possible 1 second error on top of that). Can we have the alarm builtin not assume the worst, and take a Num instead of an Int, so that on some systems at least we get higher resolution sleeps? 2. Since signals are so global and sometimes we want something else, how about a variation on the traditional u?alarm theme, in which you can pass an optional closure to alarm() that will get called back instead of having a SIGALRM raised? multi sub alarm(: Num ?$timeout = $CALLER::_, Num ?$interval, Code ?$callback) returns Int This should be reentrant and allow multiple uses. The Int return is an id on the future event so you can cancel it. (Which needs speccing. Possibly this could return a reference to some object instead of an id?) If the alarm builtin is getting too overloaded, I propose the closure version be named later. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Perl6 and Duff's Device
It looks like Duff's Device http://www.lysator.liu.se/c/duffs-device.html
won't be possible in Perl6. This is a shame.
sub duff ($from) {
# real life would use reference here, this is a demo
# dummy: simulate write to serial i/o port
my $to;
my $i = 0;
my ($n, $count);
$count = $from.chars;
$n = ($count + 7) / 8; # use integer in effect
%MY::«{l ~ $count % 8}».goto();
l0: do {$to ~= (substr $from, $i++, 1);
l7: $to ~= (substr $from, $i++, 1);
l6: $to ~= (substr $from, $i++, 1);
l5: $to ~= (substr $from, $i++, 1);
l4: $to ~= (substr $from, $i++, 1);
l3: $to ~= (substr $from, $i++, 1);
l2: $to ~= (substr $from, $i++, 1);
l1: $to ~= (substr $from, $i++, 1);
} while (--$n0);
return $to;
}
In Pugs at least, labels may only only be assigned to blocks. Any chance
the language gets to have them in more arbitrary places? Would this in
fact be enough to make this work?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
