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

[Brad Bowman]

Hi,

I used AI::Prolog once briefly, and that's the extent of my logic programming
knowledge.  There do seem to be a few Perl 6 features that may be useful for
logic programming, although I'm not really qualified to judge.


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).


"let" variables and "hypothetical" assignments within rules may be a
good starting point.

Hypothetical variables are mentioned here:
http://dev.perl.org/perl6/doc/design/syn/S04.html#Definition_of_Success

While they usually occur within rules, hypothetical assignments can
be to a target variable:
http://dev.perl.org/perl6/doc/design/syn/S05.html#External_aliasing

and "let" can now be used in any other closure.

More details in A05:
http://dev.perl.org/perl6/doc/design/apo/A05.html#Hypothetical_Variables,_er_Values


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?


Closures may have an "undo" trait which should be written to revert
the side-effects of the closure when it receives an UNDO control
exception (the block fails, see Definition of Success above).

http://dev.perl.org/perl6/doc/design/syn/S04.html#Closure_traits

For file reading the undo would seek back to the correct point.
This does require the programmer to code the undo operation, which
may not be possible (with non-seekable handles for examples).

Are there other languages that blend logic and imperative styles that
can be stolen from?


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.


There's some information about this in S05, with more info promised:

http://dev.perl.org/perl6/doc/design/syn/S05.html#Matching_against_non-strings

Brad

--
Dohaku's wife suffered some severed fingers.  Dohaku's wound was a severed
neck bone, and since only his throat remained intact, his head hung down in
front.  Now boosting his head up with his own hands, Dohaku went off to the
surgeon's.-- Hagakure http://bereft.net/hagakure/

Re: [perl #39217] [TODO] legal - eliminate "All Rights Reserved."

[Paul Johnson]

On Fri, May 26, 2006 at 01:57:40PM -0700, Allison Randal wrote:

> >>Copyright notices should have the form:
> >>
> >>   Copyright , The Perl Foundation.
> 
> Whoops, typo, that's:
> 
>Copyright (C) , The Perl Foundation.

Are you sure?  As I understand things, the symbol (C), that is the
letter C in parentheses, has no legal bearing whatsoever.  In general
the word "Copyright" is sufficient for international copyright concerns,
but if you want to add something else it should be the symbol ©, that is
the letter C in a circle.

Of course, I'm not a lawyer, but this is what they learned me at
college.  Though this was at about the same time as countries such as
Mauritius, Liberia and the USA were becoming party to the Berne
Convention, so maybe that changed things for the USA.  I don't think
this is the case though.  Indeed,
http://www.copyright.gov/circs/circ03.html only talks about:

  The symbol © (the letter C in a circle), or the word “Copyright,” or
  the abbreviation “Copr.”

I wouldn't have said anything, but your correction seems to indicate
that the (C) is important.  Is my information outdated?

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Software transactional memory / atomic_ops copyright

[Charles Reiss]

I'm the student doing the summer of code project to implement STM in
parrot. I've created a branch of parrot named 'stm' for this purpose.

So, to start off, a copyright question:

It would be nice to use libraries that provide relatively portable
atomic operation support (needed for good implementations of most
"lock-free" schemes), such as HP's atomic_ops [
http://www.hpl.hp.com/research/linux/atomic_ops/index.php4 ] which is
which is under a 'modified BSD'-like license (that is, one that
requires displaying copyright notices). Is this acceptable or not to
put in Parrot?

(If not, it's a relatively easy matter to provide fast implementations
of these operations by hand for those platforms to which I have access
-- but borrowing from a library should give a lot of extra
portability.)

  -- Charles

Re: [perl #39217] [TODO] legal - eliminate "All Rights Reserved."

[Allison Randal]

(Randal L. Schwartz) via RT wrote:


According to Brad Templeton's copyright FAQ, it really doesn't mean anything
anyway.  If I recall, It was needed in a few south american countries, all of
whom have become Berne-convention parties now, so it really means nothing.

It never meant "rights" in a licensing point of view, so while your actions
are agreeable, your motivation is misplaced. :)


You've got it half right. It came from the Buenos Aires Convention of 
1910, and was commonly used in South American countries. But the U.S. 
was also a signatory to the convention, so it was used here too.


The terms of the Buenos Aires Convention required copyright holders to 
state that they were reserving rights before they could get any 
copyright protection, hence the statement "All Rights Reserved" in 
copyright notices. Open source licenses are copyright licenses, so it is 
exactly the same "rights" as licensing rights, and we're giving some of 
them away, not reserving all of them.


And yes, the Buenos Aires Convention was effectively replaced by the 
Berne Convention of 1886, after all the parties of the Buenos Aires 
Convention became signatories of the Berne Convention in 2000. (Both are 
still in force, but since the Berne Convention has much wider adoption, 
it's the one that carries the most weight.) The Berne Convention grants 
copyright protection even if there isn't any copyright notice.


So, "All Rights Reserved" is both false and unnecessary.

But, I didn't figure people really wanted to hear all that. :)

Allison

Re: [perl #39217] [TODO] legal - eliminate "All Rights Reserved."

[Allison Randal]

Paul Johnson wrote:


I wouldn't have said anything, but your correction seems to indicate
that the (C) is important.  Is my information outdated?


It wasn't a correction based on legal requirements, it was a correction 
based on "this is what we talked about earlier and decided to 
standardize to" (and a good bit of Parrot is already standardized to 
it). Legally, there is a very slim reason (related to the Berne 
Convention) to want to add the copyright symbol instead of just the word 
"Copyright" or the ASCII representation of the symbol, but it's not 
hugely significant, and we want to stick with plain text.


Allison

Re: [perl #39217] [TODO] legal - eliminate "All Rights Reserved."

[Randal L. Schwartz]

> "Allison" == Allison Randal <[EMAIL PROTECTED]> writes:

Allison> The fundamental legal point is that we're not reserving all rights,
Allison> because we're distributing the code under an open source
Allison> license. Many open source developers include "All Rights Reserved."
Allison> in a cargo-cult fashion, without understanding what it means.

According to Brad Templeton's copyright FAQ, it really doesn't mean anything
anyway.  If I recall, It was needed in a few south american countries, all of
whom have become Berne-convention parties now, so it really means nothing.

It never meant "rights" in a licensing point of view, so while your actions
are agreeable, your motivation is misplaced. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: [perl #39217] [TODO] legal - eliminate "All Rights Reserved."

[Allison Randal]

The fundamental legal point is that we're not reserving all rights, 
because we're distributing the code under an open source license. Many 
open source developers include "All Rights Reserved." in a cargo-cult 
fashion, without understanding what it means.


Will Coleda via RT wrote:

How does this interact with files like:

./lib/Pod/Simple/HTML.pm:429:Copyright (c) 2002 Sean M. Burke.  All  
rights reserved.


I'm the current maintainer of Pod::Simple, and give you permission to 
remove "All rights reserved." (I'll be removing it from some later 
release anyway.)


Though, I'm not really sure why the module is in Parrot. Would it help 
if I reimplemented Pod::Simple in Perl 6 as soon as Patrick pushes the 
Perl 6 compiler far enough? I might even do it in PIR (it would be 
stunningly simpler in PGE/TGE than it is in Perl 5), though, frankly, 
I'd rather wait for the Perl 6 skin around PGE/TGE. :)


So, you can leave it for now, and just assume we'll be ripping the files 
out of Parrot later.


./src/bignum.c:2:Copyright (c) 2001-2006 Yet Another Society.  All  
rights reserved.


"Yet Another Society" is an older name for "The Perl Foundation". This 
is just a messy leftover from a previous global update on copyright 
notices and should read:


  Copyright (C) 2001-2006, The Perl Foundation.

./runtime/parrot/include/DWIM.pir:305:Copyright (c) 2003, Leopold  
Toetsch. All Rights Reserved.


Individuals retain copyright on the lines of code they write, but we 
don't preserve individual copyright notices in the repository. From a 
practical perspective, individual copyright notices are likely to be 
untrue, because often multiple people edit a file, so the copyright 
isn't actually owned by one person. From a legal perspective, individual 
copyright notices on contributed pieces aren't meaningful because 
everyone who receives the pieces gets them as part of the compilation, 
and all they need to know is the compilation copyright owner. So, 
eventually that'll be:


  Copyright (C) 2003, The Perl Foundation.

(But there's no need to rush on that. And, of course, Leo can remove the 
file if he didn't intend it to be distributed as part of Parrot, but 
somehow I think that's unlikely. :)



Copyright notices should have the form:

   Copyright , The Perl Foundation.


Whoops, typo, that's:

   Copyright (C) , The Perl Foundation.

Allison

Re: 3 Good Reasons...

[David Cantrell]

On Fri, May 26, 2006 at 12:37:31PM +0100, Michael Mathews wrote:

> 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?

Log4java, although it's now been cloned as Log4perl.

More importantly from a perl programmer's point of view, I'd really like
the benighted heathen pythonistas to be able to use my fabulous perl
code.

-- 
David Cantrell | Reality Engineer, Ministry of Information

It's my experience that neither users nor customers can articulate
what it is they want, nor can they evaluate it when they see it
-- Alan Cooper

Re: [perl #39217] [TODO] legal - eliminate "All Rights Reserved."

[Leopold Toetsch]

On May 26, 2006, at 20:25, Will Coleda wrote:


and

./runtime/parrot/include/DWIM.pir:305:Copyright (c) 2003, Leopold 
Toetsch. All Rights Reserved.


just rewrite these (m/Toetsch/) to any needed format.

Thanks,
leo

Re: 3 Good Reasons...

[Chris Dolan]

On May 26, 2006, at 6:37 AM, Michael Mathews wrote:


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?


I have a real-world example from my work.  Perl lacked a library for  
parsing and editing Macromedia FLV files.  There was one in Ruby[1],  
but the rest of my code was written in Perl.  So, I created the FLV- 
Info library[2].  It's pretty nice for reading FLVs IMHO, but has no  
edit features due to my time constraints.  If I were working in the  
magic future where Perl and Ruby are bytecode compatible, perhaps I  
would have just interfaced with the Ruby library directly instead of  
having to reinvent it, saving a couple of days of coding and debugging.


 [1]  http://inlet-media.de/flvtool2
 [2]  http://search.cpan.org/dist/FLV-Info/

Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: Unintended consequences

[Michael G Schwern]

On 5/26/06, Adam Kennedy <[EMAIL PROTECTED]> wrote:


Andy Lester wrote:
> Here's an example of why I'm not real excited about CPANTS:
>
> http://community.livejournal.com/perl/120747.html

Ironically, posted by someone that also makes all her modules phone home
at install time.



Let's be clear, it asks for permission first.

Re: [perl #39217] [TODO] legal - eliminate "All Rights Reserved."

[Will Coleda]

How does this interact with files like:

./lib/Pod/Simple/HTML.pm:429:Copyright (c) 2002 Sean M. Burke.  All  
rights reserved.


and

./src/bignum.c:2:Copyright (c) 2001-2006 Yet Another Society.  All  
rights reserved.


and

./runtime/parrot/include/DWIM.pir:305:Copyright (c) 2003, Leopold  
Toetsch. All Rights Reserved.


Each of which, I think, has a slightly different answer?

Should this ticket's scope be amended to "just files marked copyright  
TPF" ?


On May 26, 2006, at 1:59 PM, Allison Randal (via RT) wrote:


# New Ticket Created by  Allison Randal
# Please include the string:  [perl #39217]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39217 >


Remove the phrase "All Rights Reserved." from every copyright line in
every file in the repository. Copyright notices should have the form:

   Copyright , The Perl Foundation.

Allison



--
Will "Coke" Coleda
[EMAIL PROTECTED]

Re: packages vs. classes

[Paul Hodges]

--- Stevan Little <[EMAIL PROTECTED]> wrote:

> On 5/23/06, Sam Vilain <[EMAIL PROTECTED]> wrote:
> > People can diverge completely with completely incompatible
> > metaclasses that don't .do those roles, the only side effect
> > of which being that people who write code for the standard
> > Perl 6 metamodel will be incompatible, and maybe some ways
> > of setting up the class won't work without another layer of
> > trickery. I *think* that's what you're getting at. Of course,
> > it shouldn't be prohibited just because it smells.
> 
> I am not sure I like this, incompatible metaclass issues are really
> really tricky and hard to debug (aka - smells *really* bad). And the
> system needed to support them really can bloat the metamodel
> internals in a nasty way. There are several papers out there on the
> subject, none of which IMO provide a satisfactory solution. The 
> problem then becomes compounded by introducing the Python and Ruby
> metamodels into the fray. Having a single compatability level made
> out of roles is not that much of a restriction really, and keeps
> much of the system interals clean and orderly. It also makes it
> much easier for use to add new metamodels from other languages by
> just by writing a layer to map to the core metamodel roles.


I'd say a more standard system is much better, so long as we leave a
standard set of hooks by which someone can insert a nonstandard setup.
A small API isn't a huge bloat, and is worth it, though I agree that a
full system might actually be counterproductive.

And by all that I've seen lately, the whole language is pretty
malleable that way; those who really want the nonstandard model can
take the small overhead hit of whatever internal shenanigans they need
to implement, and just about anything like that can be stuffed into a
module now, can't it?

So the upshot is, a standardized metamodel seems like the way to go to
me



And Congrats again, gramps. May your new little one be as loved as the
language you've also labored so much to guide to maturity. >;o]


Paul

"on est aisément dupé par ce qu'on aime" -- Molière (one is easily fooled by 
that which one loves)
"Increase in wisdom can be measured accurately by the corresponding decrease in 
anger." -- Friedrich Nietzsche
"There are trivial truths and there are great Truths. The opposite of a trival 
truth is obviously false.
 The opposite of a great Truth is also true."  -- Neils Bohr

"Real friends are those whom, when you must inconvenience them, are bothered 
less by it than you are." -- me. =o) 
Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a 
thumb.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[perl #39217] [TODO] legal - eliminate "All Rights Reserved."

[via RT]

# New Ticket Created by  Allison Randal 
# Please include the string:  [perl #39217]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=39217 >


Remove the phrase "All Rights Reserved." from every copyright line in 
every file in the repository. Copyright notices should have the form:

   Copyright , The Perl Foundation.

Allison

Re: packages vs. classes

[Stevan Little]

On 5/23/06, Sam Vilain <[EMAIL PROTECTED]> wrote:

Right, but we should really ship with at least a set of Meta Object
Protocol Roles, that covers the core requirements that we will need for
expressing the core types in terms of themselves;

- classes and roles
- attributes and methods
- subsets (ie constraints/subtypes)
- generics (including, by induction, nested generics)

I *think*, at this point, that's all that are necessary.


I would maybe add a protocol for instance creation. We have recently
added that to Moose, and found it very useful in terms of abstracting
out the kind of instance storage used (ARRAY based storage currently
Just Works given the right Instance sub(meta)class).

I see the instance protocol as being an important component of cross
language runtime thing. If all instances conform to, or can be made to
conform to, an base instance protocol, making Perl 6 objects which
inherit from Python objects should be fairly easy.


People can instantiate the roles that cover all that to an actual
metaclass in whatever way they like (eg,
Moose::Meta::Class->isa(Class::MOP::Class)), but not having to detect
the type and then figure out how to talk to it for at least the core of
the object system would be good.


I think the roles can serve as the core interface nessecary to
function with the base object system. As long as my metaclass .does()
the correct role, it should be able to function in the object system.
Of course the old garbage-in garbage-out rule applies, we should give
you enough meta-rope to shoot your meta-self in your meta-foot.


People can diverge completely with completely incompatible metaclasses
that don't .do those roles, the only side effect of which being that
people who write code for the standard Perl 6 metamodel will be
incompatible, and maybe some ways of setting up the class won't work
without another layer of trickery. I *think* that's what you're getting
at. Of course, it shouldn't be prohibited just because it smells.


I am not sure I like this, incompatible metaclass issues are really
really tricky and hard to debug (aka - smells *really* bad). And the
system needed to support them really can bloat the metamodel internals
in a nasty way. There are several papers out there on the subject,
none of which IMO provide a satisfactory solution. The problem then
becomes compounded by introducing the Python and Ruby metamodels into
the fray. Having a single compatability level made out of roles is not
that much of a restriction really, and keeps much of the system
interals clean and orderly. It also makes it much easier for use to
add new metamodels from other languages by just by writing a layer to
map to the core metamodel roles.

- Stevan

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

[Uri Guttman]

> "l" == larry  <[EMAIL PROTECTED]> writes:

  l> Log:

shouldn't that be "grandpa's log, earth date 200605252055"?

  l> Deployment of julian++ at 200605252055, 8`lb + 7`oz, 20`in.
  l>Ref: 
http://www.wall.org/cgi-bin/photo/index.cgi?mode=view&album=/pix/Julian

so when does he get his commit bits? :)

congrats, grandpa!

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: 3 Good Reasons...

[A. Pagaltzis]

* Michael Mathews <[EMAIL PROTECTED]> [2006-05-26 13:40]:
> 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?

There are several Python projects that I wish I could use without
having to reimplement their functionality in Perl, such as the
Kid templating engine and Demokritos, an implementation of the
Atom Publishing Protocol.

Note that the Parrot Native Call Interface will also make it much
easier to provide bindings to libraries at ABI level, eg. if you
wrote a single Gtk2-Parrot binding it would be available
instantly for all languages hosted on Parrot, and unlike XS
modules in Perl 5 it wouldn’t need a compiler to install,
massively increasing its reach.

In short, a whole lot of duplicated effort at the plumbing layers
could go away.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Unintended consequences

[Ovid]

- Original Message 
> From: Adam Kennedy <[EMAIL PROTECTED]>
>
> Andy Lester wrote:
> > Here's an example of why I'm not real excited about CPANTS:
> >
> > http://community.livejournal.com/perl/120747.html
>
> Ironically, posted by someone that also makes all her modules phone home 
> at install time.


Huh? Can you post an example?  The logical spot for having the module "phone 
home" would be in the Makefile.PL.  I also glanced at some tests, but didn't 
see anything there, either.

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: Unintended consequences

[demerphq]

On 5/26/06, Ovid <[EMAIL PROTECTED]> wrote:

- Original Message 
> From: Adam Kennedy <[EMAIL PROTECTED]>
>
> Andy Lester wrote:
> > Here's an example of why I'm not real excited about CPANTS:
> >
> > http://community.livejournal.com/perl/120747.html
>
> Ironically, posted by someone that also makes all her modules phone home
> at install time.


Huh? Can you post an example?  The logical spot for having the module "phone 
home" would be in the Makefile.PL.  I also glanced at some tests, but didn't see 
anything there, either.


Look at the Build.PL not the Makefile.PL.

And its voluntary so im not sure why Adam thinks its bad.

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

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

[larry]

Author: larry
Date: Fri May 26 09:57:12 2006
New Revision: 9310

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

Log:
Clarifications of inner type from sam++.
Deployment of julian++ at 200605252055, 8`lb + 7`oz, 20`in.
   Ref: http://www.wall.org/cgi-bin/photo/index.cgi?mode=view&album=/pix/Julian


Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podFri May 26 09:57:12 2006
@@ -13,9 +13,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 21 Mar 2003
-  Last Modified: 24 May 2006
+  Last Modified: 26 May 2006
   Number: 6
-  Version: 36
+  Version: 37
 
 
 This document summarizes Apocalypse 6, which covers subroutines and the
@@ -1405,14 +1405,20 @@
 my $spot of Dog;
 
 In either case this sets the C property of the container to C.
-Subroutines have a variant of the C property, C, that
-sets the C property instead.  The C property specifies
-a constraint to be checked upon calling C that, unlike the C
-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 {...}
+
+Subroutines have a variant of the C property, C, that sets
+the C property instead.  The C property specifies a
+constraint (or perhaps coercion) to be enforced on the return value (either
+by explicit call to C or by implicit fall-off-the-end return).
+This constraint, unlike the C property, is not advertised as the
+type of the routine.  You can think of it as the implicit type signature of
+the (possibly implicit) return statement.  It's therefore available for
+type inferencing within the routine but not outside it.  If no inner type
+is declared, it is assumed to be the same as the C type, if declared.
+
+sub get_pet() of Animal {...}  # of type, obviously
+our Animal sub get_pet() {...} # of type
+sub get_pet() returns Animal {...} # inner type
 
 A value type on an array or hash specifies the type stored by each element:
 
@@ -1539,19 +1545,21 @@
 
 =head2 Return types
 
-On a scoped subroutine, a return type can be specified before or
-after the name.  We call all return types "return types", but distinguish
-two kinds of return type, the C type from the C type, because
-the C type must be an "official" named type, while the C type
-is merely applied as a constraint to what may be returned by the routine.
+On a scoped subroutine, a return type can be specified before or after
+the name.  We call all return types "return types", but distinguish
+two kinds of return type, the C type and the C type,
+because the C type is normally an "official" named type and
+declares the official interface to the routine, while the C
+type is merely a constraint on what may be returned by the routine
+from the routine's point of view.
 
+our sub lay returns Egg {...}  # inner type
 our Egg sub lay {...}  # of type
-our sub lay returns Egg {...}  # where type
 our sub lay of Egg {...}   # of type
 our sub lay (--> Egg) {...}# of type
 
+my sub hat returns Rabbit {...}# inner type
 my Rabbit sub hat {...}# of type
-my sub hat returns Rabbit {...}# where type
 my sub hat of Rabbit {...} # of type
 my sub hat (--> Rabbit) {...}  # of type
 
@@ -1559,14 +1567,14 @@
 namespace (module, class, grammar, or package), as if it's scoped with
 the C scope modifier. Any return type must go after the name:
 
-sub lay returns Egg {...}  # where type
+sub lay returns Egg {...}  # inner type
 sub lay of Egg {...}   # of type
 sub lay (--> Egg) {...}# of type
 
 On an anonymous subroutine, any return type can only go after the C
 keyword:
 
-$lay = sub returns Egg {...};  # where type
+$lay = sub returns Egg {...};  # inner type
 $lay = sub of Egg {...};   # of type
 $lay = sub (--> Egg) {...};# of type
 
@@ -1581,12 +1589,12 @@
 The return type may also be specified after a C<< --> >> token within
 the signature.  This doesn't mean exactly the same thing as C.
 The C type is the "official" return type, and may therefore be
-used to do type inferencing outside the sub.  The C type only
+used to do type inferencing outside the sub.  The C type only
 makes the return type available to the internals of the sub so that
 the C statement can know its context, but outside the sub we
 don't know anything about the return value, as if no return type had
 been declared.  The prefix form specifies the C type rather than
-the C type, so the return type of
+the C type, so the return type of
 
 my Fish sub wanda ($x) { ... }
 
@@ -1598,7 +1606,7 @@
 
 my sub wanda ($x) returns Fish { ... }
 
-It is possible for the C type to disagree with the C type:
+It is possible for the

Re: Unintended consequences

[Pete Krawczyk]

Subject: Re: Unintended consequences
From: Ovid <[EMAIL PROTECTED]>
Date: Fri, 26 May 2006 09:44:32 -0700 (PDT)
 
}> From: Adam Kennedy <[EMAIL PROTECTED]>
}> 
}> Ironically, posted by someone that also makes all her modules phone home
}> at install time.
}
}Huh? Can you post an example?  The logical spot for having the module
}"phone home" would be in the Makefile.PL.  I also glanced at some tests,
}but didn't see anything there, either.
 
Look in the Build.PL, which Makefile.PL also calls.
  
http://search.cpan.org/src/NICOLAW/WWW-Dilbert-1.19/Build.PL for example.
  
-Pete K
--
Pete Krawczyk
  perl at bsod dot net

Re: 3 Good Reasons...

[Dr.Ruud]

"Gabor Szabo" schreef:

> {Cobol etc.]
> IMHO - and I really saw only a few such companies - these companies
> have 0 automatic tests so it would cost them a lot of time and money
> to test their application on the new and shiny Cobol compiler.

I once worked on tests for a national center of a bank, to monitor the
nightly runs of big money flowing. The Cobol programs ran on mainframes;
there were several IBM PCs, with character terminal emulation software,
connected to them.

On each PC there was a stack of C-programs, generated with yacc and lex.
When a fresh screen came up, a main program deducted the proper test for
it and ran it. When the test failed, the PC would start beeping and
flashing, to wake up the one operator that remained: this software
replaced a couple of people that once did the same tests with mental
arithmetic and a pocket calculator.

The terminal emulation software had a very raw INT-something-API (HLLAPI
IIRC), and IBM had updated the terminal emulation software but hadn't
updated the (never supported) linkable library layer for the API, so the
first thing I had to do was to create a replacement library. That took
only half a day, because the documentation of IBM was OK, and I could
generate much of the C-code with a few macros. I wondered why IBM hadn't
done that, it would have been a nice gesture.
http://www.webopedia.com/TERM/H/HLLAPI.html

Next I had to check the test programs, because they failed often. These
were full of strdups without frees and things like that, they were made
by a Pascal programmer. It took me two days to fix all those yacc/lex
sources, throwing away about 90% of them because there was a lot of
duplication. Basically such a program would check the layout of the
screen, copy a few numbers from it and do some calculations on them,
then store the result in a log. And of course it would bark when things
didn't add up.

Monitoring, regular expressions, character based: nothing much has
changed.


http://search.cpan.org/~grommel/Convert-IBM390/IBM390.pod

http://search.cpan.org/~ingy/Inline/Inline-API.pod
"The Inline community will decide if your implementation of COBOL will
be distributed as the official Inline::COBOL or should use an alternate
namespace." :)

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: RFC: Patch for mingw-msys

[Andrew Dougherty]

On Fri, 26 May 2006, Joshua Gatcomb wrote:

> On 5/26/06, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > 
> > I don't know anything about either msys or mingw, so I don't really know
> > what to recommend.
> > 
> > I'm afraid I don't understand what a patch would actually try to do.
> > From your previous message, it looks like sh.exe is changing the path
> > delimiters and shell escapes so that things don't work anymore.  Are you
> > trying to patch Configure.pl to handle those changed delimiters and shell
> > esacapes?  Or do you have something else in mind?
> 
> The patch would be nothing more than a warning.  As I said, the PATH 
> environment has absolutely no effect on the configure process, just the 
> build process.  During the configure process, we can warn the user that 
> the build process won't work unless they do something about their PATH.  
> In particular, prevent mingw from using msys and subsequently changing 
> the the behavior of path delimiters and shell escapes.

Ok, if that's all you want to do, then I think checking PATH in the mingw 
hints file and aborting with a message instructing the user to change PATH 
is probably the right thing to do.  (Yes, I know that changing PATH as 
recommended won't affect the Configure process, but the user has got to 
fix it before the build process anyway, and putting all that info in 
the hints file makes it more likely that the right people will read, 
understand, and maintain it in the future.)

> I would love to submit a patch to make using msys transparent and "just
> work" but after searching the archives, it appears that people working on it
> far longer than I have had little to no luck with it and I am just getting
> my feet wet again.

Fair enough.  I had misunderstood and thought that, perhaps, simply using 
'nmake' instead of 'mingw32-make' might have make it "just work".  Oh 
well.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: RFC: Patch for mingw-msys

[Joshua Gatcomb]

On 5/26/06, Andy Dougherty <[EMAIL PROTECTED]> wrote:


I don't know anything about either msys or mingw, so I don't really know
what to recommend.

I'm afraid I don't understand what a patch would actually try to do.
From your previous message, it looks like sh.exe is changing the path
delimiters and shell escapes so that things don't work anymore.  Are you
trying to patch Configure.pl to handle those changed delimiters and shell
esacapes?  Or do you have something else in mind?



The patch would be nothing more than a warning.  As I said, the PATH
environment has absolutely no effect on the configure process, just the
build process.  During the configure process, we can warn the user that the
build process won't work unless they do something about their PATH.  In
particular, prevent mingw from using msys and subsequently changing the the
behavior of path delimiters and shell escapes.

I would love to submit a patch to make using msys transparent and "just
work" but after searching the archives, it appears that people working on it
far longer than I have had little to no luck with it and I am just getting
my feet wet again.


Also, what's the preliminary setting of $make got to do with it?  You've

still got to call some sort of make command in the end.



It may seem odd to some to put a warning for $make as mingw32-make in a
section of code when $make is actually nmake at that point.  Placing it at
the end of Configure.pl may make more sense since it is the last set of
instructions to the user but it appears that a lot of work has gone in to
making it platform neutral.

If you're just wondering where '$make' gets set, then config/inter/make.pm


is where to look -- it seems to prefer mingw32-make over nmake.  Perhaps
that's wrong.



I don't think it is wrong but perhaps the order of hints/make should
change.  I don't know that's why I am asking.


--

Andy Dougherty  [EMAIL PROTECTED]




Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region

Re: RFC: Patch for mingw-msys

[Andy Dougherty]

On Fri, 26 May 2006, Joshua Gatcomb wrote:

> All:
> In tracking down why building parrot with mingw was failing, I discovered
> that the culprit was having msys in my PATH even if I wasn't intentionally
> trying to use it.
> 
> There are 3 interesting things to note:
> 1.  It does not matter what msys is actually called - renaming the directory
> to foo has the same effect
> 2.  It does not matter where in the PATH it appears - placing it after mingw
> has no effect
> 3.  Changing the PATH has no effect on the configuration cycle - only the
> build cycle
> 
> Running mingw32-make with the -d (debug) flag on revealed what is going on.
> It scans PATH, using an internal routine called find_and_set_shell, looking
> for sh.exe which changes path delimiters and shell escapes.
> 
> The obvious fix is to do exactly what mingw32-make is doing and warn the
> user that the subsequent mingw32-make is going to fail.
> 
> This is where the request for comments comes in.
> 
> config/init/hints/mswin32.pm is where the mingw specific settings are set
> up.  The $make variable obtained at this point is nmake, but it would still
> be possible to probe $ENV{PATH}, discover if sh.exe exists, and warn the
> user.
> 
> Configure.pl ends by telling the user the next step.  Use $make, which has
> changed from nmake to mingw32-make along the way, which is bound to fail.
> Perhaps this is the spot where it is appropriate to warn the user.
> 
> I don't mind writing the patch but as I have been away for 1.5 years I would
> really like to hear the opinions of where is the best way to do it.

I don't know anything about either msys or mingw, so I don't really know 
what to recommend.

I'm afraid I don't understand what a patch would actually try to do.
>From your previous message, it looks like sh.exe is changing the path 
delimiters and shell escapes so that things don't work anymore.  Are you 
trying to patch Configure.pl to handle those changed delimiters and shell 
esacapes?  Or do you have something else in mind?

Also, what's the preliminary setting of $make got to do with it?  You've 
still got to call some sort of make command in the end.

If you're just wondering where '$make' gets set, then config/inter/make.pm 
is where to look -- it seems to prefer mingw32-make over nmake.  Perhaps 
that's wrong.

-- 
Andy Dougherty  [EMAIL PROTECTED]

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

[Sage La Torra]

From a language standpoint, I think this is a great solution. As Jonathan

suggests, have a default knowledge base that is referenced by default, with
the option to declare more knowledgebases. Each one can have facts set and
queries exectued seperately. I have only a passing knowledge of Prolog, but
I think this should handle Logic programming, as long as Perl facts and
queries have the same elements as their Prolog equivalents.


From an internal standpoint, I think this may be slightly harder to do.

While this is a great syntax for the problem, some of the other issues David
mentioned were internals oriented. Obviously, that's beyond this list, but
the internal implementation of this may be a bit trickier.

Sage

On 5/25/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:


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

RFC: Patch for mingw-msys

[Joshua Gatcomb]

All:
In tracking down why building parrot with mingw was failing, I discovered
that the culprit was having msys in my PATH even if I wasn't intentionally
trying to use it.

There are 3 interesting things to note:
1.  It does not matter what msys is actually called - renaming the directory
to foo has the same effect
2.  It does not matter where in the PATH it appears - placing it after mingw
has no effect
3.  Changing the PATH has no effect on the configuration cycle - only the
build cycle

Running mingw32-make with the -d (debug) flag on revealed what is going on.
It scans PATH, using an internal routine called find_and_set_shell, looking
for sh.exe which changes path delimiters and shell escapes.

The obvious fix is to do exactly what mingw32-make is doing and warn the
user that the subsequent mingw32-make is going to fail.

This is where the request for comments comes in.

config/init/hints/mswin32.pm is where the mingw specific settings are set
up.  The $make variable obtained at this point is nmake, but it would still
be possible to probe $ENV{PATH}, discover if sh.exe exists, and warn the
user.

Configure.pl ends by telling the user the next step.  Use $make, which has
changed from nmake to mingw32-make along the way, which is bound to fail.
Perhaps this is the spot where it is appropriate to warn the user.

I don't mind writing the patch but as I have been away for 1.5 years I would
really like to hear the opinions of where is the best way to do it.

Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region

Re: 3 Good Reasons...

[Gabor Szabo]

[
  I am sorry this will not respond directly to the message in question as
  I have not seen it in my inbox. I hope the attribution is correct though.
]

On 5/26/06, Dr.Ruud <[EMAIL PROTECTED]> wrote:

>> Not really. Think about a Cobol-to-Parrot translator. You could for
>> example use Perl (glue) to add GUI stuff to old Cobol programs.


Ocassionally I have this dream of having a Cobol-to-Parrot compiler and being
able to go into these huge financial institutions with a solution on how to add
GUI to Cobol, or just how to make it a lot easier to add more features
but then I wake up.

One of the reasons these companies still use Cobol is that they are afraid
of anything new.
They want a reliable (read blame-able, sue-able) company to provide
for their hardware, OS and Cobol compiler. Unless they are forced (eg.
by SWIFT) they
won't leave their current setup.

Even if another reliable (read as above) supplier comes along IMHO their
sales people would have tough time to convince the company to switch.

IMHO - and I really saw only a few such companies - these companies have 0
automatic tests so it would cost them a lot of time and money to test their
application on the new and shiny Cobol compiler.

Gabor

Re: CPANTS is not a game.

[Adam Kennedy]

Oh, and by the way...

What the hell is the "run" thing in the latest run... is the run just 
half-way through or something?


Adam K

Re: CPANTS is not a game.

[Adam Kennedy]

  I'm now settled in my new job (and new appartment), the new and
  improved CPANTS is running on a new server (provided by yi.org, thanks
  again to Tyler MacDonald!). So basically all the time I can spend on
  CPANTS will go into new tests (eg a check if used modules (minus stuff
  in Module::CoreList) matches PREREQ_PM).


That would be really nice, and thanks.

In fact, you have my continual thanks for making something that means 
your can actually keep an eye out for problems across acres of modules.


I think pretty much everyone with 20+ modules needs something like it.


- Until I grok PPI and merry it with CPANTS, testing distribution
  kwalitee is basically the only halfway serious option. Even this
  doesn't work all the time (see has_test_pod*).

  Dist tests are low-hanging fruits. But I'll promise I'll reach
  further. Later...


You can play a little with PPI if you wish, but it still can't run _all_ 
of CPAN without overloading memory usage from various enormous Perl files.


That said, I'd like to see a metric called no_insanely_large_files to 
trap everyone with a single file larger than about 250k. Almost all of 
them are trouble and could probably use various techniques to shrink 
them down (seperating the docs into *.pod or something)


I do promise to get back to you once PPI is safe for all of CPAN without 
going haywire.



- CPANTS as a multiplayer online game is an easy way to get peoples
  attention without totaly offending them. I /could/ send an email to
  everybody on CPAN with some 'helpfull hints' on how to improve
  kwalitee. I guess the biggest effect would be to get added to some SPAM
  blacklists etc...

  But with the tongue-in-cheek 'highscore lists', people get
  interested/hooked and DO improve their code. I got several mails of
  people who discovered semi-serious problems in their code (eg missing
  'use strict' statements) because they checked their CPANTS ratings.

  If people want to 'cheat', that's ok for me. As soon as I have some
  time to spend on the issue, I can improve the tests (but that's rather
  low on my todo list, as I like to assume that we are all grown-ups and
  do not need faked cpants ratings to boost our ego (I might be
  wrong...)).

  And no, I won't take the fun out of CPANTS.


I actually completely agree with you here.

If you are going to score something, people will inevitably want to 
compete. And if they compete they will inevitably also cheat.


So there's only two choices.

1. Make it so easy and obvious how to cheat there's just no challenge.

2. Start a cold war (ala page rank) with the authors

And I doubt you either have the time or the inclination to do 2.

Simply adding additional tests over time will deal with most of the 
problems of gamesmanship, because people won't have to go to such 
extreme lengths in order to do well.


You just need to be aware that people will naturally game things, and so 
adding metrics where the gaming is a positive effect (or at least, not 
negative) provides the best result.


And remind me to talk about taint_safe_versions at some point :)

Adam K

Re: Unintended consequences

[Adam Kennedy]

Andy Lester wrote:

Here's an example of why I'm not real excited about CPANTS:

http://community.livejournal.com/perl/120747.html


Ironically, posted by someone that also makes all her modules phone home 
at install time.


Adam K

Re: 3 Good Reasons...

[Dr.Ruud]

"Michael Mathews" schreef:
> [attribution repaired] Ruud:
>> [attribution repaired] Michael:

(Michael previously sent me an independent off-list reply; we're back on
the list now)

>>> As I gradually learn how Parrot works, I see that perhaps the idea
>>> of decompiling byte-code into language ___ is only a pipe-dream.
>>> But the point still remains--using the fact that one *could* mix
>>> languages X, Y, and P into your company's source tree is a very
>>> weak argument for Parrot/Perl6. I would say it is a non-argument.
>>
>> Not really. Think about a Cobol-to-Parrot translator. You could for
>> example use Perl (glue) to add GUI stuff to old Cobol programs.
>>
>> Just see it as a way to solve real problems. You don't have to use it
>> yourself.
>
> I'll try to be more clear. The original question was seeking opinions
> on what the big gains were for companies to switch to Parrot/Perl6
> (someday). My point was that saying it would allow a mixture of
> languages to be used in an application is, in my real-world
> experience, not something companies are currently seeking, plus you
> don't need to upgrade to do it, so it isn't really a selling point
> worth bringing up to your local IT Manager type person.

Then don't use this point to sell it to that manager.


>>> it also means she now has to keep a
>>> Java/PHP/Perl programmer around and happy whenever one of three
>>> different languages might throw a buggie.
>>
>> No, it is not limited by that.
>
> Huh? Let me give an actual example. A major broadcasting company I was
> contracted with needed to change part of their gigantic code base that
> dealt with a data source of live sports scores (which were
> automatically displayed on air). The code was all Perl :-) except for
> one chunk in Python--so guess where the problem was. This had to be
> fixed FAST and no one in the office knew Python well enough to do it,
> including me (the guy who wrote the Python was long gone to work at
> Google). 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.

I already knew from the start that you had a bad experience in this
area. ;)

Of course you don't want your car built partly with metric and partly
with English measured parts.
 But that is not what this is
about. The feature is not designed to crash a spacecraft, but of course
somebody will still use it for that.


> In my experience Perl has an (undeserved) bad reputation in regards to
> large, long-term projects because it allows "too much" flexibility.

That will not change.


> Really that means management has to do work to set and enforce
> standards, but those managers aren't going to be impressed by hearing
> Perl 6 makes it easy to mix lots of different languages together.
> Nevermind how cool/useful I personally think that is.

I like it that Perl5 and C go so well together. I dislike Java, so I
don't care for it.
Let's just make Perl6/Parrot the ultimate Cobol "shell" as well.

-- 
Affijn, Ruud

"Gewoon is een tijger."

Re: 3 Good Reasons...

[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: 3 Good Reasons...

[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 // 

Re: 3 Good Reasons...

[Michael Mathews]

> As I gradually learn how Parrot works, I see that perhaps the idea of
> decompiling byte-code into language ___ is only a pipe-dream. But the
> point still remains--using the fact that one *could* mix languages X,
> Y, and P into your company's source tree is a very weak argument for
> Parrot/Perl6. I would say it is a non-argument.

Not really. Think about a Cobol-to-Parrot translator. You could for
example use Perl (glue) to add GUI stuff to old Cobol programs.

Just see it as a way to solve real problems. You don't have to use it
yourself.


I'll try to be more clear. The original question was seeking opinions
on what the big gains were for companies to switch to Parrot/Perl6
(someday). My point was that saying it would allow a mixture of
languages to be used in an application is, in my real-world
experience, not something companies are currently seeking, plus you
don't need to upgrade to do it, so it isn't really a selling point
worth bringing up to your local IT Manager type person.


> The reason this would make an IT Manager cry is not (promarily)
> because it is slow (etc, etc),

It isn't slow.


My comment was in reference to the immediately preceding example of
using backticks, which spawn extra processes and therefore IS slower
than not spawning extra processes. Sorry if that was confusing.


> it also means she now has to keep a
> Java/PHP/Perl programmer around and happy whenever one of three
> different languages might throw a buggie.

No, it is not limited by that.


Huh? Let me give an actual example. A major broadcasting company I was
contracted with needed to change part of their gigantic code base that
dealt with a data source of live sports scores (which were
automatically displayed on air). The code was all Perl :-) except for
one chunk in Python--so guess where the problem was. This had to be
fixed FAST and no one in the office knew Python well enough to do it,
including me (the guy who wrote the Python was long gone to work at
Google). 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.

In my experience Perl has an (undeserved) bad reputation in regards to
large, long-term projects because it allows "too much" flexibility.
Really that means management has to do work to set and enforce
standards, but those managers aren't going to be impressed by hearing
Perl 6 makes it easy to mix lots of different languages together.
Nevermind how cool/useful I personally think that is.

--michael

Fwd: 3 Good Reasons...

[Michael Mathews]

Hi Affijn,

As I gradually learn how Parrot works, I see that perhaps the idea of
decompiling byte-code into language ___ is only a pipe-dream. But the
point still remains--using the fact that one *could* mix languages X,
Y, and P into your company's source tree is a very weak argument for
Parrot/Perl6. I would say it is a non-argument.

As you point out, it can already be done with Inline.pm & friends. In
fact, it can be done even more blatantly with backticks. It has long
been possible to do stuff like this:
 #!perl5
 $a = `/usr/bin/java foo.class`;
 $b = `/usr/bin/php bar.php`;
 $c = $a + b;

The reason this would make an IT Manager cry is not (promarily)
because it is slow (etc, etc), it also means she now has to keep a
Java/PHP/Perl programmer around and happy whenever one of three
different languages might throw a buggie.

--michael


On 26/05/06, Dr.Ruud <[EMAIL PROTECTED]> wrote:

"Michael Mathews" schreef:

> [compile down to a *language independent* format]
> So does that mean I can write a module in Perl 6, deliver it to Mr.
> Customer as byte-code. Then Mr. Customer can "decompile"(?) it into
> Python (or JavaScript, or C, etc), edit it, and then compile it back
> into working byte-code again?

No, compiling to bytecode is like a one way street: you will probably
not remain recognizable when you drive it in the opposite way. It is
less hard to go from Perl6-code to Python-code or rather v.v.

But there is no need for all that. Think about the libraries compiled
from C-code that are now linked with Perl5. You can do something
similar with Parrot: create libraries that can be efficiently "linked"
with code written in other languages (that compile to Parrot).

Mixed language source code, even cleaner than the current Perl5 with
Inline.pm, is another feasibility.

--
Affijn, Ruud

"Gewoon is een tijger."

Re: CPANTS is not a game.

[Thomas Klausner]

Hi!

On Thu, May 25, 2006 at 09:51:06PM +0200, Philippe "BooK" Bruhat wrote:
> Le mardi 23 mai 2006 ? 21:56, Thomas Klausner ?crivait:
> > 
> >   And no, I won't take the fun out of CPANTS.
> 
> Then why did you filter out the Acme modules from the prereq lists? Mmm?
> 
> For example, see http://cpants.perl.org/dist/Bot-MetaSyntactic 
> and http://cpants.perl.org/dist/Acme-MetaSyntactic-RefactorCode
> 
> Both list Acme::MetaSyntactic as a prerequisite in Makefile.PL,
> but it doesn't appear in the "Listed Prerequisites" nor in the
> "Modules/pragmas/etc use'd by Acme-MetaSyntactic-RefactorCode" lists
> (and therefore doesn't get its well earned is_prereq point).

That's a bug, not a feature :-)

I'll take a look later. BTW, there seems to be quite some dists missing
since I switched to the new version. But it's rather hard to find bugs
etc when a complete run takes several hours...



> Another side effect is that CPANTS gives false information.

Thats why it says "ALPHA VERSION - Hic sunt dracones!" on every page.
And
"Please take all the information presented here with a grain of salt.
The methods used to test the distributions are a bit flakey, and some of
the Kwalitee indicators are still subjects of discussions (which should
happen on the perl-qa list)."
on the start page.


-- 
#!/usr/bin/perl   http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: perl.perl6.users on nntp.perl.org (was: Logic Programming for Perl6)

[Ruud H.G. van Tol]

mAsterdam schreef:
> Ovid:

>> Larry pointed out that this topic is better suited
>> for perl6-language instead of perl6-users, so I'm
>> forwarding this along.
> 
> Is there a reason perl6-users isn't fed through to nntp.perl.org ?
> Maybe it is but I don't know to which group?

news://nntp.perl.org/perl.perl6.users

There is also 

  perl.perl6.announce
  perl.perl6.compiler
  perl.perl6.documentation
  perl.perl6.internals
  perl.perl6.language

-- 
Groet, Ruud

Re: 3 Good Reasons...

[Dr.Ruud]

"Michael Mathews" schreef:

> [compile down to a *language independent* format]
> So does that mean I can write a module in Perl 6, deliver it to Mr.
> Customer as byte-code. Then Mr. Customer can "decompile"(?) it into
> Python (or JavaScript, or C, etc), edit it, and then compile it back
> into working byte-code again?

No, compiling to bytecode is like a one way street: you will probably
not remain recognizable when you drive it in the opposite way. It is
less hard to go from Perl6-code to Python-code or rather v.v.

But there is no need for all that. Think about the libraries compiled
from C-code that are now linked with Perl5. You can do something
similar with Parrot: create libraries that can be efficiently "linked"
with code written in other languages (that compile to Parrot).

Mixed language source code, even cleaner than the current Perl5 with
Inline.pm, is another feasibility.

-- 
Affijn, Ruud

"Gewoon is een tijger."

perl.perl6.users on nntp.perl.org (was: Logic Programming for Perl6)

[mAsterdam]

Ovid wrote:

Larry pointed out that this topic is better suited 
for perl6-language instead of perl6-users, so I'm
forwarding this along. 


Is there a reason perl6-users isn't fed through to nntp.perl.org ?
Maybe it is but I don't know to which group?