Re: matching colors (was Stringification, numification, and booleanification of pairs)
HaloO Yuval, you wrote: On Mon, Sep 26, 2005 at 21:02:06 +0200, TSa wrote: demonstrates the lack of transitivity in matching... Sorry, but don't you mean commutativity? Transitivity of relations requires applying it twice to three values and then concluding it applies to the unchecked combination as well: Yes, I tend to confuse these ;-) Don't worry, be happy. I suffer from an impotence versus idempotence confusion. But fortunately both mean 'lack of achievement'. BTW, the context cast prefix operators + ~ ? * ** of Perl6 have that property. In addition they preserve the identity and accessability of their input data. So, beware if you intend to overload them with omnipotence :) -- $TSa.greeting := HaloO; # mind the echo!
Re: This week's summary
HaloO,
The Perl 6 Summarizer wrote:
Meanwhile, in perl6-language
\(...)
Oh look, a thread in p6l that's still going more than a fortnight later.
How unusual.
Is a long running thread considered a bad thing on this list?
I have grasped so far, that spawning a new thread after
some divergence from the original topic is considered nice.
This particular instance of the form is nominally about the
behaviour of \($a, $b) but various subthreads have drifted onto
discussions of context in general and meaningful whitespace. So far
there has been no discussion of the return value of
Pin.head.contents.grep - Angel $a {$a.is_dancing} but I'm sure it's
only a matter of time.
Please tell me if the particular pinhead is me. I'm actually about to reply
to Juerds question about my ranting about code backing the interpolation
of data into strings. Or is that considered counter productive
hairsplitting?
--
$TSa.greeting := HaloO; # mind the echo!
Re: This week's summary
TSa skribis 2005-09-27 10:15 (+0200): Is a long running thread considered a bad thing on this list? Just like how a post being Warnocked can have one or more of several causes, a long running thread can. Some are bad, some are good. As a thread becomes longer and more fanned out, it becomes hard to manage, and everyone has their favourite subthreads. This results in uninformed discussion, divergence and it getting even harder to reach concencus. I have grasped so far, that spawning a new thread after some divergence from the original topic is considered nice. Whenever you want to react on several posts simultaneously, consider it as a whole, and say what you have to say about it, usually with a new proposal, I do think it is better to start an entirely new thread. It can make a subject more accessible for outsiders, who have neither the time nor the will to read the original 50-message discussion. If this is the goal, the new thread should start off with a well structured explanation, instead of just referring to previous discussion. There are many huge differences between repying and starting a new thread, but still it can be hard to decide what to do. For me, the most noticeable difference is the time spent thinking and writing: for replies it's short, for new messages, it's long. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Exceptuations
And handling user errors in a GUI application is a task for event handling, *not* exception handling. I agree that both mechanisms share large parts of the infra-structure supporting them. But I make a strong conceptual distinction between them. Which leads to the question, does Perl6 have or need a build-in event system on the language level? -- Hear, hear. Isn't just an exception a naughty event? But when you think about it, isn't all programming about suggesting events and handling what happens next? Most of what a programmer does is suggest events to do (e.g., open file) and then handle the 'events' that happen next (e.g., file not found) and then suggest some more events (e.g., die). At the moment the programmer is the top-level event handler (e.g., damn - why didn't that work?) - but maybe some of this hassle could be handed off? Is there a way to turn the exceptions type matching / depth finding problem inside out? From the point of view of the operating system a program is a nasty exception to its normal running environment - your whole program is a kind of big exception! Like someone intruding on a conversation the programmer tries to change the topic of the operating system. Hey can you get that network socket for me? Programmers are constantly trying to change the topic of conversation of the operating system. Hey drop what you're doing. This is important. Get me that file. But some of the nastiest (and exception raising) problems arise from the conversational disconnect between operating system and program (e.g., Sorry that port is blocked, Sorry can't find that file, Socket closed etc). Is there a place in the room for a third party to the conversation? Somebody who could ... Smooth over misunderstandings? Do translation if either party doesn't understand? Queue what should be the next topic of conversation? Remember how topics are meant to be handled? Provide a log of what was said? Is there a way of integrating Perl's natural ability to stay on topic ($_) with exception handling, and event handling? Just some thoughts ... NIge
Re: Exceptuations
On Tue, Sep 27, 2005 at 07:29:48 +0100, Nigel Hamilton wrote:
And handling user errors in a GUI application is a task for event handling,
*not* exception handling. I agree that both mechanisms share large parts
of the infra-structure supporting them. But I make a strong conceptual
distinction between
them.
Which leads to the question, does Perl6 have or need a build-in event
system on the language level?
The exception mechanism is an event system that is typically used
for nothing but errors, but is much more extensible than that.
In fact, exceptions are nothing more than continuations really.
The CATCH block 'temp' sets a global exception handler continuation,
and die is simply
sub die (*$a) { *EXCEPTION_HANDLER.(*$@) }
Also, it's hard for a library writer to consistently decide what is
an error and what isn't. It's also too much trouble. If every
library had severity levels, things would be complicated for small
scripts.
On the other hand, whenever an event that is not what 90% of the
flow control should be does occur, exceptions let you delegate the
behavior of how to deal with this to other code, specifically the
code that called you.
It just happens that the default *EXCEPTION_HANDLER continuation is
essentially
print STDERR @_;
exit $bad_error_code;
Hear, hear.
Isn't just an exception a naughty event? But when you think about it, isn't
all programming
about suggesting events and handling what happens next?
Well, not necessarily. It's an event that is exceptional, i.e. not
normal.
99% of non normal events are errors, but we routinely use exceptions
for timeout, etc.
{
temp $SIG{ALRM} = { die timeout; } # we need a better
mechanism for this in perl 6, IMHO
alarm 10;
connect(...);
CATCH {
when timeout {
$!.resume if prompt(The remote party does not
seem to be responding. Keep trying?);
}
default { $!.rethrow }
}
}
Timing out is not an error unless the user decides it is. Normally
the user would have to decide beforehand when lack of responsiveness
becomes an error, but with a system like this the user can be
prompted on a case by case basis to decide whether it's an error or
not.
Is there a way of integrating Perl's natural ability to stay on topic ($_)
with exception
handling, and event handling?
As I see it continuations are a way to get back on topic...
Hey, 3rd party, the underlying thingy told me that yadda
yadda... If you can fix it, here's what you do next.
This is why I proposed the idea.
I would like to expand on your ideas though - the program is layered
with a delegation hierarchy... The lowest level agent is the
operating system. On the other side, the user makes a query to the
program which makes a query to it's first level handler, that uses a
library, that uses another and so on and so forth.
In a sense, the third party you mention is always the caller of a
given block of code, with the other two parties being the called
level, and the level below it.
Intervention on behalf of the third party can be delegated upwards
if this layer does not have enough policy on event handling. The
only level which really knows how to behave under any event
(hopefully ;-) is the user.
Just some thoughts ...
Good post!
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me does a karate-chop-flip: neeyah!!
pgpFk63eGjRwQ.pgp
Description: PGP signature
Re: This week's summary
TSa [EMAIL PROTECTED] writes:
HaloO,
The Perl 6 Summarizer wrote:
Meanwhile, in perl6-language
\(...)
Oh look, a thread in p6l that's still going more than a fortnight later.
How unusual.
Is a long running thread considered a bad thing on this list?
Nah, it's just hard to summarise.
I have grasped so far, that spawning a new thread after
some divergence from the original topic is considered nice.
Definitely.
This particular instance of the form is nominally about the
behaviour of \($a, $b) but various subthreads have drifted onto
discussions of context in general and meaningful whitespace. So far
there has been no discussion of the return value of
Pin.head.contents.grep - Angel $a {$a.is_dancing} but I'm sure it's
only a matter of time.
Please tell me if the particular pinhead is me. I'm actually about to reply
to Juerds question about my ranting about code backing the interpolation
of data into strings. Or is that considered counter productive
hairsplitting?
Just a reference to the old philosophical question of how many angels can dance
on the head of a pin. That and the fact that I occasionally get curmudgeonly
and hit the send button before I have second thoughts.
The weird thing is that the syntax I rolled there is soon to be the topic of an
original thread, once I've got the thing written up a little more.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
Re: Exceptuations
Nigel Hamilton schreef: From the point of view of the operating system a program is a nasty exception to its normal running environment - your whole program is a kind of big exception! As if a real OS really likes to run idle most of the time. ;) Like someone intruding on a conversation the programmer tries to change the topic of the operating system. Hey can you get that network socket for me? Programmers are constantly trying to change the topic of conversation of the operating system. Hey drop what you're doing. This is important. Get me that file. Or the OS is more like a waiter, nervously circling the tables, watching out for orders. Is there a way of integrating Perl's natural ability to stay on topic ($_) with exception handling, and event handling? http://poe.perl.org/?POE_FAQ/Will_Perl_6_make_POE_obsolete And how about agents and messages? -- Grtz, Ruud
