Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of luqui (5770)

Tuesday October 11, 2005
12:05 PM

Conflicted

[ #27116 ]

I'm feeling conflicted about theory.pod. While I'm very proud of it for being a great object model and giving precise semantics to things we've been handwaving over for ages, it just isn't Perl. It's too formal and static for Perl; you can't talk it into checking something a different way.

However, it is not possible to add a pure hook system that's reasonable for the everyday user to use. Type inference can't deal with arbitrary code, because it needs to go forwards and backwards and sideways through the annotations to figure things out, whereas arbitrary code can only go forwards. If we had a logic subsystem, we could give them arbitrary code (within that subsystem) because logic programming has the nice property that you can execute a function backwards:

    :- append(X, Y, [1,2,3,4,5]).

But maybe instead I need a coproposal, one that really gets down and dirty with Perl 6's internals, for the hook system on top of which theory.pod can be built as a module. If that exists (assuming it is even possible), then I wouldn't feel so uneasy about theories not being arbitrarily flexible.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I see the point of over-rigid staticness, but I think the too formal for Perl is a strange judgement; formalism is inevitable if we are to manipulate more than nine things at once.

    I wonder if you mean "too formal" as "requiring too much explicit annotation from the user", as in forcing people to think about it too much. If so, maybe it needs yet more ergonomic engineering, also known as sugar... :-)

    • The "too formal" comment came from talking with Stevan about the metamodel and remembering Smalltalk. But "formal" was the wrong word[1]. However, I'm convincing myself that theory.pod is a level above the "bless" semantics that we know and love, and can in fact cooperate nicely with it. theory.pod defines a type system, not an object system.

      See my reply to Ovids comment for a more rambly version of this answer.

      [1] Certainly. The whole reason I study mathematics is because of its incredible ability to s
  • If we had a logic subsystem, we could give them arbitrary code (within that subsystem) because logic programming has the nice property that you can execute a function backwards.

    Not knowing exactly what you're trying to accomplish, the following off the cuff statement could be totally meaningless.

    Passing arbitrary code to a logic subsystem does not necessarily mean that you can still run the function backwards. You would have to have some way of noting side-effects (it's difficult to "unwrite" a file

    • > Passing arbitrary code to a logic subsystem does
      > not necessarily mean that you can still run the
      > function backwards. You would have to have some
      > way of noting side-effects (it's difficult to
      > "unwrite" a file or unread database tuples) and
      > math in logic programming is frequently a
      > "one-way" affair unless constraints are specified.

      Oh, of course. I'm just saying that, as cool as theory theory is, making it the One True model is a bit presumptuous for Perl. I feel that the researc