Re: Perl 6 Wiki -- 2 more possibilities, further discussion.

2006-05-25 Thread Michael Mathews

The (oh so very cool) idea of implementing the perl 6 wiki IN perl 6
(eventually) is a powerful argument. I also concede that control
issues mean we don't want the official wiki to be on wikipedia. Kwiki
is already a perl-based wiki, but I have no experience using it. We
don't have to put perl 6 under the pugs subdomain, that was just an
example.

--michael

On 25/05/06, Conrad Schneiker [EMAIL PROTECTED] wrote:

(Responding to 3 notes on 2 mail lists here; Changed subject line.)

Juerd wrote:
 Feather, the semi-public, semi-private, Perl 6 development server, is
 available to host a Perl 6 wiki.

 The hostname www.perl6.nl is deliberately kept available for something
 like that.

Does that mean you are willing to be the one to set up a Perl 6 Wiki and
administer it? (Preferably using perl5 wiki software, so that the Perl 6
Wiki could be available as soon as possible?) If so, how much more
encouragement do you need to proceed?

 From: Michael Mathews [mailto:[EMAIL PROTECTED]

 As a competing suggestion, how about...
 http://pugs.kwiki.org/?perl6

Very interesting. But did you look at it? :-) I found this on the home page
link target:

Consider using Subversion instead of this Wiki

20051213Z05:58 audreyt  I'd like it [the wiki] to
be strictly a scratchpad for lambdacamels.
all reusable docs should be in the svn tree
(and now Perl6::Doc)

This reminds me of my earlier suggestion:

Could we use part of Pugs doc tree as alternative
to perl6-user-doc wiki?
http://www.nntp.perl.org/group/perl.perl6.users/28

The basic idea is this: since the pugs svn tree is mirrored at perl.org, we
could have a subdirectory (for example Perl_6_ Wiki) in the docs branch of
the source tree that would have a wiki-like hierarchy of html pages (or pod
pages for generating html) below it. The downside is that it would take
somewhat more effort to make changes and additions.

However, it might still be a good idea to take periodic snapshots of a
separate semi-officially designated primary Perl 6 Wiki and stash it in
the source/doc tree (or maybe in a CPAN module Perl6::DOC::Wiki) so that it
would be available for offline help systems / searching.

 I'm not really set on any option as long as it works and makes sense
 to everyone, including those outside this list. I probably missed it,
 but could you give the stated purpose for the wiki again, as I think a
 reminder (for me at least) would help.

Several people thought it would be a good idea to have a common place that
made it *easy* to collect and organize useful information about perl6--stuff
that is beyond the scope of standard documentation. There is a lot of
interesting and useful perl6 information that is widely dispersed in talks,
documents, articles, and so on Likewise some of it current, some of it
obsolete, and much in between. Having a central collection that is easy to
browse and that is subject to substantial ongoing indirect review could be
very valuable. Think of the Perl 6 wiki as a vastly expanded FAQ that
supplemented many of the links with semi-consolidated content. Or think of
it as a semi-free-form meta-CPAN for interesting documentation. Or think
of it as a perl6 community gathering point and mega-billboard. Some examples
of suggested content: What are the main benefits of major perl6 features?
Why were various features done one way and not another? How are they
intended to be used? What are the benefits of perl6 relative to other
languages? What are the counter-arguments to various anti-perl6 FUD?

 On 24/05/06, Michael Mathews [EMAIL PROTECTED] wrote:

  For example
  there is nothing stopping anyone (including members of this list) from
  creating and populating pages on www.wikipedia.org about Perl6 and
  this user group. Then those pages would be available to the wikipedia
  search engine. --- Insert any other popular wiki there.

I'd thought of that, but there's always the background issue of moderation
and control. (We definitely want the Perl 6 Wikipedia page to link to our
Perl 6 Wiki, of course.) I don't think Wikipedia is (at present) a suitable
forum for semi-controversial topics. Language advocacy / competitive
marketing is a highly contentious and emotional religious issue for many
people, and we certainly want perl6 people to feel free to indulge in
(reasonably civil) unbridled advocacy of all things perl6.

  And of course with the ominipresence of google, finding and searching
  is always becoming less of a problem.

In my experience, finding and searching has become more of a problem--in
particular: (1) with too many irrelevant matches, and (2) with too many
matches that turn up obsolete info. That's precisely one of the reasons I
started prodding #perl6 about a newsgroup for perl6 users. Being able to
limit your searches to group archives of what you are specifically
interested in often makes search results much more useful. Precisely one of
the reasons that a Perl 6 Wiki could be very cool is that the 

Re: Perl 6 Wiki -- 2 more possibilities, further discussion.

2006-05-25 Thread Juerd
Please, for proper threading, don't reply to multiple messages at once.


Conrad Schneiker skribis 2006-05-25  1:46 (-0700):
 Juerd wrote:
  Feather, the semi-public, semi-private, Perl 6 development server, is
  available to host a Perl 6 wiki.
  The hostname www.perl6.nl is deliberately kept available for something
  like that.
 Does that mean you are willing to be the one to set up a Perl 6 Wiki and
 administer it? (Preferably using perl5 wiki software, so that the Perl 6
 Wiki could be available as soon as possible?) If so, how much more
 encouragement do you need to proceed?

Willing, certainly. Lacking tuits, that too.

I could set up wiki software in a few minutes, but then, so could anyone
else. Personally, I think this shouldn't be rushed: there are lots of
wikis, and typically they're incompatible in terms of syntax and
storage.

Also, I'd really love a Perl 6 wiki written in Perl 6 itself. Revision
control can be outsourced to svn, leaving practically only a small bit
of HTTP and wikitext parsing. However, this is still too much work for
me to handle at this moment.

The concept of feather is that I provide hardware, and system
administration, and that others can then use that. Feather is very
actively used, and it'd be nonsense to assume that everything on it is,
or should be, done by me. I actively avoid getting involved too much,
because I know that I won't be able to handle things as they expand.

Feather was donated exactly because I wanted to do something for Perl 6
volunteers, without needing to spend much time, because I don't have
that much time to spend on computing, because of personal circumstances.

  As a competing suggestion, how about...
  http://pugs.kwiki.org/?perl6
 Very interesting. But did you look at it? :-) I found this on the home page
 link target:

I know, and have contributed to, the Pugs wiki. If I may note: I don't
like kwiki syntax, and much prefer a mediawiki-like syntax.

 I'd thought of that, but there's always the background issue of moderation
 and control. (We definitely want the Perl 6 Wikipedia page to link to our
 Perl 6 Wiki, of course.) I don't think Wikipedia is (at present) a suitable
 forum for semi-controversial topics. Language advocacy / competitive
 marketing is a highly contentious and emotional religious issue for many
 people, and we certainly want perl6 people to feel free to indulge in
 (reasonably civil) unbridled advocacy of all things perl6. 

Agreed.

 Feather has the powerful future marketing advantage that it can also be used
 to develop and then host a showcase Perl 6 implementation of the Perl 6
 Wiki. However, I think that we should initially *begin* with a solid and
 proven Perl 5 wiki implementation that we can use *immediately*. If we could
 do this, then this would be my first preference. 

Beginning with a Perl 5 wiki, with lots of features, and migrating to a
Perl 6 wiki later, means you have to support all of the 5-wiki's
features for compatibility. That may not be a great plan, as a huge
stack of functional requirements makes creative programming less
interesting, and it may then never happen.

If nobody is able to spend a day on a simple Perl 6 wiki today, why
would they be able to spend *several* days on a backwards compatible
wiki later?


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


[svn:perl6-synopsis] r9307 - doc/trunk/design/syn

2006-05-25 Thread larry
Author: larry
Date: Thu May 25 11:21:16 2006
New Revision: 9307

Modified:
   doc/trunk/design/syn/S06.pod

Log:
Clarifying the distinction between the of and where return types.


Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podThu May 25 11:21:16 2006
@@ -13,9 +13,9 @@
 
   Maintainer: Larry Wall [EMAIL PROTECTED]
   Date: 21 Mar 2003
-  Last Modified: 14 May 2006
+  Last Modified: 24 May 2006
   Number: 6
-  Version: 35
+  Version: 36
 
 
 This document summarizes Apocalypse 6, which covers subroutines and the
@@ -288,7 +288,7 @@
 including Unicode characters. For example:
 
 sub infix:(c) ($text, $owner) { return $text but Copyright($owner) }
-method prefix:± (Num $x) returns Num { return +$x | -$x }
+method prefix:± (Num $x -- Num) { return +$x | -$x }
 multi sub postfix:! (Int $n) { $n  2 ?? 1 !! $n*($n-1)! }
 macro circumfix:«!-- --» ($text) is parsed / .*? / {  }
 
@@ -1238,7 +1238,7 @@
 
 Note that unlike a sub declaration, a regex-embedded signature has no
 associated returns syntactic slot, so you have to use C -- 
-within the signature to specify the type of the signature, or match as
+within the signature to specify the Cof type of the signature, or match as
 an arglist:
 
 :(Num, Num -- Coord)
@@ -1395,15 +1395,21 @@
 Explicit types are optional. Perl variables have two associated types:
 their value type and their implementation type.  (More generally, any
 container has an implementation type, including subroutines and modules.)
+The value type is stored as its Cof property, while the implementation
+type of the container is just the object type of the container itself.
 
 The value type specifies what kinds of values may be stored in the
-variable. A value type is given as a prefix or with the Creturns or
-Cof keywords:
+variable. A value type is given as a prefix or with the Cof keyword:
 
 my Dog $spot;
-my $spot returns Dog;
 my $spot of Dog;
 
+In either case this sets the Cof property of the container to CDog.
+Subroutines have a variant of the Cof property, Creturns, that
+sets the Creturns property instead.  The Creturns property specifies
+a constraint to be checked upon calling Creturn that, unlike the Cof
+property, is not advertized as the type of the routine:
+
 our Animal sub get_pet() {...}
 sub get_pet() returns Animal {...}
 sub get_pet() of Animal {...}
@@ -1431,6 +1437,13 @@
 run-time Ctie statement unless the variable is explicitly declared
 with an implementation type that does the CTieable role.
 
+However, package variables are always considered CTieable by default.
+As a consequence, all named packages are also CTieable by default.
+Classes and modules may be viewed as differently tied packages.
+Looking at it from the other direction, classes and modules that
+wish to be bound to a global package name must be able to do the
+CPackage role.
+
 =head2 Hierarchical types
 
 A non-scalar type may be qualified, in order to specify what type of
@@ -1449,19 +1462,16 @@
 
 actually means:
 
-my Hash[returns = Array[returns = Recipe]] %book; 
+my Hash[of = Array[of = Recipe]] %book; 
 
 Because the actual variable can be hard to find when complex types are
 specified, there is a postfix form as well:
 
 my Hash of Array of Recipe %book;   # HoHoAoRecipe
 my %book of Hash of Array of Recipe;# same thing
-my %book returns Hash of Array of Recipe;   # same thing
 
-The Creturns form is more commonly seen in subroutines:
+The Creturns form may be used in subroutines:
 
-my Hash of Array of Recipe sub get_book ($key) {...}
-my sub get_book ($key) of Hash of Array of Recipe {...}
 my sub get_book ($key) returns Hash of Array of Recipe {...}
 
 Alternately, the return type may be specified within the signature:
@@ -1469,8 +1479,14 @@
 my sub get_book ($key -- Hash of Array of Recipe) {...}
 
 There is a slight difference, insofar as the type inferencer will
-ignore a Creturns but pay attention to C --  or prefix type 
declarations.
-Only the inside of the subroutine pays attention to Creturns.
+ignore a Creturns but pay attention to C --  or prefix type
+declarations, also known as the Cof type.  Only the inside of the
+subroutine pays attention to Creturns.
+
+You may also specify the Cof type as the Cof trait:
+
+my Hash of Array of Recipe sub get_book ($key) {...}
+my sub get_book ($key) of Hash of Array of Recipe {...}
 
 =head2 Polymorphic types
 
@@ -1524,42 +1540,53 @@
 =head2 Return types
 
 On a scoped subroutine, a return type can be specified before or
-after the name:
-
-our Egg sub lay {...}
-our sub lay returns Egg {...}
-
-my Rabbit sub hat {...}
-my sub hat returns Rabbit {...}
+after the name.  We call all return types return types, but distinguish
+two kinds of return type, the 

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

2006-05-25 Thread Ovid
Larry pointed out that this topic is better suited for perl6-language instead 
of perl6-users, so I'm forwarding this along.  Feel free to exercise your 
delete key.

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/

- Forwarded Message 
From: Ovid [EMAIL PROTECTED]
To: perl6-users@perl.org
Sent: Thursday, May 25, 2006 11:40:54 AM
Subject: Re: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo 
alert!))

- 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: Fw: Logic Programming for Perl6 (Was Re: 3 Good Reasons... (typo alert!))

2006-05-25 Thread Jonathan Lang

Hmm...

How about this:

Treat each knowledge base as an object, with at least two methods:
.fact() takes the argument list and constructs a prolog-like fact or
rule out of it, which then gets added to the knowledge base.
.query() takes the argument list, constructs a prolog-like query out
of it, and returns a lazy list of the results.

There would be a default knowledge base, meaning that you wouldn't
have to explicitly state which knowledge base you're using every time
you declare a fact or make a query.

--
Jonathan Lang