On 12/11/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 09, 2005 at 01:45:21PM +0100, TSa wrote:
> : So, why not call the thing what it is---a set *type* declarator!
> :
> : set SmallInt of Int where { abs < 10 };
> :
> : set SomeNums of Num = (3.14, 4, 89, 23.42);
> :
> : set Bit of
On 29/12/05, Austin Frank <[EMAIL PROTECTED]> wrote:
> So, is there a conceptual connection between imposing named argument
> interpretation on pairs in an arg list and slurping up the end of a
> parameter list? Are there other meanings of prefix:<*> that relate to
> one or the other of these two
On 03/02/06, Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> LW> pugs -V:
>
> LW> This is Perl6 User's Golfing System, version 6.2.11, February 1,
> LW> 2005 (r8945) built for i386-linux-thread-multi
>
>
> not that this has anything
On 09/02/06, Mike Guy <[EMAIL PROTECTED]> wrote:
> Robin Houston <[EMAIL PROTECTED]> wrote
> > Any Code()simple closure truth match if $b->() (ignoring $a)
>
> I obviously missed that when it went past on p5p. Surely that should
> read
>
> Any Code()predicate(value)
On 10/02/06, Stuart Cook <[EMAIL PROTECTED]> wrote:
> IIRC, that rule exists so you can create when-clauses that don't
> involve the current topic, without having to explicitly throw it away.
> This is useful when using given/when to replace a sequence of elsifs,
> w
On 5/29/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
I discovered in reading Synopsis 12 today that some code examples use
out of date syntax, as I understand it:
For example, look in the "Roles" main documentation section.
There are many places where the bareword "self" is used, whereas I
beli
On 5/30/06, Michael Mathews <[EMAIL PROTECTED]> wrote:
I see now that those pointy braces take their contents literally, so
literally a key whith the characters "dollar, en". Not what I meant at
all! Thanks for the help.
The construct you're looking for is
%q«$n»
which may also be written
On 5/30/06, Stuart Cook <[EMAIL PROTECTED]> wrote:
The construct you're looking for is
(although in this case %q{$n} is probably more appropriate)
On 6/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
+$a # simple scalar variable
+@a[123]# single literal subscript
+%a{'x'}# single literal subscript
+%a # single literal subscript
+@a[+TERM] # single term coerced to numeric for array
+%a{~TERM}
On 6/18/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
Is there a construct in Perl 6 to express this more immediately?
Something along the lines of the following would seem ideal:
$foo, $bar, ( $baz if $wibble ), $quux
How about this:
pugs> sub infix:($x, $cond) { $cond ?? ($x,) !! () }; s
On 8/19/06, Larry Wall <[EMAIL PROTECTED]> wrote:
if 0 {
...
}
The one disadvantage of that approach is that it will break if the
"commented-out" code temporarily fails to compile. If that's a
problem, though, you could always write your own macro.
Stuart Cook
On 8/30/06, Damian Conway <[EMAIL PROTECTED]> wrote:
That's a little unfair. Choose good names and it's perfectly clear:
map { "Element $^array_index is called $^array_value" } <== @array.kv;
As an aside, though, doesn't that particular solution now implicitly
rely on the fact that ('inde
On 8/30/06, Mark Stosberg <[EMAIL PROTECTED]> wrote:
Regarding The S06 description of named arguments:
http://feather.perl6.nl/syn/S06.html#Named_arguments
What I find missing here is documentation of the signature to use
if you want to declare "I accept an arbitrary number of named
arguments".
On 5/15/05, Juerd <[EMAIL PROTECTED]> wrote:
> How does [EMAIL PROTECTED] know the difference between &postcircumfix:
> and
> &postcircumfix:?
Perhaps it checks how many different variations are actually
defined--if it finds only one, it can DWIM, and if it finds more than
one it can barf with an
On 5/19/05, Matt Fowles <[EMAIL PROTECTED]> wrote:
> All~
>
> What does the reduce metaoperator do with an empty list?
>
/me puts on his lambda hat
In Haskell, there is a distinction between foldl and foldl1 (similar
remarks apply to foldr/foldr1[1]):
The former (foldl) requires you to give an
To summarise what I think everyone is saying, []-reducing an empty
list yields either:
1) undef (which may or may not contain an exception), or
2) some unit/identity value that is a trait of the operator,
depending on whether or not people think (2) is actually a good idea.
The usual none(@Larry
On 5/19/05, Brad Bowman <[EMAIL PROTECTED]> wrote:
> Can't the appropriate identity just be prepended?
>
> > > my @a;
> > > [+] @a; # 0? exception?
> [+] (0, @a);
>
> > > [*] @a; # 1? exception?
> [*] (1, @a);
>
> > > [<] @a; # false?
> [<] (-Inf, @a); # ???
Wow, that's actually pretty elegant
On 5/24/05, Adrian Taylor <[EMAIL PROTECTED]> wrote:
> eval_is('undef + 1', undef, 'undef + 1', :todo); # dies
In this case, you're expecting
(undef) + 1
but you're getting
undef(+1)
instead.
This is because 'undef' serves double-duty as both 'undefined value'
and 'prefix op for undefining vari
On 5/26/05, Juerd <[EMAIL PROTECTED]> wrote:
> You could, if you changed the precedence of , to be tighter than =.
>
> However, by default, = has higher precedence than ,, so that you need
> parens to override this decision: @a = (1,2,3);
Is giving "=" a higher precedence than "," still considere
On 5/26/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
> my $a, $b = 1, 2; # $b should contain 2, not 1
> my @foo = 3, 4, 5; # @foo should contain (3, 4, 5), not (list 3)
>
> What justification for the status quo could be so compelling that we
> feel the need to prevent both of
On 6/1/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Should {} be an empty hash rather than an empty code?
Given that an empty hashref is probably much more useful than an empty
block, I propose that {} be an empty hash and {;} be an empty block.
This mirrors the fact that (AFAIK) { $_ => 1 } is a
On 6/2/05, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> > Why did we change { %hash } from making a shallow copy of a hash to
> > the code that returns %hash?
>
> Sorry, I don't understand this question. Do you want 'shallow copy'
> to mean 'take a ref'? Or Parrot/Pugs
On 6/3/05, Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> What I would like to be able to do is:
>
> my $str = 'hello';
> my @chars = $str.chars; #
I can't see this being a problem at all. For starters, the whole "what
is a character" issue is just as relevant to +($foo.chars) as it is to
list($foo
On 6/5/05, BÁRTHÁZI András <[EMAIL PROTECTED]> wrote:
> I've tried it on the feather.perl6.nl machine, with pugs. Is it the
> right behaviour?
Caller-side splatted arguments aren't yet implemented in Pugs. As far
as I know, the specced behaviour is still correct.
Stuart
It's possible that we could do the following:
1) All subs (and methods) are considered multi 'under-the-hood'.
2) If the first declaration is explicitly 'multi', then you (or
others) can provide additional overloads (using 'multi') that won't
trigger warnings.
3) If the first declaration /doesn'
On 7/8/05, Robin Redeker <[EMAIL PROTECTED]> wrote:
> Hi,
>
> i just wanted to ask what was about the method calling syntax on
> $self, and why does
>
>method ()
>
> not work for calling a method on $self? (like in C++)
IIRC, Larry wants to be able to distinguish method calls from sub
calls
On 7/26/05, Allison Randal <[EMAIL PROTECTED]> wrote:
> I'm looking for descriptions of the kinds of nodes in PIL. Below is
> what I gathered from digging through the source code (Compile.hs and
> Compile/PIR.hs). Could one of the lamdas correct the places where I'm
> misinterpreting the code and f
On 8/4/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> How can that possibly work? If a bare closure { } is equivalent to ->
> ?$_ is rw { }, then the normal:
>
> if foo() {...}
>
> Turns into:
>
> if foo() -> ?$_ is rw { }
>
> And every if topicalizes! I'm sure we don't want that.
>
> L
Stevan,
Up until today, I thought I had a good idea of how your metamodel
works, but now I'm confused. My main sticking point is that a class
Foo seems to have three different aspects:
Foo
class(Foo)
meta(Foo)
For each of these, could you please try to explain:
1) Roughly what its responsibilit
On 11/08/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> I'll have to think about the rest of your proposal, but I was suddenly
> struck with the thought that our "platonic" Class objects are really
> forms of undef:
>
> say defined IO; # prints 0
>
> That is, we already have an object of type IO
On 11/08/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> One that you missed was that this syntax:
>
>my Dog $spot .=new();
>
> Falls out of it quite naturally.
Actually I tried to mention that indirectly, but I'm glad you
explicitly mentioned it.
> On the other hand, there are ot
Hi,
What's the current meaning of type annotations on type-variables?
For example, if I say...
my Foo ::x;
...which of these does it mean?
a) ::x (<=) ::Foo (i.e. any type assigned to x must be covariant wrt. Foo)
b) ::x is an object of type Foo, where Foo.does(Class)
c) Something else?
I
On 22/08/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Output?
>
> sub foo (+$a, *%overflow) {
> say "%overflow{}";
> }
>
> foo(:a(1), :b(2)); # b2
> foo(:a(1), :overflow{ b => 2 }); # b2
I would have thought:
overflow b
Here's a suggestion:
Outside of argument lists, both a=>'b' and :a('b') (and friends) are
equivalent, and denote an ordinary pair value.
Within argument lists, both of them are special syntactic forms for
named arguments:
foo(a => 'b', :c); # both named args
If you want to pass pair values i
On 01/09/05, Ashley Winters <[EMAIL PROTECTED]> wrote:
> If list construction is via the &infix:<,> operator, does that mean a
> blasphemous sinner could create &infix:<,=> as a synonym for push?
If the self-assignment metaoperator works the way I think it does[1],
then you shouldn't even need to
On 03/09/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> A multi sub is a collection of variants, so it doesn't have arity,
> each variant has arity.
>
> I'd say it 'fail's.
But if the reason you're calling `&foo.arity` is to answer the
question "Can I call this sub with three arguments?" then that
On 19/09/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Part 1: fmap
>
> I have a plan for the $x »+« $y form (and also foo(»$x«, »$y«, »$z«)),
> but I don't want to go into that right now. It basically involves
> zipping the structures up into tuples and applying the function to the
> tuples.
Doe
On 19/09/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> This solution lacks the elegance of the lazy loading approach, but
> has the best responsiveness. These implementations tend to be overly
> complex for what they do, and hence not worth the maintenance costs.
>
> The gain is that the user only
On 20/09/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> The basic idea is that, alongside Functor, you have a Zippable theory
> which defines:
>
> theory Zippable[::T] {
> multi zip (T[::A], T[::B] --> T[:(::A, ::B)]) {...}
> }
>
> Where that last coloney madness is a yet-to-be-prop
On 22/09/05, Juerd <[EMAIL PROTECTED]> wrote:
> By the way, is it really this simple?
>
> class HTTP::Header is Pair {
> foo {
> "{.key}: {.value ~~ s/\n/\n /g}"
> }
> }
>
> Where "foo" is whatever is needed to override stringification.
Something along the lines
On 22/09/05, Juerd <[EMAIL PROTECTED]> wrote:
> I don't think +(~$pair) makes any sense, though. It's basically the same
> as +(~$pair.key). It's probably wise to avoid that $pair can be confused
> for its key or value. A good alternative is hard to find, though. I tend
> to prefer 1 at this moment
On 22/09/05, Shane Calimlim <[EMAIL PROTECTED]> wrote:
> How about something like:
>
> if ($condition) {
> pre;
> always { # maybe "uncond" instead of always, or both -- "always" could
> # mean 'ignore all conditions' and "uncond" could mean
> # 'ignore the current block's condition
> mid_section;
On 26/09/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 25, 2005 at 23:54:56 -0700, Ashley Winters wrote:
> > Localization occurs here. Formatting occurs here.
> > Timezone/newline-convention/join-character-specification/whatever
> > happens here
>
> This is going too far, IMHO.
I can't
The think I don't like about `foo( *$bar )` is that it's not clear
whether you're splatting a pair, or a hash, or an array, or a complete
argument-list object. This is probably fine for quick-'n'-dirty code,
but I'd like to encourage a more explicit style:
my %hash = (a=>'b', c=>'d');
foo( *%
The more I think about it, the more I'm convinced that perl6 (by
default) shouldn't refuse to run programs because of a (perceived or
real) type error. It should, of course, emit a compile-type type
*warning*, which can be silenced or made fatal at the user's
discretion.
There are a few reasons b
On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> What about whitespace?
>
> foo (a => 42); # Note space
>
> Is that the first case (subcall with named arg) or the second case (sub
> with positional pair)?
Sub with positional pair, since the parens aren't call-parens (because
of the spac
(It seems you're confused about my position because I was sloppy
presenting it. My apologies; hopefully this will clear a few things
up.)
On 10/10/05, Uri Guttman <[EMAIL PROTECTED]> wrote:
> Stuart Cook <[EMAIL PROTECTED]> writes:
>
> > The think I don't like
On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> So to pass a hash that has one element requires using the hash
> keyword?
I don't see a hash in your example, so I'm not sure what you're
referring to here.
> Specifically, if I say:
>
> @args = (a => 1, get_overrides());
>
> Then can I
On 11/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Luke's Tuple proposal, aka Luke's Grand Unified Object Model, is way not
> what we need for this. As far as I can see, LGUOM is an expression of
> "Haskell envy" of brobdingnagian proportion.
The reason I refrained from linking to theory.po
On 14/10/05, Stevan Little <[EMAIL PROTECTED]> wrote:
> So anyway, here are a few ideas, in no particular order:
>
>method bark (::Dog $d:) { ... }
># not sure if this notation is already taken or not
>
>method bark ($Dog $d:) { ... }
># not sure I like this one myself, but to me it
On 29/10/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Moving on.
>
> role Baz {
> does Bar;
> }
>
> By my free-derivation (or composition in this case, I guess)
> principle, Baz is now equivalent to Foo. If you think of them as
> interfaces, it makes perfect sense. Baz provides no
As a newcomer to the Pugs project, I figured I would try to first read
the code and understand what it does. Unfortunately, without a handy
architectural overview or a reference to all the various custom types,
that can be pretty tricky.
Thus I'm interested in adding documentation and comments to
On 4/29/05, Stevan Little <[EMAIL PROTECTED]> wrote:
> Autrijus had recommended beginning with src/Eval.hs and using the
> Haddock tool (http://haskell.org/haddock/). You are welcome to start
> right there.
I've made some headway in understanding Eval.hs, but it seems to rely
pretty heavily on AST
> What I refer to now is something that takes two {coderefs,anonymous
> subs,closures} and returns (an object that behaves like) another anonymous
> sub, precisely the one that acts like the former followed by the latter
> (or vice versa!).
Do you mean like the mathematical 'f o g'?
i.e. (f o g)(
If I understand correctly, so far we have the following meta-operators:
[ ]
circumfix meta-operator on infix operator which produces a prefix operator
>> <<
circumfix meta-operator on infix operator which produces an infix operator
=
postfix meta-operator on infix operator which produces an infi
On 5/6/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
(B> (snip) As long as each meta-operator
(B> explicitly knows what type of regular operator it accepts (and
(B> produces), there shouldn't be any problems with ambiguity.
(B>
(B
(BHaving posted that, I immediately t
On 5/6/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> I find this table very interesting, in that it shows the fundamental
> difference between reduce and the existing meta-ops.
Yep, that was basically the whole point of the table.
> The existing meta-operators alter the semantics of t
On 5/7/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> It might not be a problem -- I'm thinking we may end up tokenizing
> most or all of the meta operators, so that [+] would be considered
> its own token, and then the "longest matching token" rule
> would be sufficient to disambiguate the te
58 matches
Mail list logo
