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

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.
  • 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 research that CPAN has done has been incredibly important (note all modules in the Class:: namespace), and the reason that that research can take place is because of the extremely simple and basic "bless" object-orientation.

      Of course, all that stuff can carry over to Perl 6, because at it's very very core, its object-orientation is also just "bless". However, I think that it's important to let such research go on with type annotations as well; let a module writer really screw with what it means when you say "my Int $x".

      The example that got me was when I set out (and failed) to implement compile-time physical unit checking in Haskell as I had done in C++. Turns out that I had to implement Peano naturals in order to do it. I don't want Perl to work that way. It should be possible to embed our regular numbers "under the covers" of the theory theory; not have to construct them in the language of the type system.

      So I was just pondering a way that you could go about extending a type-inferencing compiler. If you gave your extension in the language of logic programming, then it should be possible. Still, completely arbitrary code would have to be hidden under the covers of the logic paradigm, which we both know how to do :-)