equivariant functions

[Bill Baxter]

On Wed, Oct 15, 2008 at 9:27 AM, Bill Baxter <wbaxter at gmail.com> wrote:
> I'm looking at all these funky syntaxes with their many unusual
> implicit assumptions that they require a user to keep in mind, and
> thinking it would all be a lot simpler if you could just declare some
> template-like meta-variables in a preamble to the function.
>
> I also don't like the looks of using a symbol in the return type that
> doesn't get declared till you see the parameter list.
>
> So how about introducing a "typedef block" where you can introduce
> metatypes and give them constraints.
>
> For constness:
>
> typedef {  Const : const }  // in this case means any kind of const
> Const(int) someFunc(Const(int) z) { ... }
>
> For Objects:
>
> class BaseClass {}
> class DerivedClass : BaseClass {}
>
> typedef { DType : BaseClass } // DType is anything passing  is(DType :
> BaseClass)
> DType someFunc(DType input)
>
> For both:
>
> typedef {
>  DType : BaseClass;
>  Const : const
> }
> Const(DType) someFunc(Const(DType) input)
>
> And with something like this you can also come up with some solution
> to the min problem
> typedef{
>   ConstA : const;
>   ConstB : const;
>   ConstC = maxConst!(ConstA,ConstB)
> }
> ConstC(Type) max(ConstA(Type), ConstB(Type))
>
> maxConst would be some template-like thing func to take the "more
> const" of the two qualifiers.  Not sure how you'd implement that.
>
> Lots o hole's there, but the basic idea I'm suggesting is to declare
> the types and qualifiers that can vary in some sort of a preamble
> block.  To me this looks like it will be much more readable and easier
> to maintain than any of these funky syntaxes with lots of implicit
> rules to remember.

Actually, let me take a step back from any concrete syntax.  What I
think would be an easy-to-read and easy-to-use system would look like
this in pseudocode:

  let "Const" be any kind of constness
  let "BType" be any kind of object derived from BaseObject
  in the following declaration:
  Const(BType) theFunction(Const(BType) x, string y) { ... }

In other words, *first* explicitly give names to the things that will
vary, *then* use those names in the method signature.

I think this will be much easier to use and more flexible than making
up a bunch of rules with the aim of implying the same things via
subtle variations of the basic declaration syntax.

--bb