Re: Perl 6 Summary for week ending 20020728

[Ask Bjoern Hansen]

On 1 Aug 2002 [EMAIL PROTECTED] wrote:

> The mailing list archives are still not searchable (tell me about it),
> but Brent Dax points out that the ever wonderful Google has the "site:"
> keyword to do search restriction. I foresee a handy little autobookmark
> appearing on my galeon toolbar real soon now.

http://groups.google.com/groups?q=perl.perl6

(via colobus (by Jim Winstead), colobus patches (by me) and Stanford
NNTP (by Russ Allbery)).

> Stephen Rawls has a problem; Spamassassin thinks his patches are spam.

Spamassassin didn't play nicely with 5.8.0RC1 which we used until
yesterday when Robert upgraded it.

> 1 It's late.

Don't worry about that.  I'm sure I'm not the only one to really
appreciate it, whenever it comes out.  Thanks!

> Actually, feedback on this would be good; in general adding the links is
> the most time consuming and tedious part of writing the summaries,
> requiring a net connection and time to check the links. Which leads me
> to wonder if I can't write links as predictable google searches using
> the message-id. Time to experiment methinks.

nntp.perl.org supports linking by message-id.

-- 
ask bjoern hansen, http://askbjoernhansen.com/   !try; do();

Re: Perl 6 Summary for week ending 20020728

[Russ Allbery]

pdcawley <[EMAIL PROTECTED]> writes:

> Bugger, I used L and pod2text broke it.
> http:[EMAIL PROTECTED]/msg10797.html

perlpodspec sez you can't use L<...|...> with a URL, and I'm guessing that
I just didn't look at that case when writing the parsing code in pod2text
because of that.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

perl6-language@perl.org

[Miko O'Sullivan]

This is a small collection of ideas for the Perl6 language.  Think of this
posting as a light and refreshing summer fruit salad, composed of three
ideas to while away the time during this August lull in perl6-language.



Give split an option to keep the delimiters in the returned array

I often find that I want to split an expression, but I don't want to get rid
of the delimiters.  For example, I've been parsing a lot of SQL lately, and
I find myself needing to split expressions like this:

   rank=?

It would be really groovy if that expression could be split with the
delimiters in place, something like this:

   @tokens = split _/[?=*-+]/, $sql, keep=>'all';

and get back an array with these values: ('rank', '=', '?')

But that raises a problem: what if the expression is this (note the spaces):

   rank = ?

In that case I would want the = and ? but I wouldn't want the spaces.  A
slightly different option could keep just stuff in parens:

   @tokens = split _/\s*([?=*-+])\s*/, $sql, keep=>'parens';



Set preferred boolean string for scope

In Perl5, if you use a boolean expression (e.g. $x==$y) you get back 1 for
true and an empty string for false.  That makes sense, of course, but I've
always preferred 1 for true and 0 for false.  I generally use exactly only
those two values for true and false in my databases, and I find I'm forever
writing things like ($x==$y ? 1 : 0) to tidy up my booleans.

It would be cool if in Perl6 you could indicate the preferred default values
of true and false for a given namespace or scope, something like this:

   use BooleanValues TRUE=>1, FALSE=>0;

Perl itself could respect these requests in expressions like $x==$y.
Functions that declare themselves as booleans can return anything they like,
but the results would be translated into the caller's preferred true/false
values.  If no such values are indicated for a namespace then whatever the
functions returns is returned.


Push with []

Our friends over in PHP have a nifty little way of saying "push this onto
the end of the array".  You simply assign the value to the array using an
empty index.  In Perl6 it could look like this:

  @arr[] = $var;

The expression above would be exactly equivalent to

  push @arr, $var;

I've always found the first form more intuitive: it feels like I'm assigning
something. It's a paradigm issue... I'm not suggesting that we get rid of
push, just that we create this additional form that allows the programmer to
think of it in a different way.

Re: perl6-language@perl.org

[Dave Mitchell]

On Thu, Aug 01, 2002 at 06:02:14PM -0400, Miko O'Sullivan wrote:
> It would be really groovy if that expression could be split with the
> delimiters in place, something like this:
> 
>@tokens = split _/[?=*-+]/, $sql, keep=>'all';
> 
> and get back an array with these values: ('rank', '=', '?')
> 
> But that raises a problem: what if the expression is this (note the spaces):
> 
>rank = ?
> 
> In that case I would want the = and ? but I wouldn't want the spaces.  A
> slightly different option could keep just stuff in parens:
> 
>@tokens = split _/\s*([?=*-+])\s*/, $sql, keep=>'parens';

But perl5 already does this:

$ perl -le 'print join "|", split /\s*([?=*-+])\s*/, "rank = ?"'
rank|=||?
$

Dave.

-- 
You live and learn (although usually you just live).

Re: perl6-language@perl.org

[Uri Guttman]

> "MO" == Miko O'Sullivan <[EMAIL PROTECTED]> writes:

  MO> Give split an option to keep the delimiters in the returned array

perl5 can already do that. just wrap the delim part in parens and split
will return them. also by using a lookahead/behind as the regex split
won't strip out that text and it will be returned but attached to the
text next to the delimiter.

  MO> Set preferred boolean string for scope

  MO> In Perl5, if you use a boolean expression (e.g. $x==$y) you get back 1 for
  MO> true and an empty string for false.  That makes sense, of course, but I've
  MO> always preferred 1 for true and 0 for false.  I generally use exactly only
  MO> those two values for true and false in my databases, and I find I'm forever
  MO> writing things like ($x==$y ? 1 : 0) to tidy up my booleans.

do these instead:

$bool += 0 ;
($x == $y) + 0

:)

  MO> Push with []

  MO>   @arr[] = $var;

  MO> The expression above would be exactly equivalent to

  MO>   push @arr, $var;

push is just fine with me.

uri

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

Re: perl6-language@perl.org

[Damian Conway]

Miko O'Sullivan suggested:


> Give split an option to keep the delimiters in the returned array

As Dave mentioned, this already happens if you capture within the
split pattern.


 > 
> Set preferred boolean string for scope

It's possible that Perl 6 will have built-in functions C and C.
When called without arguments, they will return the standard true and false
values (1 and "") respectively. If that is the case, then to dynamically 
change them, you'd just write:

{
temp sub false() {0}
# etc.
}

Then, if the built-ins were all defined to use C and C to
return true and false values, you'd have exactly the control you need.

Though I must say I can't see the real need for this. Especially when
you can prefix any boolean expression with unary + and ensure that
any ""s are converted to 0's anyway.


> 
> Push with []
> 
> Our friends over in PHP have a nifty little way of saying "push this onto
> the end of the array".  You simply assign the value to the array using an
> empty index.  In Perl6 it could look like this:
> 
>   @arr[] = $var;

I have to admit that don't find that syntax very intuitive.

Besides, in Perl 5 the same functionality just:

$arr[@arr] = $var;

In Perl 6, that would be:

@arr[+@arr] = $var;

or:

@arr[@arr.length] = $var;

or maybe just :

@arr[.length] = $var;

(if an array were to be made the topic inside its own accessor brackets).

Damian


PS: Thanks for the ideas, Mike! :-)

Re: perl6-language@perl.org

[Graham Barr]

On Thu, Aug 01, 2002 at 06:02:14PM -0400, Miko O'Sullivan wrote:
> This is a small collection of ideas for the Perl6 language.  Think of this
> posting as a light and refreshing summer fruit salad, composed of three
> ideas to while away the time during this August lull in perl6-language.
> 
> 
> 
> Give split an option to keep the delimiters in the returned array
> 
> I often find that I want to split an expression, but I don't want to get rid
> of the delimiters.  For example, I've been parsing a lot of SQL lately, and
> I find myself needing to split expressions like this:
> 
>rank=?
> 
> It would be really groovy if that expression could be split with the
> delimiters in place, something like this:
> 
>@tokens = split _/[?=*-+]/, $sql, keep=>'all';

Try using

@tokens = split /([?=*-+])/, $sql;

> and get back an array with these values: ('rank', '=', '?')
> 
> But that raises a problem: what if the expression is this (note the spaces):
> 
>rank = ?
> 
> In that case I would want the = and ? but I wouldn't want the spaces.  A
> slightly different option could keep just stuff in parens:
> 
>@tokens = split /\s*([?=*-+])\s*/, $sql, keep=>'parens';

@tokens = split /\s*([?=*-+])\s*/, $sql;

already does, in perl 5, what you want.

Graham.

Re: Light ideas

[Miko O'Sullivan]

From: "Dave Mitchell" <[EMAIL PROTECTED]>
> But perl5 already does this:

Dave gets  the "First to Point Out the Feature Exists" award.  I knew that
out of three ideas I'd be lucky if just one of them was actually a new
feature idea.

I might still say that the parens don't make things quite obvious... what if
I need to use parens for a complex regex but *don't* want the delimiters?
But I'm not sure that it's worth changing if it already exists in some form.


From: "Damian Conway" <[EMAIL PROTECTED]>
[talking about the boolean representation thing]
> Though I must say I can't see the real need for this. Especially when
> you can prefix any boolean expression with unary + and ensure that
> any ""s are converted to 0's anyway.

 what would "true" (the string) be converted to?   Here's my point more
explicitly: in a boolean context, there's no need to get any specific string
(0, 1, "yup") as long as it correctly expresses true or false.  It's when
you convert a boolean into a string or number that it becomes convenient to
define how they are represented by default. Yes, of course there are already
ways to change a variable from [some representation of false] to 0, but by
giving a slick way to default the string, a lot of ?? :: type stuff can be
done away with.

> {
> temp sub false() {0}
> # etc.
> }

That sounds like a great way to do it.  A follow up question, then: would it
be easy enough to accomplish that in a use-type format?  I.e., something
like I said earlier:

  use StrictBoolean TRUE=>1, FALSE=>0;

or even just let it default:

  use StrictBoolean;

> >   @arr[] = $var;
> >
> I have to admit that don't find that syntax very intuitive.
> Besides, in Perl 5 the same functionality just:
>
> $arr[@arr] = $var;
>
> In Perl 6, that would be:
>
> @arr[+@arr] = $var;
>
> or:
>
> @arr[@arr.length] = $var;
>
> or maybe just :
>
> @arr[.length] = $var;

The issue of what is more intuitive is of course highly subjective, but I
would argue that for several reasons the more concise version is more
unituitive to the population at large:

- Generally, shorter is better as long as it isn't ambiguous (maybe it is
ambigous, what do you think?)

- It doesn't get bogged down in what the stuff in the braces means

- Those +s and ?s and _s are going to take some getting used to.  People
will probably learn this little shortcut faster than they learn the new
casting symbols.

- There's already a huge population of programmers out there who already use
this notation.  I frankly admit that I think of PHP as a great idea that
wasn't done quite right.  I'd love to see the PHPers of the world migrate to
Perl.


Oh, and sorry about the subject line in the previous email... my
cut-n-pasting was off target.

-Miko

Re: perl6-language@perl.org

[Mark J. Reed]

On Fri, Aug 02, 2002 at 08:30:05AM +1000, Damian Conway wrote:
>   @arr[@arr.length] = $var;
> 
> or maybe just :
> 
>   @arr[.length] = $var;
> 
> (if an array were to be made the topic inside its own accessor brackets).
I know this idea was just thrown in there, but I find that I really dislike
it.  I can see many more uses for the current topic than for array-as-topic
in index expressions.  I can easily envision instance methods wishing
to use instance variables as [part of] indices, for instance.

Having the subscript operator change the topic is, IMHO, a rather strong
violation of the principle of least surprise.

-- 
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G  | [EMAIL PROTECTED]
Atlanta, GA 30348  USA   | +1 404 827 4754 
--
Why isn't there a special name for the tops of your feet?
-- Lily Tomlin

Re: perl6-language@perl.org

[David Wheeler]

On Thursday, August 1, 2002, at 04:05  PM, Mark J. Reed wrote:

> Having the subscript operator change the topic is, IMHO, a rather strong
> violation of the principle of least surprise.

I'm inclined to agree. I think I'd much rather not have it change there, 
since I'll frequently do stuff like this:

my %hash;
for qw(one two three) {
 %hash{$_} = 1; # $_ should *not* == %hash here!
}

Regards,

David

--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]

Re: perl6-language@perl.org

[Dave Mitchell]

On Thu, Aug 01, 2002 at 06:17:11PM -0400, Uri Guttman wrote:
> do these instead:
> 
>   $bool += 0 ;
>   ($x == $y) + 0

or even

$x == $y || 0

-- 
Never do today what you can put off till tomorrow.

Re: Light ideas

[Damian Conway]

Miko O'Sullivan aksed:

>  what would "true" (the string) be converted to?

In a numeric context: 0 (as in Perl 5).


> Here's my point more
> explicitly: in a boolean context, there's no need to get any specific string
> (0, 1, "yup") as long as it correctly expresses true or false.  It's when
> you convert a boolean into a string or number that it becomes convenient to
> define how they are represented by default. Yes, of course there are already
> ways to change a variable from [some representation of false] to 0, but by
> giving a slick way to default the string, a lot of ?? :: type stuff can be
> done away with.

Well, given that Perl 6 has an actual BOOL subtype, maybe C and C 
could return objects with:

* a Boolean conversion to 1/""
* a string conversion to "true"/"false"
* a numeric conversion to 1/0



> That sounds like a great way to do it.  A follow up question, then: would it
> be easy enough to accomplish that in a use-type format?  I.e., something
> like I said earlier:
> 
>   use StrictBoolean TRUE=>1, FALSE=>0;
> 
> or even just let it default:
> 
>   use StrictBoolean;

Yes. In Perl 6 C statements will, by default be lexical in effect.
The module itself *might* look like this:

module StrictBoolean;

my @truth = ({TRUE=>1, FALSE=>0});

sub import ($class, *%beauty) { push @truth, \%beauty }
sub unimport { pop @truth }

sub true  is exported { return @truth[-1]{TRUE}  }
sub false is exported { return @truth[-1]{FALSE} }




> The issue of what is more intuitive is of course highly subjective, but I
> would argue that for several reasons the more concise version is more
> unituitive to the population at large:

Quite possibly. This is why I was so subjunctive about that option. And why 
I'm happy to leave such decisions to Larry. His track-record on DWIMity is 
exceptional. :-)


> - There's already a huge population of programmers out there who already use
> this notation.  I frankly admit that I think of PHP as a great idea that
> wasn't done quite right.  

I agree. Including that notation! ;-)


Damian

Re: perl6-language@perl.org

[Damian Conway]

>> Having the subscript operator change the topic is, IMHO, a rather strong
>> violation of the principle of least surprise.
> 
> I'm inclined to agree. I think I'd much rather not have it change there, 
> since I'll frequently do stuff like this:
> 
> my %hash;
> for qw(one two three) {
> %hash{$_} = 1; # $_ should *not* == %hash here!
> }
> 

Yes, this is one of the reasons we're hesitant to do it. Even though it does
give you lovely slice idioms like:

@public = %hash{ /^(<-[_]>.*)/ };

And, if we *did* go that way, your example would become:

my %hash;
for qw(one two three) -> $key {
 %hash{$key} = 1;
}

which doesn't seem a terribly high price to pay.

On the other hand, too many topicalizing contexts actually reduce the 
intrinsic value of topics themselves, since the current topic then doesn't 
hang around long enough to actually be useful. I suspect that it the clincher 
against this idea.

Damian

Use of regular expressions on non-strings

[David Whipp]

I'm wondering if Perl6's new regex can be applied to non-string things. I
seem to recall A5 mentioning something about strings tied to array
implementations; but I'm wanting something a little more powerful.

A bit of context: I use Perl for verification of big complex ASICs. We run a
simulation and get a waveform database (stores values of each signal over
time). We can then perform queries on that database to check verious
properties.

Example: I want to find any occasions where the bus is requested twice in a
row, without an intervening grant signal. Its a fairly simple query to
implement; but it is, in fact , a regular expresssions. So I would like to
write (pseudo-code):

  my @violations = ($waveform_database =~ m:any/  *  /);

I can think of a number of ways of implementing this (one is to first create
a string by iterating the database and mapping each signal to a bit in the
[ascii?] value of a character, and then defining character classes -- though
I'd not want to lose the timestamps); but will Perl6 make my life any easier
when I write the module? I'm not trying to implement a full CTL* formal
property checker; just something that lets me run queries on an existing
simulation trace (which is an object). Ultimately, it would be nice to
define an entire protocol as a grammer -- the signal trace either conforms,
or doesn't (in which case I get the violations).


Dave.

--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.