slowness in grammar

[Richard Hainsworth]

Is this a good place to come with code that runs into speed problems?

I am writing a program in perl6 to read the xml file from a Sony book 
reader, list the books, and move books into collections (the Sony 
software to do this will only work on windoz and not on wine).


I have a grammar that works with abbreviated test versions of the xml 
file, but it just hangs with the full version.


Since I have a line
my $parsed= sony_grammar(slurp "media.xml");

and the problem is in the parsing, I dont know how to insert trace 
statements to determine at what stage the problem is being generated.


In addition, there is a great deal in the Synopses about code points and 
backtracking and the like, which I dont quite understand. However, it 
seems to me that an intelligent use of these possibilities could 
increase the efficiency of the parsing, if only I knew how. For example, 
only three of the tags in the file are of interest, and within them 
three of the attributes. So how do I tell the regex engine to skip 
processing if the tag is not of interest?


Richard

Re: CPAN -- moving forward

[Patrick R. Michaud]

On Mon, Jun 01, 2009 at 06:34:02PM +0200, Daniel Carrera wrote:
> I am in IRC  
> working with Rakudo folk on how Rakudo is going to store modules on the  
> disk. Once that is done, one can begin talking about a package format  
> and an installer, and then go from there.
>
> So far the discussion has been productive and we have some code written  
> that we can experiment with. So I feel encouraged.

"Rough concensus and running code."  +1

Pm

Re: Module naming conventions

[Daniel Carrera]

Hi Patrick,

To reduce list traffic, I'm replying to both of your emails together.



Just because these are the only adverbs mentioned doesn't necessarily
mean they're the only ones that will be allowed.


Ok. My interpretation was that adding adverbs would require updating the 
spec. More importantly, I thought that it would be more difficult to get 
agreement on a new adverb. I figure that at this late stage in the 
process, you probably don't want to make a lot of language changes.


In your other email, you say:


> For the Parrot case at least, I suspect one would/could do:
>
> use SHA:from;
>
> (See the :from adverb in S11.)


That looks great. I didn't think of that. Perhaps it can be used for C 
as well. We might have to abuse the :from a little to include the name 
of the C bindings (if there is more than one option).


Daniel.

Re: Module naming conventions

[Patrick R. Michaud]

On Tue, Jun 02, 2009 at 10:58:21AM +0200, Daniel Carrera wrote:
> John M. Dlugosz wrote:
>> The front-end should figure out which binary is proper for your  
>> platform.
>
> I don't like that idea in the slightest. (1) It is not Perl's job to  
> know if you have a C compiler, C libraries and tool chain. (2) If my  
> computer can handle Perl, C and Parrot, I want the choice of what to  
> install. (3) That includes the possibility of installing more than one  
> module. It is perfectly legitimate to install three implementations of  
> SHA (one in C, one in Parrot and one in pure Perl). This last one means  
> that there has to be a way to tell Perl which of the Digest::SHA modules  
> I want to use for this particular program.
>
> Suppose I want to install three versions of SHA. One in C, one in Perl,  
> one in Parrot. I need a way to specify in the "use" statement which one  
> I want.

For the Parrot case at least, I suspect one would/could do:

use SHA:from;

(See the :from adverb in S11.)

Indeed, for someone who is running an implementation of Perl 6
on Parrot (and where a Parrot-specific implementation of SHA is
available), I would expect a plain "usa SHA;" to load SHA.pm
which then in turn does the :from version of use.  Or 
any other number of implementation-specific tricks that can hide the
details for a generic "use SHA" but still make it possible for
more specific requirements to be made.

Pm

Re: Module naming conventions

[Patrick R. Michaud]

On Tue, Jun 02, 2009 at 02:56:46AM +0200, Daniel Carrera wrote:
> Jon Lang wrote:
>> On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera
>>  wrote:
>>> I think we might need to come up with some sort of standard naming
>>> convention to distinguish dependencies. Something that the *user* can
>>> recognize quickly when he browses CPAN.
>>
>> Why do we need the dependencies to be part of the name?  Perl 6
>> provides a rugged versioning system for its modules; we should use it.
>
> I read S11 and AFAICT Perl 6 only includes metadata for *versions* and  
> *authority*:
>
> class Dog:ver<1.2.1>:auth;
> class Dog:ver<1.2.1>:auth;
> class Dog:ver<1.2.1>:auth;

Just because these are the only adverbs mentioned doesn't necessarily
mean they're the only ones that will be allowed.  Indeed, S11 goes
on to later say:

"The required parts for library insertion are the short name of
the class/module, its version number, and a URI identifying the 
author (or authorizing authority, so we call it "auth" to be 
intentionally ambiguous)."

The fact that S11 says "required parts" leads me to believe that
there can be other parts that aren't required.

Pm

Re: Information Model manuscript, pt.2

[TSa]

HaloO,

John M. Dlugosz wrote:
Please see part 2 of my comprehensive explaination of the Perl 6 
Information Model, at .


This isn't linked up to my main page yet.  I'm taking comments and 
further discussion here before I make it public.


This is a pretty good summary. It also nicely points out missing
specifications concerning the 'is ref' trait. I'm keen on reading
your analysis concerning the difference between a parameter with
a @ sigil and a 'Positional $x' sig.

I like your idea to call the class that handles container access
LValue. I have proposed the name AssignmentProxy elsewhere.

But I'm not sure what S06 means with "can be converted to an lvalue"
in the description of the 'is rw' parameter trait. To me this means
autoboxing such that you can call a mutating sub with a constant. The
modifications done to the automatic container are lost after the call.
You state that the compiler raises an error which clearly is the cleaner
approach.


There is a feature I miss for array and hash parameters: to make
them immutable. This allows for subtype based dispatch. So I propose
to add an 'is immutable' parameter trait. Here is an explanation
why that is useful. Assume that Dog is a subtype of Animal and that
it has a bark method that is not available in Animal, i.e. calling
it on an Animal instance is an error.

  sub store17 (Animal @a)
  {
  @a[17] = Animal.new; # assignment error?
  }
  my Dog @dog;
  store17(@s); # bind error?
  @dog[17].bark(); # dispatch error

My first question is if the indicated assignment error in store17 is
raised. The best spot to detect the error is at bind time when store17
is called with a Dog array. Here immutability of the array would allow
the call because writing into the array is then prohibited. Reading a
Dog and using the Animal interface on it is type safe.

The 'is immutable' trait should also be applicable to methods so
that objects get a subset of their interface that is not mutating
the object. This is like const methods in C++. The default 'is readonly'
of parameters applies only to the lvalue not the referenced object.

A good question is if the compiler can statically detect array
assignment because postcircumfix:<[ ]> could be an immutable method
of the Array. A mutation of the array happens only when the returned
LValue instance is used as lhs of an assignment. So the question is
if the immutability of the array is propagated to the LValue and how
the compiler knows that. How would that be written in the sig of
postcircumfix:<[ ]>? The syntax has to define a conditional trait on
the return type. One approach could be to define that a type capture
transports the trait:

role Positional
{
method postcircumfix:<[ ]>
 (::T $self: Int $i --> LValue[T] is immutable(T))
is immutable
{...}
}


After writing the above I realized that your webpage actually claims
that readonly @ sigil parameters are blocking the mutating Positional
interface. If this is true I'm happy. The thing that should be specced
then is the availability of 'is readonly' for methods. This is needed
to implement the distinction between the mutating and non-mutating
interfaces of objects. Hmm, could the compiler infer this trait from
the body of the method?


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Re: Module naming conventions

[Chris Fields]

On Jun 2, 2009, at 5:11 PM, Daniel Carrera wrote:


John M. Dlugosz wrote:

So CPAN6 is basically only going to be for Parrot?


What are you talking about? Did you even read my email? I said that  
a module might be implemented in multiple languages (see Digest::SHA  
VS Digest::SHA::PurePerl) and someone might have both versions  
installed.


Daniel.


Speaking as an almost complete outsider (I'm a bioperl core dev  
writing up a perl6 port), I find the tone of several of these more  
recent posts (re: CPAN6 and module conventions) counterproductive.  
TimToady recently posted about snippiness and 'tensegrity', so I'm not  
the only one sensing it.


chris

Re: Module naming conventions

[Daniel Carrera]

John M. Dlugosz wrote:

Yes.  did you read mine?


Yes, I read your email.

Sounds like you are thinking of Parrot vs pure 
perl, and missed my point about being utterly different implementations, 
not choices within one.


Chances are, the most popular implementations of Perl 6 will allow C 
bindings, just like Perl 5. Some, like Rakudo, will have both C and 
Parrot bindings. In this day, users do have a choice. A Rakudo user 
could install a module that uses C bindings, or he could install a 
module that is all Perl, or he could install a module that uses Parrot. 
There are perfectly valid reasons why he might choose one option or 
another. A SMOP user might install a module that uses C bindings, or one 
that is all Perl. There are valid reasons why he might want one or the 
other.



Daniel.