Re: Binary distributions

[Adam Kennedy]

But I'm not really too worried any more, the CamelPack means it's much 
easier not to just install from source than use the PPM system.


s/not/now/

sigh

Adam K

Re: Binary distributions

[Offer Kaye]

On 2/6/06, Adam Kennedy wrote:
>
> > But I'm not really too worried any more, the CamelPack means it's much
> > easier not to just install from source than use the PPM system.
>
> s/not/now/
>

Installing from souce == compiling every module that needs it... How
is that *easier* than installing a pre-compiled package?

Of course I'm assuming that the PPM method *works* as intended...
obviously it doesn't... but in an ideal world, all else being equal,
PPM would be easier, IMHO.

Cheers,
--
Offer Kaye

Re: Binary distributions

[A. Pagaltzis]

* Offer Kaye <[EMAIL PROTECTED]> [2006-02-06 09:15]:
>Installing from souce == compiling every module that needs it...
>How is that *easier* than installing a pre-compiled package?

You don’t need sit there turning a crank while the compiler does
its job. Does it take longer? Sure. Is it harder? No.

And if the alternative to compiling from source is not being able
to install the module in question at all, then it certainly is
“easier” in that sense.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Binary distributions

[Smylers]

Offer Kaye writes:

> On 2/5/06, Offer Kaye wrote:
> 
> > [http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/Scalar-List-Util-1.15.txt
> 
> 
> Something funky here...  Last night I looked at "Scalar-List-Util"...
> but the correct name as Tyler said is "Scalar-List-Utils", with an "s"
> at the end.

If you have a look at the Backpan directory of Graham Barr (the
maintainer of Scalar-List-Utils) you'll see that mostly he's called the
distribution Scalar-List-Utils-version.tar.gz, but in May last year
version 1.15 was released as Scalar-List-Util-1.15.tar.gz, without the
"s".

This shouldn't matter: Perl dependencies are on modules, not on
distributions.  And the names of the modules didn't change when the
package was named differently.  If this is confusing ActiveState then
that sounds like a bug in their system.

Smylers

Re: Binary distributions

[Smylers]

Offer Kaye writes:

> I see what you mean... what threw me off was that [List::Util and
> Scalar::Util are] not listed under:
> http://search.cpan.org/dist/perl-5.8.8/

Well spotted!  List/Util.pm (including pod) is here:

  http://search.cpan.org/src/NWCLARK/perl-5.8.8/ext/List/Util/lib/List/Util.pm

Math::Complex (for instance) is included in the above list;
Math/Complex.pm is here:

  http://search.cpan.org/src/NWCLARK/perl-5.8.8/lib/Math/Complex.pm

So it seems the extra level of subdirectories are causing List::Util
(and a whole bunch of other modules) not to show up in the main perl
dist page.

Is Cpan Search's heuristic for what gets included documented anywhere?
In other words, is it that perl5.8.8 is failing in some way to meet some
published criteria for distributions to have modules listed; or is it
that no such spec exists and therefore perl5.8.8's dist is reasonable,
it's just that Cpan Search isn't sufficiently thorough in looking for
places where modules might be hiding?

I note that Kobes's Search doesn't have List::Util listed on the Perl
distro page either:

  http://cpan.uwinnipeg.ca/dist/perl

The code behind that is available, so we can presumably look to see what
the heuristic is ...

Smylers

Re: Param count checks

[Roger Browne]

Chip Salzenberg wrote:
> I'm struggling with good PIR syntax for it
> though ... Void calls will be common, so it'd be nice to express
> them easily.

How about a 'void' keyword:
   void foo(bar, baz)

Roger

Re: Binary distributions

[Offer Kaye]

On 2/6/06, Smylers wrote:
>
> So it seems the extra level of subdirectories are causing List::Util
> (and a whole bunch of other modules) not to show up in the main perl
> dist page.
>
> Is Cpan Search's heuristic for what gets included documented anywhere?

Now that I think about it, I seem to recall reading somewhere about
dual-life modules not being listed in the main Perl page. Dual-life
modules are those that are both core AND are distributed seperatly on
CPAN. Don't remember where I saw that, and don't know if it's true or
relevant here...

Cheers,
--
Offer Kaye

Re: Binary distributions

[demerphq]

On 2/5/06, Offer Kaye <[EMAIL PROTECTED]> wrote:
> BTW Gozer have you looked at the first line:
> Cannot forceunlink D:\cpanrun\build\5-8-0\lib\auto\List\Util\Util.dll:
> Permission denied at D:\cpanrun\build\5-8-0\lib/File/Find.pm line 874
>
> Maybe the script is trying to delete a file that the system thinks is
> in use? Or something similiar? Windows has that annoying habit of
> refusing to delete things it thinks are in use...

This is a known issue on Win32 that the MakeMaker people and the
Module Build people are aware of.

I've produced a patch for the install behaviour and I'm planning to
put together a patch for the uninstall behaviour Real Soon Now. Ive
also volunteered to maintain a new distro which would be split out of
the MakeMaker distro so that people can upgrade the install behaviour
without upgrading the whole MakeMaker package.

Randy Sims put together an initial version of this package including
the install patch at

   

Cheers,
Yves




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

Re: [perl #38236] [PATCH] Restrict clear_eh to handlers in the current context

[Leopold Toetsch]

Bob Rogers wrote:

   Phooey; I should read what I write.  This version changes the word
"sub" to "handler" in a comment, thereby causing it to make sense.


I've now implemented the proposed stricter clear_eh semantics. That is
* clear_eh can only clear exception handlers
* and only from the current context

Tests unTODOed and applied - r11444

Thanks,
leo

Re: PGE vs bindings (was Re: embparrot still has two failures)

[Patrick R. Michaud]

On Mon, Feb 06, 2006 at 08:50:02AM +0800, Audrey Tang wrote:
> On 2/6/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > On Sun, Feb 05, 2006 at 11:34:33AM +0800, Audrey Tang wrote:
> > > That seems to be a fatal error at PGE's side:
> > >
> > >$ echo 'rule $x:=[]' | parrot demo.pir
> > >error:imcc:syntax error, unexpected ']'
> > >in file 'EVAL_2' line 79
> >
> > I've now updated PGE (r11427) so that it provides a more
> > useful exception:
> >
> > p6rule parse error: Term expected at offset 5, found ']'
> 
> Er, what about the originally reported bug though. :-)
> 
> $  echo 'rule $x:=[x]' | parrot demo.pir
> error:imcc:syntax error, unexpected ']'
> in file 'EVAL_2' line 79

Sorry about that, I mis-interpreted the bug you were seeking
to resolve.  PGE doesn't yet handle aliases into scalar
variables (as it's not quite certain where to put the capture
results anyway), so it's having trouble figuring out where to
stick the capture results.  

However, I'll see if I can at least get PGE to parse simple 
scalars and throw the capture somewhere for the time being, 
at least until I have a better handle on how Perl scalars 
will be stored in Parrot.

Thanks!

Pm

Re: Param count checks

[Chip Salzenberg]

On Mon, Feb 06, 2006 at 11:23:40AM +, Roger Browne wrote:
> Chip Salzenberg wrote:
> > I'm struggling with good PIR syntax for it
> > though ... Void calls will be common, so it'd be nice to express
> > them easily.
> 
> How about a 'void' keyword:
>void foo(bar, baz)

Being the first proposal, it's pretty much the best one so far.  :-,
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Param count checks

[jerry gay]

On 2/6/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 06, 2006 at 11:23:40AM +, Roger Browne wrote:
> > Chip Salzenberg wrote:
> > > I'm struggling with good PIR syntax for it
> > > though ... Void calls will be common, so it'd be nice to express
> > > them easily.
> >
> > How about a 'void' keyword:
> >void foo(bar, baz)
>
> Being the first proposal, it's pretty much the best one so far.  :-,
> --
since we already have (as will reminded me) syntax that can be used to
express this difference, and it's tested, i may as well mention it.

  () = foo(42)

works and is tested (the last two tests) in t/compilers/imcc/pcc.t. it
was added in order to make it easier for code generators, which
previously needed to special-case function calls with no returns, or
where they are ignored.

~jerry

Re: Default tests, beta testing, etc.

[Chris Dolan]

On Feb 6, 2006, at 1:37 AM, Adam Kennedy wrote:

In fact, what you just asked is already listed in the PITA  
documentation as within it's scope.


For lack of a better name, I've called it Fallout Testing.

As opposed to Rot Testing, which is when your module doesn't  
change, but makes sure it still works as Perl is upgraded and your  
dependencies evolve.


Since I've got a terribly bad habit of inventing things that have  
existing names, I'm sure someone will correct my on the two above  
namings.


I think those are great names.  Very clear.

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: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[David Cantrell]

David Landgren wrote:

David Cantrell wrote:

brian d foy wrote:

Seriously though, I would expect things in Win32::* to only work on
Windows, things in Linux::* only to work on linux, and so on for many
other sections (including Mac::* where I have some modules).  Portable
code isn't always the goal.
I want my code to be more like File::Spec, which provides a common 
interface to a load of platform-specific modules.  That has very good 
coverage of bizarro OSes ... It doesn't work on RISC OS though.
I suppose that this is less that RISC OS is so truly bizzare that it 
defies anyone to come up with platform-specific File::Spec code for it, 
and more a gentle nudge on your part for someone to find the tuits to do 
so?


Not really, given that I am not one of the three people using RISC OS. 
It was just an observation that there's plenty of nicely portable stuff 
on the CPAN which isn't as portable as we would like.  That's not really 
a problem that can be solved, and anyone expecting code outside of the 
$OSNAME hierarchy to work everywhere is doomed to perpetual disappointment.


--
David Cantrell

Re: Param count checks

[Chip Salzenberg]

On Mon, Feb 06, 2006 at 07:33:08AM -0800, jerry gay wrote:
> since we already have (as will reminded me) syntax that can be used to
> express this difference, and it's tested, i may as well mention it.
> 
>   () = foo(42)
> 
> works and is tested (the last two tests) in t/compilers/imcc/pcc.t.

No, when error checking is enabled, that throws an exception when foo
returns something.  (And if it doesn't, it should!)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Allison Randal]

On Feb 5, 2006, at 3:05, Leopold Toetsch via RT wrote:


.sub "dump" method
 .param int level

The level argument isn't optional at all. Turning on argument count
checks would prevent such errors.
It has to be:

.sub "dump" method
 .param int level :optional


Okay, thanks, changed. Joshua, let me know how it goes. Particle,  
could you check and see if this fixes your problem as well?


What's the difference between :optional and :opt_flag? I found a few  
lines of documentation on these once I knew what to grep for, but  
that's all.


Marking optional parameters is a good move forward. But... retrieving  
garbage values into parameters that aren't passed an argument is not  
a good design for a stable system. It leads to thorny bugs like this  
one. (I've been looking for it for over a month, but could never  
reproduce it on any of my machines.) Can you prevent it from  
retrieving garbage values, even when :optional isn't set?


Allison

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Leopold Toetsch]

Allison Randal wrote:

On Feb 5, 2006, at 3:05, Leopold Toetsch via RT wrote:



... Turning on argument count
checks would prevent such errors.


What's the difference between :optional and :opt_flag? I found a few  
lines of documentation on these once I knew what to grep for, but  
that's all.


Seed pdd03. :optional is the argument. :opt_flag is 1/0 if the argument 
was passed or not.


Marking optional parameters is a good move forward. But... retrieving  
garbage values into parameters that aren't passed an argument is not  a 
good design for a stable system.


Of course. The plan is to turn on argument/return value count checks on. 
See some recent discusson on p6i, e.g. "Param count checks" ;)


You can turn it on manually with the errorson opcode too, see 
t/op/calling.t for examples.



Allison


leo

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Joshua Isom]

You use :optional to denote an optional parameter, and :opt_flag on an 
int that is set to "true" if there's a parameter in :optional.  The 
fact that :opt_flag is optional could be construed to be a bug.  But 
all tests successful for me now for punie, and fairly quickly, so I'm 
going to assume the memory problem's gone.


On Feb 6, 2006, at 11:20 AM, Allison Randal wrote:


On Feb 5, 2006, at 3:05, Leopold Toetsch via RT wrote:

Okay, thanks, changed. Joshua, let me know how it goes. Particle, 
could you check and see if this fixes your problem as well?


What's the difference between :optional and :opt_flag? I found a few 
lines of documentation on these once I knew what to grep for, but 
that's all.


Marking optional parameters is a good move forward. But... retrieving 
garbage values into parameters that aren't passed an argument is not a 
good design for a stable system. It leads to thorny bugs like this 
one. (I've been looking for it for over a month, but could never 
reproduce it on any of my machines.) Can you prevent it from 
retrieving garbage values, even when :optional isn't set?


Allison

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[jerry gay]

On 2/6/06, Allison Randal <[EMAIL PROTECTED]> wrote:
> On Feb 5, 2006, at 3:05, Leopold Toetsch via RT wrote:
> >
> > .sub "dump" method
> >  .param int level
> >
> > The level argument isn't optional at all. Turning on argument count
> > checks would prevent such errors.
> > It has to be:
> >
> > .sub "dump" method
> >  .param int level :optional
>
> Okay, thanks, changed. Joshua, let me know how it goes. Particle,
> could you check and see if this fixes your problem as well?
>
indeed! as you can see by the results from prove below, all tests are
running fine now, and in good time. this seems to have done it.

D:\usr\local\parrot\trunk\languages\punie>prove t/
t\base_condok
t\base_if..ok
t\base_lex.ok
t\base_pat.ok
t\base_termok
t\io_print.ok
t\op_goto..ok
t\past.ok
t\past_nodeok
t\past_op..ok
t\past_val.ok
t\post.ok
t\post_nodeok
t\post_op..ok
t\post_val.ok
All tests successful.
Files=15, Tests=41, 14 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00 CPU)

this change made languages-smoke possible on win32 again.
i'll submit one as soon as i can.
~jerry

Re: overloading the variable declaration process

[Larry Wall]

On Sun, Feb 05, 2006 at 07:26:09PM -0800, Darren Duncan wrote:
: Part way through writing this, I had a brief chat on #perl6 with 
: stevan (and apparently the meta-model is still quite in flux) and he 
: said my question was related to Larry's "class but undef" idea, and 
: that Larry should talk more about the subject.

Aside from the fact that it's not a class, and not necessarily undef,
"class but undef" is a good name for it.  :-)

I've been calling them prototype objects lately for lack of a
better word.  To me, the Real Class is the object instance hiding
behind .meta.  But when you say bare "Foo" you actually naming a
generic object of the type ^Foo, which I see currently as shorthand
for Foo.meta, and which any object that does Foo can get at if it
needs metadata, including the Foo object itself.  In short,

Foo.does('Foo')

This is mostly motivated by linguistics rather than computer science,
insofar as types/classes/roles in natural language are normally
represented by generic objects rather than "meta" objects.  When I
ask in English:

Can a dog bark?

that's equivalent to asking in Perl 6:

Dog.can('bark')

The "Dog" there is in the same type category as $dog, and specifically
is *not* in the same type category as the class that is managing
the logic behind the scenes.  As a user, I'm thinking about "doggy"
objects, not "classy" objects.  It's the very same kind of linguistic
reasoning that gives us "given" rather than "switch", and "when" rather
than "case".  People want to think about their problem's objects,
not the language implementor's representations of those objects.

Now in the case of .can, we do eventually end up asking the metaobject
whether this objects supports the .bark method, but the point is that
the user doesn't have to keep track of how many metas there are.
Or looking at it the other way, any object can stand in for all its
meta objects.  This is how we think (I think).

Psycholinguistially, every "dog" object in your brain is really a
kind of partially instantiated object that is slowly being filled in
with knowledge about the real world counterpart to your mental model.
Your mental model is never perfect.

The trend in the world today is away from monolithic computers that
either know everything or nothing, and toward programs that have
to work with imperfect knowledge that is generated or downloaded on
the fly.  So I think the modeling view of reality is the sweet spot
for the future, and languages that have to know everything before
they think they know anything are doomed to fail.  Well, not fail,
but have restricted ecological niches, such as rocket science.
(And maybe not even there, as machines get more autonomous.)

So the basic answer to you question is, I think, yes.  If Dog chooses
to always return true for .defined, then (in Haskell terms) it's more
like a Just type than a Maybe type.  Perl 6's objects like to be Maybe
types by default, but you can override it.  (I'm using the Haskell
terms loosely here, of course.)  But the very concept of definedness
is getting mushy in Perl 6.  What we need is more concepts of the
form "Is this *sufficiently* defined for what I want to do with it?"
That's why I proposed "defined according to a particular role" as
one way to ask that sort of question.

Hope this helps.

Larry

Re: Is S05 correct?

[Larry Wall]

On Mon, Feb 06, 2006 at 07:26:44AM +1100, Andrew Savige wrote:
: --- Larry Wall wrote:
: > Yes, that's a typo.
: 
: Which reminds me, I noticed some Synopsis typos as follows.

Fixed, thanks!

Larry

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Allison Randal]

On Feb 6, 2006, at 10:04, Leopold Toetsch via RT wrote:

Allison Randal wrote:


What's the difference between :optional and :opt_flag? I found a few
lines of documentation on these once I knew what to grep for, but
that's all.


Seed pdd03. :optional is the argument. :opt_flag is 1/0 if the  
argument

was passed or not.


Ah, need a case insensitive grep for that one. (pdd03 doesn't contain  
the strings "opt" or "optional" anywhere, only "OPT" and "OPTIONAL".)



Marking optional parameters is a good move forward. But... retrieving
garbage values into parameters that aren't passed an argument is  
not  a

good design for a stable system.


Of course. The plan is to turn on argument/return value count  
checks on.

See some recent discusson on p6i, e.g. "Param count checks" ;)


On by default? Or on-all-the-time-you-can't-turn-it-off-even-if-you- 
want-to?


If it's the former, the problem still needs to be solved.


You can turn it on manually with the errorson opcode too, see
t/op/calling.t for examples.


I'll use this to ferret out the places where Punie and TGE use  
optional parameters. But I'm more concerned about the overall design  
question than I am about Punie. (Punie is an exercise to explore what  
we want out of the AST interface and find potential obstacles to  
other language implementations.)


Allison

Re: A GraphViz eye view of Parrot

[Allison Randal]

On Feb 5, 2006, at 5:56, dakkar wrote:


I did, and the big problem is that it has a size of 106967 x 2031 pts,
which I think translates to 1485 x 28 inches. This not only makes it
hard to display, but also hard to follow...


That's more a result of Parrot than it is of any particular diagram  
format. For me, this was actually the most valuable result of the  
display. It's easy to look at the top level directory of Parrot and  
think it's simple. But, the code base is quite large, with intricate  
interlocking pieces. (The diagram was a side-shoot off working on an  
architectural overview.)


As a side note in the useless statistics department: for some strange  
reason, a very high percentage of Parrot's files are 3 levels down  
from the root.



I might try to convice dot to lay it out a bit more clearly. I don't
promise anything (I'm not a GraphViz expert by any stretch of the
definition), but it might be fun to try.


There are some things you can do to group sections of the graph into  
boxes, etc. If you start with the .dot file I posted and send me a  
diff of your changes, I'll work them into the script.


Allison

[perl #38447] [BUG] bc tests should check for installed python

[via RT]

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


almost all the languages/bc tests are failing if python's not
installed. output below.
~jerry

# Failed test (bc\t\function.t at line 87)
bc\t\functionNOK 6#  got: ''python' is not recognized as an internal
 or external command,
# operable program or batch file.
# Error reading source file languages/bc\t\function_6_antlr2_no_past.pir.
# '
# expected: '1
# 2
# '
# 'python languages/bc/bc.py languages/bc\t\function_6.bc && .\parrot.exe langua
ges/bc\t\function_6_antlr2_no_past.pir' failed with exit code 7.

# Failed test (bc\t\function.t at line 99)
#  got: ''python' is not recognized as an internal or external command,
# operable program or batch file.
bc\t\functionNOK 7# Error reading source file languages/bc\t\function_7_antl
r2_no_past.pir.
# '
# expected: '1
# 2
# '
# 'python languages/bc/bc.py languages/bc\t\function_7.bc && .\parrot.exe langua
ges/bc\t\function_7_antlr2_no_past.pir' failed with exit code 7.
# Looks like you failed 7 tests of 8.
bc\t\functiondubious
Test returned status 7 (wstat 1792, 0x700)
DIED. FAILED tests 1-7
Failed 7/8 tests, 12.50% okay
Failed Test Stat Wstat Total Fail  Failed  List of Failed
---
bc\t\basic.t  71 1817675   71  94.67%  1-71
bc\t\function.t7  1792 87  87.50%  1-7
Failed 2/2 test scripts, 0.00% okay. 78/83 subtests failed, 6.02% okay.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.

Re: overloading the variable declaration process

[Darren Duncan]

At 3:02 PM +0800 2/6/06, Audrey Tang wrote:

On 2/6/06, Darren Duncan <[EMAIL PROTECTED]> wrote:

 Speaking briefly, I would like it if Perl 6 provided a way for a
 class (or role, or meta-class, etc) to declare that all variables
 declared to be of that type are automatically/implicitly set to a
 particular value at declaration time, so that they are not undefined

 > if the programmer using them doesn't explicitly set a value.

If so, your use case can be satisfied by declaring that ::NumType (the
class object)
numifies to 0, and ::StrType stringifies to "", via the coerce form.


That could be fine for some situations, but I was looking for a more 
generic solution for:


  my FooType $foo; # acts like we said .= new()
  $foo.do_action();

Essentially, that $foo is like or is a fully instantiated object on 
which you can call arbitrary FooType object methods as if someone set 
it with new(), but where in fact the user never did this.


The coercing solution won't work if the types of use are not 
coersions to simple data types like strings or numbers.


Thank you. -- Darren Duncan

Re: Macros?

[Larry Wall]

On Sun, Feb 05, 2006 at 02:32:08AM +0100, Brad Bowman wrote:
: 
: Hi,
: 
: I've read and reread the macro explanation but I'm still not entirely
: clear on number of things.  The questions and thoughts below are based
: on my (mis)understanding.
: 
: On 03/02/06 02:05, Larry Wall wrote:
: >Macros are functions or operators that are called by the compiler as
: >soon as their arguments are parsed (if not sooner).  The syntactic
: >effect of a macro declaration or importation is always lexically
: >scoped, even if the name of the macro is visible elsewhere.  
: 
: And presumably they can be lexically unimported, or whatever the verb is
: for what "no" does.

Presumably.  At least its grammatical effect must be unimportable, even
if the name isn't.  Which we could do, since we've divorced the grammatical
effect from name visibility.  Nevertheless, the easiest thing might just
be to hide the name, or rather the lexical alias of the name, if the
existence of the lexical alias is what controls the lexical scoping of
the grammatical effect.

: >As with
: >ordinary operators, macros may be classified by their grammatical
: >category.  For a given grammatical category, a default parsing rule or
: >set of rules is used, but those rules that have not yet been "used"
: >by the time the macro keyword or token is seen can be replaced by
: >use of "is parsed" trait.  (This means, for instance, that an infix
: >operator can change the parse rules for its right operand but not
: >its left operand.)
: >
: >In the absence of a signature to the contrary, a macro is called as
: >if it were a method on the current match object returned from the
: >grammar rule being reduced; that is, all the current parse information
: >is available by treating C as if it were a C<$/> object.
: 
: Is this a :keepall match object?  
: Or is the Perl6 grammar conserving by default?  
: (The "Syntax trees [...] are reversible" suggests so)
: Or is this one of the "signature to the contrary" possibilities?

It feels to me like something that wants to be controlled by a very
large context, such as which debugger/IDE you're working under, if any.
Maybe that's one of those "signature to the contrary" things.  I dunno.

: >[Conjecture: alternate representations may be available if arguments
: >are declared with particular AST types.]
: >
: >Macros may return either a string to be reparsed, or a syntax tree
: >that needs no further parsing.  The textual form is handy, but the
: >syntax tree form is generally preferred because it allows the parser
: >and debugger to give better error messages.  Textual substitution
: >on the other hand tends to yield error messages that are opaque to
: >the user.  Syntax trees are also better in general because they are
: >reversible, so things like syntax highlighters can get back to the
: >original language and know which parts of the derived program come
: >from which parts of the user's view of the program.
: >
: >In aid of returning syntax tree, Perl provides a "quasiquoting"
: >mechanism using the keyword "CODE", followed by a block intended to
: >represent an AST:
: >
: > return CODE { say $a };
: 
: I guess the string form is C

Seems like that would bind variables differently, unless we took steps
for it not too.  I was thinking that string macros would have no binding
to the macro's definition's lexical scope.  But then I'm not sure what
that could desugar to.

: If CODE may enclose arbitrary source text of whatever DSL poeple invent,
: alternate braces would probably be useful.  Either q()-like, HERE-doc
: or pod's C<< >> nesting style.

Any CODE-like macro could choose its own delimiter policy.  Arguably we
could go with q:code or some such instead, and I considered this,
but it seemed to me that if you're parsing something that the user
is thinking of primarily as generic Perl code, it ought to look more
like a code block and less like a string.

: >[Conjecture: Other keywords are possible if we have more than one
: >AST type.]
: 
: Ocaml and camlp4 are probably a good source of ideas for quasiquoting.
: I've only perused the documentation, has one actually used Ocaml here?

Not this one.

: See: http://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial004.html

In my copious free time...  :-)

: Rather than misrepresenting Ocaml with my sketchy understanding,
: I'll just mention some possibly interesting features:
: 
: Specific expander rules from the grammar can be used, <:rulename< ... >>

Our rules are all just subs in disguise, so I'm sure we could do something
similar, modulo syntactic sugar.

: They have a C -> AST expander.  I can imagine a SQL -> AST expander
: would find some use in Perl.  I don't think the same AST type is used but 
: that's just a guess.

At this point I'm not so interested in specific mappings, but I'm sure
everyone will have their favorites.

: Two of 

Re: Binary distributions

[Adam Kennedy]

Offer Kaye wrote:

On 2/6/06, Adam Kennedy wrote:

But I'm not really too worried any more, the CamelPack means it's much
easier not to just install from source than use the PPM system.

s/not/now/



Installing from souce == compiling every module that needs it... How
is that *easier* than installing a pre-compiled package?

Of course I'm assuming that the PPM method *works* as intended...
obviously it doesn't... but in an ideal world, all else being equal,
PPM would be easier, IMHO.


I didn't say it uses less resources, I said it's easier.

Installing from source is easier because I have some level of control if 
something goes wrong. I can contact the author or take over 
maintainership if needed.


With PPM I'm reliant on one company to create PPMs (in the default case) 
over which I have no control, and if there's a problem I don't really 
have any influence or ability to get it fixed.


Adam K

Re: overloading the variable declaration process

[Luke Palmer]

On 2/6/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> This is mostly motivated by linguistics rather than computer science,
> insofar as types/classes/roles in natural language are normally
> represented by generic objects rather than "meta" objects.  When I
> ask in English:
>
> Can a dog bark?
>
> that's equivalent to asking in Perl 6:
>
> Dog.can('bark')

That sentence is ambiguous.  You can interpret it as:

Can some dog bark?

Or as:

Can every dog bark?

I think you meant the latter, however the sentence is leaning toward
the former.  "Can dogs bark?" would be less ambiguous in that respect.

And while I'm starting to see the linguistic rationale behind this
decision, I still can't find anything concrete that this buys us. 
Call me an American, but I like instant gratification.

Luke

RE: Is S05 correct?

[Joe Gottman]

> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 06, 2006 3:03 PM
> To: perl6-language@perl.org
> Subject: Re: Is S05 correct?
> 
> On Mon, Feb 06, 2006 at 07:26:44AM +1100, Andrew Savige wrote:
> : --- Larry Wall wrote:
> : > Yes, that's a typo.
> :
> : Which reminds me, I noticed some Synopsis typos as follows.
> 
> Fixed, thanks!
> 

   This may be a stupid question, but where can I view the fixed Synopsis?
When I go to http://dev.perl.org/perl6/doc/design/syn/S05.html, I see that
the modification date is November 16, 2005. Is this the most up-to-date
version?

Joe Gottman

Re: Is S05 correct?

[Patrick R. Michaud]

On Mon, Feb 06, 2006 at 08:29:54PM -0500, Joe Gottman wrote:
>This may be a stupid question, but where can I view the fixed Synopsis?
> When I go to http://dev.perl.org/perl6/doc/design/syn/S05.html, I see that
> the modification date is November 16, 2005. Is this the most up-to-date
> version?

Essentially, yes.  There have been a few corrections since Nov 16
to some typographical errors (for which none of the committers felt
was worth updating the modification date), but nothing substantial
has changed in S05 since then.

Pm

Re: Param count checks

[Bob Rogers]

   From: Chip Salzenberg <[EMAIL PROTECTED]>
   Date: Mon, 6 Feb 2006 08:22:21 -0800

   On Mon, Feb 06, 2006 at 07:33:08AM -0800, jerry gay wrote:
   > since we already have (as will reminded me) syntax that can be used to
   > express this difference, and it's tested, i may as well mention it.
   > 
   >   () = foo(42)
   > 
   > works and is tested (the last two tests) in t/compilers/imcc/pcc.t.

   No, when error checking is enabled, that throws an exception when foo
   returns something.  (And if it doesn't, it should!)

So maybe that could mean "I want exactly zero values," whereas

foo(42)

could mean "I want any number of values"?  That way, the compiler could
specify whether or not extra values were OK in any given case.

   So what is missing is the ability to allow additional values after
one or more expected values.  I can say "Take between zero and two
values" like this:

($P41 :optional, $I41 :opt_flag, $P40 :optional, $I40 :opt_flag)
= $P85($P45, $P46)

But there is no way to specify that three or more args are OK, without
actually specifying an explicit :slurpy register that will consume time
and memory.  Maybe Parrot should support an ":ignore_extras" keyword in
the last position?  So that

(:ignore_extras) = foo(42)

is equivalent to the version above without the "=".  (Which preserves
orthogonality for code generators; you can do it all with the
parenthesized list syntax.)

   And something equivalent ought to be done for parameters.  Allowing

.param :ignore_extras

would be directly equivalent, but ugly.  How about one of

.ignore_extras
.ignore_extra_params

instead?

   I see the handwriting on the wall -- it says that someday soon,
Parrot will insist on strict arg/return checking all the time.  In order
to support Common Lisp correctly (and efficiently), I would like to be
able to shut this off for returns without having to add a useless
:slurpy register everywhere.  Doing so for parameters is less necessary,
but also useful.

-- Bob Rogers
   http://rgrjr.dyndns.org/

Re: Param count checks

[Joshua Isom]

From what I can tell, the biggest concern is how different languages 
will want it done.  Why not allow it to be hll specific?  Perhaps 
either using a .HLL directive or perhaps a sub with a :hll_init or 
something that is called whenever entering that hll, so strictness can 
be defined per hll and make it easier for hll's to interoperate with 
regards to differences in what's allowed.  Some languages are very 
strict, some are very loose.  But for pir native code(not associated 
with a specific hll), I believe it'd be best to be strictest with all 
errors on, that way for any code that requires loose callings it would 
have to explicitly disable errors.


For syntax, I think it'd be expected that few will combine pasm calling 
conventions, the long pir conventions, and/or the short pir 
conventions.  So then why not say "foo(42)" just means "ignore 
returns", and combining the various conventions to be "undefined 
behavior"?


On Feb 6, 2006, at 9:02 PM, Bob Rogers wrote:


   From: Chip Salzenberg <[EMAIL PROTECTED]>
   Date: Mon, 6 Feb 2006 08:22:21 -0800

   On Mon, Feb 06, 2006 at 07:33:08AM -0800, jerry gay wrote:

since we already have (as will reminded me) syntax that can be used to
express this difference, and it's tested, i may as well mention it.

  () = foo(42)

works and is tested (the last two tests) in t/compilers/imcc/pcc.t.


   No, when error checking is enabled, that throws an exception when 
foo

   returns something.  (And if it doesn't, it should!)

So maybe that could mean "I want exactly zero values," whereas

foo(42)

could mean "I want any number of values"?  That way, the compiler could
specify whether or not extra values were OK in any given case.

   So what is missing is the ability to allow additional values after
one or more expected values.  I can say "Take between zero and two
values" like this:

($P41 :optional, $I41 :opt_flag, $P40 :optional, $I40 
:opt_flag)

= $P85($P45, $P46)

But there is no way to specify that three or more args are OK, without
actually specifying an explicit :slurpy register that will consume time
and memory.  Maybe Parrot should support an ":ignore_extras" keyword in
the last position?  So that

(:ignore_extras) = foo(42)

is equivalent to the version above without the "=".  (Which preserves
orthogonality for code generators; you can do it all with the
parenthesized list syntax.)

   And something equivalent ought to be done for parameters.  Allowing

.param :ignore_extras

would be directly equivalent, but ugly.  How about one of

.ignore_extras
.ignore_extra_params

instead?

   I see the handwriting on the wall -- it says that someday soon,
Parrot will insist on strict arg/return checking all the time.  In 
order

to support Common Lisp correctly (and efficiently), I would like to be
able to shut this off for returns without having to add a useless
:slurpy register everywhere.  Doing so for parameters is less 
necessary,

but also useful.

-- Bob Rogers
   http://rgrjr.dyndns.org/

Re: overloading the variable declaration process

[Matt Fowles]

Larry~

On 2/6/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> This is mostly motivated by linguistics rather than computer science,
> insofar as types/classes/roles in natural language are normally
> represented by generic objects rather than "meta" objects.  When I
> ask in English:
>
> Can a dog bark?
>
> that's equivalent to asking in Perl 6:
>
> Dog.can('bark')

Or you might think of it more as a question like "Can the ideal of a
dog bark?"  the answer to which is of course "No, it doesn't exist.".

Perhaps, I am just too firmly rooted in old paradigms but I think it
is very important not to conflate the representation of a thing with
the thing.

http://en.wikipedia.org/wiki/Image:MagrittePipe.jpg

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

Re: Is S05 correct?

[Jonathan Scott Duff]

On Mon, Feb 06, 2006 at 08:29:54PM -0500, Joe Gottman wrote:
>This may be a stupid question, but where can I view the fixed Synopsis?

I don't think it's a stupid question at all.  Larry could have meant
"it's fixed in my working copy" when he said "fixed!" and there would
be no possibility for you to view the fixed version until he commits
his changes.

> When I go to http://dev.perl.org/perl6/doc/design/syn/S05.html, I see
> that the modification date is November 16, 2005. Is this the most up-to-
> date version?

I believe the html representations of these documents are generated
directly from the pod source in the subversion repository. Though I
don't know the particulars of how this happens. For S05, if you look at
http://svn.perl.org/perl6/doc/trunk/design/syn/S05.pod you'll see the
most up-to-date version. But, as pmichaud says, it doesn't differ
substantially from what you've already seen.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

add methods in dynpmc

[François PERRAD]

Hi all,

With the following patch, I try to add two methods (tostring & tonumber) at 
each Lua PMC.

With the first new test, I obtain :

Method 'tostring' not found
current instr.: '_main' pc 13 (languages\lua\t\pmc\number_10.pir:6)

What is it wrong or what have I forget to do ?

François.

add_method.patch
Description: Binary data