Re: 3 Good Reasons...

2006-05-26 Thread A. Pagaltzis
* Michael Mathews [EMAIL PROTECTED] [2006-05-26 12:45]:
 In the end it was decided to rewrite that chunk in Perl. I can
 tell you, there definitely was cursing in the office that day,
 and I doubt anyone there would see it as a plus to have the
 ability to mix languages more easily. I just wouldn't put it
 that way if I were trying to sell Perl6 to a business manager.

Using libraries from other languages and writing code in multiple
languages are very different things. You will not be able to
argue with a straight face that being able to do the former is a
downside. Currently, “other languages” translates to C, so the
utility of this is limited; being able to bridge to more
languages would be a great boon.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/


Re: 3 Good Reasons...

2006-05-26 Thread Michael Mathews

On 26/05/06, A. Pagaltzis [EMAIL PROTECTED] wrote:

* Michael Mathews [EMAIL PROTECTED] [2006-05-26 12:45]:
 In the end it was decided to rewrite that chunk in Perl. I can
 tell you, there definitely was cursing in the office that day,
 and I doubt anyone there would see it as a plus to have the
 ability to mix languages more easily. I just wouldn't put it
 that way if I were trying to sell Perl6 to a business manager.

Using libraries from other languages and writing code in multiple
languages are very different things. You will not be able to
argue with a straight face that being able to do the former is a
downside. Currently, other languages translates to C, so the
utility of this is limited; being able to bridge to more
languages would be a great boon.


I use the expat and libxslt libraries (both in C) regularly via perl,
so I guess I must agree that there is a distinction -- thank you for
clarifying that. But I can't think of any examples where I was stuck
because I couldn't use a library only available in, say Python, or
JavaScript in my Perl. But then I'm seeking to learn here so can you
give a nice juicy example of a non-C library that would be a big plus
to be able to include in Perl?

--michael


Re: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))

2006-05-25 Thread Larry Wall
This topic may be better suited to perl6-language, unless you consider
its denizens to already be self-selected against logic programming. :)

Larry


Re: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))

2006-05-25 Thread Ovid
- Original Message 
From: David Romano [EMAIL PROTECTED]

  duplicate results and this is almost always wrong. (See 
  http://use.perl.org/~Ovid/journal/28378 
  for an SQL example of this problem).
 I re-read your journal entry and comments (I had read it back when you
 first had posted it), and I'm curious about what obstacles that you
 think need to be overcome for Perl6 to support logic programming.

If anyone wants to know what the heck this is about, you can read 
http://search.cpan.org/dist/AI-Prolog/lib/AI/Prolog/Article.pod

That's an article I originally had published in The Perl Review 
(http://www.theperlreview.com/) and it explains the basics of logic programming 
and how to do it in Perl5.  It also explains the append/3 predicate, something 
I mention below.

The first hurdle would be the syntax.  The programmer just looking at the code 
would need to know when one section of code represents a snippet of logic 
programming.  Is the following a function call or a Prolog fact?

  loves( 'foo', 'bar' );

How would one assert facts and rules in Perl6?  How would one know that a 
variable is a logic variable and not a normal one?  Assignment to a logic 
variable which is still subject to rebinding could break code.  On the other 
hand, using normal variables for logic variables could let us use objects for 
them and I think this might get us contraint programming (long story).

There's also the question of non-logical behavior in logic programming.  What 
happens if you try to use math in Perl6 logic programming?  Generally speaking, 
math is non-logical in the sense that it's used in Prolog (see the 
aforementioned article).  Opening and reading from a file is also non-logical 
(you can't backtrack over it). How are those issues to be handled?

My biggest concern, though, is a rule like the following:

  customer_cities(City) :-
700 = credit_rating(Customer),
customer(Customer, City).

That's logically equivalent to the SQL I posted in a previous email and, like 
that SQL, will very likely return duplicates.  Prolog students are constantly 
faced wtih the how do I get rid of duplicates? problem.  This results in 
inefficient queries and a lot of time spent culling the duplicate answers when 
the person just wants to know the list of cities which meets their requirements.

Perl6 grammars may be able to assist with this, but grammars (as far as I can 
tell) are still based around strings and not data structures.  Admittedly, 
Prolog is essentially a fancy string rewriting system, but it's not clear how 
the grammars would be applied to this problem.

For anyone familiar with logic programming and the append/3 predicate, here's 
one way of representing it in Perl5:

  use re 'eval';
  my $string = abc;
  my $length = length $string;
  my $regex = qr/(\G[$string]{0,$length}(?{print # [$][$'][$string]\n}))/ x 
2;
  $string =~ $regex;

Can you say yuck?  However, that only represents a limited subset of 
append/3's functionality and trying to generalize it would be a very difficult 
task.  One approach might be to write a wrapper around 
http://www.perlmonks.org/?node_id=318350.  That's an approach I found to 
leverage Perl5's regex engine for logic programming, but I discovered that 
Perl5's regexen aren't re-entrant, killing that project.  Perl6 rules might be 
perfect for this.

In short, there are lots of questions which would need to be answered to get 
logic programming done correctly in Perl6.  I'm quite happy that @Larry decided 
not to answer those questions since things would have been delayed.  We can 
hack in logic programming later.

Cheers,
Ovid

-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/






Re: 3 Good Reasons...

2006-05-25 Thread Steffen Schwigon
Michael Mathews [EMAIL PROTECTED] writes:
 So my question to the list is, in simple terms even an IT manager
 could grasp, explain what problems Perl 5 has that Perl 6 fixes,
 such that they would want to undergo the pain of ever switching.

From a Perl point of view: there should be no pain.
At least that's a stated goal.

From a manager point of view: it's as use(ful|less) as ever to decide
for a language independently of the problem to solve. If Perl5 does
the job, stick with it. If Perl6 helps you somewhere, use it. If
Visual Basic solves your problem because it's already built into the
problem, just use it.

Perl5 is already gluey enough to not force you into a decicion for
*the only one* technology. Perl6 shouldn't change that.

Steffen
-- 
Steffen Schwigon [EMAIL PROTECTED]
Dresden Perl Mongers http://dresden-pm.org/