Re: specifying the key Type for a Hash
On Sat, 04 Dec 2004 08:01:46 -0700, [EMAIL PROTECTED] (David Green) wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Larry Wall) wrote: S9 talk about it. We current have things like: my Cat %pet is shape(Str); and parameters to types are in square brackets, so it's more like: my %pet is Hash[:shape(Str) :returns(Cat)]; I still prefer shaped, for pronounceability. Although shape is a bit of a stretch for something that's really more like size, and even stretchier for describing hash keys. I'm not sure what better word we could use, though. is built # a constructive choice is determined # good for typing practice =P is bound # what if you're bound AND determined? is disposed# sounds like a destructor is composed# I kinda like this one is arrayed # oh, array in that other sense is reckoned# bet no other language has that as a keyword is cinched # it sounds so easy is confined# to quarters is walled # now we're just being silly (no offense to Larry) is earmarked # some people wouldn't hear of it is indexed # a bit better than is keyed (especially if it's your car) is sized # I think this was already rejected is like# works really well if your type happens to be 'Totally' is thus# very vague, but short Hm. On the other hand, imagining Type-shaped holes into which your hash keys fit *does* have a rather picturesque appeal... -David the thesaurus is your friend (sometimes) Green I probably missed teh comprehensive dismissal thread, but why not 'type'? my %pet is Hash[:type(Str) :returns(Cat)]; njs
Re: [perl #27304] [PATCH] move libnci.def out of root directory
Will Coleda via RT wrote: Can we get a ruling on this? I tend to agree with the statement Random build files do not belong in the root directory. The patch has been un-ACK'd for nine months at the moment. While we are at it, shouldn't we rename 'libnci.so' and 'libnci.def' to 'libnci_test.so' and 'libnci_test.def'. The library isn't used for NCI support, but for testing NCI support. CU, Bernhard Steps: (1) move ./libnci.def to ./src/libnci.def (2) apply patch Patch updates ./config/gen/makefiles/root.in and ./MANIFEST with the new location. Why? Random build files do not belong in the root directory. -- ** Dipl.-Physiker Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
C implementation of Test::Harness' TAP protocol
Having done the initial work to get most of FreeBSD's regression testing
infrastructure producing Test::Harness TAP compatible output, I've started
putting together a C library that makes it easier to write tests in C.
This is a few hours work at the moment, but it's functional, and I'd
appreciate comments. The code's at:
http://jc.ngo.org.uk/trac-bin/trac.cgi/browser/nik/libtap/trunk/src/
I realise that's not the easiest way to download it, I'll make a tarball
available soon. On the plus side, it's only a handful of files...
There are still a few things to do before it's a 1.0 candidate, listed at
http://jc.ngo.org.uk/trac-bin/trac.cgi/report/9
Here's the README:
Usage:
#include tap.h, and link against libtap.so
Start by calling one of the plan_* functions:
plan_no_plan() /* you have no test plan, or */
plan_skip_all(Because...) /* all tests will be skipped, or */
plan_tests(42); /* you will run 42 tests */
Then you have one of ok() or ok2() at your disposal. ok()'s first parameter
is the code to test. The second parameter is the test name. This is a
printf()like format string, and the third and subsequent parameters should
fill out any values in the string.
ok(a_func() == 0, test name);
ok(some_func(i), some_func(%d), i);
ok2() is for situations where the code to test is sufficiently
self-documenting that you don't need to provide a test name.
ok2(code to test); /* test name is automatically the same as the code */
E.g.,
ok(1 == 1, 1 equals one); /* PRINT: ok 1 - 1 equals 1 */
ok2(1 == 2);/* PRINT: not ok 2 - 1 == 2 */
Sets of tests can be skipped. Ordinarily you would do this because
the test can't be run in this particular testing environment.
For example, suppose some tests should be run as root. If the test is
not being run as root then the tests should be skipped. In this
implementation, skipped tests are flagged as being ok, with a special
message indicating that they were skipped.
skip(n, msg, ...);
will produce output for 'n' lines of skipped tests. The output message
is 'msg', and is printf()like. It is your responsibility to ensure that
'n' is correct for the number of tests to skip.
This is normally implemented with a do { ... } while(0); loop, with a
continue; immediately after the skip() call. This ensures that there
are no additional side effects from the skipped tests.
do {
if(getuid() != 0) {
skip(1, Test only makes sense as root);
continue;
}
ok(do_something_as_root() == 0, do_something_as_root() worked);
} while(0);
Two macros, SKIP_START and SKIP_END can handle some of this for you. The
above example could be re-written:
SKIP_START(getuid() != 0, 1, Test only makes sense as root);
ok(do_something_as_root() == 0, do_something_as_root() worked);
SKIP_END;
You also have diag(), which takes a printf() style format string and related
arguments, and sends the output to stderr as a test comment. diag() adds
the necessary trailing \n for you.
diag(Expected return code 0, got return code %d, rcode);
Finally, there's exit_status(), which returns an int suitable for use
when return'ing from main(), or calling exit(). You should always do one
of:
return exit_status();
exit(exit_status());
As appropriate.
--
11 2 3 4 5 6 77
0 0 0 0 0 0 05
-- The 75 column-ometer
Not speaking on behalf of my employer. /bush
Re: specifying the key Type for a Hash
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
Maybe type parameters are just subscripts? [...]
my Fight %fight does key{Dog;Cat};
I like that.
But if English-like is the criterion that'd still read better as
my Fight %fight has key{Dog;Cat};
I like that even better.
Maybe has and does are just synonyms, and you can use
whatever makes more grammatical sense. But pretty much every time
I've introduced synonyms into Perl I've come to regret it. But hey,
if I introduce *different* synonyms this time, does that count as
making a new mistake?
=) Isn't synonym just Greek for TMTOWTDI?
To me, role-has seems different enough from attribute-has that
the context would make it pretty clear which was meant. (But maybe
I'm just missing something subtle. Or else something blatant.)
The problem with a thesaurus is that it only gives you synonyms, not the
word you really want. :-)
Heh. Sometimes I know the word I want, I just don't know I know it
until the thesaurus reminds me. And the rest of the time I just like
looking through all the words. As often as not, something on the
opposite page catches my eye and I end up forgetting what I was
looking for in the first place.
Well, there's always domain and range, if we want to be mathematical.
I'm happy with those too (perhaps because I do want to be a bit
mathematical).
Or we we wanted to be NASAesque, they'd be FATs, for Formal Argument Types.
is FAT? Yeah, that works for me too. =)
Well, I just put is shape because that's what the PDLers settled on,
but as far as I'm concerned linguistically, it could just be is dim.
That would settle the make-it-like-English question by making it
not at all like English.
On the aesthetic hand, shape is a much prettier word than dim.
I would take that as an abbreviation and read it as is dimensioned,
which is English-like enough for me. It's also short. And I don't
mind calling it dim, because if it were so smart, I wouldn't have to
tell it what to do in the first place. But shape *is* prettier.
-David pondering the shape of things to come Green
Re: Premature pessimization
Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. Except what you're talking about here is premature *optimzation*. No. I don't think so. During design considerations we (including me of course too) tend to discard or pessimize ideas early, because they look inefficient And I've summarized a bunch of examples. Maybe it wasn't too clear, but the conclusion is of course: spilling, lexical refetching, using method calls, ... (expensive looking operations) should not be discarded early. They can be optimized *later*. ... Inline caching is just another optimization. We need to be feature complete. That's exactly what I've written. I've described this idea as a possible later optimization. And if you really feel like you need to optimize something, look into the lexicals-as-registers idea you had to fix continuation semantics. Then you can work under the guise of fixing something broken. Yeah. Have a look at chromatic's 4 c-words: compiles - correct - complete - competitive compiles isn't really given, when there are compilers that either can't compile an -O3 build of the switched core or take ages to complete (if memory usage even permits that) choking the CG* cores. correct. I've discovered and analysed the problem with continuations. I've made a proposal to fix that. No one has said that it's technically wrong or couldn't work. It seems you are liking the idea, but Dan doesn't. Now what? complete - read e.g. my recent postings WRT MMD (and perl.cvs.parrot:) competitive well, I like a speedy Parrot, that's obvious. It's a nice to have. But not only. Folks on conferences get interested in Parrot because it can proof that programs will run faster. Luke leo
Re: continuation enhanced arcs
Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Matt Fowles [EMAIL PROTECTED] wrote: Thanks for the clear explanation. I did not realize that S registers could switch pointers, that does make things a little harder. I have a recommendation for a possible hybrid solution. Incur the cost of spilling I,S,N registers heavily. Restore the state of P register. My conclusion was that with the copying approach I,S,N registers are unusable. But you only need to copy when the frame you're restoring is a full continuation Yes. With the effect that semantics of I,S,N (i.e. value registers) suddenly changes. I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it. *If* the programmer is aware of the fact that a subroutine can return multiple times, he can annotate the source so that a correct CFG is created that prevents register reusing alltogether. The problem is gone in the first place. *If* that's not true, you'd get the effect that suddenly I,S,N registers restore to some older values which makes this registers de facto unusable. leo
Re: iteration (was Re: Angle quotes and pointy brackets)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Matt Diephouse) wrote: On Sat, 04 Dec 2004 08:59:24 -0700, David Green [EMAIL PROTECTED] wrote: Cdoes Iterate signifies a role named Iterate. Roles are sort of a mix of interfaces and mixins (as I understand it -- I'm still waiting for E12). So saying a class fulfills a role just means that it provides certain methods. In this case, I was saying class with the Iterate role would provide a C.next method. I thought of that at first, but I don't want to have to call my iterating method next any more than I want to *have* to call my constructor new. But there is a difference in that new is called by some user who is supposed to have read the documentation, whereas next needs to get implicitly called by for. So maybe it really should be a Role. (One can always provide methods with better names that simply call the real .next, .prev, .final, etc. for increased user-friendliness.) eof := final;# is that how to create an alias for a sub/method? We've got while for looping, .next for iterating, and for for doing both in one convenient little shortcut. But for needs to know if it has an iterator or a list. You don't want it iterating over things you didn't want it iterating. In this case, I was suggesting making an, though I suppose something like C$sth.execute could just return one. Well, I was looking at lists as being kinds of iterators. If you want to for over an iterator without actually iterating it, I guess you'd have to make a reference to it or put it inside a list (so the list would be iterated instead). - David iterate: to go around and around, like my head Green
Re: specifying the key Type for a Hash
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Smylers) wrote: No! Avoid synonyms. They're initially tempting, because then everybody gets to pick the one he/she wants to use, but then it turns out you need to learn all of them so as to read other people's code, and that's worse than not having them at all. In one way I agree, but I think there's a better (right!) way to use synonyms. In natural language, you don't use a synonym to avoid learning some other word; you learn both and choose whichever one has the more appropriate connotations, the more suitable flavour under the given circumstances. (Computers care only about denotations, so typical computer languages don't bother with synonyms, but that's one of the reasons why Perl has a better flavour than your typical language.) Perl already has lots of synonyms, really: zip and ¥, or and ||, unless and if not. Nobody learns = *instead* of -- you expect everyone to be familiar with both, and use whichever one reads better in its particular context. So some synonyms (perhaps like has for is) I'm all for: people would use both on a regular basis and I don't see any problem with that. On the other hand, I do think your point applies to things like, say, suggesting put as a synonym for unshift. The only reason to do that is not to have to use unshift at all, but you have to know it anyway because if it's available, you're going to run into it sooner or later. - David a rose by any other name would parse as sweet Green
Re: [perl #27304] [PATCH] move libnci.def out of root directory
Will Coleda via RT [EMAIL PROTECTED] wrote: Can we get a ruling on this? I tend to agree with the statement Random build files do not belong in the root directory. There's a stricter rule too (IIRC proposed by Nick or Jarkko). No build files in the Parrot tree, because this prevents a shared (possibly r/o) source tree. Configure.pl --build-dir=xxx with a reasonable default inside the tree would be better. leo
Re: pull put (Was: Angle quotes and pointy brackets)
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Luke Palmer) wrote: But what we'd really like to do is: given the user knows what push/pop do, what would they *guess* to mean shift (I tend to think that this is a very good technique for naming). And, well, I'm thinking pull. So it's a toss-up between shift/unshift and put/pull. I think push and pull fairly naturally could be taken to refer to the front of an array; you might even argue that the natural direction for something to pop is away from you (i.e. off the back) The problem I have with push/pull referring to opposite ends is that the same person is doing the pushing and the pulling, so both words ought to apply to the same end of the array (the front end), which violates the comp-sci-y expectations. (And although normally I'm happy to chuck CS jargon out the window, because so much of it is really bad, the push/pop thing goes pretty deep.) Not to mention everyone coming from Perl 6. Though if we had push without pop, that wouldn't be as bad. I guess we could always use prepend/append, pull/pop. You might not guess what they meant, but once you know, I think the meanings are reasonably obvious. (Dislike typing though I may, I'm hesitant to suggest prep and app.) Hm, actually counting letters, prepend is no longer than unshift (and if not a real word, is at least used as one more often than unshift is). In fact, prepend/append/pull/pop altogether are only one letter more than push/pop/shift/unshift. So those are now officially my preferred replacements. But if we want something that makes it immediately obvious what end of the array we're messing with.. something visually obvious... ooh, this sounds like a job for Unicode!! (Just kidding. Sort of.) We've already got those lovely pipe operators to build on, and they can already do assignment; if you can go from = to +=, why not from == to +==? @a == $foo, $bar; # @a=($foo, $bar) $foo, $bar == @a; # ditto @a +== $foo, $bar; # push @a, $foo, $bar $foo, $bar ==+ @a; # unshift @a, $foo, $bar @a -== $foo, $bar; # ($bar, $foo) = (pop @a, pop @a) $foo, $bar ==- @a; # ($foo, $bar) = (shift @a, shift @a) The + or - tells you whether you're adding on or taking away, and the arrow points to (or from) the end of the array you're doing it to. (I know some people will hate four symbols in a row. That's why we have seven-letter alternatives like prepend.) I was going to say an advantage over old-fashioned pop/shift is that you could remove more than one element at a time, but there isn't any reason for their P6 versions not to return as many items as are want()ed, is there? The bad news (assuming anyone actually thinks there's anything good in the above suggestion) is that since +== and friends are assignment operators, you can't just do foobar( @a-==, $x, $y). Um, unless -== could be made to work as a unary operator. Which even I don't think I like. =) So we should keep the wordy versions too. -David pull goes the weasel Green
Re: specifying the key Type for a Hash
David Green writes:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Larry Wall) wrote:
Maybe type parameters are just subscripts? [...]
my Fight %fight does key{Dog;Cat};
I like that.
Yeah, me too. Except I'm having trouble seeing how key is a role. It's
not adding anything into a hash; it's changing it. Maybe I just don't
quite grok roles yet.
But if English-like is the criterion that'd still read better as
my Fight %fight has key{Dog;Cat};
I like that even better.
Maybe has and does are just synonyms, and you can use
whatever makes more grammatical sense. But pretty much every time
I've introduced synonyms into Perl I've come to regret it. But hey,
if I introduce *different* synonyms this time, does that count as
making a new mistake?
Yeah, that's true. But, on the other hand, has seems to have quite a
lot to do with roles:
class Foo {
has $.bar; # compose in a .bar() method
}
Then you can think of a class as an elementary decomposition of roles.
That's algebralicious. (And its one of those things I can imagine not
seeing the potential in until someone does something Profound with it).
Well, there's always domain and range, if we want to be
mathematical.
I'm happy with those too (perhaps because I do want to be a bit
mathematical).
Remember what happened last time you gave something a mathematical name
that was wrong? Yeah, vector ops. And then everyone (read: me) carped
about them not being vector anything.
What you want here is domain and codomain. Which leads me to
believe that you don't want either.
Luke
Re: pull put (Was: Angle quotes and pointy brackets)
David Green writes: I guess we could always use prepend/append, pull/pop. No! Cpush and Cpop are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Smylers
Re: Premature pessimization
Leopold Toetsch wrote: correct. I've discovered and analysed the problem with continuations. I've made a proposal to fix that. No one has said that it's technically wrong or couldn't work. It seems you are liking the idea, but Dan doesn't. Now what? I would suggest focusing on one issue at a time and starting with writing a test case. But, overall, it is clear that you are frustrated. It show when you give responses like Doesn't really matter when people like me ask questions about your proposals. That, in turn, makes people like me frustrated. Re: classoffset... I don't currently use this opcode, nor do I plan to. This opcode has a builtin assumption that attributes are stored as attributes. They may in fact be methods or properties in the Parrot sense, or Property's in the Python sense. Re: VTABLES... I disagree with you on this one. Prematurely mapping an operation to a string is a premature pessimization. Add to that the fact that such names can conflict with usages by languages of this runtime. Overall, the design of the opcodes and PMC layout should focus on trying to retain as much information as possible. Re: continuations... frankly, I'm hoping that a solution emerges that doesn't involve significant reduction in functionallity. I might be misunderstanding you, but it sounds to me like you are proposing ditching lexical pads. - Sam Ruby
Re: Premature pessimization
Ashley Winters wrote: On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: This term came up in a recent discussion[1]. But I'd like to give this term a second meaning. Except what you're talking about here is premature *optimzation*. You're expecting certain forms of the opcodes to be slow (that's the pessimization part), but then you're acutally using opcodes that you think can be made faster. This is a classic Knuth example. So the sequence of using classoffset/getattribute is a _feature_ necessary for completeness, rather than a pessimization to compensate for the belief that not explicitly caching would be hopelessly slow? Ahh. I'm learning much. :) citing Luke Palmer On a semi-related note, can I get a classoffset without doing a hash lookup? That is, can I store the class number I get assigned somewhere for quick fetching? *SCNR* - leo
Re: [perl #27304] [PATCH] move libnci.def out of root directory
Bernhard Schmalhofer [EMAIL PROTECTED] wrote: Will Coleda via RT wrote: Can we get a ruling on this? I tend to agree with the statement Random build files do not belong in the root directory. The patch has been un-ACK'd for nine months at the moment. While we are at it, shouldn't we rename 'libnci.so' and 'libnci.def' to 'libnci_test.so' and 'libnci_test.def'. The library isn't used for NCI support, but for testing NCI support. Yep. CU, Bernhard leo
Re: Premature pessimization
Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: correct. I've discovered and analysed the problem with continuations. I've made a proposal to fix that. No one has said that it's technically wrong or couldn't work. It seems you are liking the idea, but Dan doesn't. Now what? I would suggest focusing on one issue at a time and starting with writing a test case. But, overall, it is clear that you are frustrated. ... a bit by the lack of progress that can be achieved to e.g. fix broken continuation behavior. But not much ;) ... It show when you give responses like Doesn't really matter when people like me ask questions about your proposals. That, in turn, makes people like me frustrated. Well, you worried about different classes having identical method names, but the methods do different things. I asked why this is a problem. I gave an example. Here is one more: obj.__set_integer_native(10) does 2 totally different things for arrays (set array size) or for scalars (assign value 10). Re: VTABLES... I disagree with you on this one. Prematurely mapping an operation to a string is a premature pessimization. Except that we are doing that already. Please read through classes/delegate.c. The problem is that this scheme doesn't work for MMD of real objects. ... Add to that the fact that such names can conflict with usages by languages of this runtime. Parrots method names (two leading underscores + vtable name) are reserved. And again, when two distinct clases use the same method name this is no conflict at all. Issues with classes in an inheritance chain are easily avoided by following that convention. ... Overall, the design of the opcodes and PMC layout should focus on trying to retain as much information as possible. Nothing get lost. Visible opcodes don't change. An example .sub m $P0 = newclass Foo $I0 = find_type Foo .local pmc obj obj = new $I0 obj = 5 .end running that snippet gives: Can't find method '__set_integer_native' for object 'Foo'. The vtable method set_integer_native clearly maps to a real method that can be either inherited or be provided by the user. This doesn't work for MMD functions. Re: continuations... frankly, I'm hoping that a solution emerges that doesn't involve significant reduction in functionallity. I might be misunderstanding you, but it sounds to me like you are proposing ditching lexical pads. No. I'm not ditching lexical pads at all. They are of course needed. The top pad is in the registers. Outer pads are looked up as usual. - Sam Ruby leo
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Larry Wall wrote:
But here's the kicker. The null filename can again represent the
standard filter input, so we end up with Perl 5's
while () {...}
turning into
for = {...}
Two more issues: idiom, and topification
= Topification:
There are cases in P5 when I *don't* want
while () {...}
but prefer
while ($input = ) {...}
so that I can have something else be the topic. Every example to date
has used Cfor:
for .lines {...}
but that sets the topic. I'm a little fuzzy on this, but doesn't Cfor
play topic games even in this?
for .lines - $input { ... $input ... }
That is, even though $_ remains unaffected, doesn't this affect
smartmatch etc.?
= Idiom:
The other concern is idiom. Using Cfor suggests start at the
beginning, continue to the end. OTOH, using Cwhile is a little
weaker -- keep doing this until it's time to stop. Obviously they'll
usually be used in the same way:
for = {...} vs. while () {...}
This seems a subtle concern, and maybe it's just my latent fear of
change making me uncomfortable, but I actually *think* in english -- not
that it does much good -- and this isn't how I think.
Can we ditch Cfor in the examples in favor of Cwhile, for a while? :)
=Austin
Re: pull put (Was: Angle quotes and pointy brackets)
Smylers wrote: Larry Wall writes: But then are we willing to rename shift/unshift to pull/put? Yes. Cunshift is a terrible name; when teaching Perl I feel embarrassed on introducing it. No! But I'd be willing to rename them to get/put. 'Pull' is the opposite of 'push', but 'pop' already works. Given the nature of many of the other changes in Perl 6, completely changing regexps for example, renaming a couple of functions seems minor. Agreed. Smylers =Austin
Re: Premature pessimization
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
correct. I've discovered and analysed the problem with continuations.
I've made a proposal to fix that. No one has said that it's technically
wrong or couldn't work. It seems you are liking the idea, but Dan
doesn't. Now what?
I would suggest focusing on one issue at a time and starting with
writing a test case.
But, overall, it is clear that you are frustrated.
... a bit by the lack of progress that can be achieved to e.g. fix
broken continuation behavior. But not much ;)
My philosophy is simple: things without test cases tend not not get
fixed, and when fixed, tend not to stay fixed.
... It show when you
give responses like Doesn't really matter when people like me ask
questions about your proposals. That, in turn, makes people like me
frustrated.
Well, you worried about different classes having identical method names,
but the methods do different things. I asked why this is a problem. I
gave an example. Here is one more:
obj.__set_integer_native(10)
does 2 totally different things for arrays (set array size) or for
scalars (assign value 10).
I am worried about Parrot trying to establish common public names for
common functions. Many of the examples you gave did not include the
prerequisite double underscores. For example: sub, imag, eof.
These names are not likely to have a commmon behavior across all languages.
Re: VTABLES... I disagree with you on this one. Prematurely mapping an
operation to a string is a premature pessimization.
Except that we are doing that already. Please read through
classes/delegate.c. The problem is that this scheme doesn't work for
MMD of real objects.
I don't know enough to have an informed opinion yet on MMD. But
__set_integer_native is not a MMD operation. It already is efficiently
dispatched to the correct method. What do we benefit from the premature
pessimisation of mapping this to a string?
... Add to that the
fact that such names can conflict with usages by languages of this
runtime.
Parrots method names (two leading underscores + vtable name) are
reserved. And again, when two distinct clases use the same method name
this is no conflict at all. Issues with classes in an inheritance chain
are easily avoided by following that convention.
Again, my point is that the examples need to follow that convention.
Without exception.
... Overall, the design of the opcodes and PMC layout should focus
on trying to retain as much information as possible.
Nothing get lost. Visible opcodes don't change. An example
.sub m
$P0 = newclass Foo
$I0 = find_type Foo
.local pmc obj
obj = new $I0
obj = 5
.end
running that snippet gives:
Can't find method '__set_integer_native' for object 'Foo'.
The vtable method set_integer_native clearly maps to a real method that
can be either inherited or be provided by the user. This doesn't work
for MMD functions.
Again, set_integer_native is not an MMD function?
Re: continuations... frankly, I'm hoping that a solution emerges that
doesn't involve significant reduction in functionallity. I might be
misunderstanding you, but it sounds to me like you are proposing
ditching lexical pads.
No. I'm not ditching lexical pads at all. They are of course needed. The
top pad is in the registers. Outer pads are looked up as usual.
I guess I don't understand. I guess it is time for a test case. ;-)
How would the following work if the top pad is in registers?
var = 1
def g():
global var
var = 2
print before, var
g()
print after, var
Such behavior is the default for perl5:
my $var = 1;
sub g {
$var = 2;
}
print before $var\n;
g();
print after $var\n;
- Sam Ruby
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
for = {...}
I dub the...the fish operator!
:-)
David
Re: specifying the key Type for a Hash
On Mon, Dec 06, 2004 at 05:43:16AM +, Nigel Sandever wrote:
: I probably missed teh comprehensive dismissal thread, but why not 'type'?
:
: my %pet is Hash[:type(Str) :returns(Cat)];
Well, type is just a little off in a couple of ways. On the one hand,
it's not specific enough, insofar as there are several different
types involved. On the other hand, it's too specific, insofar as what
you're specifying there is not a type, but something more like a signature,
albeit one without parameters. It's more like the attachment on a
multi to pick one of a set: abscomplex.
That says to me that what we're really looking at is
my Cat %pet is sig(Str);
my @matrix is sig(int where 0..3, int where 0..3);
where those might be abbreviated as:
my Cat %pet (Str);
my %matrix (3,3);
or
my Cat %pet .{Str};
my %matrix .[3;3];
or maybe even
my Cat %pet{Str};
my %matrix[3;3];
Which says that
my sub foo ($a) {...}
is maybe short for
my sub foo .($a) {...}
Hmm. Also says maybe you could attach a block to a hash or array to
define what subscripting does. Hmm.
Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Mon, Dec 06, 2004 at 09:06:22AM -0800, David Wheeler wrote:
: On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
:
:for = {...}
:
: I dub the...the fish operator!
:
: :-)
Mmm. Next thing you'll know, people will name their files oddly just so
they can write things like:
for =///º {...}
for =|||' {...}
for =###* {...}
for =]]]° {...}
for =)))º {...}
Larry
Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion
On Sun, 5 Dec 2004, Jarkko Hietaniemi wrote: I am pretty certain that parrot was building fine in Tru64 back in 2004/11/07 15:12:42 when I submitted a patch (directly to CVS) for jit/alpha/jit_emit.h to get alpha JITing to compile at all. Since then something has broken building parrot in Tru64. What happens is that dynclasses/build.pl attempts something called a partial link for the various Python-related objects, and the attempt fails because it tries to invoke ld with parameters meant exclusively for the native cc (or the C++ compiler cxx): ld -std -D_INTRINSICS -fprm d -ieee -I/p/include -DLANGUAGE_C -pthread -g -DHAS_JIT -DALPHA-L/p/lib -shared -expect_unresolved * -O4 -msym -std -s -L/p/lib ../src/extend.o -o python_group.so lib-python_group.o pybuiltin.o pyobject.o pyboolean.o pyclass.o pycomplex.o pydict.o pyfloat.o pyfunc.o pygen.o pyint.o pylist.o pylong.o pymodule.o pynone.o pytype.o pystring.o pytuple.o ld: Badly formed hex number: -fprm ld: Usage: ld [options] file [...] partial link python_group.so failed (256) If ld in the above is replaced with cc, things work fine. The offending line in config/gen/makefiles/dynclasses_pl.in is probably this one: $LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT That CFLAGS doesn't belong there. CFLAGS are intended to be sent to $CC, not to $LD. The command being called here is $LD, which is defined in config/init/data.pl as the Tool used to build shared libraries and dynamically loadable modules. I no longer remember why LD is set to 'ld' on Tru64 -- is it just Ultrix heritage combined with lots of inertia or is it really a sensible setting? In any case, dynclasses_pl.in is wrong. There should be no CFLAGS there. -- Andy Dougherty [EMAIL PROTECTED]
Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: Two more issues: idiom, and topification
:
: = Topification:
:
: There are cases in P5 when I *don't* want
:
: while () {...}
:
: but prefer
:
: while ($input = ) {...}
:
: so that I can have something else be the topic. Every example to date
: has used Cfor:
:
: for .lines {...}
:
: but that sets the topic. I'm a little fuzzy on this, but doesn't Cfor
: play topic games even in this?
:
: for .lines - $input { ... $input ... }
:
: That is, even though $_ remains unaffected, doesn't this affect
: smartmatch etc.?
Currently it does. There have been some rumblings in the design team
that maybe it shouldn't. But it occurs to me that this might be another
spot to have our cake and eat it to. We could say that
for @foo - $input { ... $input ... }
doesn't set the topic in the block by default. However, methods do set
the topic (though there have been rumblings about that too). So we could
simply say that pointy subs can also be pointy methods if you specify
an invocant:
for @foo - $input: { ... $input and $_ ... }
I think I like that, but it needs to be thunk about some more. The downside
is that it's rather subtle. The upside is that it falls out of existing
rules, and lets - map more naturally in the way people expect. I don't
think people will naturally expect - to clobber $_.
Larry
while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: = Idiom:
:
: The other concern is idiom. Using Cfor suggests start at the
: beginning, continue to the end. OTOH, using Cwhile is a little
: weaker -- keep doing this until it's time to stop. Obviously they'll
: usually be used in the same way:
:
: for = {...} vs. while () {...}
:
: This seems a subtle concern, and maybe it's just my latent fear of
: change making me uncomfortable, but I actually *think* in english -- not
: that it does much good -- and this isn't how I think.
:
: Can we ditch Cfor in the examples in favor of Cwhile, for a while? :)
Okay. Have an example:
while =$IN - $line {...}
I think that works. I'm back to thinking unary = in scalar context iterates
like p5's , and you should use extraordinary means to get extraordinary
results:
while file $IN - $blob {...}
while slurp $IN - $bigblob {...}
Larry
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
Or even the dead fish operator:
while =###x - $net {...}
And here's a flounder:
while =:
Larry
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: : But I'd be willing to rename them to get/put. If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. Larry
Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion
Andrew Dougherty wrote: The offending line in config/gen/makefiles/dynclasses_pl.in is probably this one: $LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT That CFLAGS doesn't belong there. CFLAGS are intended to be sent to $CC, not to $LD. The command being called here is $LD, which is defined in config/init/data.pl as the Tool used to build shared libraries and dynamically loadable modules. I can't find anything that fails if this is removed, so I committed the change. - Sam Ruby
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
David Wheeler wrote:
On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
for = {...}
I dub the...the fish operator!
:-)
Back before there was a WWW, I used an editor called tgif. It was
written in france, and part of the idiom was to have two GUI buttons
showing respectively the head ( * ) and tail ( ( ) parts of a
fish. This were graphical images, please forgive my poor ascii drawing.
It took me a while to figure it out, but it was a cute bit of
bilingualism. (Or perhaps it was a bit of bilingual cute-ism...)
=Austin
Re: while Idiom (Was: Arglist I/O)
Austin Hastings writes:
The other concern is idiom. Using Cfor suggests start at the
beginning, continue to the end. OTOH, using Cwhile is a little
weaker -- keep doing this until it's time to stop. Obviously they'll
usually be used in the same way:
for = {...} vs. while () {...}
This seems a subtle concern, and maybe it's just my latent fear of
change making me uncomfortable, but I actually *think* in english -- not
that it does much good -- and this isn't how I think.
I think that Cfor reads much better than Cwhile for English-ness.
Having taught Perl 5 beginners that Cforeach can be used to iterated
over each item in a list, many of them then instinctively try to use the
same keyword for iterating over each line in a file. (Which of course
works -- albeit inefficiently and umidiomatically -- so they don't
bother looking any further.)
To me Cfor makes sense when you've got a pile of stuff you're
intending to process (such as array items or lines in a file), and
Cwhile makes sense when you're waiting for a condition (such as the
user correctly entering her/his password) and you couldn't possibly know
in advance how many times you'll be looping.
Smylers
Re: specifying the key Type for a Hash
On Mon, 6 Dec 2004, Larry Wall wrote:
Hmm. Also says maybe you could attach a block to a hash or array to
define what subscripting does. Hmm.
That's tantalizing. Did you have something like this in mind:
# Count number of accesses to each key
our %counter_hash;
my %hash is subscripted
- $subscript { %counter_hash{$subscript}++; %hash{$subscript} };
Or even:
# Provide a view of the hash
my %hash is subscripted
- $address { %hash{address_to_zipcode($address)}};
so that users can think that they are accessing %hash{Bloomington, IN}
when they are really accessing %hash{47401}.
Or scarier, using MMD-like stuff (I am not even thinking about syntax) we
get different things based on the signature of the key, giving us the
ability to differentiate between %hash{$Dog} or %hash{$Vet}.
And pretty soon somebody will define an accessor for the signature
(SQL_Query $s).
It seems to me that this idea is not very far away from P5 tying, but I
may be wrong. If it is not very far away, maybe we can even have:
my %hash is subscripted - $s{
FETCH {...}
STORE {...}
}
Crazy stuff. I don't know if it is doable or even desirable, but it sure
is cool!
Larry
--abhijit
Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Larry Wall writes:
Currently it does. There have been some rumblings in the design team
that maybe it shouldn't. But it occurs to me that this might be another
spot to have our cake and eat it to. We could say that
for @foo - $input { ... $input ... }
doesn't set the topic in the block by default. However, methods do set
the topic (though there have been rumblings about that too). So we could
simply say that pointy subs can also be pointy methods if you specify
an invocant:
for @foo - $input: { ... $input and $_ ... }
I think I like that, but it needs to be thunk about some more. The downside
is that it's rather subtle. The upside is that it falls out of existing
rules, and lets - map more naturally in the way people expect. I don't
think people will naturally expect - to clobber $_.
Considering that I was the rumbler, I'll try to stay concise. Don't
think that this is anything more than a stormy brain, though.
I really like the fact that for always topicalizes. I like it because
it forces refactors where they ought to be happening. I always get
confused when I see:
for (@array) {
for my $row (@{$data-[$_]}) {
for my $element (@$row) {
foobar($_) if $element;
}
}
}
It works that way in natural languages too. If you try to use it too
remotely, you just confuse everybody. In particular:
For each element in @array, look up the corresponding $row in $data,
and for each $element in the $row, call foobar on it if $element is
true.
Call foobar on what?
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (oper) {
oper($.left);
oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Luke
Re: while Idiom (Was: Arglist I/O)
Smylers writes: To me Cfor makes sense when you've got a pile of stuff you're intending to process (such as array items or lines in a file), and Cwhile makes sense when you're waiting for a condition (such as the user correctly entering her/his password) and you couldn't possibly know in advance how many times you'll be looping. And iterating over lines in a file is kind of between the two. Since both while and for work just as efficiently, and they're both just as clear (we see that Austin thinks while is clearer than for, and I think the opposite), I think it's great that you can use both. Luke
Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: Can we ditch Cfor in the examples in favor of Cwhile, for a while? :)
Okay. Have an example:
while =$IN - $line {...}
I think that works. I'm back to thinking unary = in scalar context iterates
like p5's
What would these do?
while =$IN - $l1,$l2 {...}
while =$IN - @x {...}
That first one seems particularly useful. I'm not exactly sure what
the second one should do, but it seems like it should be similar to
{ my @x = $IN.slurp; ... }
Can it be that unary = in n-ary context iterates like p5's except
when n == Inf or n == 0 (which are list and void context I guess) ?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: pull put (Was: Angle quotes and pointy brackets)
If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. But get has too strong a class accessor connotation in most OO. unpull? ;-)
Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote:
: On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
: On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: : Can we ditch Cfor in the examples in favor of Cwhile, for a while? :)
:
: Okay. Have an example:
:
: while =$IN - $line {...}
:
: I think that works. I'm back to thinking unary = in scalar context iterates
: like p5's
:
: What would these do?
:
: while =$IN - $l1,$l2 {...}
: while =$IN - @x {...}
:
: That first one seems particularly useful. I'm not exactly sure what
: the second one should do, but it seems like it should be similar to
: { my @x = $IN.slurp; ... }
The Cwhile statement is not an arbiter of lists. It want a scalar
value that can play the bool role. Assuming that $IN is really $*IN,
they would both fail because you're trying to bind a scalar string
to a signature that doesn't accept a single scalar string. It would
be exactly like
sub foo($I1, $I2) {...}
foo(#!/usr/bin/perl\n); # missing $I2
sub bar(@x) {...}
bar(#!/usr/bin/perl\n); # Trying to bind non-string to @x
That being said, if =$iterator returns a list of array references, the
second one would work. I don't see any way to make the first one work.
: Can it be that unary = in n-ary context iterates like p5's except
: when n == Inf or n == 0 (which are list and void context I guess) ?
You mean slurps all the values and then throws away all but n of them?
That's how p5's currently behaves. Or did you mean scalar ?
In any event, I don't think Cwhile is ever going to provide an n-ary
context to whatever it wants a boolean value from. That's what Cfor
is for.
Larry
Re: while Idiom (Was: Arglist I/O)
On Monday 06 December 2004 01:26 pm, Smylers wrote: I think that Cfor reads much better than Cwhile for English-ness. Having taught Perl 5 beginners that Cforeach can be used to iterated over each item in a list, many of them then instinctively try to use the same keyword for iterating over each line in a file. (Which of course works -- albeit inefficiently and umidiomatically -- so they don't bother looking any further.) To me Cfor makes sense when you've got a pile of stuff you're intending to process (such as array items or lines in a file), and Cwhile makes sense when you're waiting for a condition (such as the user correctly entering her/his password) and you couldn't possibly know in advance how many times you'll be looping. Smylers But you need to process the file while you haven't reached the end yet, or until you reach the end. And I can't think of an occasion where I knew going in what the length of the file I was processing was going to be. I suppose foreach might make sense if you sucked in the whole file at once and then processed the individual lines, but I've seldom been in situations where I could assume it was safe to do that. (Data expands to fill the space available, plus 10 %... and the production data file is always bigger than they told you it would be.) The same goes for database queries: you loop while the query is returning data or until it stops returning data. Foreach implies to me that you want to do the same thing, or something very similar, to each of the things you are processing. But in handling the lines of a file or the records returned by a query you may in fact want to throw many of them away, or handle various subgroups of data in different ways. -- Elyse Grasso http://www.data-raptors.comComputers and Technology http://www.astraltrading.com Divination and Science Fiction
Re: while idiom [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
On Mon, Dec 06, 2004 at 10:59:18AM -0800, Larry Wall wrote:
On Mon, Dec 06, 2004 at 12:45:18PM -0600, Jonathan Scott Duff wrote:
: On Mon, Dec 06, 2004 at 09:56:57AM -0800, Larry Wall wrote:
: On Mon, Dec 06, 2004 at 10:38:10AM -0500, Austin Hastings wrote:
: : Can we ditch Cfor in the examples in favor of Cwhile, for a while?
:)
:
: Okay. Have an example:
:
: while =$IN - $line {...}
:
: I think that works. I'm back to thinking unary = in scalar context
iterates
: like p5's
:
: What would these do?
:
: while =$IN - $l1,$l2 {...}
: while =$IN - @x {...}
:
: That first one seems particularly useful. I'm not exactly sure what
: the second one should do, but it seems like it should be similar to
: { my @x = $IN.slurp; ... }
The Cwhile statement is not an arbiter of lists.
Okie.
In any event, I don't think Cwhile is ever going to provide an n-ary
context to whatever it wants a boolean value from. That's what Cfor
is for.
Somehow I knew you were going to say that. I'm just being reluctant
to use Cfor for something I've been using Cwhile for all this time.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Premature pessimization
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
My philosophy is simple: things without test cases tend not not get
fixed, and when fixed, tend not to stay fixed.
There is of course a test case. I have mentioned it at least 20 times ;)
t/op/gc_13.imc - currently using lexicals.
I am worried about Parrot trying to establish common public names for
common functions. Many of the examples you gave did not include the
prerequisite double underscores. For example: sub, imag, eof.
Ah ok. Sorry. __subtract. OTOH some might be that common and the usage
is the same in all languages that we might use that common name. But
that's probably not worth the effort. So yes, we should establish the
notion that all methods follow that convention.
Re: VTABLES... I disagree with you on this one. Prematurely mapping an
operation to a string is a premature pessimization.
Except that we are doing that already. Please read through
classes/delegate.c. The problem is that this scheme doesn't work for
MMD of real objects.
I don't know enough to have an informed opinion yet on MMD. But
__set_integer_native is not a MMD operation. It already is efficiently
dispatched to the correct method.
For PMCs yes. For objects not efficiently and only with a separate
delegate meta-class.
... What do we benefit from the premature
pessimisation of mapping this to a string?
Well, method names happen to be strings ;)
Anyway, I'll try to summarize our current method dispatch scheme:
vtableMMD NCI method
-
opcodeset P0, 4 add P0, P1, P2 io.__eof()
-
PMC pmc-vtable-.. mmd_dispatch_* callmethod
objectdelegate.c 1) callmethod
object(PMC) deleg_pmc.c 1) callmethod
NCI methods are working, the method lookup is dynamic, inheritance
works.
MMD inheritance is totally static (set up during PMC compilation).
PMCs dispatch with the mmd_dispatch_* functions in ops/*.ops.
1) overloading a MMD infix operation needs the mmdvtregister opcode, but
this does not effect any class inheritance and it's just for the given
two types.
Multi-dimensional MD is not implemented.
For vtables objects and objects derived from PMCs use two helper classes
that bridge the dynamic inheritance of objects to the static inheritance
in PMCs. This doesn't support runtime overloading of methods that
defaulted to the PMC method.
Looking at 5 different schemes that work for ~50% of the cases can -
well - make one pessimistic ;)
I'm proposing that *internally* (implementation detail ...) one scheme
should be enough. Again: the opcodes don't change.
The vtable method set_integer_native clearly maps to a real method that
can be either inherited or be provided by the user. This doesn't work
for MMD functions.
Again, set_integer_native is not an MMD function?
__set_integer_native is a vtable method.
No. I'm not ditching lexical pads at all. They are of course needed. The
top pad is in the registers. Outer pads are looked up as usual.
I guess I don't understand. I guess it is time for a test case. ;-)
How would the following work if the top pad is in registers?
The top pad is always the currently executing one.
var = 1
def g():
global var
var = 2
print before, var
g()
print after, var
It's obviously up to the global to do the right thing. My impression
(I don't have more Python knowledge ;) is, that global refers to the
outermost lexical pad in the main module.
Such behavior is the default for perl5:
my $var = 1;
sub g {
$var = 2;
}
As there is no my $var in the inner pad, that's just a Cfind_lex
opcode. It follows the Cprev pointer to the outer pad and finds in the
lexical hash the $var which maps to a position in the register store
of the outer pad.
my ($a, $b) in the innermost pad (in sub g) would map directly to
registers as my $var maps to a register in main (in the outer pad).
It's the same as currently, except that we have now a separate array
that holds the lexicals. I was just mapping that array into the
preserved area of registers, which would make this area of course
variable-sized with the nice benefit that my int $i also works (we
don't have natural int lexicals currently).
- Sam Ruby
leo
Re: pull put (Was: Angle quotes and pointy brackets)
Dan Brian wrote: If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. But get has too strong a class accessor connotation in most OO. unpull? ;-) pushf/popf. f is for front. But I still don't see anything wrong with shift/unshift. I'd prefer to avoid having a group of words that all mean about the same thing, but keeping them straight requires some memory trick. I program in too many languages to keep my mnemonics straight. There's going to be enough fun with is/has/does/but. For reference, I always have to do a 'perldoc perlvar' when I need a P5 $punct. -- Rod Adams
slight discrepancy between S2 and S7
S2:
my $foo = 42;
say %MY::$foo;# prints 42
S6:
Perl5ish subroutine declarations
...
sub say { print qq{@_\n}; } # args appear in @_
Because Cprint has no final newline, I would expect Csay will have
one. Final newline or not. What is your say?
--
stef
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 01:25:29PM -0600, Rod Adams wrote: Dan Brian wrote: If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. But get has too strong a class accessor connotation in most OO. unpull? ;-) pushf/popf. f is for front. Ew! I'd prefer :head/:tail modifiers to push/pop over that. But ... But I still don't see anything wrong with shift/unshift. Neither do I. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote: : If I went with get, the opposite would be unget for both historical : and huffmaniacal reasons. : : But get has too strong a class accessor connotation in most OO. : : unpull? ;-) Given the existence of a unary = for abbreviated use, I'd probably stick with shift/unshift. (Presumably changing the semantics of shift from p5 to be list/scalar/n-ary context sensitive, so you'd have to write scalar shift to get Perl 5's shift semantics in list context.) Though it's awfully tempting to fill in the holes in the periodic table: ($a, $b, $c) = @foo * 3; And then just say all the corresponding unaries default to 1 (or the arity of the left): $bit = + $number; # $number + 1 $graph = ~ $string; # chip()/chimp() $whether = ? $boolean;# presumably clears $boolean $elem = * $iterator; # shift $iterator That would mean that we couldn't use those unaries in front of ... though. I suppose unary * would mean pop. Blurch. Let's stick with the binaries, if we add 'em at all. I do think foo( @bar * 3 ) foo( @bar * 3 ) might actually be clearer than foo( splice(@bar,0,3) ) foo( splice(@bar,-3,3) ) Also, note that neither of the latter examples means the same as foo( pop(@bar,3) ) since pop would presumably pop them in reverse order from splice. We also get all the rotates if we allow * and *. On the other hand, if anyone suggests a list xor: @foo *^ @bar I'll ask whether they mean @foo »+^« @bar @foo »~^« @bar @foo »?^« @bar @foo »*^« @bar Larry
Re: specifying the key Type for a Hash
On Mon, Dec 06, 2004 at 03:11:15AM -0700, David Green wrote: [snip] : I like that. [snip] : I like that even better. [snip] : I'm happy with those too (perhaps because I do want to be a bit : mathematical). [snip] : is FAT? Yeah, that works for me too. =) [snip] : I would take that as an abbreviation and read it as is dimensioned, : which is English-like enough for me. [snip] : But shape *is* prettier. Um. You're so very...easy to please... I guess I'm okay with that... Larry
Re: iterators and functions (and lists)
On Sun, Dec 05, 2004 at 12:05:46AM +, Matthew Walton wrote:
: I'm sorry, but from a C++ background, overriding postcircumfix:( )
: feels far more natural to me than setting 'is default' on some method.
That only works for disambiguation if you know which .() to call in
the first place. It seems likely that that .() maps straight to MMD
and doesn't look for a singly dispatched .() at all. But maybe I'm
just not understanding this.
: What if you do 'is default' on two methods? Compile-time error?
Syntactically legal, and semantically legal if they have different MMD
signatures. Otherwise a compile time error if the compiler can catch
it then, but I wouldn't require a compiler to do so if it's onerous.
Seems like it ought to be pretty easy though, if one has a way of
doing a test dispatch without really dispatching, and we need something
like that to resolve a reference like abscomplex.
: What if
: you're opening up someone else's class and want to override the existing
: default (okay, so you shouldn't be doing that in an OOP world, but what
: if you are? What if you're like me and like Perl's delightful mishmash
: of paradigms while simultaneously liking other languages for their
: purity? What if I actually talk about something relevant?)
I suppose you could always wrap it instead. What you're talking about
already sounds suspiciously like Aspect Oriented Programming.
: : # other thingies:
: :
: : sub foo { ... };
: : @array = @foo # all the results of foo, lazily.
:
: Don't see the need for that when
:
: @array := foo()
:
: does laziness implicitly already. Maybe even
:
: @array = foo()
:
: maintains laziness if it sees an infinite iterator in the return
: value of foo(). Or maybe it blows up and tells you to use :=
: to avoid trying to make a copy. That's probably cleaner.
:
: This is going to take me a while to get my head round... Does this
: particular foo() return an iterator? Or is it something which is
: iterated? Have I missed a bit of a synopsis or apocalypse which would
: make all this clear to me or are we still in handwaving mode?
Any foo() can return a list. That list can be a Lazy list. So the
ordinary return can say:
return 0...;
to return an infinite list, or even
return 0..., 0...;
to return a surreal list. Either of those may be bound to an array
as its generator of missing values. Assignment sort of implies
copying, but I'm just saying that the copier could also be smart
at least about infinities or indefinities (ohh, a cool new word),
even if it flattens everything else.
: Exceptions should not be used for
: something so mundane as running out fo values.
:
: Amen to that! One reason I ran screaming from Java was having to catch
: ArrayOutOfBoundsException all the time. And all those exceptions which
: the compiler forces you to catch. They're handy, but there is a limit. I
: prefer return values which can indicate if they're valid or not. undef
: is excellent for that :-)
:
: A string pretending to be undef can be even better. Can we still do
: that? I seem to recall it being in something at some point along the way.
An object can play the Undef role. Or maybe undef can play Ref role.
In any event, since a string is an object, the answer is Yes, but
an unthrown Exception object that can stringify would be better...
: If that's necessary to keep the Lazy from blocking when it runs out
: of values. Just like an ordinary array, a Lazy has to be aware of
: when it is out of values, and when it should call into some meta-Lazy
: for more iterator values. And I suppose that meta-Lazy could in
: turn have a meta-meta-Lazy, which could have a meta-meta-meta-Lazy,
: and now my brane hurts.
:
: And soon your entire program consists of code which may or may not ever
: be evaluated. Welcome to Haskell :-)
Next thing you'll be telling me is that all this partially evaluated
code shouldn't have any side effects. :-)
Larry
Re: C implementation of Test::Harness' TAP protocol
Keeping in mind I'm not a C programmer so my user expectations may be
all wrong.
On Mon, Dec 06, 2004 at 10:00:32AM -, Clayton, Nik wrote:
Then you have one of ok() or ok2() at your disposal. ok()'s first parameter
is the code to test. The second parameter is the test name. This is a
printf()like format string, and the third and subsequent parameters should
fill out any values in the string.
ok(a_func() == 0, test name);
ok(some_func(i), some_func(%d), i);
Why add that extra auto-sprintf complexity? Can't the user do the exact
same thing with:
ok(some_func(i), sprintf(some_func(%d), i));
Making the test name a sprintf string can complicate things if they want
to do formatting themselves, they have the extra problem of escaping their
result for sprintf.
Also, folks putting in bare strings might be surprised.
ok( tax(.05), taxing at 5% );
ok2() is for situations where the code to test is sufficiently
self-documenting that you don't need to provide a test name.
ok2(code to test); /* test name is automatically the same as the code */
E.g.,
ok(1 == 1, 1 equals one); /* PRINT: ok 1 - 1 equals 1 */
ok2(1 == 2);/* PRINT: not ok 2 - 1 == 2 */
Why the split? You can do variable length argument lists in C.
This is normally implemented with a do { ... } while(0); loop, with a
continue; immediately after the skip() call. This ensures that there
are no additional side effects from the skipped tests.
do {
if(getuid() != 0) {
skip(1, Test only makes sense as root);
continue;
}
ok(do_something_as_root() == 0, do_something_as_root() worked);
} while(0);
It might make more sense to do this.
if( getuid() != 0 ) {
skip(1, Test only makes sense as root);
}
else {
ok(do_something_as_root() == 0, do_something_as_root() worked);
}
I'm becoming less and less happy with the way skip is implemented in
Test::More.
Two macros, SKIP_START and SKIP_END can handle some of this for you. The
above example could be re-written:
SKIP_START(getuid() != 0, 1, Test only makes sense as root);
ok(do_something_as_root() == 0, do_something_as_root() worked);
SKIP_END;
That's pretty cool. Does it work with loops? What if in that SKIP section
somebody calls a routine which then calls ok()?
You also have diag(), which takes a printf() style format string and related
arguments, and sends the output to stderr as a test comment. diag() adds
the necessary trailing \n for you.
diag(Expected return code 0, got return code %d, rcode);
Don't forget about adding the # comment on the front of each line.
Finally, there's exit_status(), which returns an int suitable for use
when return'ing from main(), or calling exit(). You should always do one
of:
return exit_status();
exit(exit_status());
What is this for? --- possible C ignorance
I hope you're not emulating Test::More's exit code == # of tests failed
feature that I'm planning on getting rid of.
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
michael schwern is
Re: slight discrepancy between S2 and S7
On Mon, Dec 06, 2004 at 08:26:48PM +0100, Stéphane Payrard wrote:
: S2:
:
: my $foo = 42;
: say %MY::$foo;# prints 42
:
: S6:
:
: Perl5ish subroutine declarations
: ...
: sub say { print qq{@_\n}; } # args appear in @_
:
:
: Because Cprint has no final newline, I would expect Csay will have
: one. Final newline or not. What is your say?
Yes, the built-in Csay certainly adds a newline. That's the only thing
that distinguishes it from Cprint. The comment in S2 is misleading,
but you shouldn't ever believe the comments anyway. :-)
Or the Subject line. Yours seems to have suffered a bitflip somewhere...
Larry
Re: Container method calls
On Sat, Dec 04, 2004 at 03:28:12PM -0800, Ashley Winters wrote: : On Sat, 4 Dec 2004 11:15:14 -0800, Larry Wall [EMAIL PROTECTED] wrote: : On Sat, Dec 04, 2004 at 10:25:49AM -0700, Luke Palmer wrote: : : But this convention provides much more accuracy than memorizing a list : : of methods that don't automatically thread, or memorizing a list of : : iterator methods that act on the iterator and not its current value. : : Except that you don't actually have to memorize a list. Methods thread : on their invocant only if their invocant isn't a Junction. Its : mnemonic value is no better or worse than any other MMD distinction. : : Is this behavior exclusive to methods? Or does something like this: : : 3.14159 + 1|2; : : try to MMD-dispatch to: : : multi sub *infix:+ (Num $foo, Str|Int $bar) : : instead of (or before) threading? That would be an instead of, I suspect. Larry
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Luke Palmer wrote:
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (oper) {
oper($.left);
oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Well it's not using oper on the elems anymore.
method perform (oper) {
for @.elems {
oper($_);
}
}
But I don't think that was the mistake you were talking about. And I
don't see what it has to do with unary dot either, because you don't
need to use unary dot to implement that method. Unless each member of
@.elems is a Duple, in which case the class isn't one I'd call Tuple.
Sorry, nitpicking level seems to be set to 9 at the moment. What did you
mean?
Re: while Idiom (Was: Arglist I/O)
Elyse M. Grasso wrote:
But you need to process the file while you haven't reached the end yet, or
until you reach the end. And I can't think of an occasion where I knew going
in what the length of the file I was processing was going to be. I suppose
foreach might make sense if you sucked in the whole file at once and then
processed the individual lines, but I've seldom been in situations where I
could assume it was safe to do that. (Data expands to fill the space
available, plus 10 %... and the production data file is always bigger than
they told you it would be.)
The same goes for database queries: you loop while the query is returning data
or until it stops returning data.
Foreach implies to me that you want to do the same thing, or something very
similar, to each of the things you are processing. But in handling the lines
of a file or the records returned by a query you may in fact want to throw
many of them away, or handle various subgroups of data in different ways.
That doesn't make any difference as far as I'm concerned. foreach (or
for in Perl 6) implies to me that you have a list of things and you're
going to look at each of them in turn. Whether you do the same thing to
them or not is to my mind irrelevant, you're stepping over a list item
by item. for is, to me, ideally suited for anything where you're looking
at a sequence of things one at a time - reading lines from a file fits
that perfectly.
Perhaps the reason the indeterminate length of a file doesn't bother me
is because I'm a Haskell programmer, where everything is lazy and
recursing over lists is about the only way to get any kind of looping at
all. Iterating over something of indeterminate length really doesn't
bother me :-)
Something like the C++y
while(!in.eof()) {
...
}
Is attractive in its way, but I'd rather have something more convenient,
and I think doing a for over a conceptual list (as in it's not really a
list, but it's behaving kind of like one in this context) of lines in
the file is infinitely better.
One can also view the results of a database query as a list of rows
returned which you then look at one at a time. In fact, I find that far
more natural than fetching until there are none left.
Of course, you're still really doing that behind the scenes.
Re: Premature pessimization
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
My philosophy is simple: things without test cases tend not not get
fixed, and when fixed, tend not to stay fixed.
There is of course a test case. I have mentioned it at least 20 times ;)
t/op/gc_13.imc - currently using lexicals.
$ parrot t/op/gc_13.imc
3 * 5 == 15!
What's broken?
I am worried about Parrot trying to establish common public names for
common functions. Many of the examples you gave did not include the
prerequisite double underscores. For example: sub, imag, eof.
Ah ok. Sorry. __subtract. OTOH some might be that common and the usage
is the same in all languages that we might use that common name. But
that's probably not worth the effort. So yes, we should establish the
notion that all methods follow that convention.
Cool.
Re: VTABLES... I disagree with you on this one. Prematurely mapping an
operation to a string is a premature pessimization.
Except that we are doing that already. Please read through
classes/delegate.c. The problem is that this scheme doesn't work for
MMD of real objects.
I don't know enough to have an informed opinion yet on MMD. But
__set_integer_native is not a MMD operation. It already is efficiently
dispatched to the correct method.
For PMCs yes. For objects not efficiently and only with a separate
delegate meta-class.
The current delegation internals are not likely a good match for
languages like Python or Ruby. I see such languages as implementing
their own semantics for classes, and Parrot limiting its knowledge to
methods like findmeth and invoke.
... What do we benefit from the premature
pessimisation of mapping this to a string?
Well, method names happen to be strings ;)
Using the table below, at the moment, there are exactly zero strings
materialized and/or compared against during the execution of vtable/PMC
methods. To the extent that these are represent common operations, this
can be significant from a performance perspective.
Anyway, I'll try to summarize our current method dispatch scheme:
vtableMMD NCI method
-
opcodeset P0, 4 add P0, P1, P2 io.__eof()
-
PMC pmc-vtable-.. mmd_dispatch_* callmethod
objectdelegate.c 1) callmethod
object(PMC) deleg_pmc.c 1) callmethod
NCI methods are working, the method lookup is dynamic, inheritance
works.
MMD inheritance is totally static (set up during PMC compilation).
PMCs dispatch with the mmd_dispatch_* functions in ops/*.ops.
1) overloading a MMD infix operation needs the mmdvtregister opcode, but
this does not effect any class inheritance and it's just for the given
two types.
Multi-dimensional MD is not implemented.
For vtables objects and objects derived from PMCs use two helper classes
that bridge the dynamic inheritance of objects to the static inheritance
in PMCs. This doesn't support runtime overloading of methods that
defaulted to the PMC method.
Looking at 5 different schemes that work for ~50% of the cases can -
well - make one pessimistic ;)
I'm proposing that *internally* (implementation detail ...) one scheme
should be enough. Again: the opcodes don't change.
I don't think that there can be a single dynamic mechanism that works
for all languages, let alone one that works for Parrot internals too.
For starters, findmeth is a method. One that merits its own VTABLE
entry (otherwise, how would you find it?). Others that map cleanly onto
existing language syntax also can benefit from such optimizations.
MMD might help out with mutiple language interop, but Python as
currently designed doesn't need any such facility.
The vtable method set_integer_native clearly maps to a real method that
can be either inherited or be provided by the user. This doesn't work
for MMD functions.
Again, set_integer_native is not an MMD function?
__set_integer_native is a vtable method.
Cool.
No. I'm not ditching lexical pads at all. They are of course needed. The
top pad is in the registers. Outer pads are looked up as usual.
I guess I don't understand. I guess it is time for a test case. ;-)
How would the following work if the top pad is in registers?
The top pad is always the currently executing one.
var = 1
def g():
global var
var = 2
print before, var
g()
print after, var
It's obviously up to the global to do the right thing. My impression
(I don't have more Python knowledge ;) is, that global refers to the
outermost lexical pad in the main module.
Such behavior is the default for perl5:
my $var = 1;
sub g {
$var = 2;
}
As there is no my $var in the inner pad, that's just a Cfind_lex
opcode. It follows the Cprev pointer to the outer pad and finds in the
lexical hash the $var which maps to a position in the
Re: pull put (Was: Angle quotes and pointy brackets)
Larry Wall wrote:
On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: If I went with get, the opposite would be unget for both historical
: and huffmaniacal reasons.
Why? (I get the huffman, not the history.) Is it just a nod to unshift?
Given the existence of a unary = for abbreviated use, I'd probably
stick with shift/unshift. (Presumably changing the semantics of
shift from p5 to be list/scalar/n-ary context sensitive, so you'd
have to write scalar shift to get Perl 5's shift semantics
in list context.)
What about add/remove?
sub unshift(@a, [EMAIL PROTECTED])
{
@a.add(@items);
}
We could add :head and :tail, with :head the default, and let push|pop
be equivalent to (add|remove).assuming(tail = 1)
As a side note, other than historical consistency, is there a good
reason for push/pop to use the end of the array? I'd argue that for a
stack, you only want to know one address: @stack[0] -- the 'top' of
the stack -- and if you ever iterate a stack you're inclined to see the
items in distance-from-top order, making 0..Inf the right array
sequence. If we're going to reorg the function space, let's huffmanize
the stack stuff (push/pop/0) and let the other stuff go hang.
=Austin
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 03:50:42PM -0500, Austin Hastings wrote:
: Larry Wall wrote:
:
: On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: : If I went with get, the opposite would be unget for both historical
: : and huffmaniacal reasons.
:
:
: Why? (I get the huffman, not the history.) Is it just a nod to unshift?
Try man ungetc.
: Given the existence of a unary = for abbreviated use, I'd probably
: stick with shift/unshift. (Presumably changing the semantics of
: shift from p5 to be list/scalar/n-ary context sensitive, so you'd
: have to write scalar shift to get Perl 5's shift semantics
: in list context.)
:
:
: What about add/remove?
Backwards Huffman, considering removal happens more often.
: sub unshift(@a, [EMAIL PROTECTED])
: {
: @a.add(@items);
: }
:
: We could add :head and :tail, with :head the default, and let push|pop
: be equivalent to (add|remove).assuming(tail = 1)
remove is a transitive verb. I think people would take remove
to be remove any occurrences of, and in the absence of any obvious
direct object, remove this array, or remove the list of files in
this array.
: As a side note, other than historical consistency, is there a good
: reason for push/pop to use the end of the array? I'd argue that for a
: stack, you only want to know one address: @stack[0] -- the 'top' of
: the stack -- and if you ever iterate a stack you're inclined to see the
: items in distance-from-top order, making 0..Inf the right array
: sequence. If we're going to reorg the function space, let's huffmanize
: the stack stuff (push/pop/0) and let the other stuff go hang.
For indexable arrays, the front is what you want to nail down, but
that means it's difficult to make unshift efficient. Swapping push/pop
for shift/unshift would make push/pop rather inefficient. And the top
of your stack can just as easily be @stack[-1] as it is now.
I don't see much reason to change what we have currently unless we
decided shift was too long, and it isn't if we have unary = for
interators, and real function args to take away most of my $arg = shift;.
Appearances to the contrary notwithstanding, I'm not trying to break
Perl 5 constructs just for the heck of it.
Larry
Re: C implementation of Test::Harness' TAP protocol
--- Michael G Schwern [EMAIL PROTECTED] wrote: Why add that extra auto-sprintf complexity? Can't the user do the exact same thing with: ok(some_func(i), sprintf(some_func(%d), i)); No. sprintf in C needs a buffer and you don't know how big to make it. ok2() is for situations where the code to test is sufficiently self-documenting that you don't need to provide a test name. ok2(code to test); /* test name is automatically the same as the code */ E.g., ok(1 == 1, 1 equals one); /* PRINT: ok 1 - 1 equals 1 */ ok2(1 == 2);/* PRINT: not ok 2 - 1 == 2 */ Why the split? You can do variable length argument lists in C. Not with the pre-processor. And you need the pre-processor for __LINE__ and __FILE__. An alternative is to drop the ugly ok2() and force the test writer to use: ok(1 == 2, ); I prefer that since I want to make it hard for people to avoid giving a test a name, er, comment. Finally, there's exit_status(), which returns an int suitable for use when return'ing from main(), or calling exit(). You should always do one of: return exit_status(); exit(exit_status()); What is this for? --- possible C ignorance I hope you're not emulating Test::More's exit code == # of tests failed feature that I'm planning on getting rid of. I tried returning the number of failed tests in the exit status in a C++ regression test suite a while back and dropped it because: i) you are limited to 0-255 for this exit status; ii) you can always tell the number of failed tests by parsing stdout; iii) it's nice to cleanly detect a program crash; if it don't return zero, it crashed. /-\ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: C implementation of Test::Harness' TAP protocol
On Mon, Dec 06, 2004 at 02:25:42PM -0800, Andrew Savige wrote: --- Michael G Schwern [EMAIL PROTECTED] wrote: Why add that extra auto-sprintf complexity? Can't the user do the exact same thing with: ok(some_func(i), sprintf(some_func(%d), i)); No. sprintf in C needs a buffer and you don't know how big to make it. If the user doesn't know how will ok() know how big to make it? ok(1 == 1, 1 equals one); /* PRINT: ok 1 - 1 equals 1 */ ok2(1 == 2);/* PRINT: not ok 2 - 1 == 2 */ Why the split? You can do variable length argument lists in C. Not with the pre-processor. And you need the pre-processor for __LINE__ and __FILE__. An alternative is to drop the ugly ok2() and force the test writer to use: ok(1 == 2, ); I prefer that since I want to make it hard for people to avoid giving a test a name, er, comment. At the very least some better name than ok2(). Finally, there's exit_status(), which returns an int suitable for use when return'ing from main(), or calling exit(). You should always do one of: return exit_status(); exit(exit_status()); What is this for? --- possible C ignorance I hope you're not emulating Test::More's exit code == # of tests failed feature that I'm planning on getting rid of. I tried returning the number of failed tests in the exit status in a C++ regression test suite a while back and dropped it because: i) you are limited to 0-255 for this exit status; For informational purposes... TM gets around this by just declaring 254 to mean 254 failures or more. If you have more than 254 failures something tells me the exact number isn't all that important. :) ii) you can always tell the number of failed tests by parsing stdout; Assuming you have a parser that's quiet. This is less than simple with Test::Harness at the moment. iii) it's nice to cleanly detect a program crash; if it don't return zero, it crashed. Yeah, I agree with that. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Quit looking, kids! It'll EAT YOUR MIND!! -- http://www.angryflower.com/fuck.gif
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Matthew Walton writes:
Luke Palmer wrote:
The remaining problem is what to do about unary dot. Repeated here for
the, er, benefit? of p6l:
class Duple {
has $.left;
has $.right;
method perform (oper) {
oper($.left);
oper($.right);
}
}
Let's change that into a Tuple class:
class Tuple {
has @.elems;
method perform (oper) {
for @.elems {
.perform($_);
}
}
}
Can you find the mistake?
Well it's not using oper on the elems anymore.
That's mostly because I really screwed up the example. Mind, it was
very, very early in the morning when I wrote this. Let's try again.
(This is a pretty trivial example, but the problem only gets worse as we
approach real life).
class MyStream {
has $.stream;
method :send_one ($item) {
$.stream.send($item);
}
method send ([EMAIL PROTECTED]) {
.:send_one(BEGIN);
for @data {
.:send_one($_);
}
.:send_one(END);
}
}
Luke
Re: iterators and functions (and lists)
Larry Wall writes: Any foo() can return a list. That list can be a Lazy list. So the ordinary return can say: return 0...; to return an infinite list, or even return 0..., 0...; Is it just me, or did you just return *2? http://en.wikipedia.org/wiki/Ordinal#Arithmetic_of_ordinals That would be totally cool. But um, how do we get at the structure of that list from within Perl? It looks like no matter what you do it would be impossible to see the second 0. Luke
Re: iterators and functions (and lists)
Luke Palmer wrote: Larry Wall writes: Any foo() can return a list. That list can be a Lazy list. So the ordinary return can say: return 0...; to return an infinite list, or even return 0..., 0...; Is it just me, or did you just return *2? http://en.wikipedia.org/wiki/Ordinal#Arithmetic_of_ordinals That would be totally cool. But um, how do we get at the structure of that list from within Perl? It looks like no matter what you do it would be impossible to see the second 0. Luke my ($foo1, $foo2) = foo(); ? =Austin
Re: iterators and functions (and lists)
On Mon, Dec 06, 2004 at 06:14:56PM -0500, Austin Hastings wrote: (B: Luke Palmer wrote: (B: (B: Larry Wall writes: (B: (B: (B: Any foo() can return a list. That list can be a Lazy list. So the (B: ordinary return can say: (B: (B:return 0...; (B: (B: to return an infinite list, or even (B: (B:return 0..., 0...; (B: (B: (B: (B: Is it just me, or did you just return $B(B*2? (B: http://en.wikipedia.org/wiki/Ordinal#Arithmetic_of_ordinals (B: (B: That would be totally cool. But um, how do we get at the structure of (B: that list from within Perl? It looks like no matter what you do it (B: would be impossible to see the second 0. (B: (B: Luke (B: (B: (B: (B: my ($foo1, $foo2) = foo(); (B: (B: ? (B (BNo, that'd put 0 and 1 into those variables. (B (BYou'd have to bind the return value to @foo and then ask @foo for its (Bhidden specs that generates its values. That has two elements, one for (Beach infinite iterator. Here's the quote from A6: (B (BThe List type in particular is an internal type for the temporary (Blists that are passed around in Perl. Preflattened lists are Eager, (Bwhile those lists that are not preflattened are Lazy. When you call (B@array.specs, for instance, you actually get back an object of type (BLazy. Lists (Lazy or otherwise) are internal generator objects, (Band in general you shouldn't be doing operations on them, but on (Bthe arrays to which they are bound. The bound array manages its (Bhidden generators on your behalf to "harden" the abstract list (Binto concrete array values on demand. (B (BAs far as I can recall we haven't renamed C.specs to anything else yet. (B (BLarry
Re: Topification [Was: Arglist I/O [Was: Angle quotes and pointy brackets]]
Luke Palmer wrote:
class MyStream {
has $.stream;
method :send_one ($item) {
$.stream.send($item);
}
method send ([EMAIL PROTECTED]) {
.:send_one(BEGIN);
for @data {
.:send_one($_);
}
.:send_one(END);
}
}
I'll guess that you're pointing at
.:send_one($_);
Which supposedly uses topic to resolve .:send_one into $this.send_one.
If that works, then I'm happy -- I like being able to control topic and
$_ differently. But if Cfor changes topic, then what?
OUTER::.:send_one($_);
Yuck.
=Austin
Re: pull put (Was: Angle quotes and pointy brackets)
stuff grab :-) -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: : But I'd be willing to rename them to get/put. If I went with get, the opposite would be unget for both historical and huffmaniacal reasons. Larry
Re: continuation enhanced arcs
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Matt Fowles [EMAIL PROTECTED] wrote: Thanks for the clear explanation. I did not realize that S registers could switch pointers, that does make things a little harder. I have a recommendation for a possible hybrid solution. Incur the cost of spilling I,S,N registers heavily. Restore the state of P register. My conclusion was that with the copying approach I,S,N registers are unusable. But you only need to copy when the frame you're restoring is a full continuation Yes. With the effect that semantics of I,S,N (i.e. value registers) suddenly changes. I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it. *If* the programmer is aware of the fact that a subroutine can return multiple times, he can annotate the source so that a correct CFG is created that prevents register reusing alltogether. The problem is gone in the first place. *If* that's not true, you'd get the effect that suddenly I,S,N registers restore to some older values which makes this registers de facto unusable. But they're bloody value registers. They're *supposed* to restore to the state they were in when the function was originally called. Which is what copying semantics does.
Re: continuation enhanced arcs
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Matt Fowles [EMAIL PROTECTED] wrote: Thanks for the clear explanation. I did not realize that S registers could switch pointers, that does make things a little harder. I have a recommendation for a possible hybrid solution. Incur the cost of spilling I,S,N registers heavily. Restore the state of P register. My conclusion was that with the copying approach I,S,N registers are unusable. But you only need to copy when the frame you're restoring is a full continuation Yes. With the effect that semantics of I,S,N (i.e. value registers) suddenly changes. I'd submit that, in the vast majority of cases you're not going to be dealing with full continuations, and on the occasions when you are the programmer using them will be aware of the cost and will be willing to pay it. *If* the programmer is aware of the fact that a subroutine can return multiple times, he can annotate the source so that a correct CFG is created that prevents register reusing alltogether. The problem is gone in the first place. *If* that's not true, you'd get the effect that suddenly I,S,N registers restore to some older values which makes this registers de facto unusable. Further to my last response. If you have things set up so that you can return multiple times from the same function invocation then the return continuation should have been replaced with a full continuation before the first return, so even the first return will use copying semantics, and the registers will always be restored to the state they were in when the function was first called, which is absolutely the right thing to do.
Re: Premature pessimization
Leopold Toetsch writes: citing Luke Palmer On a semi-related note, can I get a classoffset without doing a hash lookup? That is, can I store the class number I get assigned somewhere for quick fetching? Hey now, you're citing the Luke Palmer that writes code. Don't confuse him with the Luke Palmer who does software design. They really don't get along so well... Luke
[perl #32906] Can't make TCL
# New Ticket Created by Matthew Zimmerman # Please include the string: [perl #32906] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32906 --- osname= linux osvers= 2.4.21-4.elsmp arch= i386-linux-thread-multi cc= gcc 3.3.3 20040412 (Red Hat Linux 3.3.3-7) --- Flags: category=core severity=high ack=no --- I can't get TCL to `make', on the most recent CVS checkout: [EMAIL PROTECTED] ~/personal/devel/parrot $ cd languages/tcl [EMAIL PROTECTED] ~/personal/devel/parrot/languages/tcl $ make make: *** No rule to make target `lib/commands/join.imc', needed by `lib/tcllib.imc'. Stop. --- Summary of my parrot 0.1.1 configuration: configdate='Mon Dec 6 12:02:34 2004' Platform: osname=linux, archname=i386-linux-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATH PERL5LIBSHELL -- Matt Matthew Zimmerman Interdisciplinary Biophysics, University of Virginia http://www.people.virginia.edu/~mdz4c/
Re: C implementation of Test::Harness' TAP protocol
--- Michael G Schwern [EMAIL PROTECTED] wrote: On Mon, Dec 06, 2004 at 02:25:42PM -0800, Andrew Savige wrote: --- Michael G Schwern [EMAIL PROTECTED] wrote: Why add that extra auto-sprintf complexity? Can't the user do the exact same thing with: ok(some_func(i), sprintf(some_func(%d), i)); No. sprintf in C needs a buffer and you don't know how big to make it. If the user doesn't know how will ok() know how big to make it? By the magic of the ANSI C macros: va_start(), va_arg(), va_end(). These macros are provided by the C runtime library and typically require some assembler to implement. In Nik's _gen_result() function (tap.c) he employs these macros in harness with vprintf(): in this way, he does not need to allocate a buffer at all, nor does he need worry about possible buffer overruns. FWIW, I agree with this implemenatation decision, and feel it will be well received by C programmers ... unless anyone can suggest a better alternative, of course. /-\ Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, 6 Dec 2004 11:34:24 -0800, Larry Wall [EMAIL PROTECTED] wrote:
Though it's awfully tempting to fill in the holes in the periodic table:
($a, $b, $c) = @foo * 3;
And then just say all the corresponding unaries default to 1 (or the arity
of the left):
$bit = + $number; # $number + 1
$graph = ~ $string; # chip()/chimp()
$whether = ? $boolean;# presumably clears $boolean
$elem = * $iterator; # shift $iterator
Well, that's interesting.
I suppose unary * would mean pop. Blurch. Let's stick with the binaries,
if we add 'em at all. I do think
foo( @bar * 3 )
foo( @bar * 3 )
Hrm... if you're thinking of going that way, I'd rather have a
lazy-assignment/destructive-pipe operator of some sort:
($a,$b) == [EMAIL PROTECTED]; # splice(@bar, 0, 2)
($a, $b) == [EMAIL PROTECTED] # splice(@bar, 0, 0, $a, $b)
[EMAIL PROTECTED] == ($a, $b); # splice(@bar, -2)
[EMAIL PROTECTED] == ($a, $b); # splice(@bar, @bar, 0, $a, $b);
Of course, with something indicating the desire to modify the array. I
don't know that [EMAIL PROTECTED] would be right for that, but I dunno. Just an
idea.
I'd want some way of telling the array to lazily add/remove elements
as part of the pipe operator, which would make:
foo == [EMAIL PROTECTED]; # REMOVE however many elements from the front of
@bar
as foo() wants
However, this would lead to me thinking about this sequence:
[EMAIL PROTECTED] == map == grep == @whatever;
as:
while pop @this { ... unshift @that, $_ }
Which would be interesting (bad) for performance
Ashley
Re: C implementation of Test::Harness' TAP protocol
--- Clayton, Nik [EMAIL PROTECTED] wrote:
Having done the initial work to get most of FreeBSD's regression testing
infrastructure producing Test::Harness TAP compatible output, I've started
putting together a C library that makes it easier to write tests in C.
Great!
This is something I'm interested in and wish I had more spare time
to pursue. Here are a few random ideas.
1) You might be able to steal some implementation ideas from:
http://cutest.sourceforge.net/
This is a very simple C Unit Testing framework.
In particular, it keeps state in a CuTest struct which is passed
around as the first (mostly hidden) parameter to most functions.
2) A uniform mechanism for test programs to handle command line
arguments would be nice. For example:
int main(int argc, char* argv[])
{
tap_init(argc, argv); /* mythical new tap function */
// ...
}
Some possible command line arguments are:
-v verbose
-d debug
-t give timing information (via ANSI C clock() function, say)
3) Implementing cmp_ok() in C is a challenge. ;-)
xUnit/cutest have things like:
AssertStrEquals
AssertIntEquals
...
The trouble with plain old ok() is that investigating test failures
is a pest. I suppose you could support equals for the basic C types.
For example:
cmp_ok_int_equals
cmp_ok_double_equals
cmp_ok_cstr_equals
cmp_ok_mem_equals
...
and so on. In the cstr/mem case, you can have the function check
for NULL pointers and give a nice diagnostic rather than crashing.
4) Is thread-safety a requirement of your library?
If so, you better think about it now because it's very hard to
retrofit.
HTH,
/-\
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
Perl 6 Summary for 2004-11-29 through 2004-12-06
Perl 6 Summary for 2004-11-29 through 2004-12-06 All~ Last week I asked for help identifying the source of a quotation. One friendly soul suggested Alan J. Perlis, but could not find an actual attribution. It did lead me to find a very applicable (and in my mind funny) quote from Perlis, which I will now inflict upon you all, before your regularly scheduled summary: When someone says I want a programming language in which I need only say what I wish done, give him a lollipop. -Alan J. Perlis Perl 6 Language qq:i Jim Cromie wondered if there could be a qq:i which sometimes interpolates and sometimes doesn't depending on whether the variable had been previously defined. There was some discussion which led to the conclusion that this was just asking for strange bugs. http://xrl.us/d95h getters and setters John Siracusa wanted to know if Perl 6 would allow one to expose a member variable to the outside world, but then later intercept assignments to it without actually having to switch to using getters and setters in all of the code that uses the variable. The answer: yes, yes you can. http://xrl.us/d95i « foo Richard Proctor asked if he could do list of words». Juerd pointed out that this had already been asked. Which brings us to the fine point, ask not Larry for he will tell you both yes and no. Although in this case I think he said, probably... http://xrl.us/d95j flipflop operator Juerd wondered about the fate of the flipflop. Larry explained that while it had lost the election it was still going to work hard for you in the Senate. Err, that's not quite right, he said that It's leaving syntactically but not semantically., but the new syntax has not been specified... http://xrl.us/d95k temp $var Alexey Trofimenko wanted to know whether temp would preserve or destroy its old value. Larry is leaning towards the Perl 5 semantics of destroying, I think. http://xrl.us/d95m state vs my Alexey Trofimenko wondered how much advice about optimizing Ruby also applied to perl. Unfortunately, he also misunderstood the state specifier. The topic then quickly veered into what exactly state does. http://xrl.us/d95n specifying a hash's key type Abhijit Mahabal wanted to know if he could specify a hash's key type. The answer is yes, but the exact syntax seems to be worth a discussion. Luke Palmer, in his Mathematician's rage, attempted to shoot down any usage of Domain and Range, as they really should be Domain and Codomain. http://xrl.us/d95o http://en.wikipedia.org/wiki/Range_%28mathematics%29 -- wikipedia: range Range (mathematics) - Wikipedia, the free encyclopedia container methods Ashley Winters wants to have syntax for calling a method on the container object rather than the containee. Luke Palmer agreed that this was problematic. Larry appears to be in no hurry to add more operators for this one, yet. http://xrl.us/d95p slight discrepancy between synopses Stéphane Payrard pointed out a small issue in some synopses. Larry replied oops. http://xrl.us/d95q arrays, lists, iterators, functions, coroutines, syntax Many people suggested many things about the best thing to replace the now missingop. I think Larry is leaning towards adding a undare = op, which would do cool things. I don't thing anything is final yet. http://xrl.us/d95r -- iterators as functions http://xrl.us/d95s -- unary = talk Push/Pop/Pull/Monkey Many folk voiced their dislike of shift and unshift. I must agree with them, but they also suggested a great many alternatives, including pull/put, get/unget, and even getting rid of Push/Pop. I must say that I really dislike that last idea, fortunately I am no alone. Currently we are waiting for inspiration to strike. http://xrl.us/d95t Topicalization It was noticed that for might override one's topic at undesired times. Larry rumminated about ways to solve this. http://xrl.us/d95u Required Whitespace Rod Adams does not like inconsistent whitespace rules. Larry explained why the existing rules really were consistent. http://xrl.us/d95v Perl 6 Compilers The lack of traffic on p6c has given me another space to abuse. You should listen to Soul Coughing. If you would like to join in the fun of abusing p6c, you should submit tests. Nothing is more abusive then stress testing ;-) Parrot Tuning and Monitoring Matt S asked how much support for tuning and monitoring. This week I exercise the awesome powers of the summarizer and invoke the mighty Warnock's Dilemnia. http://xrl.us/d95w imcc.globals-- Leo removed some imcc globals. Nice work. http://xrl.us/d95x ensure directories exist first
Re: C implementation of Test::Harness' TAP protocol
On Tue, Dec 07, 2004 at 12:55:01PM +1100, Andrew Savige wrote: 3) Implementing cmp_ok() in C is a challenge. ;-) xUnit/cutest have things like: AssertStrEquals AssertIntEquals ... The trouble with plain old ok() is that investigating test failures is a pest. I suppose you could support equals for the basic C types. For example: cmp_ok_int_equals cmp_ok_double_equals cmp_ok_cstr_equals cmp_ok_mem_equals ... and so on. In the cstr/mem case, you can have the function check for NULL pointers and give a nice diagnostic rather than crashing. Yucko. Test::More implements cmp_ok() using an eval. Could a macro prove useful here to do something similar? cmp_ok(foo, 'int', '==', bar); -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I am the soul of honor, kindness, mercy, and goodness. Trust me in all things. -- Corwin, Guns of Avalon
Re: Perl 6 Summary for 2004-11-29 through 2004-12-06
Matt Fowles wrote: keyword arguments Sam Ruby wondered how he out to handle keyword arguments to functions. Dan admitted that this is complex and outlined the cheat he has been contemplating. No one has either commented on or implemented it yet. http://xrl.us/d955 Oh, yes, I did. ;-) Here's a test case that now passes: http://pirate.versionhost.com/viewcvs.cgi/pirate/test/python/varargs.py?rev=HEADcontent-type=text/vnd.viewcvs-markup At the moment, there is no Parrot conventions for such things, so this can't be expected to iteroperate across languages; but if such conventions ever do materialize, I'll adjust. - Sam Ruby
Re: [perl #32906] Can't make TCL
You mean, someone actually tried to use Tcl? *Rub eyes* Whoops. File got added to the tcl makefile based on a local copy of the command. Committed update to MANIFEST and the join file (which isn't complete or tested, btw.) Try again? Matthew Zimmerman (via RT) wrote: # New Ticket Created by Matthew Zimmerman # Please include the string: [perl #32906] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32906 --- osname= linux osvers= 2.4.21-4.elsmp arch= i386-linux-thread-multi cc= gcc 3.3.3 20040412 (Red Hat Linux 3.3.3-7) --- Flags: category=core severity=high ack=no --- I can't get TCL to `make', on the most recent CVS checkout: [EMAIL PROTECTED] ~/personal/devel/parrot $ cd languages/tcl [EMAIL PROTECTED] ~/personal/devel/parrot/languages/tcl $ make make: *** No rule to make target `lib/commands/join.imc', needed by `lib/tcllib.imc'. Stop. --- Summary of my parrot 0.1.1 configuration: configdate='Mon Dec 6 12:02:34 2004' Platform: osname=linux, archname=i386-linux-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATH PERL5LIBSHELL
Re: C implementation of Test::Harness' TAP protocol
--- Michael G Schwern [EMAIL PROTECTED] wrote:
Yucko.
Test::More implements cmp_ok() using an eval. Could a macro prove useful
here to do something similar?
cmp_ok(foo, 'int', '==', bar);
Good idea Schwern.
These test suites inevitably degenerate into macro crack-pipe
smoking sessions. Lacking 'eval', it is always going to be very
hard work to even get close to Perl's Test::More functionality
and ease-of-use in C.
I don't have a filthy enough mind to make your:
cmp_ok(foo, 'int', '==', bar);
macro work (mainly because '==' is not a valid C identifier).
But I can make this one work:
cmp_ok(foo, int, eq, bar);
pretty easily:
#include stdio.h
void cmp_ok_inteq(int s, int t) {
printf(in cmp_ok_inteq: %d %d\n, s, t);
}
void cmp_ok_streq(const char* s, const char* t) {
printf(in cmp_ok_streq: '%s' '%s'\n, s, t);
}
#define cmp_ok(s, y, o, t) cmp_ok_##y##o(s, t)
int main() {
int ifoo = 42;
int ibar = 43;
static const char* sfoo = foo;
static const char* sbar = bar;
cmp_ok(ifoo, int, eq, ibar);
cmp_ok(sfoo, str, eq, sbar);
return 0;
}
/-\
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
Test labels
I think even better than ok( $expr, name ); or ok( $expr, comment ); is ok( $expr, label ); RJBS points out that comment implies not really worth doing, and I still don't like name because it implies (to me) a unique identifier. We also talked about description, but description is just s overloaded. Thoughts? xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion
The offending line in config/gen/makefiles/dynclasses_pl.in is probably this one: $LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT That CFLAGS doesn't belong there. CFLAGS are intended to be sent to $CC, not to $LD. The command being called here is $LD, which is defined in config/init/data.pl as the Tool used to build shared libraries and dynamically loadable modules. I no longer remember why LD is set to 'ld' on Tru64 -- is it just Ultrix heritage combined with lots of inertia or is it really a sensible setting? Could well be Ultrix heritage, but in any case the parameter syntaxes of Tru64 cc and ld are rather different and non-intersecting, and the cc doesn't automatically pass through unknown parameters to ld (one needs to use the -W for explicit passing.) The cc and ld manpages for example here (blame HP for the awful URLs): http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN1/0607.HTM http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN1/0668.HTM In any case, dynclasses_pl.in is wrong. There should be no CFLAGS there. -- Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Re: [perl #32877] parrot build broken in Tru64, cc/ld confusion
Sam Ruby via RT wrote: Andrew Dougherty wrote: The offending line in config/gen/makefiles/dynclasses_pl.in is probably this one: $LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT That CFLAGS doesn't belong there. CFLAGS are intended to be sent to $CC, not to $LD. The command being called here is $LD, which is defined in config/init/data.pl as the Tool used to build shared libraries and dynamically loadable modules. I can't find anything that fails if this is removed, so I committed the change. Thanks, that helped! - Sam Ruby -- Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Re: C implementation of Test::Harness' TAP protocol
On Tue, Dec 07, 2004 at 03:18:17PM +1100, Andrew Savige wrote:
Good idea Schwern.
These test suites inevitably degenerate into macro crack-pipe
smoking sessions. Lacking 'eval', it is always going to be very
hard work to even get close to Perl's Test::More functionality
and ease-of-use in C.
I don't have a filthy enough mind to make your:
cmp_ok(foo, 'int', '==', bar);
macro work (mainly because '==' is not a valid C identifier).
But I can make this one work:
cmp_ok(foo, int, eq, bar);
pretty easily:
Whoa.
#include stdio.h
void cmp_ok_inteq(int s, int t) {
printf(in cmp_ok_inteq: %d %d\n, s, t);
}
void cmp_ok_streq(const char* s, const char* t) {
printf(in cmp_ok_streq: '%s' '%s'\n, s, t);
}
#define cmp_ok(s, y, o, t) cmp_ok_##y##o(s, t)
int main() {
int ifoo = 42;
int ibar = 43;
static const char* sfoo = foo;
static const char* sbar = bar;
cmp_ok(ifoo, int, eq, ibar);
cmp_ok(sfoo, str, eq, sbar);
return 0;
}
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
Kids - don't try this at--oh, hell, go ahead, give it a whirl...
Re: iterators and functions (and lists)
Larry Wall writes: As far as I can recall we haven't renamed C.specs to anything else yet. That sounds like a challenge ... Smylers
