Re: import/export and module configuration

[Gaal Yahas]

On Fri, Dec 16, 2005 at 01:05:21PM -0800, Larry Wall wrote:
> I think we can certainly let the module specify the default when
> someone says
> 
> use Module <$hownow>;
> 
> rather than
> 
> use Module :my<$hownow>;
> 
> I suspect the notation for setting default on the module end is simply
> to allow tag pseudo-sets that specify it:
> 
> my $hownow is export(:state); # override implicit :my default

Would uppercase work better to avoid clashes with user-defined tagsets?
I.e. <:STATE :LET :TEMP :ENV :MY :OUR :GLOBAL>. Except I'm not sure what
some of these mean as exportables.

If I export a var from one scope to another, that's fine; the caller
gets a differently scoped alias to the same memory. But what about
closed lexicals? What does this mean:

 sub make_tag {
 my $tag is export = shift;
 { "<$tag>{ @_ }" };
 }

Audrey suggested that perhaps only top-level lexicals should be
exportable.

> : Second, where does a module consumer communicate configuration requests
> : to the module?
> : (e.g., 'use Test::More "no_plan"'),
> 
> Well, there's a lot to be said for ad-hoc, but yes, it would be good
> to get control of the various forms of adhocracy so we know which
> ones are necessarily ad hoc and which ones are that way accidentally.

A straightforward and Huffmanly unoptimized protocol would be to
stipulate an explicit configuration argument. &import can receive it as
a named arg.

 use Test::More conf => "no_plan";

Alternatively disallow implicit my importation specs and treat everything
to the right of the module name syntactically as arguments to import,
with the parser picking out things it recognizes as imports and passing
everything else through.

-- 
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/

Re: handling undef better

[Michele Dondi]

On Fri, 16 Dec 2005, Darren Duncan wrote:

An undefined value is NOT the same as zero or an empty string respectively; 
the latter two are very specific and defined values, just like 7 or 'foo'.

[snip]
Therefore, I propose that the default behaviour of Perl 6 be changed or 
maintained such that:


You have very strong arguments, but I think that Perl becoming more solid 
should not come at the expense of practicity. Indeed the single warning I 
most often happen to have to (locally) disable is 'uninitialized'. 
Granted, a C< //0 > or C< //'' > is even shorter, in production code that 
is, and clearly specifies what one expects, but


(i) people may still trust the data they're working on and prefer the 
other way round,


(ii) they may still want to chunk up quick'n'dirty one-liners (still 
expect to be not strict- and not warnings-safe).



Michele
--
Have you ever stopped to consider that what is crashing
your Perl is sitting between the keyboard and chair?
- Sherm Pendley in clpmisc, "Re: Perl IDE" (edited)

RE: handling undef better

[Michele Dondi]

On Sat, 17 Dec 2005, Darren Duncan wrote:

Undef means "don't know", which is distinct from "zero", because in the 
latter case we explicitly have a value of zero.


But when we don't know we can, and generally do, make reasonable 
_guesses_.


Experience has shown that 0 or '' according the context are ehm, not only 
reasonable, but even good guesses that work most of the time. So much that 
we can safely rely on them. Or if they don't, then it's easy to explicitly 
take care of that particular undef like you suggest.


Also, let undef be an "I don't know" as much as you like: still you can't 
negate that it is invariably associated psychologically with a feeling of 
'nothingness' - indeed it's nothing else; or possibly anything else at the 
same time...



Michele
--
Gavin: Oliver, my father used to say that a man can never outdo a woman when
it comes to love and revenge.
- The War of the Roses (1989)

Re: handling undef better

[Michele Dondi]

On Sat, 17 Dec 2005, Darren Duncan wrote:

Actually, I don't like autovivification either, and wish there was a pragma 
to make attempts to do it a fatal error; it smacks too much of using 
variables that weren't declared with 'my' etc.  I prefer to put in the


What has the latter to do with autovivification? Luke was referring to 
autovivification in the sense of, say, complex data structures. In Perl 5 
we can (strict-)safely write


my $x;
$x->{foo}[42][2005]{bar}='quux';

Would you like to have to explicitly and verbosely declare the shape of 
the structure held in $x instead?



Michele
--
People can parse multi-dimensionally.  Computers cannot... yet.
- chromatic in p6l, "Re: Parsing indent-sensitive languages".

Re: handling undef - second draft

[Michele Dondi]

On Sat, 17 Dec 2005, Darren Duncan wrote:

1. I accept the proposal that we just make another class that implements the 
SQL concept of a null value, perhaps named Null or SQL::Null, rather than


Somebody else suggested the nicely huffmanized 'nil', which IMHO sounds 
definitely interesting, although I guess I still prefer the current 
behaviour...



Michele
--

How can one prove the consistency of "field"??  How to prove that
there are no self contradiction??

How can one prove the consistency of "wombat"??  How to prove that
there are no self contradiction??
- Robin Chapman in sci.math

Obsoleting "require 'Some/Module.pm'"

[Gaal Yahas]

Can we make this work?

 my $mod = "Some::Module";
 require $mod;

It's a very simple patch to pugs. While we're at it, does anybody see a
compelling reason to leave in the Perl 5 semantics of "require $file"?

We could follow the heuristic of the very sane Module::Load, and try
*either* a file *or* a module, but I'm wondering if it isn't a good time
to clean up how we look at modules of code and say that anything loaded
via use or require is named Perlishly only. %*INC keys would thus be
uniformly Perlish names, and their values can be an interesting
structure containing the relative and actual absolute path of the
resources loaded. (In fact, this is what recent pugs does :).

I know some code does "require 'foo.ini'", but can't that be relegated
to a module and use a different store than %*INC?

-- 
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/

[OT?] Quote (was: "Re: handling undef better")

[Michele Dondi]

On Mon, 19 Dec 2005, Michele Dondi wrote:

You have very strong arguments, but I think that Perl becoming more solid 
should not come at the expense of practicity. Indeed the single warning I


Speaking of which:

| The connection between the language in which we think/program and the 
| problems and solutions we can imagine is very close. For this reason 
| restricting language features with the intent of eliminating programmer 
| errors is at best dangerous.


  -- Bjarne Stroustrup


Michele
--
A painting in a museum hears more ridiculous opinions
than anything else in the world.
- Edmond de Goncourt

Re: handling undef better

[Paul Johnson]

On Mon, Dec 19, 2005 at 12:13:04PM +0100, Michele Dondi wrote:

> my $x;
> $x->{foo}[42][2005]{bar}='quux';
> 
> Would you like to have to explicitly and verbosely declare the shape of 
> the structure held in $x instead?

I would like the option to have to, or to be able to do that, and maybe
to declare which hash keys or array elements are valid.

Do we have that already?

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

This week's summary

[The Perl 6 Summarizer]

The Perl 6 summary for the week ending 2005-12-18
Welcome to another Perl 6 summary. This has been a week of shootouts,
cleanups, relationships and cunning translations. Read on for the
details (or, this being a summary, pointers to the details).

This week in perl6-compiler
2 messages? Sometimes I wonder why I even bother summarizing this list;
I could just paste its contents in their entirety. However:

  Call for a Pumpking: Do you want a Ponie?
Jesse announced that Nicholas Clark was retiring as Ponie's Pumpking
following his departure from Fotango. So we're looking for another
volunteer to take Ponie from its current state to a working Perl 5
runtime fully integrated with Parrot. If you're a C programmer with a
good grasp of the Perl 5 internals and you're interested in taking on
the job, [EMAIL PROTECTED] is eager to hear from you.



  Pugs, Javascript and Perl 5
Continuing Pugs' tradition of linguistic mashup, Chia-liang Kao
announced that Pugs Javascript backend can now support Perl5.



Meanwhile, in perl6-internals
  Parrot Shootout
Work continued on implementing and optimizing Parrot's entry for the
Language Shootout.













  Variables, Aliasing and Undefined-ness
Matt Diephouse wondered how he should translate the following in to PIR
code:

  $var   = "Foo";
  *alias = *var;
  $alias = undef;
  $alias = "Baz";
  print $var, "\n";

Audrey "Autrijus" Tang suggested that allowing multiple LexInfo names to
point to the same underlying register would make this sort of thing (and
several Perl6isms) a good deal easier to implement. Leo pointed out that
it actually had been implemented, though I'm not sure if Luthor includes
this. (Pugs always targets the latest Parrot release).



  Cleaning up the build process
Joshua Hoblitt went to town on RT posting a breakdown of proposed
refactorings of the Parrot build process

  ParTCL shootout
Will Coleda suggested that it would be useful to set things up to run
the TCL shootout benchmarks on ParTCL. He's not exactly sure that they'd
*work* just yet (or be fast, come to that), but they'd certainly be a
handy test/benchmark suite. After a couple of patches, it seems that
ParTCL can at least run the "hello" benchmark. Still, a journey of a
1000 miles starts with but a single step and all that.



  Parrot directory reorganization (phase 2 mark 3)
Jerry Gay's reorganization of the Parrot distribution's directory
structure continued apace. Reorganizing the JIT subdirectory and its
associated config system proved to be something of a sticking place, but
Joshua Hoblitt sorted things out.



  Bug or feature?
Chip had some thoughts about PIR's macro support and concluded that we
need a robust multi-line quoting convention in order to pass multiple
lines of code to macros. He outlined some suggested syntax. Discussion
ensued, mostly favourable.



  Building Parrot includes
Leo noted that the files in runtime/parrot/include/*.pasm are created by
configure. He argued that they should really be generated by a Makefile
rule, which would have the advantage of taking note of dependencies.
There followed a certain amount of quibbling with Joshua Hoblitt, but I
don't think anyone disagrees with the gist of the proposal.



  Library loading - no more duplicates
Leo announce that, as a of r10458, Parrot doesn't "load_bytecode" from
the same file twice any more. Chip and Nicholas Clark applauded the
change and plotted ways to make it even more effective.



  Fixing japhs
Not content with implementing shootout benchmarks, Joshua Isom has also
fixed a few of Parrot's example japhs.



  Q: String.get_integer
Leo had some questions about magical conversion between strings and
integers. Patrick and others reckoned that his proposed behaviour was
about right. Personally, I'm not convinced that the basic String PMC
should do any magic conversion, but PerlString definitely should.



  Parrot Borking
Steve Gunnell had a problems with Parrot throwing segfaults. Leo gave
him some pointers to tracking the issue down and recommended using the
SVN repository and not the CVS mirror.



Meanwhile, in perl6-language
  Relational data models and Perl 6
Darren Duncan's been doing some thinking about Relational data models
and how to support working with them in Perl 6 and posted the results of
his thought on this to the list. Lots of di

Re: relational data models and Perl 6

[Dave Rolsky]

On Thu, 15 Dec 2005, Luke Palmer wrote:


On 12/15/05, Darren Duncan <[EMAIL PROTECTED]> wrote:

I propose, perhaps redundantly, that Perl 6 include a complete set of
native


Okay, I'm with you here.  Just please stop saying "native" and "core".
Everyone.


Here, here.


I would like to hear from Ovid and Dave Rolsky on this issue too, as
they seem to have been researching pure relational models.


My take on this is that with all the features that are supposed to be in 
Perl6, implementing a declarative mini-language for relations and tuples 
would be a simple matter of programming ;)


The following bits seem to me to be key to making this work:

* built-in set operators, which can presumably be overloaded
* powerful OO system
* optional strong typing
* macros and grammar engine

So we can do stuff like this:

 my $emp_rel = Relation.new_from_dbms('Employee');
 my $dep_rel = Relation.new_from_dbms('Department');

 my $emp_dep_rel = $emp_rel natural join $dep_rel; # natural join is a macro of 
some sort

 my @array = $emp_dep_rel.sorted_tuples($emp_rel.attribute('name'));

This is a kind of bastardized semi-logical semi-OO language, but 
presumably we could do this instead


  my $relation = relational($dbh,  'employee_name' );

In fact, there's really no reason this couldn't be done in Perl5 today. 
The hard part is gluing the Perl bits to a DBMS, or alternatively 
implementing all of the relational logic (and therefore an RDBMS) in Perl.


Given that there is no truly relational DBMS available, I'm not sure 
exactly what Perl6 can do here, as the hard part is implementing such a 
that TRDBMS.  Of course, you could implement one client-side on top of a 
SQL DBMS.  It's just a simple matter of programming ;)



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

Re: Obsoleting "require 'Some/Module.pm'"

[Darren Duncan]

At 2:58 PM +0200 12/19/05, Gaal Yahas wrote:

Can we make this work?

 my $mod = "Some::Module";
 require $mod;

It's a very simple patch to pugs. While we're at it, does anybody see a
compelling reason to leave in the Perl 5 semantics of "require $file"?



I would very much appreciate such a feature myself, since I always or 
primarily use Perlish names when loading modules.  With such a 
change, I would be able to say:


require $module_name;

... and have it DWIM, which in my mind is the same as "require Foo;", 
and I would no longer have to say:


eval "require $module_name;";
die if $!;

... as I do now.

I like to save string evals for when I'm actually using arbitrary 
runtime generated Perl code which is in a variable.


-- Darren Duncan

Re: handling undef - second draft

[Darren Duncan]

First of all, I concede that features like autovivification and 
undefs defaulting to the domain-qualified 'none' are fine as what 
Perl does by default, so I retract any request to change this; I am 
fine for these things to remain as they are and were.


-- Darren Duncan

P.S. FYI, permit me to illustrate here that alternatives to 
autovivification are not as laborous as they can be made out to be.


At 1:49 PM -0600 12/19/05, Rod Adams wrote (off-list):

That makes histograms, which I use constantly, a major pain in the rump.

  my @x;
  # something which fills @x

  my %x;
  for @x { %x{$_}++ }

that last line becomes

  for @x {
if defined(%x{$_}) {
  %x{$_}++;
} else {
  %x{$_} = 1;
}
  }


There is a much more concise, but still explicit solution, which is 
what I do in these situations.  Instead of:


  my %x;
  for @x {
%x{$_}++;
  }

You have:

  my %x;
  for @x {
%x{$_} //= 0;
%x{$_}++;
  }

The number of code lines increases linearly by depth, with one line 
added per nest level, and not by orders of magnitude such as the 
doubling that your if/else would suggest.



It gets even worse when you consider something like:

  my %data;
  for =$File -> $line {
my ($x, $y, $z) = $line.split;
%data{$x}{$y}{$z}++;
  }


Considering that Perl 6 has multi-dimensional hash keys, you may only 
need something like this instead of the last line anyway:


%data{$x;$y;$z} //= 0;
%data{$x;$y;$z}++;

But even if you do this the older way, that last line would become only:

%data{$x} //= hash();
%data{$x}{$y} //= hash();
%data{$x}{$y}{$z} //= 0;
%data{$x}{$y}{$z}++;

-- Darren Duncan

Re: [OT?] Quote (was: "Re: handling undef better")

[chromatic]

On Monday 19 December 2005 05:06, Michele Dondi wrote:

> Speaking of which:

> | The connection between the language in which we think/program and the
> | problems and solutions we can imagine is very close. For this reason
> | restricting language features with the intent of eliminating programmer
> | errors is at best dangerous.
>
>-- Bjarne Stroustrup

In theory, I agree.

In practice, HEY look over there at that thing that is not C++!

-- c

Re: Obsoleting "require 'Some/Module.pm'"

[Sam Vilain]

On Mon, 2005-12-19 at 14:58 +0200, Gaal Yahas wrote:
> Can we make this work?
> 
>  my $mod = "Some::Module";
>  require $mod;

What about casting it to a package;

  require ::{$mod};

(not sure if the syntax is quite right)

Sam.

Shootout Updates Posted

[Brent Fulgham]

FYI, the revised shootout updates are on the site:

http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=parrot

Performance seems much better with the interpreter
flags suggested.  Please let me know if you notice any problems.

[perl #37987] Configuration flags are being ignored...

[via RT]

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


Basically, the copy&paste done forgot that the var is not a scalar but 
an array.


-- 
Alberto Simões - Departamento de Informática - Universidade do Minho
  Campus de Gualtar - 4710-057 Braga - Portugal
Index: lib/Parrot/Configure/Step/Base.pm
===
--- lib/Parrot/Configure/Step/Base.pm   (revision 10589)
+++ lib/Parrot/Configure/Step/Base.pm   (working copy)
@@ -35,7 +35,7 @@
 my $class = shift;
 {
 no strict 'refs';
-${$class . "::args"}
+@{$class . "::args"}
 }
 }

Use of num instead of float

[Joshua Isom]

I was talking to Leo in the IRC room and he told me post onto the list 
about proposing to change all floats to nums.  Code such as `.local 
float i` would instead be written as `.local num i`, but as I gather 
it, current behavior would remain the same, or at least general 
behavior.

Re: [perl #37987] Configuration flags are being ignored...

[Joshua Hoblitt]

This is a patch that I pasted to #parrot earlier today but it looks like
Leo has already applied it as r10590.

-J

--
On Mon, Dec 19, 2005 at 02:43:54PM -0800, Alberto Simoes wrote:
> # New Ticket Created by  Alberto Simoes 
> # Please include the string:  [perl #37987]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/rt3/Ticket/Display.html?id=37987 >
> 
> 
> Basically, the copy&paste done forgot that the var is not a scalar but 
> an array.
> 
> 
> -- 
> Alberto Sim??es - Departamento de Inform??tica - Universidade do Minho
>   Campus de Gualtar - 4710-057 Braga - Portugal

> Index: lib/Parrot/Configure/Step/Base.pm
> ===
> --- lib/Parrot/Configure/Step/Base.pm (revision 10589)
> +++ lib/Parrot/Configure/Step/Base.pm (working copy)
> @@ -35,7 +35,7 @@
>  my $class = shift;
>  {
>  no strict 'refs';
> -${$class . "::args"}
> +@{$class . "::args"}
>  }
>  }



pgpoO4crAe1L4.pgp
Description: PGP signature

Re: Shootout Updates Posted

[Joshua Hoblitt]

On Mon, Dec 19, 2005 at 04:35:58PM -0800, Brent Fulgham wrote:
> FYI, the revised shootout updates are on the site:
> 
> http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=parrot
> 
> Performance seems much better with the interpreter
> flags suggested.  Please let me know if you notice any problems.

I'm surprised that Parrot's memory usage is so high relative to other
platforms.  It looks like a hog even relative to Java.  Has anyone taken
a serious look at where all that memory is going?

-J

--


pgpCK8lOLEU4w.pgp
Description: PGP signature

Re: Test::Harness spitting an error

[Troy Denkinger]

Ian Langworth wrote:


No one else has replied, so here's a shot in the dark: Try setting the
PERLIO environment variable to "crlf" (without quotes).

 

Thanks, Ian.  That didn't rid me of the error, but I did do a bit more 
digging.  The error is related to my pod.t which is, just as in the docs:


use Test::More;
eval "use Test::Pod 1.14";
plan skip_all => "Test::Pod 1.14 required for testing POD" if $@;
all_pod_files_ok();

Running this under my test harness, I get the error.  Running this with 
prove directly, I get no errors.  I probably won't dig further into this 
as it's not really worth the time.  I'm guessing the problem is 
Test::Harness::* related.


Thanks,

Troy