Re: matching colors (was Stringification, numification, and booleanification of pairs)
On 9/25/05, Luke Palmer [EMAIL PROTECTED] wrote:
On 9/25/05, Juerd [EMAIL PROTECTED] wrote:
We can do better than equivalence testing for colors. Instead, try to
match. Surely a *smart* match operator really is smart?
$color ~~ '#FF00FF'
==
$color ~~ 'magenta'
==
$color ~~ [ 255, 0, 255 ]
Hmm. That violates my proposal that the right side is the thing that
determines how the left side is matched. So there's something wrong
with one of the two...
If we keep my proposal, then we get:
$color ~~ color('#FF00FF')
$color ~~ color('magenta')
Interesting proposal. Is there any motivation for people not to simply
flip the argument-order to take advantage of the right-wise
determinism? Or is that actually a benefit?
'#F0F' ~~ $color ?? 'yes' !! 'no';
Ashley Winters
Re: Allomopherencing
On 9/25/05, Yuval Kogman [EMAIL PROTECTED] wrote: In order to enforce that level of compile-time type safely, you should need to declare my Dog $dog, or stick a pragma up top: That's the point of my question - why? What do I lose by inferrencing? Nothing that I see. I recant my arguments when strict inferencing is in place. That's exactly how I'd want it to work when optimization and/or stricture is in place. It'd be a *very* nice compiler feature. Ashley Winters
Re: numification and stringification of objects
On 9/25/05, Juerd [EMAIL PROTECTED] wrote: Whenever possible, object should have useful numeric and string representations. These are generally lossy, but this is not a problem, because a scalar stays a scalar even after being used in a certain context, and the object isn't lost. Sounds good. Let me summarize what I've gleaned so far, in the context of what I was looking for: Presentation: $object.as(Str, ...) where ... is a format string; perhaps an sprintf format, or something else. Localization occurs here. Formatting occurs here. Timezone/newline-convention/join-character-specification/whatever happens here Representation: ~$object eq $object.as(Str) eq DWIMiest string Presentation Serialization: my Thingy $obj.=thaw($object.freeze) Interpolation: foo $object eq foo ~ ~$object This makes sense, and I can accept it. I still think the proposed Representation behavior should really be the Interpolation behavior, and Representation should be a lossless but readable version of Serialization, though I'm clearly wrong, since I can't defend it. No worries. I'll come around to see the light. Someday. :) Ashley Winters
Re: numification and stringification of objects
On Mon, Sep 26, 2005 at 02:24:33 +0200, Juerd wrote:
Whenever possible, object should have useful numeric and string
representations. These are generally lossy, but this is not a problem, because
a scalar stays a scalar even after being used in a certain context, and the
object isn't lost.
When a protocol or data format that already has a string format is represented
as an object, it should of course evaluate to its common string form when used
in string context. Good examples of this can be found in the LWP package.
Class Num Str
HTTP::Headers number of headers Foo: bar{crlf}Bar: baz{crlf}
HTTP::Status200 HTTP/1.1 200 OK
HTTP::Date universal epochtime Sun, 06 Nov 1994 08:49:37 GMT
HTML::Form number of elementsform ../form
One must be careful NOT to pick a certain numification or stringification just
because a certain number or string found in the object will be useful. For
code
to be understandable, the numification or stringification must really BE what
the object represents. Again, LWP provides good examples.
Class Num Str
HTTP::Request - GET / HTTP/1.1{crlf}...
LWP::UserAgent - -
There's no single obvious meaningful number that represents HTTP::Request, but
a careless designer could try and guess that people would be interested in the
HTTP version number, the number of headers, or the number of bytes in the
body.
It should therefor produce a warning when it's used in numeric context. What
it
returns, is mostly irrelevant but I'd go as far as returning a random number,
just to avoid that people actually do this. (This is no problem. Compare it to
Perl 5's habit of returning the memory address.) There is, however, a good
string representation of an HTTP message. Whether or not this includes the
body
is irrelevant at this point, but if it's know, it probably should. It can
hopefully do so lazily.
An UserAgent object has no single obvious meaningful number that it
represents,
and it's hard to express a machine as a string too. Still, someone who feels a
need to use every feature that Perl provides, might use the number of requests
and the last requested URL, thinking these would be very popular. In a good
design, it shouldn't be a number or a string at all, because it would lead to
non-obvious code and would require a comment or diving into documentation, and
then an explicit method name serves both ease of programming and readability
much better.
However, I do think there should be some kind of useful stringification for
ALL
objects, because objects are often printed for debugging purposes. But I
suggest that this be a global method that all objects implicitly inherit from,
and not be defined in the object itself. This helps to make all these
stringified-for-debugging strings look the same (one programmer could for
example perhaps implement a coloured scheme) and to enable us to make using
them fatal. Because every object may have its own attributes or even other
calculations that will be useful for debugging, there must be a way to specify
which ones are used. I think a simple method that returns a string is most
appropriate.
One example of what this debugging output could be is:
{ LWP::UserAgent(aen3kx) }
This relates to the Debuggable role I proposed a while back...
Basically it's an interface that should never be used within actual
code, but is used for helping debuggin. The things I consider
debugging:
Dumping to the screen
Using DDD to graph structures
Making sure tracing policies have levels, so that framework
code doesn't confuse a user who is trying to trace through their
own code.
I think that this role should define the dump operator. Perhaps
prefix or postfix ?! can work... That seems fairly obvious. For
example
warn Done fetching $url, { $ua?! };
Let's call it the wtf operator.
Now to assimilate some more of your ideas:
aen3kx being the id of the object, and {} being simple delimiters to visually
group. Another example, this time with some attributes that a certain method
in
LWP::UserAgent told Perl to use:
The debuggable role is allowed to carry an implicit state. The
interface that controls the state has to do with further reporting
info, or helping the debugger track the progress of an object.
For example:
$ua.debug_verbosity++;
$ua.debug_verbosity--;
These increase and decrease the verbosity number (which starts at a
default, specific to each class that does Debuggable) to get more
info in the ?! output.
To control different attributes is entirely specific to the class
being debugged. I suppose something along the lines of a debug mask
object, that acts like a log filter will be the de-facto standard
for any complex dump.
But,
Re: matching colors (was Stringification, numification, and booleanification of pairs)
On Sun, Sep 25, 2005 at 23:21:33 -0700, Ashley Winters wrote:
On 9/25/05, Luke Palmer [EMAIL PROTECTED] wrote:
On 9/25/05, Juerd [EMAIL PROTECTED] wrote:
We can do better than equivalence testing for colors. Instead, try to
match. Surely a *smart* match operator really is smart?
$color ~~ '#FF00FF'
==
$color ~~ 'magenta'
==
$color ~~ [ 255, 0, 255 ]
Hmm. That violates my proposal that the right side is the thing that
determines how the left side is matched. So there's something wrong
with one of the two...
If we keep my proposal, then we get:
$color ~~ color('#FF00FF')
$color ~~ color('magenta')
Interesting proposal. Is there any motivation for people not to simply
flip the argument-order to take advantage of the right-wise
determinism? Or is that actually a benefit?
I see a very good reason - the more topicalized and localized an
object the earlier in the sentance it usually goes in any natural
language that I know of.
99% of programmers that know that
if ($number == 123) {
}
is bad because a simple typo makes it into assignment, but
if (123 == $number) {
}
is safe still don't use the safer form, because it just doesn't read
or write as well.
Matching is even more verbose in that sense... If noun defining
concrete object is like shape, pattern, etc makes sense. Other
forms do not:
if greenish describes the color
vs
if the color is greenish
demonstrates the lack of transitivity in matching... Ofcourse, the
sentances say the same thing, but the first one is deceiving,
because you think that 'greenish' is the important thing, when we're
really concerned about the color. It is definately not good for
reading code you didn't write, because it's unclear in subtle ways.
I guess this is just as you guys probably have trouble reading my
subtly pigeon english - it seems normal most of the time, but
occasionally it just doesn't make sense since I'm actually
transliterating hebrew.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me wields bonsai kittens: neeyah
pgpLdaCjgkCrs.pgp
Description: PGP signature
Re: numification and stringification of objects
On Sun, Sep 25, 2005 at 23:54:56 -0700, Ashley Winters wrote:
Localization occurs here. Formatting occurs here.
Timezone/newline-convention/join-character-specification/whatever
happens here
This is going too far, IMHO.
What if your app is running in some time zone, generating reports
for an office 2 time zones away? What if you are exporting the
reports into a serialized formats, but the user needs to input the
time zone info in their -2 time zone?
What if your interface is demonstrating localization... Do you do
for language other_language - $ENV{LANG} {
display($the_object);
}
If this becomes to DWIMMY and implicit, presentation will get
unstable.
The interfaces to these concepts are too complex, and because we
can't refactor reality or culture (swatch tried it, but no one
understands .beat... Esperanto is not the de facto language, in fact
the last time I checked my internationalization system settings give
me much more than 1 choice, wrt date formatting, input mode, spell
checking, and UI display). I think that there is no way to get away
with simplifying this.
These things should be easy:
Say what you generally want for a certain section of a program
(could be the whole program)
Get that behavior implicitly in a certain section (all
interpolations are localized in this block)
Make exceptions (don't localize, except for this string)
Have fine grained control that does not break encapsulation or
interfere with other code (localization is yadda yadda, but date
formatting is ISO).
The environment variable interface that we use on UNIX nowadays is
not enough for the age of web applications, collaboration software,
and stuff like that.
The cross cutting concerns of display are so deep and spaghettied
that we simply cannot and should not support these in the language
implicitly. It's too dangerous, and will cause too many headaches.
Much like debugging is more complicated than just printing, I think
that localization is done with a role that helps the view code
display localized versions of objects instead of providing localized
strings for the view code.
What I definately won't mind is a module that exports a lexical
*prefix:~ (and thus otherwise augments interpolation) so that any
stringification in a certain block of code is localized.
Then I would have one such block per program (not module or
anything) that makes an attempt at doing this.
Serialization: my Thingy $obj.=thaw($object.freeze)
Part of the Serializable role, i guess, which can be implemented
with any serialization module that works well for $obj.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me groks YAML like the grasshopper: neeyah!!
pgptJDAv5nBQx.pgp
Description: PGP signature
Re: Stringification, numification, and booleanification of pairs
Mark A. Biggar skribis 2005-09-25 19:42 (-0700):
In a private conversation with Larry this afternoon, he said that by
default $foo and ~$foo and $foo.as(Str) all give the same result
(assuming scalar context, etc.). And that @foo[] and [EMAIL PROTECTED] and
@foo.as(Str) are the same as join(' ', @foo) where join is effectively:
This news pleases me.
Also that a pair ($x = $y) stringifies to $x\t$y and that [EMAIL
PROTECTED] for an
array of pairs is the same as join(\n, @A);
Did he happen to mention what would be done with mixed arrays? Or is
this of pairs not related to content, but to declaration, and thus of
Pair?
It is also intended that .as(Str, ...) takes extra named args (names
TDB) for things like separators and sprintf like format strings so you
can customize it, including ways to change the defaults for a class
(like the separator for arrays of pairs being \n instead of ' ').
Just the way I imagined it. Great!
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: numification and stringification of objects
On 26/09/05, Yuval Kogman [EMAIL PROTECTED] wrote:
On Sun, Sep 25, 2005 at 23:54:56 -0700, Ashley Winters wrote:
Localization occurs here. Formatting occurs here.
Timezone/newline-convention/join-character-specification/whatever
happens here
This is going too far, IMHO.
I can't speak for Ashley, but when I read that I assumed it meant things like:
$num.as(Str, :scientific);
$message.as(Str, :localeja-JP);
$date .as(Str, :calendarHebrew);
$pair .as(Str, :join );
Which you'll probably agree is a lot more sane.
What I definately won't mind is a module that exports a lexical
*prefix:~ (and thus otherwise augments interpolation) so that any
stringification in a certain block of code is localized.
{
# (The details might not be 100% accurate, but the intent should
# be clear.)
temp *prefix:~ .= assuming(:localeen-GB);
say $message; # localizes
say $message.as(Str, :locale(undef)); # default behaviour
}
Something along those lines, anyhow.
Stuart
Summary rollover date
I thought we'd switched to a Monday deadline for the summary and a Sunday night roll over. I just noticed your last summary ended on a Monday night. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/
Re: numification and stringification of objects
On 9/26/05, Yuval Kogman [EMAIL PROTECTED] wrote:
I think that this role should define the dump operator. Perhaps
prefix or postfix ?! can work... That seems fairly obvious. For
example
warn Done fetching $url, { $ua?! };
Let's call it the wtf operator.
No, please... how about just calling it the interrobang operator
http://en.wikipedia.org/wiki/Interrobang? :-D
Aankhen
Re: .chars, .bytes, etc.
HaloO, Juerd wrote: wolverian skribis 2005-09-24 13:45 (+0300): Why not define .chars like this: Context Return value itemamount of units listunits themselves I still have my objections to this outside-in flow of type information. Originally I thought that .elems and .chars were symmetric and both should behave the same semantically I still think this. They certainly LOOK symmetric. But with respect to what are .elems and .chars symmetric? Do you mean they are just two five elems err chars long names for the identical concept? Otherwise elems could be perhaps renamed 'smelems' and even my poor eyes could see the symmetry ---sorry, couldn't resist! But .elems isn't needed. At all. [EMAIL PROTECTED] already is the number of elements, list @foo already is a list of elements. So is [EMAIL PROTECTED] I can easily interpret .elems as the postfix equivalent to prefix *. Well and list as just the four character name of the concept in prefix context. Thus I see, with =::= denoting meta|semantic level identity: (* @foo) =::= (list @foo) =::= (@foo .elems) =::= (@foo .list) which leaves postfix .elems somewhat redundant. But perhaps it is just the slot accessor that happens to be implemented in the particular array class that @foo refers to. But I have proposed that this be written (@foo :elems) or (elems = @foo) or (@foo .elems). And of course there also is the total slice (@foo .[]) notation. BTW, I have use parens and whitespace here to explicitly give precedence, nothing else. Given explicit type info about elems beeing a postfix operator, even (@foo elems) is viable. The dot form is just the auto-postfixing of a prefix op to me---a postfix cast of the operator, so to say. Note that e.g. the increment operator ++ is not invariant in this transformation! And there is no guarranty that you can factor out its application as in: (++$x - $x++) =::= ( (++ - ++) $x ) =::= ( $x .(++ - ++) ) where the latter two terms are hardly valid syntax. But I wanted to be terse. But again, junctions seem to pull exactly this stunt =:) Now, if we're going to have .elems anyway, then let it be symmetric with .chars. The 'symmetric' there meaning 'semantic identity' or giving cardinality? The difference with @foo without .elems would then be non-Num item context: item @foo returns [EMAIL PROTECTED], but item @foo.elems returns [EMAIL PROTECTED] I have no problems to understand (item @foo) =::= (\ @foo) =::= (@foo .item) =::= ([EMAIL PROTECTED]) where the last term uses the itimizing circumfix [], and that (num @foo) =::= (+ @foo) =::= (elems @foo) =::= (@foo .elems) but I don't follow how you manage to mix these concepts and come up with 'non-Num item context'. Where is such a beast born syntactically, and how does it propagate? BTW, does everybody expect more than one prefix numerifyer beeing redundant or is there an idea of (+ (+ @foo)) beeing modelled after (bar (bar @foo)) where prefix bar is called twice, first with the array @foo, then with a non-negative integer value from which no way leads back to @foo? Note that I would write the redundancy as ((+ +) @foo) which means that + returns itself un-invoked or some such. Sorry, if this is too much LISPish thinking and Perl 6 is not LISP without parens and some sigils thrown in---but what then? ... Perl 6, of course. But that definition is unfortunately self referencial! Still, I'd prefer not having .elems at all, as it adds nothing but confusion, regardless of which of the two semantic sets is chosen. To me it adds flexibility or unspecificity on the semantic level, which can be construed as confusion! The only thing I dislike is that it increases the burden of someone who wants to deliver the identical meanings under all possibly choosable names. An example of what I mean can be seen in the 'generic equality' problem. -- $TSa.greeting := HaloO; # mind the echo!
Re: .chars, .bytes, etc.
Hi, please configure your e-mail client to use (greater-than, space) for quoting, if possible. It currently uses (greater-than). TSa skribis 2005-09-26 13:43 (+0200): Why not define .chars like this: Context Return value itemamount of units listunits themselves I still have my objections to this outside-in flow of type information. Can you explain please what outside-in means to you? I still think this. They certainly LOOK symmetric. But with respect to what are .elems and .chars symmetric? Do you mean they are just two five elems err chars long names for the identical concept? They are both plural, and the word used is used to describe a fundamental building piece of the greater whole: an array has elements, a string has characters. It has nothing to do with both elems and chars being 5 letters. The difference with @foo without .elems would then be non-Num item context: item @foo returns [EMAIL PROTECTED], but item @foo.elems returns [EMAIL PROTECTED] ... but I don't follow how you manage to mix these concepts and come up with 'non-Num item context'. non-Num item context is item context that isn't specifically numeric. Bare @foo in non-Num context returns a reference, @foo.elems in non-Num context returns the number of elements. In Num context, both return the number of elements. BTW, does everybody expect more than one prefix numerifyer beeing redundant or is there an idea of (+ (+ @foo)) beeing modelled It's providing context to something that was already providing context. A bit redundant indeed. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Sort of do it once feature request...
Michele Dondi [EMAIL PROTECTED] writes:
Every time I've desired a feature for Perl6 it has turned out that either it
was already planned to be there or I have been given good resons why it would
have been better not be there.
And you've done it again. What you ask for is already there. See below.
Now in Perl(5) {forum,newsgroup}s you can often see people doing stuff like
my @files=grep !/^\.{1,2}/, readdir $dir;
Letting aside the fact that in the 99% of times they're plainly reinventing
the
wheel of glob() a.k.a. File::Glob, there are indeed situations in which one
may
have stuff like
for (@foo) {
next if $_ eq 'boo';
# do something useful here
}
for @foo {
next if (($_ ne 'boo')..undef)
# do something useful
}
whereas they know in advance that Cif can succeed at most once (e.g. foo
could really be Ckeys %hash).
Or another case is this:
while () {
if (@buffer MAX) {
push @buffer, $_;
next;
}
# ...
shift @buffer;
push @buffer, $_;
}
while {
if 0..MAX { push @buffer, $_; next }
end
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
.thingies in contexts
We've had several discussions of .chars and .elems, and I said something about objects in certain contexts. In the discussion about objects, I left item and list context out, because in those contexts, always the object is just itself. One thing makes .chars and .elems look symmetric: they are both plural. We are used to having plural things, like arrays, behave such that in Num context, they evaluate to their number of things, and in list context, they evaluate to the things themselves. I'd like to have that be a global and consistent thing in Perl 6's design: whenever a method name is plural, it behaves like this, and vice versa. String context is free, but in general, the elements joined by some kind of separator is expected. Unspecified item context is expected to result in an arrayref, but it could very well be an object too. This allows HTTP::Message::headers to return an HTTP::Headers object, which of course evaluates to a number of headers in Num context. Do note that it doesn't allow HTTP::Message::headers to return an HTTP::Headers object in *list* context, because in list context, it has to return the individual elements, because the name is plural. It'll have to decide to use $headers.headers all by itself. Summarized: The expected behavior for any .thingies (method name in plural) is: Context Expectated evaluation item Something that does Array, e.g. an object or an arrayref Num Number of thingies Str Thingies all stringified, then joined list The thingies themselves In fact, the behaviors for Num and Str are implied by item returning something that does Array. Making it explicit helps to understand the structure. I believe that this kind of consistency will contribute to overall ease of programming and understanding. Perhaps there are other word forms and expected return values. I'm a bit careful with asking this question, because I expect something to be said about imperatives and boolean return values, and I like split too much although you could argue that split should be called chunks and behave as described in this message. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Sort of do it once feature request...
Piers Cawley skribis 2005-09-26 16:34 (+0100):
And you've done it again. What you ask for is already there. See below.
next if (($_ ne 'boo')..undef)
if 0..MAX { push @buffer, $_; next }
IIRC, flip flop will not return as the .. operator. Also, the global
state of syntactic flip flops makes me be afraid of using them in subs.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Sort of do it once feature request...
On Mon, Sep 26, 2005 at 05:42:31PM +0200, Juerd wrote:
: Piers Cawley skribis 2005-09-26 16:34 (+0100):
: And you've done it again. What you ask for is already there. See below.
: next if (($_ ne 'boo')..undef)
: if 0..MAX { push @buffer, $_; next }
:
: IIRC, flip flop will not return as the .. operator.
That's correct, though we haven't decided what to call the flipflop
operator. Wants to be relatively long, huffmanly speaking, so
flipflop() could work. Could maybe be infix:thru or infix:till or
some such. Could have ^ forms as well. I'm not sure about preserving
the line number hack though.
: Also, the global
: state of syntactic flip flops makes me be afraid of using them in subs.
When you say that sort of thing nowadays, think state variables. So
if truify() till falsify() {...}
macroizes to something like:
if state $s ?? $s = falsify() !! $s = truify() {...}
Actually, I think that's the old ... operator. You'd write it slightly
differently to allow it to falsify immediately.
if state $s ?? $s = falsify() !! $s = truify() !falsify() {...}
Or something like that...
But yes, even with that desugaring, it does mean you're not writing
pure code in the functional sense.
Larry
Re: Exceptuations
Luke Palmer [EMAIL PROTECTED] writes:
On 9/25/05, Yuval Kogman [EMAIL PROTECTED] wrote:
I propose a new model - each exception has a continuation that
allows it to be unfatalized.
I think we've already talked about something like this. But in the
presence of use fatal, it makes a lot more sense.
Something comes to mind:
use fatal;
sub foo() { bar() }
sub bar() { baz() }
sub baz() { quux() }
sub quux() { fail }
{
say foo();
CATCH { $!.continue(42) }
}
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call chain, do:
$!.caller(n).continue(42)
Assuming caller returns a continuation (which I still fondly hope it will). I'm
assuming you're examples aren't necessarily tail calls of course.
Where do we cut off the call chain and replace our own value? This comes up
again with open(). Let's say open is implemented with a series of five
nested calls, the innermost which knows how to fail and propagate outwards.
However, the programmer using open() has no idea of its internals, so it
ought to override the return value of open() itself, rather than its utility
functions. However, we can't go with outermost, because then you'd only be
fixing the lexical call (say foo() above). So it's somewhere in between.
Where?
Obviously the topmost function should do:
sub open(...) {
...
CATCH { $!.rethrow }
}
This assumes that 'rethrow' throws a new exception that delegates to the
original exception for lots of its behaviour. If, later, you want to explicitly
get at the exception thrown by the helper function, you could do something
like:
$!.inner
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
This week's summary
The Perl 6 Summary for the week ending 2005-09-25
Hello all. It's another Monday afternoon, which means I'm writing
another summary. There's no cricket to distract me this week, so I'm
letting iTunes Party Shuffle attempt to distract me instead.
This week in perl6-compiler
Nobody said anything on the list this week. I blame IRC.
Meanwhile, in perl6-internals
About multithreading
Leo pointed everyone at an article about about 'A Fundamental Turn
Toward Concurrency in Software'. Jonathan Worthington liked it.
http://xrl.us/hq4w
Bug Wrangling
It's possibly a failing of mine as a summary writer, but I've not been
following Parrot's RT traffic. Luckily, Joshua Hoblitt has volunteered
as a Bug Wrangler and he's hoping to increase the signal/noise ratio. To
that end, he'll be pinging people who reported bugs that are older than
3 or 4 months to find out if they're still current or can be closed. It
sounds like a mammoth task in the short term, but it also sounds like a
very useful project that'll get easier once the big house cleaning has
been done.
He hinted that this is the sort of project that *really* benefits from
having more than one volunteer doing the work.
Later in the week, he posted a bunch of IMCC TODOs.
http://xrl.us/hq4x
Tcl, exceptions in leo-ctx5
Andy Dougherty posted some more details about a bug in ParTcl when
running under Leo's branch. The bug seems to depend on whether there's a
slash in the script path passed to ParTcl. There was no response, but
hopefully work continues on fixing it.
http://xrl.us/hq4y
[RFC] Debug Segment, HLL Debug segment and Source Segment
Jonathan Worthington posted a discussion of how debugging segments could
work in Parrot in the future. He outlined a suggested unified debug
segment format that should work for both PASM/PIR and high level
language debugging requirements.
Roger Browne applauded Jonathan's efforts and made some further
suggestions.
And then the thread got Warnocked.
http://xrl.us/hq4z
Magic is useless unless verifiable
Jonathan Worthington posted a discussion about how Parrot bytecode files
should handle their magic number. At present, apparently, Parrot checks
the magic number only after it's tried to work out word size and
bytecode. Which is somewhat bass ackward. After some discussion, Chip
reckoned that the solution would be to have a magic string rather than a
magic number.
http://xrl.us/hq42
loadlib and libraries with '.' in the name
Ross McFarland found a problem with loadlib. Apparently it won't let
you load a library that has a '.' in the name. It turns out that fixing
things robustly isn't quite as straightforward as it at first appears.
Discussion ensued.
Ross posted a patch to RT.
http://xrl.us/hq43
http://xrl.us/hq44
Find copied and pasted code
That gentleman of great intelligence, sagacity, wit and annoying
capitalization; the one and only chromatic wondered what running PMD's
copy and paste detector plugin on Parrot's .c files would show. If
anyone has run it yet, they haven't reported on its findings, but it
surely won't be long now.
http://pmd.sf.net/cpd.html
http://xrl.us/hq45
Amber's Ashes Announced
Roger Browne announced the release of Amber for Parrot version 0.2.3a
(Ashes). According to the announcement, Amber's a Eiffel like scripting
language for Parrot. Joe Bob says Check it out!
http://xamber.org/index.html
http://xrl.us/hq46
Meanwhile, in perl6-language
\(...)
Oh look, a thread in p6l that's still going more than a fortnight later.
How unusual. 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.
http://xrl.us/hq47
Junctions, patterns and fmap again
Luke continued to discuss Junctions and fmap with Stuart Cook.
http://xrl.us/hq48
Conditional wrapper blocks
Yuval Kogman discussed the inelegance of code that reads like:
if $condition { pre }
unconditional midsection;
if $condition { post }
And proposed a possible syntax that could be implemented in a macro. I
confess that I would be taking this thread more seriously if, when I was
writing this summary I had been able to come up with a realistic example
of code that had this problem.
Anyhoo, it sparked a good deal of discussion.
http://xrl.us/hq49
Object Model Pictures
Stevan Little's ongoing development of the Perl 6 MetaModel continues to
yield pictures. This week he incorporated Roles into the bigger picture.
Re: .chars, .bytes, etc.
HaloO, Juerd wrote: Can you explain please what outside-in means to you? TSa wrote: BTW, does everybody expect more than one prefix numerifyer beeing redundant or is there an idea of (+ (+ @foo)) beeing modelled Juerd answered: It's providing context to something that was already providing context. A bit redundant indeed. This is exactly what I mean with outside-in. The outer + puts the inner + into numeric context and that puts the innermost array in numeric context. My view is that an array of course knows how many elements it represents. This is sort of required by the specification of 'a Perl6 Array'. The prefix + operator is one possibility to retrieve this information *out of* the array! So is .elems, .size are whatever name is choosen. Let's assume this number is 42. At what point in a syntactic sequence outward from the array does this 42 loose its relation to the array @foo? Compare that to the case where two prefix ops are wrapped around this number-of-elements retrieval operation in (op1 (op2 (+ @foo))). Or in the extreme case beeing parametric with respect to all three operations (op1 (op2 (op3 @foo))). Where is the context generated and is it propagating inwards, outwards or both? To me the bottom of the language specification is reached when you hit a sigiled term or a literal. In the above case this is @foo in (op3 @foo), which results in op3 becoming a prefix op that has to be capable of handling an array, *without* retrieving any further meta information. From there I think the type information of the as of the expression itself unknown return type must be handled by the op2 and so on until the whole expression is typed as the return type of op1. If nothing else is known, all these type checks or dispatches are deferred until the actual call and result in an exception if they don't hold. Sorry if my joke attempt of elems and chars both having a 5 chars name symmetry didn't work. What I want to say is that the other thing that the language spec has to nail down is the name under which certain, central concepts are known and how to provide them for non-standard classes, modules, types or whatever. One means of providing them is MMD. Messing with the grammar in my eyes is possible but shouldn't be the canonical, lightweight approach how you add numerification to your class. The same applies to stringification and with greater difficulty to equality. This greater difficulty for equality stems from the fact that the concept is generic with respect to *both* participants while numerification has a defined result type. Unfortunately the concepts in both cases are not so well defined either. A string could e.g. numerify to its length or by parsing its content. I mean +'12' should be twelve not two. OTOH, +'two' == 2 is not too far fetched. This obviously is prefix + for numerification. Interestingly, prefix - does *not* have this redundancy or do you expect the numerical context it imposes inwards combined with flipping the sign makes (- (- @foo)) = 0? Or is the sign flipping honoured with each step inwards but numeric context travels unhindered once it is established? -- $TSa.greeting := HaloO; # mind the echo!
Re: Sort of do it once feature request...
HaloO,
Larry Wall wrote:
... though we haven't decided what to call the flipflop operator.
Sorry, I'm totally out of scope to what 'the flipflop operator' is.
Could you be so kind to give some hints. Thanks in advance.
if state $s ?? $s = falsify() !! $s = truify() !falsify() {...}
Or something like that...
It is beautiful to see all these double-char boolean connectives at work
but again I'm hopelessly confused what you are referring to.
BTW, has dropping the '::' from the ternary alleviated its beeing a macro
and it has now a simple
infix:?? !!:(condition, true_block, false_block -- Bit) {...}
signature? The Bit there is actually oversimplified because it should be
the supertype of the two alternative blocks.
--
$TSa.greeting := HaloO; # mind the echo!
Re: Sort of do it once feature request...
TSa skribis 2005-09-26 19:39 (+0200): Sorry, I'm totally out of scope to what 'the flipflop operator' is. Could you be so kind to give some hints. Thanks in advance. http://perldoc.perl.org/perlop.html#Range-Operators Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Exceptuations
HaloO, Piers Cawley wrote: Exactly which exception is continued? The bottommost one. If you want to return to somewhere up its call chain, do: $!.caller(n).continue(42) Whow, how does a higher level exception catcher *in general* know what type it should return and how to construct it. The inocent foo() caller shouldn't bother about a quux() somewhere down the line of command. Much less of it innards. Think of receiving a 'shelf picker died of lung cancer' exception when you just ordered a book from your favorite book dealer. Irrespective of the seriousness to the shelf picker, but how would you expect a customer to handle such an exception? To me exceptions are to be handled with respect to the service the scope invoked. In my example I would conclude that the book dealer has more than one shelf picker under contract and just re-issue the order. Well, or buy it elsewhere. In other words if the task at hand is buying a certain book, exception handling means iterating all viable sources with the assumption that the most convenient one *usually* delivers. Otherwise I would code an iteration over the sources right away. 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? -- $TSa.greeting := HaloO; # mind the echo!
Re: Sort of do it once feature request...
HaloO, Juerd wrote: TSa skribis 2005-09-26 19:39 (+0200): Sorry, I'm totally out of scope to what 'the flipflop operator' is. Could you be so kind to give some hints. Thanks in advance. http://perldoc.perl.org/perlop.html#Range-Operators Thanks. I'm glad that 1..Inf these days is just a lazy closure or some such. Does someone consider this 'inner boolean state' and the 'magical auto-increment algorithm if the operands are strings' of the Perl5 range op a feature worth preserving? -- $TSa.greeting := HaloO; # mind the echo!
Re: Sort of do it once feature request...
TSa skribis 2005-09-26 20:32 (+0200): Does someone consider this 'inner boolean state' and the 'magical auto-increment algorithm if the operands are strings' of the Perl5 range op a feature worth preserving? Yes, many someones do. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: matching colors (was Stringification, numification, and booleanification of pairs)
HaloO, Yuval Kogman wrote: if greenish describes the color Indeed, it sounds like Yoda Speak: If greenish that color is, modifying it I will. Same in the German version. I don't know of hebrew though. 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: a ~~ b b ~~ c = a ~~ c -- $TSa.greeting := HaloO; # mind the echo!
[regex] \
Think about adding \ to the replacement part of a s///. As in sed, the means the whole match. Then one can do s/$search/*\*/go in stead of s/($search)/*\1*/go and there needs to be no $1 variable set up. (I assume that using () always makes a $1 available, even if it is not being used.) -- Grtz, Ruud
Re: [regex] \
Ruud H.G. van Tol skribis 2005-09-26 21:27 (+0200): Think about adding \ to the replacement part of a s///. As in sed, the means the whole match. Do you know Perl 5's $ variable? What you want isn't exactly new for Perl. In Perl 6, the match object $/ will instead be used. It's a bit harder to use with s///, because it will look ugly, but remember that you can always choose to use s^^^ or s[][] or any other of the many possibilities instead. s/($search)/*\1*/go \1 in Perl 5 is bad style and emits a warning, if you were clever enough to enable warnings. \1 in Perl 6 strings will no longer have anything to do with regex matches. and there needs to be no $1 variable set up. Perl 6 will count from 0, so it'll be $0. (I assume that using () always makes a $1 available, even if it is not being used.) Perl 5's $ is inefficient because of this. If the variable is used anywhere, Perl will for every regex used capture everything. An implicit match string is far less efficient than an explicit one, in terms of Perl 5. Perl 6, however, will handle things smarter and not copy the substring until it needs to be. That's why the equivalent of $ will be usable without any frowning. Grtz, Ruud K vnd grtz n btj mljk t lzn, n d z mt ntrljk n s zjn. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [regex] \
On Sep 26, 2005, at 4:19 PM, Juerd wrote: Perl 5's $ is inefficient because of this. If the variable is used anywhere, Perl will for every regex used capture everything. My understanding is that this died with 5.10. Is that right? --Dks
Re: [regex] \
On Mon, Sep 26, 2005 at 05:00:00PM -0400, David Storrs wrote: On Sep 26, 2005, at 4:19 PM, Juerd wrote: Perl 5's $ is inefficient because of this. If the variable is used anywhere, Perl will for every regex used capture everything. My understanding is that this died with 5.10. Is that right? $ is dynamically scoped (rather than lexically scoped). I don't believe that it's possible to avoid capturing it anywhere, without affecting correctness somehow. There is already an optimisation to avoid capturing it if $ is never seen, but even that is actually buggy: $ perl -lwe '$_ = trouble; /o/; print eval q.$.' Use of uninitialized value in print at -e line 1. compare with $ perl -lwe '$; $_ = trouble; /o/; print eval q.$.' Useless use of a variable in void context at -e line 1. o where by mentioning $ I set the seen $ somewhere flag, so $ is captured, and it's there when the '' eval gets compiled at run time. IIRC the perl 6 equivalents of $` $ and $' are all lexical rather than dynamic, so the pain will be far less. (at least in its scope) Nicholas Clark
Re: Exceptuations
TSa [EMAIL PROTECTED] writes:
HaloO,
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call chain, do:
$!.caller(n).continue(42)
Whow, how does a higher level exception catcher *in general* know
what type it should return and how to construct it.
It asks the continuation? The information should be there. Consider a function
definition:
sub whatever(...) returns List {
throw ResumableException;
}
Then, assuming that caller returns continuation -- which is a pretty big
assumption, but which would be really cool -- $!.caller(1) would be a
continuation with an signature of (List $not_a_real_name). If the function can
return several types dependent on context, then the continuation's signature
would be the appropriate one for the context in which the function was
called. Monkeying with this kind of thing in code isn't necessarily a good
idea, but it's great for, for instance, having a top level exception catcher
that could (potentially) bring up an interactive shell with limited debugging
features which would allow you to inspect the running program and work out what
went wrong. Ruby on Rails already does something like this, with the added
wrinkle that, if it hits a breakpoint when running in the server it hands off
the interactive session to a console process rather than having you monkey with
it within your browser. A very neat trick and a remarkably powerful debugging
technique.
The inocent foo() caller shouldn't bother about a quux() somewhere down the
line of command. Much less of it innards.
Think of receiving a 'shelf picker died of lung cancer' exception when you
just ordered a book from your favorite book dealer. Irrespective of the
seriousness to the shelf picker, but how would you expect a customer to
handle such an exception?
I wouldn't, but I would expect that a programmer would find such an exception
very useful indeed.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
Re: Exceptuations
On Mon, Sep 26, 2005 at 17:40:52 +0100, Piers Cawley wrote:
Luke Palmer [EMAIL PROTECTED] writes:
On 9/25/05, Yuval Kogman [EMAIL PROTECTED] wrote:
I propose a new model - each exception has a continuation that
allows it to be unfatalized.
I think we've already talked about something like this. But in the
presence of use fatal, it makes a lot more sense.
Something comes to mind:
use fatal;
sub foo() { bar() }
sub bar() { baz() }
sub baz() { quux() }
sub quux() { fail }
{
say foo();
CATCH { $!.continue(42) }
}
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call chain, do:
$!.caller(n).continue(42)
This breaks encapsulation, like luqui mentioned.
However, since every exception has an exception stack, i guess you
could see exactly how it was propagated non-fatally, before it was
actually thrown.
sub open(...) {
...
CATCH { $!.rethrow }
}
...
$!.inner
That way behavior like that could be automated
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me sushi-spin-kicks : neeyah
pgpz89jwQwGFi.pgp
Description: PGP signature
Re: matching colors (was Stringification, numification, and booleanification of pairs)
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 ;-) -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me whallops greyface with a fnord: neeyah!!! pgpRqxoEoLhIe.pgp Description: PGP signature
Re: This week's summary
On Mon, Sep 26, 2005 at 18:12:23 +0100, The Perl 6 Summarizer wrote: Allomopherencing Not satisfied with inventing Exceptuations, Yuval invented Allomopherencing as well. Just don't ask me what it means because I don't know. It was just a bad joke on Exceptuation's expense ;-) The thread asks whether disabling strong and compile-time-angry type ineferencing should ever be disabled, since we have much better allomorphism-oriented support for typing and introspection. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!! pgpfR0MdzmzgI.pgp Description: PGP signature
Re: Allomopherencing
On Sun, Sep 25, 2005 at 08:29:07PM +0300, Yuval Kogman wrote: : Is there any situation where a compile time error is not a good : thing to have? Sure, when it slows down your compiler so much that it's useless for running code that doesn't have the error, especially if it's a rare error that is likely to be caught some other way anyway. Where to balance this should be the decision of the user, particularly since the balance point changes over time and space. It's also potentially counterproductive if the information available at compile time leads to confusingly abstract error messages when run-time information might produced clearer concrete error messages. When I use the term confusing, I do so in the Pooh sense. I'm trying to think of what will be confusing to ordinary folks, not to geniuses like you. I'd love to be proven wrong, but I strongly suspect that most type-inferencing error messages will be complete gibberish to commonfolk. Larry
Re: Allomopherencing
On Mon, Sep 26, 2005 at 17:36:04 -0700, Larry Wall wrote: Sure, when it slows down your compiler so much that it's useless for running code that doesn't have the error, especially if it's a rare error that is likely to be caught some other way anyway. Where to balance this should be the decision of the user, particularly since the balance point changes over time and space. Good point... Is there half-way solution, btw? Perhaps type inferrencing annotation rich areas is a good idea to help a user who is trying to debug by adding more of these. It's also potentially counterproductive if the information available at compile time leads to confusingly abstract error messages when run-time information might produced clearer concrete error messages. When I use the term confusing, I do so in the Pooh sense. I'm trying to think of what will be confusing to ordinary folks, not to geniuses like you. *blush*. For the record it takes me roughly 1 irc client or around 10 careful, concentrated rereadings to understand what GHC tells me in these situations, but for the record. A useful reference is the Error Messages section on this page: http://www.haskell.org/ghc/survey2005-summary.html It mentions both that there are active areas of research on how to make these better, and that GHC messages both suck and don't suck at the same time. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me dodges cabbages like macalypse log N: neeyah! pgpb2QyvQWJkC.pgp Description: PGP signature
