Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>> All infix operators are multi subs. I can't imagine that we want to pay
>> the penalty for simple operations like:
>>
>> $a = $b + $c
>>
>> to inspect the values of operands, constraints, rules and what not.
> Having written se
--- Rod Adams <[EMAIL PROTECTED]> wrote:
> I was just relaying the observation that the P6RE was fairly close to
> being able to implement Logical Programming, which several people
> seem to be trying to get into Perl in some fashion or another.
When I get a chance to talk to someone about logic p
Larry Wall wrote:
I suspect it's another one of the many things we just try to
stay within hailing distance of without trying to solve for 6.0.0.
That's cool.
I was just relaying the observation that the P6RE was fairly close to
being able to implement Logical Programming, which several people
On Wed, Mar 09, 2005 at 08:56:22AM -0700, Luke Palmer wrote:
: I was decently insane last night. This generator stuff probably isn't
: going anywhere. It's too abstract, and not precise enough, to be a
: truly powerful part of the language.
I suspect it's another one of the many things we just t
Rod Adams writes:
> >
> >You could do all of this with a library of rules.
> >
> > / $:= )> /
> >
> >
> I don't think this does what I want. In this, &generate returns a rule
> or string of some kind, matches the string being tested, captures what
> matches, and then binds the capture to $.
Luke Palmer wrote:
Rod Adams writes:
Or you could avoid the global modifier and write your tests in <( )>
blocks instead... after all, that's what it's there for.
I *knew* I had seen a syntax for that before... I just didn't see it
when I scanned S05 for it.
I still want the :z modifier for
HaloO Luke,
you wrote:
[..] The *method* is the one that knows everything,
not the object. So definitions on subtypes of general types only check
for those subtypes when dispatching to the methods defined in them.
I stand corrected. Lax usage of Any is fair. Defining subtypes
of general types and
Thomas Sandlaà writes:
> Luke Palmer wrote:
> >But we always have enough knowledge to optimize the hell out of this,
> >and they're not not handwavy "we can probably" optimizations. They're
> >real, and they're pretty darn easy.
>
> I fully agree. But I like to add that a single 'where' on genera
/ $:= )> /
How the rule is actually written is getting into some rule
engine internal stuff, but we're making sure that the rule engine has
enough hooks to do that.
I think you'll be interested in where my 'Argument Patterns' proposal
was going next, before I ran off
Luke Palmer wrote:
But we always have enough knowledge to optimize the hell out of this,
and they're not not handwavy "we can probably" optimizations. They're
real, and they're pretty darn easy.
I fully agree. But I like to add that a single 'where' on general
types like Int, Str or even Any can s
Leopold Toetsch writes:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> > I think we should replace our multimethod system with a more general
> > pattern matcher, a "variadic multimethod" system of sorts. Multimethods
> > need to be variadic anyway, because we want pugs's quicksort example to
> > w
Luke Palmer <[EMAIL PROTECTED]> wrote:
> I think we should replace our multimethod system with a more general
> pattern matcher, a "variadic multimethod" system of sorts. Multimethods
> need to be variadic anyway, because we want pugs's quicksort example to
> work.
I'd not say replace. The dispa
Autrijus Tang wrote:
On Tue, Mar 08, 2005 at 04:55:28PM -0600, Rod Adams wrote:
I thought Larry already declared that we are not making Perl act like ML
(yet).
And that was re: type inferencing, not re: pattern matching. :)
Thanks,
/Autrijus/
Sorry about that. Comcast has decided I only
On Tue, Mar 08, 2005 at 04:55:28PM -0600, Rod Adams wrote:
> I thought Larry already declared that we are not making Perl act like ML
> (yet).
And that was re: type inferencing, not re: pattern matching. :)
Thanks,
/Autrijus/
pgpY1oAkekJDn.pgp
Description: PGP signature
Luke Palmer wrote:
All this Haskell programming has opened my eyes to what our multimethod
dispatch could be. As we have seen with C, the dispatch system is
a pattern matcher. But it's a pretty terrible one.
I think we should replace our multimethod system with a more general
pattern matcher, a
All this Haskell programming has opened my eyes to what our multimethod
dispatch could be. As we have seen with C, the dispatch system is
a pattern matcher. But it's a pretty terrible one.
I think we should replace our multimethod system with a more general
pattern matcher, a "variadic multimet
16 matches
Mail list logo
