headers
David Green | 1 Jun 2008 14:06

Re: assignable mutators (S06/Lvalue subroutines)

On 2008-May-27, at 9:40 am, Dave Whipp wrote:
> TSa wrote:
>>       method inch
>>       {
>>           yield $inch = $.mm * 25.4;
>>           self.mm = $inch / 25.4;
>>       }
>> Would you regard that as elegant?
>
> That looks functionally incorrect to my eyes: if the caller resumes  
> at the time of the "yield" statement, and immediately assigns a new  
> value to the "mm" attribute, then there is a race between the two  
> updates to "mm".

It seems overly complex to me, but perhaps I'm missing good reasons  
for such an approach.  I see lvalue subs mainly as syntactic sugar:

     foo(42);          # arg using normal syntax
     foo <== 42;       # arg using feed syntax
     foo = 42;         # arg using assignment syntax

Feeds are a way of passing values to a function, but work like  
assignment when used on a variable; assignment is a way of giving a  
value to a variable, so it should work like passing args when used on  
a function.  Then you can easily do whatever you want with it.

In fact, it could work just like a feed, and pass values to the slurpy  
params, but I think assignment is special enough to be worth treating  
separately.  Maybe something like:
(Continue reading)

Permalink | Reply | 7 comments |
headers
David Green | 1 Jun 2008 14:16

Huffman encoding (was Re: treatment of "isa" and inheritance)

On 2008-Apr-30, at 1:29 pm, Brandon S. Allbery KF8NH wrote:
> On Apr 30, 2008, at 15:14 , Jon Lang wrote:
>> On a side note, I'd like to make a request of the Perl 6 community
>> with regard to coding style: could we please have adverbal names that
>> are, well, adverbs?  "is :strict Dog" brings to my mind the English
>
> -ly suffixes everywhere conflicts with Huffman coding, which per  
>  <at> Larry is a primary design concern.  Consider the leading colon to  
> be the Perl6 equivalent.

Logically, yes, a ":" on the front of a word is as good an indicator  
of an adverb as an "ly" on the end.  Psychologically, however, it  
isn't; for one thing, my mind doesn't pronounce punctuation the same  
way as letters.  Whatever the reason, I've been reading English for  
decades longer than I have P6 (and by the time I've spent that many  
decades getting familiar with P6, I'll be even more familiar with  
English... which is of course one of the reasons why Perl tries to  
look kinda sorta like English in the first place; it may as well try  
to look like half-decent English!).

But the more general point I wish to make is that extra characters  
don't necessarily conflict with the goal of Huffman encoding.  I  
assume the idea was that extra 'ly's everywhere take up space that  
isn't needed -- of course Huffman himself was concerned with  
minimising bits, but in terms of Perl what we're interested in is  
efficient understanding, not efficient storage.

Now "short code" is not a bad first approximation to "understandable  
code", since longer reading-time will contribute to longer  
understanding-time.  But that's only a very rough rule of thumb: if
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Green | 1 Jun 2008 14:22

Re: ordinal access to autosorted hashes

On 2008-May-27, at 8:32 pm, Jon Lang wrote:
> [...]
> Would it be reasonable to allow hashes to use .[] syntax as something
> of a shortcut for ".iterator in list context", thus allowing
> autosorted hashes to partake of the same sort of dual cardinal/ordinal
> lookup capabilities that lists with user-defined array indices have?

I thought it already did, but apparently it's something that we  
discussed that didn't actually make it into S09.  I agree that .[]  
should apply to hashes just as .{} can apply to arrays.  The hashes  
don't even need to be sorted -- %h[$n] would basically be a shorter  
way of saying  <at> (%h.values)[$n], in whatever order .values would give  
you.

> Side issue: S09 doesn't specify whether or not you need to explicitly
> declare a hash as autosorted.  I'm assuming that the parser is
> supposed to figure that out based on whether or not .iterator is ever
> used; but it isn't immediately obvious from reading the "Autosorted
> hashes" section.  As well, there might be times when explicitly
> declaring a hash as autosorted (or not) might be useful for
> optimization purposes.

Does the parser need to know?  All hashes have an .iterator method,  
but you can override it to force elements to be returned using some  
particular ordering.

Providing a flag for optimisation sounds useful... although since Perl  
doesn't do any sorting for you, if you want something more optimised  
than making .iterator re-sort the hash every time it's called, you'd  
have to replace the innards of the Hash type yourself anyway.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jon Lang | 1 Jun 2008 19:20
Picon

Re: ordinal access to autosorted hashes

David Green wrote:
> Jon Lang wrote:
>> Would it be reasonable to allow hashes to use .[] syntax as something
>> of a shortcut for ".iterator in list context", thus allowing
>> autosorted hashes to partake of the same sort of dual cardinal/ordinal
>> lookup capabilities that lists with user-defined array indices have?
>
> I thought it already did, but apparently it's something that we discussed
> that didn't actually make it into S09.  I agree that .[] should apply to
> hashes just as .{} can apply to arrays.  The hashes don't even need to be
> sorted -- %h[$n] would basically be a shorter way of saying
>  <at> (%h.values)[$n], in whatever order .values would give you.

I believe that the order that .values (or is that :v?) would give you
is determined by .iterator - which, if I'm understanding things
correctly, means that any use of :v, or :k, :p, or :kv, for that
matter, would autosort the hash (specifically, its keys).

Or am I reading too much into autosorting?

Bear in mind that keys are not necessarily sortable, let alone
autosorted.  For instance, consider a hash that stores values keyed by
complex numbers: since there's no way to determine .before or .after
when comparing two complex numbers, there's no way to sort them -
which necessarily means that the order of :v is arbitrary, making
%h[0] arbitrary as well.  This is why I was suggesting that it be
limited to autosorted hashes: it's analogous to how  <at> a{'x'} is only
accessible if you've actually defined "keys" (technically,
user-defined indices) for  <at> a.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jon Lang | 1 Jun 2008 21:50
Picon

Re: assignable mutators (S06/Lvalue subroutines)

David Green wrote:
> It seems overly complex to me, but perhaps I'm missing good reasons for such
> an approach.  I see lvalue subs mainly as syntactic sugar:
>
>    foo(42);          # arg using normal syntax
>    foo <== 42;       # arg using feed syntax
>    foo = 42;         # arg using assignment syntax
>
> Feeds are a way of passing values to a function, but work like assignment
> when used on a variable; assignment is a way of giving a value to a
> variable, so it should work like passing args when used on a function.  Then
> you can easily do whatever you want with it.
>
> In fact, it could work just like a feed, and pass values to the slurpy
> params, but I think assignment is special enough to be worth treating
> separately.  Maybe something like:
>
>    sub foo ($arg1, $arg2, * <at> slurpy, =$x) {...}
>
>    foo(6,9) = 42;       # the 42 gets passed to $x
>
> That example uses a leading "=" for the "assigned" param (parallel to the
> leading "*" for the slurpy param), but I'm not crazy about it for various
> reasons (and =$x refers to iteration in other contexts).

OK; my take on it:

An "lvalue sub" is a sub that can be assigned to - the operative word
being "can".  There's a reason why Perl 6 talks about "is rw" and "is
ro" so much, but has yet to (and may never) officially approach the
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jon Lang | 1 Jun 2008 22:10
Picon

Re: assignable mutators (S06/Lvalue subroutines)

Jon Lang wrote:
> This approach could be functionally equivalent to the "proxy object"
> approach, but with a potentially more user-friendly interface.  That
> is,
>
>  sub foo (*$value) { yadda }
>
> might be shorthand for something like:
>
>  sub foo () is rw {
>    return new Proxy:
>      FETCH => method { return .doit() },
>      STORE => method ($val) { .doit($val) },
>      doit => method ($value?) { yadda }
>  }

Correction:

  sub foo (*$value) { yadda }

might be shorthand for something like:

  sub foo () is rw {
    return new Proxy:
      FETCH => method { return .() },
      STORE => method ($val) { .($val) },
      postcircumfix:<( )> => method ($value?) { yadda }
  }

i.e., it can be called like a regular function as well as via
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Fenwick | 2 Jun 2008 04:31
Picon
Favicon

Fatal/autodie exception hierarchies for Perl 5

G'day p6l and p5p,

I'm currently working on the 'autodie' pragma for Perl 5, which is 
essentially 'Fatal' but with lexical scope.  It's similar to the 'fatal' 
pragma described in S04/Exceptions.

autodie is implementing an exception hierarchy for in-built functions. 
Essentially we have a tree that looks like:

   :all
       :USER
       :CORE
           :math
               atan2
           :io
               :file
                   open
                   close
               :filesys
                   opendir
               :socket
                   accept
                   bind
                   connect
                   ...

Currently, when testing exceptions from autodie, we can use:

	given ($ <at> ) {
		when (undef)   { say "No errors here" }
(Continue reading)

Permalink | Reply | 0 comments |
headers
TSa | 2 Jun 2008 18:24

Re: The Inf type

HaloO,

John M. Dlugosz wrote:
> The sqrt(2) should be a Num of 1.414213562373 with the precision of the 
> native floating-point that runs at full speed on the platform.

That makes the Num type an Int with non-uniform spacing. E.g. there
are Nums where $x++ == $x. And the -Inf and +Inf were better called
Min and Max respectively. IOW, the whole type based aproach to Inf
is reduced to mere notational convenience.

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
Permalink | Reply | 10 comments |
headers
Jon Lang | 2 Jun 2008 20:50
Picon

Re: The Inf type

TSa wrote:
> John M. Dlugosz wrote:
>> The sqrt(2) should be a Num of 1.414213562373 with the precision of the
>> native floating-point that runs at full speed on the platform.
>
> That makes the Num type an Int with non-uniform spacing. E.g. there
> are Nums where $x++ == $x. And the -Inf and +Inf were better called
> Min and Max respectively. IOW, the whole type based aproach to Inf
> is reduced to mere notational convenience.

Please give an example value for a Num where $x++ == $x.  Other than
Inf, of course.

As well, I can easily buy into the idea that +Inf _is_ conceptually
equivalent to Max, in that '$x before +Inf' will be true for all
non-Inf values of $x that are Nums.  Likewise, -Inf is conceptually
equivalent to Min in the same way.  But just because they're
conceptually equivalent, that doesn't mean that they're better off
renamed.

If you intend to come up with a more encompassing definition of Inf,
please do so in a way that preserves the above behavior when you apply
that definition to Num.

--

-- 
Jonathan "Dataweaver" Lang
Permalink | Reply | 9 comments |
headers
Mark J. Reed | 2 Jun 2008 20:54
Picon

Re: The Inf type

On Fri, May 9, 2008 at 9:10 AM, TSa <Thomas.Sandlass <at> barco.com> wrote:
> E.g. sqrt(2) might return a special Inf that can be lazily
> stringified to an arbitrary long sequence of digits of sqrt(2).

In what the heck mathematical world is the square root of two an
infinite value?  Irrationality and infinitude are not the same thing;
in particular, there are an (uncountably) infinite number of
irrational numbers...
--

-- 
Mark J. Reed <markjreed <at> gmail.com>
Permalink | Reply | 1 comment |

Gmane