Re (tilly) 1: Polymorphic prototypes? (creating new syntax)

The problem with having multiple prototypes for the same function is that Perl doesn't know how to dispatch on the prototype. (An idea from C++ which people have mixed opinions on.)

I would use intuitive solution 2 and use the sub keyword to generate closures on the fly. That is instead of typing

my_func {block1} {block2} $arg;
[download]

you would type:

my_func(sub {block1}, sub {block2}, $arg);
[download]

Now if that is not the syntax you want, you can try (I have not so no idea how hard this will be) to play games with Filter::Util::Call to define a custom language. Similarly you could do something like use Parse::RecDescent to parse the configuration, generate equivalent Perl code from slight markups, and then eval that.

Too get a sense of how far you can go with those ideas, take a look at Lingua::Romana::Perligata (but don't blame me if you lose your sanity)...

Comment on Re (tilly) 1: Polymorphic prototypes? (creating new syntax) Select or Download Code

Replies are listed 'Best First'.
Re: Re (tilly) 1: Polymorphic prototypes? (creating new syntax) by kaatunut (Scribe) on Apr 08, 2001 at 22:27 UTC
Too get a sense of how far you can go with those ideas, take a look at Lingua::Romana::Perligata (but don't blame me if you lose your sanity)... :) I almost started studying latin just to be able to code in Perligata... I just find the idea of coding perl in latin incredibly cool. Dispatch on prototype? What do you mean? That expression is alien to me, but I don't see a problem with prototype polymorphism. Hook up a list of possible matches for invocation compile-time and only if the sub is prototyped to be polymorphic, if the number of matches != 1, complain. Mmm? Of course this would only work with prototypes, who already generate syntax errors on incorrect invocation. How this relates to anonymous functions and whatnot, I dunno, but you can't defined prototypes for those anyways, can you? -Kaatunut	[reply]
Re (tilly) 3: Plymorphic prototypes? (creating new syntax) by tilly (Archbishop) on Apr 08, 2001 at 22:36 UTC
By dispatch on prototype I mean that when Perl looks up a function it can figure out what function to call based on the name and the look of the arguments. As for whether it is doable, probably. It would be hairy. It would not fit well in the list-oriented nature of Perl. People often find the APIs they create with such facilities to be very confusing. And Perl does not support it because it does not support having 2 functions in the same package of the same name at the same time. Anyways about prototypes, I completely side with Tom Christiansen on this. Unless you have a darned good reason you need them, they are a bad idea in Perl...	[reply]
Re: Re: Re (tilly) 1: Polymorphic prototypes? (creating new syntax) by princepawn (Parson) on Apr 09, 2001 at 21:01 UTC
While you're at it, take a look at Michael Schwern's DNA and Leon Brocard's Buffy, then you can code Perl in DNA sequences and various capitalizations of Buffy and have it work! All these magics are due to Paul Marquess' Filter::Cpp (I believe it's called).	[reply]
Re: Re (tilly) 1: Polymorphic prototypes? (creating new syntax) by princepawn (Parson) on Apr 09, 2001 at 21:02 UTC
Have you seen Class::MultiMethods ? That allows for multiple dispatch in Perl.	[reply]
Re (tilly) 3: Polymorphic prototypes? (creating new syntax) by tilly (Archbishop) on Apr 09, 2001 at 21:12 UTC
Yes, I have seen it. But note that it does not and cannot be readily extended to allow dispatching based on what prototype coercion finally made the code not a syntax error. Which is what was being asked for. So it doesn't solve the problem at hand. Besides that it is a performance hit, and there is considerable conceptual complexity in the APIs that it makes possible. That complexity makes me personally inclined to avoid it and seek to rethink problems in a simpler way rather than add that complexity to the problem at hand. All of which were reasons why I didn't mention it before...	[reply]