Lazyness and IO
I was thinking about lazyness and IO and worked out this potenial
gotcha. In essence its quite simmler to the pipe buffering problems
you sometimes can get in perl5.
my IO $news = io("nntp://nntp.perl.org",:rw); # Open a nntp connection
my $banner = =$news # Throw away the banner. So far so good.
say($news,"group perl.perl6.language"); # Also no problem
my $status = =$news;
say($news,"listgroup");
my @artical <= grep { True .. /^.$/ } <= for =$news; # Is this
# construction
# right? Anyway
# you should get
# what I'm trying
# todo.
say($news,"article @artical[0]");
for =$news -> {say};
# What happens at this point? Lazyness means that only the first
# artical number has been read. Does my for loop here have the side
# effect of causing the rest of artical list to be read into @artical?
# This is what I would hope would happen.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
Re: The Use and Abuse of Liskov
Luke wrote: A variant a is said to be _more specific than_ a variant b if: * Every type in a's signature is a subset (derived from or equal) of the corresponding type in b's signature. * At least one of these is a proper subset (not an equality). A variant is dispatched if there is a unique most specific method applicable to the given arguments. That is, there exists an applicable variant a such that for all other applicable variants x, a is more specific than x. How did you think pure ordering worked? Were we arguing over different definitions of that algorithm? Yes. I had wrongly assumed that the algorithm required "orderability" along all paths. Some (though not all) of my arguments were indeed predicated on that assumption, and are hence invalid. I obviously need to reconsider your (actual ;-) proposed dispatch scheme, almost certainly by playing with Class::Multimethods::Pure. I'll try to make time to do that this week, though with OSCON looming, my tuits are even more pitifully limited than usual. Thanks for persevering with this, Luke (and everyone else). It's this kind of passionate commitment to finding the best possible design solutions that has made/is making/will make Perl 6 insanely great. Damian
Re: Curious use of .assuming in S06
On Fri, Jul 29, 2005 at 12:53:03PM -0700, Brent 'Dax' Royal-Gordon wrote:
> Autrijus Tang <[EMAIL PROTECTED]> wrote:
> > In S06's Currying section, there are some strange looking examples:
> >
> > &textfrom := &substr.assuming(:str($text) :len(Inf));
> >
> > &textfrom := &substr.assuming:str($text):len(Inf);
> >
> > &woof ::= &bark:(Dog).assuming :pitch;
> >
> > Why is it allowed to omit comma between adverbial pairs, and even
> > omit parens around method call arguments? Is .assuming a special form?
>
> Isn't this just another form of the syntactic rule that gives us
> @array.grep:{ ... } ?
I thought that only applies to adverbial blocks, not arbitary
adverbial (named) pairs. Hm, S04 uses this:
leave :from(Loop) :label <== 1,2,3;
So maybe this is as intended? (If so, tests welcome. :-))
Thanks,
/Autrijus/
pgpBmDywDzHtW.pgp
Description: PGP signature
Re: Curious use of .assuming in S06
Autrijus Tang <[EMAIL PROTECTED]> wrote:
> In S06's Currying section, there are some strange looking examples:
>
> &textfrom := &substr.assuming(:str($text) :len(Inf));
>
> &textfrom := &substr.assuming:str($text):len(Inf);
>
> &woof ::= &bark:(Dog).assuming :pitch;
>
> Why is it allowed to omit comma between adverbial pairs, and even
> omit parens around method call arguments? Is .assuming a special form?
Isn't this just another form of the syntactic rule that gives us
@array.grep:{ ... } ?
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Curious use of .assuming in S06
In S06's Currying section, there are some strange looking examples: &textfrom := &substr.assuming(:str($text) :len(Inf)); &textfrom := &substr.assuming:str($text):len(Inf); &woof ::= &bark:(Dog).assuming :pitch; Why is it allowed to omit comma between adverbial pairs, and even omit parens around method call arguments? Is .assuming a special form? This is S06-specific; neither A06 nor E06 exhibits this syntax. Thanks, /Autrijus/ pgpDDyLumBz2q.pgp Description: PGP signature
Re: lazy list syntax?
Just wondering - would 'reverse =$foo' call '$foo.previous()' ? - Flavio 2005/7/29, Aankhen <[EMAIL PROTECTED]>: > On 7/29/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote: > > Is "for =" only for filehandles? I tried: > > No, it's for anything that supports iteration... `=$foo` == > `$foo.next()`, if I recall correctly. It's probably not yet > implemented. > > Aankhen
Re: Slurpy "is rw" arrays ([EMAIL PROTECTED] is rw)
HaloO,
Adriano Ferreira wrote:
Only
sub foobar (@args) { push @args, 42 }
would change @some_array in
foobar @some_array;
That is how I undestood that. Can someone confirm this belief?
I share your belief. It's up to others to confirm it. I just
want to add that I further believe that the push call is dispatched
on the type of the array and only succeeds if @array.does(Pushable).
I guess a default array does this or another role that implies it.
--
$TSa.greeting := "HaloO"; # mind the echo!
Complete type inferencing
On Fri, Jul 29, 2005 at 04:59:21AM +0800, Autrijus Tang wrote:
> However, my intuition is that a soft-typed system, with clearly defined
> dynamic parts translated to runtime coerce and dependent types, that can
> work exactly as Perl 5 did at first, but provide sensible inferencing
> and compile-time diagnostics as you gradually provide annotations, is
> really the way forward.
Several people replied off-list to point out the SBCL/CMUCL system does
inferencing and static+runtime type tagging for Common Lisp. After
playing with it a bit, it seems that "soft typing" does not naturally
describe my initial intuition, as it never rejects any programs.
When types cannot be inferred, it merely inserts runtime assertions.
What I'm designing is a system that can decide on one of five classes of
judgements for each PIL term:
0. Untyped
As in Perl 5, nothing is done for $x or the call to $x.close.
Runtime failures are never detected until the actual call is made.
sub f (Any $x) { $x.close }
f(42);
1. Asserted
The usual case for Perl 6 functions, due to its default "Item"
signature for parameters. In the example below, I assume that ::* cannot
be changed freely to do away with ::*IO at runtime. (If it could, then
assertions won't be of much use in general.)
sub f (IO $x) { $x.close }
f(open('/etc/passwd'));
As both &f and &open may be rebound at runtime, we cannot guarantee that
this will not go wrong. However, we can insert an runtime assertion for $x
in &f's scope, so we can avoid doing the same assertion in &*IO::close
again. If IO is declared as final, then &*IO::close can also be resolved
statically.
2. Well-typed
This term's type is provably sound, and can be optimized at will
without any runtime checks. An example:
{
my sub f (IO $x) { $x.close }
my sub g () returns IO { open('/etc/passwd') }
f(g());
}
Here the call to &f and $x.close doesn't need assertions, as &g's return
type took care of it. Under "use optimized", many more terms can be
resolved statically and checked in this manner.
3. Warning
Under certain circumstances, this term's type can be shown to be unsound,
but we cannot prove statically that this will come to pass:
my sub f (IO $x) { $x.close }
my sub identity ($y) returns IO|Str { $y }
f(identity("/etc/passwd"));
Here the call to &identity masked a potential type incompatibility.
We know that if the IO half of the junctive type is chosen then it
will typecheck; on the other hand, nothing in &identity or $y tells
whether it will return IO or Str. Hence we can raise a warning that
says "this call can potentially go wrong had it returned Str".
4. Error
This is a type error:
my sub f (IO $x) { $x.close }
f("/etc/passwd");
Note that this can still be made to work at runtime by introducing
&coerce: from Str to IO, or make Str a subtype of IO. Therefore
in the absence of optimization hints of "closed" for Str and "final"
for IO, the compiler should only raise a severe warning, that says
"if you don't do something, this will fail at runtime".
However, if the user had provided the neccessary optimization hints:
use optimize :classes< close finalize >;
my sub f (IO $x) { $x.close }
f("/etc/passwd");
Then there is no way it could have worked, and the compiler should
reject this program.
Interested readers can consult Manfred Widera's similar work for Scheme,
in his "Complete Type Inference in Functional Programming" paper.
Feedback, preferably on-list, are most welcome. :-)
Thanks,
/Autrijus/
pgp5buvcnk4pn.pgp
Description: PGP signature
Re: Slurpy "is rw" arrays ([EMAIL PROTECTED] is rw)
On 7/29/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Or is @args always readonly and the declaration ([EMAIL PROTECTED] is rw) is
> an
> error?
The declaration ([EMAIL PROTECTED] is rw) can't be outlawed as it is how Perl 5
default sig translates to Perl 6.
IMHO @args as a parameter works like a 'my' variable in subroutine
scope. In C arguments will be copied and (possibly) flattened (as
the parameter is slurpy) and stuffed into @args. In C it is the
same, but instead of copying, the elements of @args will be aliased to
the actual parameter items. And the point here is "aliased to
parameter ITEMS".
If you change @args with a 'push' or other operation that changes the
array, not its elements, it changes the subroutine variable, as the
connection to @some_array were lost, leaving in the case of bar the
connection to the elements of @some_array.
In conclusion,
foo @some_array;
bar @some_array;
are both ok, but changes are not seen from the caller's perpective, as
'push' operated on subroutine parameter @args.
Only
sub foobar (@args) { push @args, 42 }
would change @some_array in
foobar @some_array;
That is how I undestood that. Can someone confirm this belief?
Adriano.
Re: An idea for doing pack.
On Thu, 28 Jul 2005 15:46:14 +0300, Yuval Kogman
<[EMAIL PROTECTED]> wrote:
[...]
> I like your Pack object - that is the parsed template, but I'd also
> like to be able to generate these templates with a programmatic
> interface that isn't string concatenation...
>
> Is it just a simple data structure? Or do you have anything in mind?
I was thinking of having it compile down to as close to native code as
possable. But this may be premature optimization.
> Will we have more powerful nesting? I think this is in order
> nowadays.
Thinking about it the declarations are very similar to (un)pack
templates. So it may be possable to build them up from them. If my
compile template macro took a name and that name was then treated as a
new declaration we could do something like this.
Pack::compile byte {
@^_ :=: { pack => &chr, unpack => &ord }
}
Pack::compile null {
0x00 :=: byte
}
Indeed I can see the pack module as creating all of the builtins this
way. Further more this approach makes it concivable to have a set of
methods on the Pack object itself for example.
method Pack::declaration() returns Array of Pack
is doc("The declarations that this pack consists of in the
order of there application") {...}
method Pack::packer() returns Code is doc("The code that will
be run to pack using this pack object") {...}
method Pack::unpacker() returns Code is doc("The code that will
be run to unpack using this pack object") {...}
Mm if we have something that returns previousely defined
delarions and a constructor.
method Pack::declaration(::Class $class,Str $name) returns Pack is
doc("The Pack object which corrasponds to this declaration") {...}
method Pack::new(::Class $class,@declaration of Pack) returns
Pack is doc("Create a new Pack object composed of declarations") {...}
This would allow the best of both worlds. A template based system for
those of us who are creating our Pack's at compile time, and also an
OOish programmatic interface for thouse of us who need something more
convenient then string concatination.
> Actually, to be really wicked, I think that packing is just applying
> rules in reverse (this is tricky and indeterminate, since there are
> no alternatives or options in unpacking/packing), and unpacking is
> the opposite, with two exceptions:
>
> captures are converted by looking at the binary data and
> interpreting it, not just stuffing it in a string
>
> the syntax is different
The other diffrence is that unpacking makes use of pattens of fixed
length so it doesn't need to parse its input.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
Slurpy "is rw" arrays ([EMAIL PROTECTED] is rw)
Hi,
are the following assumptions correct?
sub foo ([EMAIL PROTECTED]) { push @args, 42 }
sub bar ([EMAIL PROTECTED] is rw) { push @args, 42 }
foo @some_array; # dies ("Can't modify constant array...")
bar @some_array;
# works, but does not change @some_array, as the * causes &bar to
# receive a *new* array (which happens to contain @some_array's
# elements), right?
# @args is only an array constructed by the parameter binding code;
# @args =:= @some_array is false (consider bar(@some_array, 42)).
bar 1,2,3; # works too
Or is @args always readonly and the declaration ([EMAIL PROTECTED] is rw) is an
error?
--Ingo
--
Linux, the choice of a GNU | Perfection is reached, not when there is no
generation on a dual AMD | longer anything to add, but when there is
Athlon!| no longer anything to take away.
Re: lazy list syntax?
On 7/29/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote: > Is "for =" only for filehandles? I tried: No, it's for anything that supports iteration... `=$foo` == `$foo.next()`, if I recall correctly. It's probably not yet implemented. Aankhen
