Re: named arguments: What's the signature?

[Stuart Cook]

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". (Like the param() methods common in Perl5 do).


Go down one section and read "List parameters". (I agree that it's not
particularly explicit, and there probably should be a mention of it
under "Named parameters".)

A06 also says:

"A hash declaration like *%named indicates that the %named hash should
slurp up all the remaining named arguments (that is, those that aren't
bound explicitly to a specific formal parameter)."

This description should probably be copied to the Synopsis.


Maybe it's the slurpy hash?

sub foo (*%h) {...} ?


Correct.


Stuart

Perilous placeholder parameters

[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 ('index' lt 'value')?

I get the feeling that if people want to give meaningful names to
their $^ parameters, they'll have to learn to start putting
predictable alphabetic prefixes in front of them.
($^a_index/$^b_value?)

Perhaps the lesson is that if you want something more descriptive than
$^a/$^b, you should be using a pointy block instead ...


Stuart

Re: multi-line comments, C macros, & Pod abuse

[Stuart Cook]

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

Re: [svn:perl6-synopsis] r9463 - doc/trunk/design/syn

[Stuart Cook]

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}  # single term coerced to string for hash
+@a[SIMPLE] # any of these simples used as subscript recursively
+%a[SIMPLE] # any of these simples used as subscript recursively


Typo alert: that last one should be %a{SIMPLE}, right?


Stuart

Re: outdated/incorrect S12 examples

[Stuart Cook]

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
believe the current syntax is "$?SELF" for the same thing, and has
been for awhile.


Actually, I seem to recall `self` being accepted as the correct form,
though I can't remember exactly when that was.


I'm fairly sure the "self" syntax is invalid.


It's just a 0-ary sub call, I believe.


Moreover, S12 explicitly says that Perl 6 has no barewords, save
package names in specific circumstances.


I think that just means P6 has no
barewords-that-are-interpreted-as-strings. You still need to use
"bareword" syntax to write things like class names and subroutine
calls, after you've declared them.

Any "syntactic bareword" without a preceding declaration is assumed to
be a list operator that will be declared later. (Syntactic barewords
are also legal just before `=>`, which autoquotes.)


Stuart

Re: Smart match table

[Stuart Cook]

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,
> when not all of them use $_.

(In light of David's response, it seems what I wrote is not 100%
correct, so please ignore.)


Stuart

Re: Smart match table

[Stuart Cook]

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) match if $b->($a)
>
> meaning that $a satisfies the predicate implemented by the code $b?
>
> Ignoring $a seems a completely stupid thing to do.

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,
when not all of them use $_.

The problem, as I see it, is that you can't really have all three of
the following:
1) Sensible (symmetric, non-ignoring) behaviour of `~~`
2) Simple correspondence between `when` and `~~`
3) Sensible (dwimmy) behaviour of `when`

Currently, it's (1) that's been lost.  Now, personally I wouldn't mind
exchanging it for (2), but there certainly are valid reasons for
wanting to keep (2).


Stuart

Re: relationship between slurpy parameters and named args?

[Stuart Cook]

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 meanings?

The missing link is that prefix:<*> in an argument list also causes
things like arrays to be treated as a sequence of separate parameters,
rather than as a single array parameter.  See "Flattening argument
lists" in S06.

(This was the original meaning of prefix:<*> in arglists; the
named-pair behaviour was added later, when pair values ceased to have
named behaviour automatically.)


Stuart

Re: proposal: rename 'subtype' declarator to 'set'

[Stuart Cook]

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 Int = (0,1);
>
> Interesting idea.  I expect a bit of interference from the verb
> "to set", but that's probably not a showstopper, particularly since
> the next token isn't a variable.

I think 'subset' might be a nicer colour for this bikeshed.  For an
extra three characters you lose the confusion with "to set", and it
highlights the fact that you're (usually) declaring a *constrained*
subset of the original type.


Stuart

Re: Role Method Conflicts and Disambiguation (Theory-theoretic take)

[Stuart Cook]

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 additional
> implementations, nor imposes any additional requirements, and thus you
> must do precisely the same things to conform to Baz as to Foo.
>
> Baz: bar() default

You meant to write 'equivalent to Bar', not Foo, right?


Stuart

Re: Re(vised): Proposal to make class method non-inheritable

[Stuart Cook]

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 helps to re-
> enforce the singleton nature of the class instance
>
>method bark (Dog) { ... }
># this would be similar to functional languages where the
> parameter matches a value, not the type of a value.
># The user would then be forced to use $?CLASS inside (this one is
> probably too much B&D)
>
>classmethod bark { ... }
># you can't get more specific than this :)
>
> Okay, thats all for now, however, be on the lookout for some other
> mails on the specifics of class method dispatch. If we are going to
> do it, we need to do it right.

How about:

  method bark (Dog ::K:) { ... }

Where ::K must hold a class that is a subclass of Dog.  Or 'is a
subtype of', or 'does', or whatever the most correct term is in this
context.

(I seem to recall Damian mentioning something like this on the list
somewhere, but I might have misunderstood him and made it up myself.)

I do notice, though, that most of these class-method forms don't stand
out very well--maybe something like 'classmethod' might be best after
all, particularly if class methods aren't heavily used.


Stuart

Re: Sane (less insane) pair semantics

[Stuart Cook]

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.pod was that I didn't
want people getting distracted by a document that's 90% irrelevant to
what we're discussing here.

That other 10%, though, is Tuples--and they're exactly what's needed
for representing an argument-'list' in its entirety.  That is, after
all, a large part of what they were designed for.

>  A rule that says "splatting
> a list coerces all pairs into named args" works just fine. The
> corresponding rule, "accessing the parameters to your sub as a list (not
> using *%args) coerces all named args to pairs". Presto! Reversible, etc.

1)
What happens if that list is lazy?
You'd have to force the entire thing, just to check if there were any
pairs hiding in it.
What if it's an infinite list?
What if you can't know whether it's infinite or not?

2)
What if the list contains pairs, but you want to pass them as positionals?
What if it might contain pairs, but you're not sure?
What if you introduce a new named parameter (or change a parameter
name), and what you thought was a positional pair now becomes a named
arg?

Your suggestion would involve re-introducing some of the 'magic' that
real experience suggests we should be trying desperately to get away
from.

And look, if you really wanted to, you could define your own
splat-style operator that works exactly as you describe.  But I don't
think it should be the default.

> An alternative might be PHP-style arrays. But nobody wants that.

The key difference is that while a PHP-style array can't decide
whether it's an array or a hash, a Tuple *knows* that it has to be
both (and more), in order to accurately represent the full power of
Perl 6's argument system.

(Also, Tuples might end up being immutable, but don't quote me on that.)

> Tuple construction conflicts with a lot of things. Given the amount of
> new (to me, anyways) syntax proposed in the rest of the document, I'm
> surprised that LQe didn't unify lists and tuples (or push list
> construction elsewhere).

He very nearly does, actually (albeit with a handwave).  But Tuple
syntax (and the rest of theory.pod) is largely irrelevant here.  (I
personally think Ingo's `Tuple.new` might be sufficient.)


Stuart

Re: Sane (less insane) pair semantics

[Stuart Cook]

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 say
>
>   foo([EMAIL PROTECTED]);

Not if you want that a=>1 to be a named argument.

Under the proposal, the only ways to pass a named argument are:
1) By using a literal pair in the syntactic top-level of the arg list
2) By splatting a pair, hash, or arg-list-object

> Or will I, in the case of no overrides, get a positional pair instead of
> named a =>1 ?

The overrides have nothing to do with it.  That a=>1 will *always* be
a positional, because by the time it reaches the argument list, it's a
value (not a syntactic form).  The only way to use a pair-value as a
named argument is to splat it directly, or splat a hash or
arg-list-object containing it.  Splatting an array *never* introduces
named arguments, only positionals.


Stuart

Re: Sane (less insane) pair semantics

[Stuart Cook]

(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 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:
>
> but perl will know the type of the value in $bar and expand/splat it
> accordingly.

I realise that perl can cope with it--my concern was more for the
person reading the code.  Just like perl can cope without explicit
type annotations, but some of us will choose to write them anyway.

The idea is that when you (the human) see *%, you _know_ it's a named
splat, and when you see *@ you _know_ it's a positional splat.  With
*$, it could be either, depending on what's in the variable.  I agree
that sensible variable names and type annotations should make this a
minor issue, it's just that I'd sometimes like to add an extra sigil
for additional clarity.

And to clarify, as far as I'm aware, nothing I suggested here is new
syntax--just ways of combining existing explicit-deref syntax with (*)
to produce more self-descriptive code.

> >   my $pair = a=>'b';
> >   foo( *%$pair );  # view the pair as a 1-elem hash, and splat that
>
> the % there isn't a hash. perl can see the single pair and deal with
> that. the way to make this more readable is to use better variable
> names. $pair here is fine and *$pair would mean to splat it into the
> named arguments.

My understanding (possibly incorrect) was that the % 'derefs' the pair
into a one-element hash, in much the same way that %$href derefs a
hashref into a hash.  From there, *%$pair is exactly the same as:

  # there's probabaly a shorter way of writing this first line, but
I'm shooting for clarity :)
  my %hash = ($pair.key => $pair.value);
  foo( *%hash );

> >   sub returns_a_hash { ... }
> >   foo( *%{returns_a_hash} );  # call the sub, view the result as a
> > hash, and splat that
>
> isn't that what hash() is for? what is returns_a_hash really returning,
> a list or a hash ref because you can't return a hash (or can you this
> week? :).

My sloppy language again--the idea was that &returns_a_hash produces a
hashref, which is dereffed by %{}, and finally splatted.

> >   sub returns_an_array { ... }
> >   foo( [EMAIL PROTECTED] );  # call the sub, view the result as a
> > hash, and splat that
>
> where is the hash? wouldn't you want %{} in your system? and %{} derefs
> a hash and doesn't convert a list to a hash. that is what hash() does.

Sorry, that was meant to say "view the result as an array".  (I swear
I proofread that post!)

In summary:
1) I believe all my suggestions use currently-existing syntax (modulo
errors on my part)
2) Yes, the extra sigils/derefs are redundant, but sometimes we want
to be explicit
3) I don't particularly object to `foo( *$pair )` also working; this
is meant as an extra option


Stuart

Re: Sane (less insane) pair semantics

[Stuart Cook]

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 space), so they protect the pair.  It would probably be prudent
to emit a warning in this case, for obvious reasons.  (Actually, this
is one of the major problems with using parens to protect pair args.)

> What's the most complete way to get the sub's arguments?
>
> That is, for a sub that takes positional, optional, named, and variadic
> (*) arguments, what's the best mechanism for grabbing the entire call?

As far as I know there currently *isn't* a concise way to
capture/forward all (or some) of a sub's arguments; the closest thing
is:

  sub foo([EMAIL PROTECTED], *%named) { bar([EMAIL PROTECTED], *%named) }

Which is ugly and unwieldy.  I believe Luke was considering some kind
of 'unified arg-list object' which you could use to slurp and splat
entire argument lists, like so:

  sub foo(*$args) { bar(*$args) }

But I don't think it's been posted to the list yet.


Stuart

Re: Type annotations

[Stuart Cook]

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 behind this:

1) If I'm not using type annotations in my code, I shouldn't be forced
to go out of my way to satisfy the typechecker before my program will
even run, just because I used external subs that have (incompatible)
type annotations.  Of course, my program will fail at run-time when
the predicted type error actually occurs, but in this case we're no
worse off than in any other dynamically-typed language--and at least I
had advance warning from the compiler.

2) Even if a program has a compile-time type error, it may be possible
to use part of the program's functionality without ever encountering a
run-time type error.  If a program has two modes, A and B, and the
type errors are all in the code for B, it makes no sense to prevent
the program from running in mode A.  If I'm trying to fix run-time
bugs in A, I shouldn't have to repair B before I can even start.

3) perl6 should be quite capable of running an ill-typed program,
right up until the point at which a run-time type error actually
occurs.  Perl 6 isn't one of those languages that needs code to be
well-typed in order for the compiler/runtime to figure out how to
actually execute it.  (Well-typedness helps for optimisation, of
course, but it isn't *required*.)


Stuart

Re: Sane (less insane) pair semantics

[Stuart Cook]

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( *%hash );  # splat a hash as named arguments
  # => foo( a=>'b', c=>'d' );

  my $pair = a=>'b';
  foo( *%$pair );  # view the pair as a 1-elem hash, and splat that

  my $href = \%hash;  # or just %hash
  foo( *%$href );  # view the hashref as a hash, and splat that

  sub returns_a_hash { ... }
  foo( *%{returns_a_hash} );  # call the sub, view the result as a
hash, and splat that

  my @array = (1, 2, 3);
  foo( [EMAIL PROTECTED] );  # splat an array as positional arguments
  # => foo( 1, 2, 3 );

  my $aref = [EMAIL PROTECTED];  # or just @array
  foo( [EMAIL PROTECTED] );  # view the arrayref as an array, and splat that

  sub returns_an_array { ... }
  foo( [EMAIL PROTECTED] );  # call the sub, view the result as a
hash, and splat that

In this style, the splat character (*) is always next to a sigil (% or
@) telling you exactly how the arguments are being substituted (named
or positional).

I'm also a little wary of giving parens the power to change pair
behaviour, but the rules are simple enough that I can probably get
over it.  The other proposal, IIRC, was to have `named()` and `pair()`
special-forms for forcing the desired behaviour; these would only be
valid in argument lists.


Stuart

Re: numification and stringification of objects

[Stuart Cook]

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 speak for Ashley, but when I read that I assumed it meant things like:

  $num.as(Str, :scientific);
  $message.as(Str, :locale);
  $date   .as(Str, :calendar);
  $pair   .as(Str, :join< >);

Which you'll probably agree is a lot more sane.

> What I definately won't mind is a module that exports a lexical
> &*prefix:<~> (and thus otherwise augments interpolation) so that any
> stringification in a certain block of code is localized.

  {
# (The details might not be 100% accurate, but the intent should
#  be clear.)

temp &*prefix:<~> .= assuming(:locale);

say $message;  # localizes
say $message.as(Str, :locale(undef));  # default behaviour
  }

Something along those lines, anyhow.


Stuart

Re: conditional wrapper blocks

[Stuart Cook]

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;
> }
> post;
> }

That's quite elegant, but overloading `if` like that is completely
insane and unpredictable, because you can no longer assume that all
the code inside is tied to the conditional.

A more maintenance-programmer-friendly version might look more like this:

  # doesn't really matter what it's called, so long as it's not `if`
  sometimes $condition {
pre;
ALWAYS { body; }  # caps help too
post;
  }

Which is exactly the same, except that by using a different keyword,
we're telling the reader that the rules of `if` don't apply
here--there's going to be some unconditional code in the conditional
block.  This way, `if` always means 'if', rather than 'if, except on a
Tuesday'.

Mind you, this sort of solution is probably implementable purely as a
module, so if people don't think it's useful enough to go in core then
those who do need it won't really miss out.


Stuart

Re: Stringification, numification, and booleanification of pairs

[Stuart Cook]

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 (coincidentally, that's +?$pair).

While having stringification on everything is quite useful (for
debugging dumps, if nothing else), I'm wary of giving numification
behaviour to objects that simply can't produce a meaningful value.

If there's no (single) obvious interpretation of "turn a value into a
number" for a particular type, then don't struggle to come up with a
non-obvious one--I say just leave it undefined, or have it fail(), or
whatever.

Otherwise, if someone just says to himself "I think a pair is a
collection of two elements, so it will obviously numify to 2" and then
unknowingly gets `1` back, things can get confusing *real* quick.


Stuart

Re: Stringification, numification, and booleanification of pairs

[Stuart Cook]

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 of `method prefix:<~>`, IIRC.


> I am assuming that s/// does not mutate, because mutation isn't
> something I think a smart *match* operator should do. (To be honest, I
> don't think s/// and ~~ should belong together.) How does this actually
> work?

This always bugged me as well. I think it currently still mutates (for
culture-backwards-compatibility reasons), but I do think the match
operator needs to be distinguished from the substitute/translate
operator. We also need to be able to choose between copying and
mutation. In my view, smart-match (~~) should be first and foremost
about returning a meaningful boolifiable value.

(If people want to discuss it further it's probably best to start a new thread.)


> Also, it'd be nice to be able to say s/^^/ /g, but have it skip the
> first. There's :2nd, but is there also something like :(2...)th?

S05 has:
# Lists and junctions are allowed: :nth(1|2|3|5|8|13|21|34|55|89).

So I assume :nth(2...) would work as expected.

Oh, and remember to start putting your `:g`s at the start of the
substitution/rule :-)


Stuart

Re: Junctions, patterns, and fmap again

[Stuart Cook]

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-proposed tuple type
> (but tuples can be emulated if they are not in the core language, so
> it's no biggie).  That is, zip takes two structures and figures out
> how to combine them in a reasonable way into pairs of values.  So:
> 
> zip([1,2,[3,4]], [["a","b"], "c", "d"])
> 
> Gives:
> 
> [[:(1,"a"), :(1,"b")], :(2,"c"), [:(3,"d"), :(4,"d")]]

Oh, looks like I was way off. So in this particular scenario, when one
side 'runs out' of structure, that part degenerates to a one-side fmap
using the leaf value as the non-hyper arg.

Of course, this is the behaviour for /built-in/ arrays--it's up to the
person defining &fzip to determine how to handle their own Zippable
types. So, if they want &fzip to fail() on incompatible structures, or
do some other crazy thing, they can just put that in their version of
&fzip.

> So it's really up to the zippable functor itself to figure out the
> best way to zip.  After the structures are zipped up, you fmap the
> binary function on each of the tuples, resulting in a reasonable
> functor structure again.

Bottom line: user-defined &fzip turns two structures into one
structure of pairs (in whatever way the user deems reasonable), and
then &fmap transforms the tuples of that one structure.

For things like `foo(»$x«, »$y«, »$z«)` (assuming it ends up being
supported), you would either extend &fzip over n-tuples, or just use
pair-fzip repeatedly and reduce the nested pairs into a single
n-tuple.

> Nope.  Here it is.  And it was 22 lines. :-)
> 
> http://svn.luqui.org/svn/misc/luke/work/code/haskell/hyper.hs

Thanks, that made it a lot clearer. Haskell++ :)

I just hope you and I aren't the only ones who think this is a great idea...


Stuart

Re: Lazy lists and optimizing for responsiveness

[Stuart Cook]

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 has to wait for the first message,
> and if the throughput of the system is higher than the user's input,
> there is no responsiveness loss because something is always ready
> for the user to get at.
> 
> Ideally we could have the lazy list approach have some kind of way
> to modify the lazyness so that it's something in between -
> background eagerness - the lazy list is resolved in the background,
> accumilating to @messages. When @messages is filling up quickly the
> background resolution thread might get a lower priority. when
> @messages is empty, the receiver side has to block.

Initial reaction: I like it!

It's one of those "I always subconsciously wanted to do this, but
never knew it" ideas.

Essentially, if lazy means "don't force items until I ask for them",
and strict means "everything must be forced up-front", then async
relaxes both restrictions, saying "I don't need this list to be forced
up-front, but I also don't care if they end up forced before I use
them--just make each access as quick as you can".

Obviously, applying this to an /infinite/ list might be a bad idea
(unless you could specify a finite buffering limit)...

> Note: I have an idea of how easy I want this to be, but not how I
> want to do it.
> 
> I think that a nice solution is to allow an optional named adverb to
> gather which defaults to lazy:

More generally, it would be nice to have a sub &async_force (or
whatever) that takes a lazy list and produces an asynchronously
pre-forced one. Shortcuts for common cases (like gather/take) would be
nice too, though.


Stuart

Re: Junctions, patterns, and fmap again

[Stuart Cook]

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.

Does this mean that 'unary' (one-side) hyper would be
structure-preserving, but 'binary' (two-side) hyper would not? Or
would you take the final list of tuples and re-build a structure?

I guess it comes down to whether you want to allow binary-hyper on
values that aren't structurally equivalent.  Either you flatten both
structures to lists (which might be semantically dubious), or you
disallow binary-hyper on structurally distinct arguments (which might
prohibit some useful operations). Or you do something inconsistent.

(Have you written any of these deep details up somewhere? I'd love to
read them.)


> Part 2: Junctions
> 
> So my proposal is to make a Junction into a plain old Functor.  So
> what used to be:
> 
> if any(@values) == 4 {...}
> 
> Is now:
> 
> if any(@values) »== 4 {...}
> 
> And the only thing that makes junctions different from Sets (which are
> also Functors) is their behavior in boolean context (and their ability
> to be Patterns; see below).

I think this is really nice: we get rid of invisible junction magic,
yet accessing that magic explicitly is only one or two characters
away. Being able to pass junctions around as values (safely) is a nice
bonus too.


Stuart

perl6-language@perl.org

[Stuart Cook]

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 kind of
behaviour isn't going to help very much.

Which leads me to believe that instead of writing

  if &foo.arity == 3 { ... }

you should probably be writing something like this:

  if &foo.accepts(3) { ... }

Implying that you could also write:

  if &foo.accepts(:pos(1..3) :named :code) { ... }

None of this really answers the question "What should &foo.arity
return?", but my point is that most of the time you probably shouldn't
be calling it yourself anyway.  Better to tell the sub what you
actually intend to do, and let it make up its own mind (via its
Signature(s)).

> To get the arity you must tell it which variant yyou mean, either by
> providing enough of the prototype, eg
> 
> &foo(Any).arity   vs   foo(Any, Any).arity

Unfortunately, that particular syntax is going to end up *calling*
&foo (unless of course you make .arity a special form).


Stuart

Re: @array = $scalar

[Stuart Cook]

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 create &infix:<,=> yourself -- it
should work automatically.


Stuart

[1] i.e. magically applies itself to any valid infix operator, just
like »« and [] do

Re: Demagicalizing pairs

[Stuart Cook]

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 into a sub, either use an intermediate
variable...

  my $pair = :a;
  foo($pair);  # not a named-arg call

...or else find new syntax to disambiguate:

  foo( (a => 'b') );  # ok, so maybe parens aren't such a good idea

Or just use existing language constructs:

  foo( do{a=>'b'}, {:c;}() );  # both positional args

And if you explicitly want to use individual pair values as named
args, just exploit the fact that a pair can act like a one-element
hash, and splat it:

  my $arg = :echo;
  foo( *%$arg );  # yes, I know it's three symbols

Then the only magic rule most people need to remember is:

  "Pair syntax denotes named-arg passing, but only in an arg list."

Magic can never be hidden (or happen accidentally), people can
explicitly circumvent the default behaviour, and the whole system has
very little inconsistency.

Thoughts?


Stuart

Re: *%overflow

[Stuart Cook]

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   2
i.e. %overflow = (b => 2)

Because :overflow() is an unrecognised named argument, so it goes in the slurpy
hash.  The fact that the hash has the same name as the argument is a
coincidence--does it make sense to explicitly name a slurpy when you can just
splat *{ b => 2 } in directly?

> foo(:a(1), :overflow{ b => 2 }, :c(3));  # ???

overflow   b   2
c  3

Of course, that's just my way of thinking.

(Also, last I heard you /could/ have multiple slurpy hashes, but any after the
first would always be empty.)


Stuart

Re: Classes as special undefs

[Stuart Cook]

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 other things that don't work quite so well:
> 
>my Dog $spot;
>$spot.can('bark');# Not until he's instantiated...

Are you objecting to the fact that it can't possibly return a valid
method, or that it will inappropriately true/false (depending on your
point of view)?

> On the gripping hand, maybe you should have to ask the metaclass about
> that anyway:
> 
>$spot.meta.class_can('bark');#No
>$spot.meta.instance_can('bark');#Yes

Yeah, but if we're trying to view (undef but Dog) as the platonic
instance of Dog, it would be nice if told us what the ideal Dog can &
can't do.  (In either case, the metaclass will be able to tell us.) 
Something to ponder, I suppose.


Stuart

Classes as special undefs

[Stuart Cook]

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 that doesn't really
> have a value yet.  And maybe that's the real difference between the
> class object and the metaclass object.  And maybe we can reason
> about objects of type IO without worrying about the definedness,
> if all classes already include their own personal undef.

Wow, that's crazy enough to actually work!

This approach has a few nice properties:

* It neatly handles the fact that 'platonic' instances only kinda-sorta 
exist by making them undefined.  You can answer hypothetical questions
about instances in general, but as soon as you try to treat undef
as an actual instance of something (rather than just dispatching to
the class) you'll encounter an error.

* Classes don't have to be considered first-class objects (beyond being
the type of certain special undefs); they can be their own kind of 
thing, and if you want to treat them as objects you can just use the
metaclass.

* It puts up quite a clear barrier between the responsibilities of the
class (dispatch class methods and initialisers, but don't actually
/do/ anything) and the metaclass (act as the class's representative
in object-space).

Am I thinking along the same lines as you?


Stuart

Typed type variables (my Foo ::x)

[Stuart Cook]

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 seem to recall Damian suggesting (a) in order to solve the "what's
the invocant type of a class method" problem[1], but I wasn't sure
whether it was already canon.

Also, can I do crazy stuff like this?

my $a = ::Foo;
my ::$a $obj;  # analogous to @$x, where $x is an arrayref


Thanks,

Stuart


[1] 

Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)

[Stuart Cook]

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 responsibility is (and how it relates to the others)
2) Whether it is actually an object
3) If so, what its class is

I realise that some of these details are probably spread around
Synopses, source code, and the inside of your own head, but it would
really help to have a concise, clear definition of each.

So far, this is what I have picked up; some/most of it is probably wrong:

~ Foo ~
Is a type that variables etc. can be declared to have
Is not an object
  => I'm really not sure about this...

~ class(Foo) ~
Used as the invocant of class methods
  => Any other purpose?
Is an object; instance of the 'Class' class
  => How do we get properly-typed access to members that class(Foo) has
 that aren't declared in 'Class'?

~ meta(Foo) ~
Members contain info /about/ Foo, rather than /of/ Foo
  => This is to avoid name-clashes with 'name', 'authority' etc.
Is an object; instance of the 'MetaClass' class


Thanks,
Stuart

Re: If topicalization

[Stuart Cook]

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.
> 
> Luke


Here's one solution:

1) Bare blocks don't topicalise if you call them without an argument.

2) 'if' doesn't pass the value of the condition to its body, _UNLESS_
the body is incapable of accepting 0 arguments.


This means:

* The most common case, "if foo() { ... }", won't topicalise.

* If you /really/ want to access the value of the conditional, you can
say one of:
if foo() -> $_ { ... }# topicalise
if foo() -> $cond { ... } # don't topicalise
and 'if' will give it to you.

* The bare-block-to-pointy-sub rewrite rule is preserved, because a
bare block's parameter is optional.

Is there anything I've failed to take into account?


Stuart

Re: method calls on $self

[Stuart Cook]

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, so that when you see 'foo()' inside a method, you know that
it's NOT using $?SELF.  If you want to call a method, either use an
explicit self, or use './method'.

(As a side note, putting space between the sub/method name and the
call parentheses is now disallowed.  If you must have the space, you
need to use '.()'.)


Stuart

Re: SMD is for weenies

[Stuart Cook]

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't/ use 'multi', then defining
another sub/method of the same name triggers an error/warning. BUT,
later declarations can override this by using some sort of special
declaration.


e.g.

sub foo(Int $x) { ... }
sub foo(Str $x) { ... } # error/warning

multi sub foo(Int $x) { ... }
multi sub foo(Str $x) { ... } # ok

sub foo(Int $x) { ... }
sub foo(Str $x) is overload { ... } # ok; not sure about the trait name


This provides uniqueness checking for SMD subs by default, while still
allowing hardcore hackers to overload other people's subroutines
without their explicit consent.  It's not as clean as Yuval's
suggestion, but I think it might be more acceptable to folks who are
used to SMD.


Stuart

Re: "flattening arguments"

[Stuart Cook]

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

Re: Revisiting .chars (and friends) in list context

[Stuart Cook]

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.chars).

Secondly, the "use bytes/codes/graphs/langs" pragmata should be
sufficient to define what a character is in any dynamic context. The
whole "should we decompose ligatures?" question (raised in the earlier
thread) can be answered by the appropriate "use langs".

And finally, it should be easy enough to do the efficient thing in
scalar context.


Stuart

Re: Empty hash

[Stuart Cook]

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 level COW?

I think he means "Why does it produce a Code (which happens to return
%hash), instead of a (ref to a) new hash that starts out with the same
k/v pairs as %hash, but thereafter can be modified independently?"


Stuart

Re: Empty hash

[Stuart Cook]

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 hash and { $_ =>
1; } is a block.

Alternatively, it could be a special hash that can also be called (and
which does nothing), but I doubt that's useful or desirable.


Stuart

Re: (1,(2,3),4)[2]

[Stuart Cook]

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 these from doing the 'natural' thing?

(Scanning through the the history of this thread, I noticed the link
to Larry's comment about the precedence of "=" and ",". I personally
would still prefer them to be changed, but I guess it's not a big
deal, as long as we have warnings to catch obvious-but-wrong code like
my suggestions. When in doubt, use parens...)

Re: (1,(2,3),4)[2]

[Stuart Cook]

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 considered A Good Thing?

I'm not familiar with the reasoning behind the current situation, but
I'm struggling to come up with any good reasons for keeping it.

Consider the alternative:

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 these from doing the 'natural' thing?


Stuart

Re: reduce metaoperator on an empty list

[Stuart Cook]

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, and it has the benefit of
explicitly TELLING the reader what you intended to do.

Another option (depending on your situation) is to use 'err' to
replace the resultant 'undef' with a value of your choosing, i.e.

[*]  @coefficients   err 1;
[+]  @scores err 0;
[&&] @preconditions  err 1;

etc. (assuming I got the precedence right)

I think all these rather nice workarounds, combined with the hairiness
and complexity of trying to come up with default answers, make a
really strong case for undef/fail being the right choice here.


Stuart

Re: reduce metaoperator on an empty list

[Stuart Cook]

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) disclaimer applies, of course...


Stuart

Re: reduce metaoperator on an empty list

[Stuart Cook]

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 explicit 'left unit'[2],
which is implicitly added to the left of the list being reduced. This
means that folding an empty list will just give you the unit.

i.e.
foldl (+) 0 [a,b,c] = ((0+a)+b)+c
foldl (+) 0 [] = 0

The latter (foldl1) doesn't use a unit value, but this means that you
can't fold empty lists.

i.e.
foldl1 (+) [a,b,c] = (a+b)+c
foldl1 (+) [] = ***error***


/me puts camel hat back on

This suggests that []-reducing an empty list should probably (IMO) do
one of the following:

* Fail, since it's an ill-defined operation without an explicit unit
* Try to find a suitable unit value (see below), and fail if it doesn't find one

You /could/ try to do something 'sensible' and return 0 or undef, but
this seems likely to result in more confusion.

Another alternative is to give the user the option of specifying such
a unit when using the reduction meta-operator, but this seems to work
against the whole point of [+] (which is brevity). If you want to
specify your own unit, use '&reduce'.

> my @a;
> [+] @a; # 0? exception?
> [*] @a; # 1? exception?
> [<] @a; # false?
> [||] @a; # false?
> [&&] @a; # true?
> 
> Also if it magically supplies some correct like the above, how does it
> know what that value is?
> 

Perhaps the operator could have some kind of 'unit' trait? (Or perhaps
'left_unit' and 'right_unit'?)


Stuart

[1] Just remember that unlike foldr/foldl, which are explicitly
right/left associative, [+] is 'DWIM-associative', reflecting the
associativity of the underlying operator.

[2] e.g. 0 is the left (and right) unit of + because 0 + x == x (and x + 0 == 0)

Re: Plethora of operators

[Stuart Cook]

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 error message complaining about an "ambiguous
postcircumfix operator" or somesuch. In that case, you may have to
write it out longhand.

If we combine this with Damian's [EMAIL PROTECTED] instead of [EMAIL 
PROTECTED], this should
cover most cases fairly cleanly. If your postcircumfix operators are
that ambiguous, you should probably be writing things out longhand
anyway.


Stuart

Re: reduce metaoperator

[Stuart Cook]

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 terms:
> 
>   $x = [+1, -2, +3]; # token [ indicates a term
>   $y = [+] @stuff; # token [+] indicates a meta-op prefix operator

Does that mean postfix meta-ops that modify syntax become possible?
(Not necessarily a good idea, mind you, but possible...)


Stuart

Re: reduce metaoperator

[Stuart Cook]

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 the opoerator, but
> don't really change its syntax; a unary operator is still unary, a
> binary operator is still binary, and so on.  Reduce is irreducibly
> (pardon the pun) different, in that it alters the syntax as well as
> the semantics.

I was thinking of restricting the ways in which meta-ops can alter the
syntax of an op, but now I think we're better off not letting it
happen at all. Meta-ops that redefine syntax would be very hairy for
the compiler (as I pointed out), and probably wouldn't buy us much
that you couldn't achieve with a macro anyway.

> That would result in the following syntaxes:
> 
> reduce { $^a / $^b } @foo;
> reduce [/] @foo;
> 
>$sum = reduce[+] @array;
>$fact = reduce[*] 1..$num;
>$firsttrue = reduce[||] @args;
>$firstdef = reduce[//] @args;
>@sumrows := reduce[+«] @rows;
>@foo[0..9; reduce[;](@dims); 0..9]

I personally like that, and it has the additional property of avoiding
the "[+] @foo" vs. "[+1, -2]" ambiguity I pointed out.

Furthermore, it makes it /much/ easier for newbies to figure out what
that code actually does (since they can just grep for 'reduce' in the
docs).


Stuart

Re: reduce metaoperator

[Stuart Cook]

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 thought of some problems:
(B
(BIf a meta-operator has
(B{meta-fixity => prefix|circumfix, result-fixity => prefix}
(Bthen it can be confused with a term, e.g.:
(B
(B$x = [+1, -2, +3]; # opening [ indicates a term
(B$y = [+] @stuff; # opening [ indicates a meta-op producing a prefix operator
(B
(BThis might confuse the parser, though I suppose you could always try
(Bboth possibilities and see which one works.
(B
(BThe second problem is if a meta-operator has
(B{meta-fixity => postfix, argument-fixity => x, result-fixity => y}
(Bwhere (x != y).
(B
(B# Imagine '$B!}(B' is a meta-postfix taking an infix and and returning a 
(Bprefix.
(B# The parser will reject (J\(B, because it doesn't know to expect
(B# an infix op until it reaches the $B!}(B.
(B@x = (J\(B$B!}(B @z;
(B# The parser might assume that + is prefix (since a term is expected),
(B# then have to go back and treat it as an infix instead.
(B$x = +$B!}(B $z;
(B
(BThis will /really/ confuse the parser, and should probably (IMO) be outlawed.
(B
(B
(BStuart

Re: reduce metaoperator

[Stuart Cook]

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 infix operator

>>
prefix meta-operator on postfix operator which produces a postfix operator

<<
postfix meta-operator on prefix operator which produces a prefix operator

In other words:
+-+---+-++
| Meta-op | is| operates on | to produce |
+-+---+-++
| [ ] | circumfix | infix   | prefix |
+-+---+-++
| >> <<   | circumfix | infix   | infix  |
+-+---+-++
| =   | postfix   | infix   | infix  |
+-+---+-++
| >>  | prefix| postfix | postfix|
+-+---+-++
| <<  | postfix   | prefix  | prefix |
+-+---+-++

>From this table, we can see that [ ] is the only meta-operator that
produces a different 'type' of operator from that which it accepts,
which might be where the confusion lies. As long as each meta-operator
explicitly knows what type of regular operator it accepts (and
produces), there shouldn't be any problems with ambiguity.

Re: Cmmposition binop

[Stuart Cook]

> 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)($x) == f(g($x))

Maybe we could just use 'o'.

(Too bad we can't use Haskell's 'f . g'...)


Stuart