headers
Damian Conway | 1 Oct 2005 04:33

Re: Look-ahead arguments in for loops

Rather than addition Yet Another Feature, what's wrong with just using:

	for  <at> list ¥  <at> list[1...] -> $curr, $next {
	    ...
	}

???

Damian
Permalink | Reply | 14 comments |
headers
Luke Palmer | 1 Oct 2005 04:39
Picon
Gravatar

Re: Look-ahead arguments in for loops

On 9/30/05, Damian Conway <damian <at> conway.org> wrote:
> Rather than addition Yet Another Feature, what's wrong with just using:
>
>         for  <at> list ¥  <at> list[1...] -> $curr, $next {
>             ...
>         }
>
> ???

Thanks.  I missed that one.

However, I think your point is pretty much the same as mine. 
Certainly adding this to specialized syntax in signature matching is
an overfeature, so I tried to squish it down into options, which we
can add at will without really complexifying the core language.  But
without options, like this, is even better.

Incidentally, the undef problem just vanishes here (being replaced by
another problem).  Since zip takes the shorter of its argument lists,
you'll never even execute the case where $next is undef.

Luke
Permalink | Reply | 5 comments |
headers
Mark A. Biggar | 1 Oct 2005 04:44

Re: Look-ahead arguments in for loops

Damian Conway wrote:
> Rather than addition Yet Another Feature, what's wrong with just using:
> 
>     for  <at> list ¥  <at> list[1...] -> $curr, $next {
>         ...
>     }
> 
> ???
> 
> Damian
> 

Shouldn't that be:

for [ <at> list, undef] ¥  <at> list[1...] -> $curr, $next {
         ...
}

As I remember it zip hrows away extras, not fills in with undef.

--

-- 
mark <at> biggar.org
mark.a.biggar <at> comcast.net
Permalink | Reply | 1 comment |
headers
Mark A. Biggar | 1 Oct 2005 05:46

Re: Look-ahead arguments in for loops

Mark A. Biggar wrote:
> Damian Conway wrote:
> 
>> Rather than addition Yet Another Feature, what's wrong with just using:
>>
>>     for  <at> list ¥  <at> list[1...] -> $curr, $next {
>>         ...
>>     }
>>
>> ???
>>
>> Damian
>>
> 
> Shouldn't that be:
> 
> for [ <at> list, undef] ¥  <at> list[1...] -> $curr, $next {
>         ...
> }
> 
> As I remember it zip hrows away extras, not fills in with undef.
> 

Drat I did that backwaeds didn't I.

try:

for  <at> list ¥ [ <at> list[1...], undef] -> $curr. $next {

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Whipp | 1 Oct 2005 05:57

Re: Look-ahead arguments in for loops

Damian Conway wrote:
> Rather than addition Yet Another Feature, what's wrong with just using:
> 
>     for  <at> list ¥  <at> list[1...] -> $curr, $next {
>         ...
>     }
> 
> ???

There's nothing particularly wrong with it -- just as ther's nothing 
particularly wrong with any number of other "we don't need this, because 
we can program it" things. Perl5 had many other these: "we don't need a 
switch statement", "we don't need function signatures", etc.

My original idea, not consuming optional bindings, is barely a new 
feature: just a clarification of the rules in a corner-case of the 
language. Others took the idea and ran with it and added the bells as 
whistles. I guess the best alternative is to say that optional bindings 
aren't allowed in this context -- that leaves the issue open for Perl 
6.1 (or a module).
Permalink | Reply | 0 comments |
headers
Austin Hastings | 1 Oct 2005 11:57
Picon
Favicon

Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail

Yuval Kogman wrote:

>On Thu, Sep 29, 2005 at 13:52:54 -0400, Austin Hastings wrote:
>  
>
[Bunches of stuff elided.]

>>A million years ago, $Larry pointed out that when we were able to use
>>'is just a' classifications on P6 concepts, it indicated that we were
>>making good forward progress. In that vein, let me propose that:
>>
>>* Exception handling, and the whole try/catch thing, IS JUST An awkward
>>implementation of (late! binding) run-time return-type MMD.
>>    
>>
>
>Exception handling is just continuation passing style with sugar.
>
>Have a look at haskell's either monad. It has two familiar keywords
>- return and fail.
>  
>
>Every statement in a monadic action in haskell is sequenced by using
>the monadic bind operator.
>
>The implementation of >>=, the monadic bind operator, on the Either
>type is one that first check to see if the left statement has
>failed. If it does, it returns it. If it doesn't it returns the
>evaluation of the right hand statement.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Austin Hastings | 1 Oct 2005 12:33
Picon
Favicon

Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail

TSa wrote:

>
> The view I believe Yuval is harboring is the one examplified
> in movies like The Matrix or The 13th Floor and that underlies
> the holodeck of the Enterprise: you can leave the intrinsic
> causality of the running program and inspect it. Usually that
> is called debugging. But this implies the programmer catches
> a breakpoint exception or some such ;)
>
> Exception handling is the programmatic automatisation of this
> process. As such it works the better the closer it is in time
> and context to the cause and the more information is preserved.
> But we all know that a usefull program is lossy in that respect.
> It re-uses finite resources during its execution. In an extreme
> setting one could run a program *backwards* if all relevant
> events were recorded!
>

The current state of the art dictates that exceptions are to be avoided
when it is possible to handle the error in-line. That "exceptions should
only be used for exceptional cases, and anything you encounter in the
manual pages is not exceptional."

I don't agree with this, because it is IMO effectively saying "We had
this powerful notion, but it turned out to be difficult to integrate
post-hoc into our stack-based languages, so we're going to avoid it.
Rather than admitting defeat, though, we're going to categorize it as
some kind of marginal entity."
(Continue reading)

Permalink | Reply | 0 comments |
headers
Austin Hastings | 1 Oct 2005 13:19
Picon
Favicon

Re: Look-ahead arguments in for loops

Damian Conway wrote:

> Rather than addition Yet Another Feature, what's wrong with just using:
>
>     for  <at> list ¥  <at> list[1...] -> $curr, $next {
>         ...
>     }
>
> ???

1. Requirement to repeat the possibly complex expression for the list.
2. Possible high cost of generating the list.
3. Possible unique nature of the list.

All of these have the same solution:

 <at> list = ...
for [undef,  <at> list[0...]] ¥  <at> list ¥ [ <at> list[1...], undef] -> $last, $curr,
$next {
  ...
}

Which is all but illegible.

=Austin
Permalink | Reply | 4 comments |
headers
Yuval Kogman | 1 Oct 2005 13:55
Gravatar

Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail

On Sat, Oct 01, 2005 at 05:57:54 -0400, Austin Hastings wrote:

> Internally, it may be the same. But with exceptions, it's implemented by
> someone other than the victim, and leveraged by all. That's the kind of
> abstraction I'm looking for. My problem with the whole notion of "Either
> errorMessage resultingValue" in Haskell is that we _could_ implement it
> in perl as "Exception|Somevalue" in millions of p6 function signatures.
> But I don't _want_ to. I want to say "MyClass" and have the IO subsystem
> throw the exception right over my head to the top-level caller.

In haskell it's the job of the Either monad to let you pretend you
aren't doing Exception|Somevalue everywhere.

You can sequence operations in a deeply nested manner, and then
'fail' at some point. Then control flow will just pop back up all
the way with the error, instead of trying to continue.

You don't really need to say 'Either ... ...', you just use do
notation.

> For appropriate definitions of both 'elegant' and 'convenient'. Java
> calls this 'checked exceptions', and promises to remind you when you
> forgot to type "throws Exception::Math::DivisionByZero" in one of a
> hundred places. I call it using a word to mean its own opposite: having
> been exposed to roles and aspects, having to code for the same things in
> many different places no longer strikes me as elegant or convenient.

I agree with that wholeheartedly, but in haskell you are making no
obligation towards the shape of an exception - it can be 'Either
thing Error' where Error is any data type you like.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Damian Conway | 1 Oct 2005 14:53

Re: Look-ahead arguments in for loops

Austin Hastings wrote:

> All of these have the same solution:
> 
>  <at> list = ...
> for [undef,  <at> list[0...]] ¥  <at> list ¥ [ <at> list[1...], undef] -> $last, $curr,
> $next {
>   ...
> }
> 
> Which is all but illegible.

Oh, no! You mean I might have to write a...subroutine!??

     sub contextual ( <at> list) {
         return [undef,  <at> list[0...]] ¥  <at> list ¥ [ <at> list[1...], undef]
     }

     for contextual( create_list_here() ) -> $last, $curr, $next {
         ...
     }

The horror!!!

;-)

Damian
Permalink | Reply | 3 comments |

Gmane