Re: Return with no expression
Alexey Trofimenko [EMAIL PROTECTED] writes:
I wanna ask, could be there in perl6 any difficulties with
recognizing C:: as part of C... ?? ... :: ... and C:: as
module sigil? Does it involve some DWIM?
Among other things, the ?? will tip off the parser that it's looking
for an expression followed by the :: operator, so under normal
conditions the namespace-oriented :: will never be mistaken for the ::
that goes with ??, because the parser won't be looking for that kind
of :: except after a ??.
It may be though that if you need to put the namespace-oriented ::
between a ?? and its corresponding ::, you might need parentheses:
my $foo = $bar ?? ($baz::wibble) :: $baz::quux; # This is clear and good.
Otherwise...
my $foo = $bar ?? $baz::wibble :: $baz::quux; # This is more questionable.
The parser _might_ try to pair the first :: with the ??, in which case
it's going to get confused -- probably when it tries to figure out
what wibble is, or definitely when it hits the second :: -- and would
then have to either backtrack or complain. (Complaining is easier;
backtracking is DWIMmier and arguably more Perlish in the long run but
could be added in the post-6.0 era if desired; turning a former error
into something valid is usually considered to be backward-compatible.)
But that case -- using the namespace :: between ?? and :: -- should be
the only situation where any ambiguity could arise over ::, and so it
seems reasonable to require (or at least strongly recommend) the
parentheses in that case.
I am assuming here that we don't need to have a unary or binary ??
operator. That would complicate matters rather substantially.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Need some opinions on base behavior
On Mon, 2004-08-23 at 18:13, Dan Sugalski wrote: The unary behavior of the types is reasonably straightforward. What I'm puzzling over right now is the binary behavior. It's the edge cases that are troublesome, of course -- what to do on overflow, and what to do with fractional results. Fractions are an issue mainly with integer division -- in the case of int/int, should the result be an int, or a float of some sort? Just the other day you were wondering about multidispatch on return types. Here's your chance! -- c
Re: GC/DOD API
Dan Sugalski [EMAIL PROTECTED] wrote:
So, being clear here (I hope, though recent history suggests
otherwise) what I want is the API that the GC/DOD system presents to
the rest of the engine. This includes the functions you call to
trigger a DOD or GC sweep, any functions or macros that need to wrap
pointer fetches or stores (if any), what stats are kept, the
functions it exposes to the allocation system, or what parts of the
allocation system it peeks at.
I'm currently thinking of something like that:
Parrot_gc_XXX_init(Interp *) // init GC system XXX
This function has to fill the following function pointers in Carena_base
PObj * arena_base-get_free_object(Interp *, Small_Object_Pool *)
void arena_base-do_dod_run(Interp *, int flags) // normal, lazy ...
void arena_base-de_init_gc_system(Interp *) // free resources
void arena_base-mark_object_live(Interp *, PObj *)
The latter could have a macro form too that e.g. does nothing if the
object is already marked live.
Arena_base is divided into 2 parts: the public part holding these
function pointers and common statistic variables and a private part for
that GC system.
Statistics are basically the same as now, plus an interface to private
statistic data for that GC system.
Finally the GC/DOD system might need a write barrier:
DOD_WRITE_BARRIER(interp, aggregate, old_item, new_item)
For hash keys we might need either two such calls (the 2nd with keys) or
an extended form that both takes keys and PObj*.
I think we can ignore read barriers as these systems are too slow to be
usable.
All the DOD related flags (live, on_free_list) are private to the GC
system. The public part is to set custom_mark, _destroy, array_of_PObjs,
and _needs_early_DOD.
The allocation system is only accessible by -get_free_object(). That's
all. [1]
The current stop-the-world MS DOD is spread over dod.c, headers.c,
and smallobjects.c. Incremental MS has its own allocator but reuses
parts of these files.
The proposed implicit reclamation system would have separate
pobject_lives and mark routines and its own pool allocator that contains
the forward and backward object pointers. Marking an object live is
chaining these pointers so that the PObj* is moved from the
Cfrom_space into the Cto_space.
Comments welcome,
leo
[1] we might consider an explicit opcode Cunused {Px, Sx} though,
which could be emitted for temporariers. I know that we had Cdestroy
some time ago (at that time I thought it would be unneeded ;) But it
could take pressure from the GC system.
Re: NCI and callback functions
Stephane Peiry wrote:
dlfunc P2, P1, 'g_signal_connect_object', 'lptppi'
Whatever you'll try the current scheme is not compatible with this GTK
callback. Parrot needs a PMC as user_data. GTK awaits a GObject.
Parrot stuffs the interpreter and the Sub PMC into user_data and unpacks
that when the callback should run. This is based on the assumption that
the function that establishes the callback takes a (void *) pointer and
*does not* care, what the pointer is pointing to. GTK obviously takes
either a NULL (which isn't usable with Parrot) or a GObject* only.
I can currently only imagine to put the needed information into the
function pointer, which is obviously not that easy:
struct callback_info {
Interp *interpreter;
PMC *sub;
opcode_t code[1];
}
GTK gets the address of C code ). At code[0] ... code[n] is a function
(created NCI-like on-the-fly) that extracts the interpreter (code[-2])
and the Sub (code[-1]) and calls the C function inside Parrot that
actually triggers the call of the callback.
The problem is of course that it would need (minimal) JIT support for
every platform.
(as I understand it, by having p on the signature for the user data,
gtk gets what it wants, a pointer to the user data,
No. 'p' means that GTK get's, what PMC_data(user_data) is pointing to.
I mean understood from this thread (*):
[1] pdd16 states:
Hand over control to the external library. IT IS
IMPORTANT THAT THE INTERPRETER YOU ARE CALLING BACK
INTO IS NOT ACTIVE WHEN THE CALLBACK IS MADE!
That's IMHO a restriction we hardly can fulfill. This is the reason for:
As we don't know, when the callback is invoked, my scheme uses an event
so that its safe to run the PASM code.
that callbacks were indeed installed through an event (that is on its own
thread) so that it wouldnt block nomatter what parrot would be doing at a
given point (say it invoked some long running function in a lib :) unless
there would be a lock on the user data itself.
Yes. But draining the event queue still needs a running Parrot runloop.
Only because the event system is running its own thread does not mean,
that we just can run the code at any time or in parallel with the
foreground runloop.
Callbacks or timer event subroutines are always run by the interpreter
that created that event. This needs a running Parrot.
Otherwise, already thaught of actually unrolling the gtk_main function
and have it handled/implemented within parrot directly (mainly gtk_main
simply loops and waits on the gtk event queue).
That's the way to go.
Thanks,
Stephane
leo
Re: Need some opinions on base behavior
Dan Sugalski [EMAIL PROTECTED] wrote: I'm up for some discussion on this one. I'm tempted to leave integer binary ops integers, I've already outlined that Python as well as Perl6 silently promote to BigInt. I'd rather have Integer as the common base type that implements most of these two languages' integer type. And BTW divistion by zero behavior needs to be nailed down too. ... We could do them all, but... that seems more than a little excessive. Besides the MMD table entries, there'd be a lot of flag checking (or a *really* big set of MMD tables) which is sub-optimal. Yep. leo
Re: Instantiation
[EMAIL PROTECTED] (Aaron Sherman) writes: my $x = Some::Module::That::Defines::A::Class.AUTOLOAD.new(blah); Wow, that's pretty amazing... uh... I think I'd just prefer to do it the old fashioned way. If my suggestion was really that horrific, I withdraw the question. These days, to me, the old fashioned way is just a variation on UNIVERSAL::require. ;) Foo-require-new # UNIVERSAL::require doesn't return Foo, but it (c|sh)ould. -- fimmtiu Sucks really Forth. Ugh.
Re: Return with no expression
Aaron Sherman [EMAIL PROTECTED] wrote: I've always thought that particular bit of sugar was rather dangerous. I'd even prefer a longhand: $foo either 0 or split(); The overloading of 'or' there is (IMHO) far more dangerous than the overloading of '::' being discussed in this thread. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal.
Re: Progressively Overhauling Documentation
* Juerd ([EMAIL PROTECTED]) [040823 19:46]:
David Green skribis 2004-08-23 11:30 (-0600):
One of the selling features (or one of the features that is always sold)
of POD is that you can mix it with your code. Except nobody does, at
least I can't recall that last time I saw a module that did that, and I
don't think I've ever really done that myself. The POD usually sits in
a lump at the end of the file.
Oops, someone starts the holy war (again). Wether you put the docs in
begin or end of the file, or intermixed with the code has a lot to do
with your personal background.
I also think POD should be overhauled completely. I've been thinking
about proposing something like:
sub foo (
) description {
Calculates the foo-intersection of $bar and $xyzzy, optionally
blah blah blah...
} returns Array | undef {
# real code here
}
I found a few suggestions on the list, but... it's oversimplifying
things. Let's state
1) Code is doing things
2) Documentation explains how to use the code (some people explain
the code itself, but that is where the '#' comments are for)
To be able to write code easily, it should be compact enough to get a
good overview. Intermixing code and comment is a bad idea. For
instance in my programs, docs are about 5 times the volume of the
code which would be ugly in the proposed solution.
I prefer to put documentation just before the code. That's the only
way my sloppy mind can preoduce docs which stay in sync with the
intention of the code.
Certainly in larger programs --and always in OO programs-- the
functions methods in a user's document can be organized better
than the order of the code. So: why not support that? What do you
need to be able to do that?
In my case, I had to document my set of distributions. It's 125
packages on the moment, all in OO with up to 4 levels of hierarchy.
In total 988 methods, 174 diagnics explained (errors and warnings)
and 242 examples included. Do you think that you can document
this in POD?
The thing which POD lacks the most, is that it is visual markup
(like B and I in HTML) not logical markup (like STRONG and EM).
So, I added logical markup markers, like =method =overload =function.
Then, =error and =warning clears that up, and =example starts some
docs. =option, =default, =requires describe the OPTIONS
A full method in my code looks like this:
=method showSomeText TEXT, FORMAT, OPTIONS
Print the TEXT in the specified FORMAT.
=option linewidth INTEGER
=default linewidth 70
The maximum number of characters.
=requires language STRING
ISO indication of the languages
=example
$obj-showSomeText('hoi!', '%s', language = 'nl')
=error language required
The language is not use on the moment, but still must be
specified.
=cut
sub showSomeText
{ my ($self, $text, $format, %option) = @_;
my $lw = $option{linewidth} || 70;
my $lang = $option{language} or die language required;
printf $format, $text;
}
The number of options tend to grow when the program gets bigger.
Especially the constructors (like new()) can have many. On some
levels of hierarchy you may want to add new options, or change
their default, or fixate it.
OODoc is the module which processes the MANIFEST file of one or more
modules to produce real documentation out of this. POD is a
simplification, but there is also enough info to produce real HTML
(which optimal hyperlinks). With HTML, you can create templates to
organize the info in the pages (the OODoc distribution come with
examples for very small and for a huge setup).
The documentation fragments are split, joined, grouped, sorted,
formatted and reformatted in various ways to produce the optimal
result for users of the module.
As example, the HTML output for MailBox (and related):
http://perl.overmeer.net/mailbox/html/
Hey! Before you say anything: it is very difficult to give any
form of documentation on close to 1000 methods! Verbosity on
various spots is configurable in the templates.
TO MAKE MY POINT
I do not want to turn people over into using OODoc, that's not the point.
But I would really like Perl6 to have a logical markup (which may or may
not have code syntax, like description{} introduced above).
We (I) need more than only a discription of some options and the method
as a whole. Let's try to get an integrated solution, including the
defaults, diagnistics, and examples.
IMO, user documentation should stay outside the main part of the code
or discription, to keep the code readible.
Any nice solutions for Perl6?
--
MarkOv
drs Mark A.C.J. OvermeerMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Progressively Overhauling Documentation
David Green wrote: In [EMAIL PROTECTED], [EMAIL PROTECTED] (Aaron Sherman) wrote: This bit of POD made me think about POD's lack of tabular formatting, a common idiom in technical documentation. I know POD is still in the wings, as it were, but I wanted to say this before I forget /me flings coffee cup against the wall [no, not Larry!]. Has anyone seen Natural Docs? http://www.naturaldocs.org/ Clayton
Test::DoubleQuotedEntities
I released another testing module yesterday:
http://search.cpan.org/dist/Test-DoubleEncodedEntities/
It detects strings like 'amp;eacute;' in your HTML, meaning it can detect
the case when you've double encoded your entities.
Anyone who spots any errors - please chuck 'em into RT. Patches against
http://unixbeard.net/svn/mark/perlmods/ always welcome.
(oh, and as an aside I released a new Acme::Test::Buffy, with slightly
improved documentation and spelling too - but no one cares about that)
--
#!/usr/bin/perl -T
use strict;
use warnings;
print q{Mark Fowler, [EMAIL PROTECTED], http://twoshortplanks.com/};
Re: Return with no expression
Luke Palmer wrote: Aaron Sherman writes: $foo??0::split() ouch! Yeah, seriously. I mean, what a subtle bug! It would take him hours to figure out went wrong! Sarcasm is an ugly thing. One thing that I just thought of that could be intersting: $foo = 'a' or 'b' My thought was that logic operators could treat a pair specially by testing C.key, but returning C.value... hence no overloading of Cor... it's the way everything works (or everything is overloaded, depending on how you look at it). The problem would be that that C'a' would be evaluated regardless of C$foo's value. There it makes no difference, but here: $foo = a() or b() it's huge... But it seems to me that something like this would be the way to go if you could make it work.
Re: cvs commit: parrot/build_tools build_nativecall.pl
Dan Sugalski [EMAIL PROTECTED] wrote: cvsuser 04/08/23 13:24:37 Modified:build_tools build_nativecall.pl Log: Due to an amazing amount of ineffable evil in hash.c, build_nativecall got redone to use a PerlHash and PMCs instead of the lower-level access system it had, since that wasn't working Well, the Evil wasn't in hash.c, the creation of the hash was bogus. It used a pointer PMC to hold the Hash. So that hash got never marked during DOD. I've now tried s/enum_class_Pointer/enum_class_PerlHash/ and it works as expected. But there is another problem with the original cstring hash. It uses string_to_cstring() and never frees the result. OTOH instead of converting the passed STRING to a cstring we could as well keep your patch, which doesn't need the conversion. For the final version we should probably use CONST_STRING for the signatures, which should be more efficient (with the macro on its own line to work around compiler issues). leo
Concat, Cows Basil
/lurk Hello, I am currently in the early stages of writing a (parrot targeting) compiler for an interpreted language I have been working on/with for the past 4 years. Background: The language (Basil) is basically a functional (ish) language with a C-like syntax that has an implicit concatenation (or list join for efficiency) between each statement. It kinda looks like slightly funny perl with tags in. Thus a large tree of strings is efficiently filtered and a big chunk of text is thrown out at the end. It is used for creating very flexible web templates. The original Basil was created for a company I worked for who wrote everything in C despite doing only web-based work. Perl and PHP were banned. So I wrote a scripting layer that would be handed a symbol table and return a huge chunk of formatted HTML. I guess these days most folks would use XSLT for this. However, I still find XSLT a closed-book and would love to see Basil running on Parrot, being called from a Perl Web Application to spit out formatted HTML. Especially as you could link the two lots of code as one and use the usual calling convention to call the Basil as if it were a standard Perl sub (or Python, etc). Plus Basil has of course grown over the years to be an object-oriented, stand-alone CGI environment that is very good at one thing - making web pages - and I find it hard to work without it. Problem: 1) To create an efficient implementation of Basil I'll need a big PerlArray that is formed by expressions that create PerlStrings or more PerlArrays. At the end the tree of PerlStrings and PerlArrays is iterated over and concatenated together and returned (or just printed out). The PerlArray is just a way of avoiding even more concats plus it allows you to build list stuctures to iterate over.. By using the standard Perl ones I'm hoping to be easy-to-call plus I get the added bonuses of stretchy arrays, int-to-string converstion etc. So my main question is this: Are PerlArrays and PerlStrings an efficient way to go with this? - how much copying goes on within a string concatenation? Iterator? etc ( ie does using COW prevent a deep copy every time I make a concatenation). I tried to make sense of PerlString concatenation and they seem to use string_concat which in turn has two mem_sys_memcopys doing the actual concatenation. 2) If concat isn't the way forward then push probably is (I could just hand back a tree and iterator (as a closure err do I mean continuation?) to the calling function). I take it there are no hidden caveats in using push on a PerlArray? 3) I take it a proper iterator is far more efficient than a loop with a shift in it? eg:- .sub _printall .param PerlArray xs .local PerlString s .local int t loop: unless xs, endloop shift s, xs typeof t, s if t == .PerlArray goto recurse print s branch loop recurse: _printall(s) branch loop endloop: .pcc_begin_return .pcc_end_return .end 4) why doesn't '.' work on a PerlString in IMC? :-) 5) I guess the way-forward for the future is a custom class of very-lazy string-lists that can be concatenated, split, iterated, searched, sorted etc by always doing the least amount of copying they can get away with. But I'll have to get my head round Basil OOP first (and to be honest, PerlArrays PerlStrings have 90% of what I need if they too are very-lazy). Would you agree? I may of course be just plain getting things wrong (I still can't get iterators to work properly).. just trying to get my head round it all.. so feel free to humiliate me (or indeed ignore me).. Anyway - I'm having fun. Thanks for all your hard work so far It's most appreciated. Any flames, advice encouragement would be gratefully accepted.. Cheers, Sambeau [EMAIL PROTECTED] lurk
Re: cvs commit: parrot/build_tools build_nativecall.pl
At 12:03 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: cvsuser 04/08/23 13:24:37 Modified:build_tools build_nativecall.pl Log: Due to an amazing amount of ineffable evil in hash.c, build_nativecall got redone to use a PerlHash and PMCs instead of the lower-level access system it had, since that wasn't working Well, the Evil wasn't in hash.c, the creation of the hash was bogus. It used a pointer PMC to hold the Hash. So that hash got never marked during DOD. I've now tried s/enum_class_Pointer/enum_class_PerlHash/ and it works as expected. Ah, I was blinded by all the evil in hash.c to the fact that the problem wasn't actually there. :) But there is another problem with the original cstring hash. It uses string_to_cstring() and never frees the result. OTOH instead of converting the passed STRING to a cstring we could as well keep your patch, which doesn't need the conversion. Works. While I'm not sure there was a huge scaling issue with the original code, it was nasty, and potentially could be problematic for large library registration, so we might as well leave it as it is now. For the final version we should probably use CONST_STRING for the signatures, which should be more efficient (with the macro on its own line to work around compiler issues). Sounds like a plan. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Need some opinions on base behavior
At 11:05 AM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: I'm up for some discussion on this one. I'm tempted to leave integer binary ops integers, I've already outlined that Python as well as Perl6 silently promote to BigInt. I'd rather have Integer as the common base type that implements most of these two languages' integer type. And BTW divistion by zero behavior needs to be nailed down too. And inf handling too. Okay, here's my thought. Basic PMC operations which result in a division by zero, or operations which'd produce either an infinite or not-a-number result, throw an exception. The default MMD functions for math will do this, and folks who want a different result can override the MMD table. (Which could be made scoped, if we really wanted to, though I'm not sure I do) This doesn't address the issue of low-level ops with numbers, but we can get there later. I'm thinking now that multiplication of integers should upgrade to a float (which is large enough to hold the result with no loss of precision), division of integers should return a bignum (or a bigrat), and all float operations should produce floats. The destination PMC type can downconvert if it wants, so: Pint = Pint / Pint would produce a bignum which'd then be converted to an integer as part of the store. (I'm not that tied to the production of a bignum though. Feel free to argue me out of it if you want) As for rounding, I'm open to changes there too. Standard for computing is round-to-zero, since it's easy (drop the fractional part) but I was always taught round-to-closest-int. Too many physical sciences classes, I expect. Either way's arguably correct, and arguably horribly wrong, so I can see it being a big tossup there. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Need some opinions on base behavior
Dan~ I'm thinking now that multiplication of integers should upgrade to a float (which is large enough to hold the result with no loss of precision), division of integers should return a bignum (or a bigrat), and all float operations should produce floats. The destination PMC type can downconvert if it wants, so: Pint = Pint / Pint Are you sure that you mean PInt * Pint - Pfloat or do you mean to say PInt * Pint - Pbigint Maybe I had been debugging too long and am just brainfried. But if you could summarize your current thinking in the form bigint / bigint - bigrat int / int - float It would facilitate my following your exact plans. Thanks, Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Low-level math op behavior
Okay, since we're finally talking defined math semantics, lets talk the low-level ops. All our math ops right now just quietly do their thing. If values wrap, truncate, or otherwise fuzz out, we don't do anything special. This is fine, and fast, and what many languages want. It is, however, reasonable to have math ops that are a bit higher-level -- basically throwing exceptions if something exceptional happened rather than quietly proceeding. What I'm thinking is that we add an O or X (or E, I don't care. I suppose we could get more verbose there too) variant to the basic math ops which checks the result for validity and throws an exception on something exceptional happening. Only for the basics (add, subtract, multiply, divide, possibly modulus) but it ought to be useful. Folks think it's worth it? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Need some opinions on base behavior
At 11:29 AM -0400 8/24/04, Matt Fowles wrote: Dan~ I'm thinking now that multiplication of integers should upgrade to a float (which is large enough to hold the result with no loss of precision), division of integers should return a bignum (or a bigrat), and all float operations should produce floats. The destination PMC type can downconvert if it wants, so: Pint = Pint / Pint Are you sure that you mean PInt * Pint - Pfloat or do you mean to say PInt * Pint - Pbigint Bah, I was mis-thinking. I had it in my head that a float could hold the worst-case size of an int*int, but it can't. Bignum's the thing here, I think. Or either an int or bignum, depending on the size of the result. (No bigints. It's all bignums. We may do bigrats, but I doubt it) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Return with no expression
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Aaron Sherman [EMAIL PROTECTED] wrote:
I've always thought that particular bit of sugar was rather dangerous.
I'd even prefer a longhand:
$foo either 0 or split();
The overloading of 'or' there is (IMHO) far more dangerous than the
overloading of '::' being discussed in this thread.
Not necessarily. You're assuming that Ceither in a ternary operator. It
could be a binary operator, defined as {eval $RHS if $LHS; return $LHS}. For
that interpretation, one might choose a different name (e.g. Cimplies).
We could actually define ?? as a binary operator in much the same way.
Dave.
Re: Need some opinions on base behavior
At 4:26 PM +0100 8/24/04, Nicholas Clark wrote: On Tue, Aug 24, 2004 at 10:49:37AM -0400, Dan Sugalski wrote: As for rounding, I'm open to changes there too. Standard for computing is round-to-zero, since it's easy (drop the fractional part) but I was always taught round-to-closest-int. Too many physical sciences classes, I expect. Either way's arguably correct, and arguably horribly wrong, so I can see it being a big tossup there. I'd be confused if a computer language didn't truncate towards zero. Despite being a physical scientist by training. Fair enough -- we'll round to zero then. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Concat, Cows Basil
Sam Phillips [EMAIL PROTECTED] wrote: Problem: 1) To create an efficient implementation of Basil I'll need a big PerlArray that is formed by expressions that create PerlStrings or more PerlArrays. How big is big? So my main question is this: Are PerlArrays and PerlStrings an efficient way to go with this? - how much copying goes on within a string concatenation? There ar basically 2 forms of concat, one inplace and the 2nd creating a new string. The former is much more efficient the more you are appending small items to the first string. ... Iterator? Iteration doesn't involve any copying. ... etc ( ie does using COW prevent a deep copy every time I make a concatenation). COW doesn't help in the case of concat. COW is mainly useful for extracting substrings. I tried to make sense of PerlString concatenation and they seem to use string_concat which in turn has two mem_sys_memcopys doing the actual concatenation. Well, that depends. Inplace needs one only. 2) If concat isn't the way forward then push probably is (I could just hand back a tree and iterator (as a closure err do I mean continuation?) to the calling function). I take it there are no hidden caveats in using push on a PerlArray? Push is fine. 3) I take it a proper iterator is far more efficient than a loop with a shift in it? Yep. 4) why doesn't '.' work on a PerlString in IMC? :-) It works - at least partially - inplcace is missing ;) $ cat c.pir .sub main $P0 = new PerlString $P1 = new PerlString $P2 = new PerlString $P0 = a $P1 = b $P2 = $P0 . $P1 # note the space before the dot print_item $P2 # $P0 .= $P1 # print_item $P0 print_newline end .end $ parrot c.pir ab 5) I guess the way-forward for the future is a custom class of very-lazy string-lists that can be concatenated, split, iterated, searched, sorted etc You might have a look at cord which can be found e.g. in the gcc sources under the boehm-gc subdirectory. Sambeau leo
Re: Low-level math op behavior
At 11:29 -0400 8/24/04, Dan Sugalski wrote: What I'm thinking is that we add an O or X (or E, I don't care. I suppose we could get more verbose there too) variant to the basic math ops which checks the result for validity and throws an exception on something exceptional happening. For floating point operations, and that's pretty much all perl 5 seems to do, the not a number or NaN capability of the floating point arithmetic units is pretty good. Correctly ignored, an error condition can resolve itself in a later formula. An underflow, for instance, when added to a legitimate floating point number is not an error. It's just a no-op. Even a divide by zero error can be a non-event. Things like real square roots of negative numbers are different. Perl6 could define some of its own NaN's if it seems appropriate. Perhaps a NaN meaning undef. A simple way to identify and categorize a NaN might be nice. -- -- On the eighth day, about 6 kiloyears ago, the Lord realized that free will would make man ask what existed before the Creation. So He installed a few gigayears of history complete with a big bang and a fossilized record of evolution. --
RE: Low-level math op behavior
So, would it have things like $i = $j /E $k $i = $j %E $k which would both throw and exception if $k == 0 whereas $i = $j / $k $i = $j % %k would not throw an exception and would instead return NaN -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 11:29 AM To: [EMAIL PROTECTED] Subject: Low-level math op behavior Okay, since we're finally talking defined math semantics, lets talk the low-level ops. All our math ops right now just quietly do their thing. If values wrap, truncate, or otherwise fuzz out, we don't do anything special. This is fine, and fast, and what many languages want. It is, however, reasonable to have math ops that are a bit higher-level -- basically throwing exceptions if something exceptional happened rather than quietly proceeding. What I'm thinking is that we add an O or X (or E, I don't care. I suppose we could get more verbose there too) variant to the basic math ops which checks the result for validity and throws an exception on something exceptional happening. Only for the basics (add, subtract, multiply, divide, possibly modulus) but it ought to be useful. Folks think it's worth it? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Test::Harness with modules that output to STDOUT
I am attempting to write tests (using whichever Tests::...) for a module that will use Test::Harness. The module outputs to STDOUT (it just does). Now, in theory, Test::Harness currently ignores anything that doesn't start with ok or not ok, but for whatever reason, when I have no_plan, it can't handle it. Ok, I can deal with that - I can make a plan. HOWEVER, from the POD for Test::Harness: Any other output Test::Harness sees it will silently ignore BUT WE PLAN TO CHANGE THIS! If you wish to place additional output in your test script, please use a comment. Ok, what's the elegent way to ignore/dispose of the output the tested module produces? So far, I've come up with 2 ideas: 1. Hack something up to snatch away STDOUT and hope Test::More handles it correctly. 2. Use Test::Builder and direct the tests output to some file... But there has to be some better way, right? Thanks! --Peter
RE: Low-level math op behavior
At 11:34 AM -0400 8/24/04, Butler, Gerald wrote: So, would it have things like $i = $j /E $k $i = $j %E $k which would both throw and exception if $k == 0 whereas $i = $j / $k $i = $j % %k would not throw an exception and would instead return NaN That'd be the plan, yeah. $i wouldn't get NaN if $i is an integer, though I expect everyone figured that one out. :) -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 11:29 AM To: [EMAIL PROTECTED] Subject: Low-level math op behavior Okay, since we're finally talking defined math semantics, lets talk the low-level ops. All our math ops right now just quietly do their thing. If values wrap, truncate, or otherwise fuzz out, we don't do anything special. This is fine, and fast, and what many languages want. It is, however, reasonable to have math ops that are a bit higher-level -- basically throwing exceptions if something exceptional happened rather than quietly proceeding. What I'm thinking is that we add an O or X (or E, I don't care. I suppose we could get more verbose there too) variant to the basic math ops which checks the result for validity and throws an exception on something exceptional happening. Only for the basics (add, subtract, multiply, divide, possibly modulus) but it ought to be useful. Folks think it's worth it? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
On Tue, 24 Aug 2004, Dan Sugalski wrote: 6) Division of two ints produces a bignum Surely it should only produce a bignum as a last resort. For instance, shouldn't: 4 / 3 produce a float? Also, what about a case like: 4 / 2 Does that produce an int, a float or a bignum? 9) Any operation with a bignum produces a bignum Should there be some way to test whether a bignum can be downgraded into a float? Simon
RE: Numeric semantics for base pmcs
At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs Okay, so: 1) We round to zero when going from float to int 2) Overflows, underflows, and division by zero throws an exception 3) All-float operations produce floats 4) Addition and subtraction of ints produces an int 5) Multiplication of two ints produces a bignum or an int, depending on the result 6) Division of two ints produces a bignum 7) Strings are treated as floats for math operations 8) Any operation with a float and an int, string, or bool produces a float 9) Any operation with a bignum produces a bignum 10) The destination PMC is responsible for final conversion of the inbound value That seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Test::DoubleQuotedEntities
On Tue, Aug 24, 2004 at 10:38:50AM +0100, Mark Fowler wrote: I released another testing module yesterday: http://search.cpan.org/dist/Test-DoubleEncodedEntities/ I note that that's not the name in the subject of your mail. I hope this is the right one. :-) (oh, and as an aside I released a new Acme::Test::Buffy, with slightly improved documentation and spelling too - but no one cares about that) Says who? dha -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ What kind of marathon crack binge would cause you believe this? - Mark Rogaski
Re: Numeric semantics for base pmcs
Dan~ -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs 10) The destination PMC is responsible for final conversion of the inbound value I know there has been a lot of grumbling in the past about the need to create PMCs to be the LHS of operations. I don't have a real suggestion here, but I just wanted to draw attention to this recurring theme, since now would be a good time to deal with it. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
RE: Numeric semantics for base pmcs
Shouldn't 4 also have potential to produce BigInt? -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs Okay, so: 1) We round to zero when going from float to int 2) Overflows, underflows, and division by zero throws an exception 3) All-float operations produce floats 4) Addition and subtraction of ints produces an int 5) Multiplication of two ints produces a bignum or an int, depending on the result 6) Division of two ints produces a bignum 7) Strings are treated as floats for math operations 8) Any operation with a float and an int, string, or bool produces a float 9) Any operation with a bignum produces a bignum 10) The destination PMC is responsible for final conversion of the inbound value That seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
RE: Numeric semantics for base pmcs
Oops. I meant BigNum. -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:47 PM To: Butler, Gerald; '[EMAIL PROTECTED]' Subject: RE: Numeric semantics for base pmcs At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs Okay, so: 1) We round to zero when going from float to int 2) Overflows, underflows, and division by zero throws an exception 3) All-float operations produce floats 4) Addition and subtraction of ints produces an int 5) Multiplication of two ints produces a bignum or an int, depending on the result 6) Division of two ints produces a bignum 7) Strings are treated as floats for math operations 8) Any operation with a float and an int, string, or bool produces a float 9) Any operation with a bignum produces a bignum 10) The destination PMC is responsible for final conversion of the inbound value That seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Benchmark Stuff
--- Sebastian Riedel [EMAIL PROTECTED] wrote: Take a look at tools/dev/parrotbench.pl It already does most of the things you want, you just have to parse it's output and feed it to your database. Cheers, Sebastian parrotbench.pl didn't correctly handle hyphens in names (it was using \w char class) - fixed parrotbench.pl doesn't properly handle foo.pasm and foo.imc, it quietly discards one parrotbench.pl only provided a single regex for you to specify which benchmarks to run. This made it difficult to say, run all but x. I added a skip benchmarks that match regex support. I also modified the regex to parse the configuration file (death to .*). Unfortunately, I also added some stuff that really doesn't need to be there to make my life easier. Here is the modified parrotbench script along with the new data collection script and the script to make it into a web page. I don't know what kind of layout/data would be useful to people so let me know if you want something else. I will update every Tuesday morning. Cheers Joshua Gatcomb a.k.a. Limbic~Region __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail parrotbench.gat Description: parrotbench.gat benchit.pl Description: benchit.pl webit.pl Description: webit.pl
Re: Benchmark Stuff
--- Joshua Gatcomb [EMAIL PROTECTED] wrote: Here is the modified parrotbench script along with the new data collection script and the script to make it into a web page. I don't know what kind of layout/data would be useful to people so let me know if you want something else. I will update every Tuesday morning. I guess it helps if I share the web page to look at: http://perlmonk.org/~limbicregion/parrot_bench.html Cheers Joshua Gatcomb a.k.a. Limbic~Region ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com
Re: Test::DoubleQuotedEntities
On Tue, Aug 24, 2004 at 01:51:12PM -0400, David H. Adler wrote: (oh, and as an aside I released a new Acme::Test::Buffy, with slightly improved documentation and spelling too - but no one cares about that) Says who? *I* care. And you have no idea how stupid I felt submitting an RT on that module, either. K. -- Kirrily 'Skud' Robert - [EMAIL PROTECTED] - http://infotrope.net/ There's too much blood in my caffeine system.
How to build ??/:: without ::
On Tue, 2004-08-24 at 08:24, Aaron Sherman wrote:
$foo = 'a' or 'b'
I was too focused on the idea of C??/C:: as a pair-like construct,
and I missed what should have been obvious:
a ?? b :: c
IS
given a { when true { b } default { c } }
Which S4 tells us is:
a - $_ { when true { b } default { c } }
If you take the C?? out of the ternary expression and make it a
generic, binary logical operator that tests the topic for truth and
executes lhs if topic is true and rhs if it is false, then that becomes:
a - $_ { b ?? c }
And further S4 tells us that that can become:
a ~~ b ?? c
because C~~ automatically topicalizes its lhs for its rhs.
So, with the very minor change of making C?? binary instead of
ternary, it turns out that we ALREADY HAVE a replacement for C?:, and
didn't realize it!
C?? would also be darn useful in all sorts of places, as this lets you
write things like:
given a {
b ?? c;
say We did the first step;
d ?? e;
say We did the second step;
}
etc. My $0.02, but I think this is the way to go, and the whole C::
thing just fades into historical note land.
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
Re: Numeric semantics for base pmcs
At 1:39 PM -0400 8/24/04, Simon Glover wrote: On Tue, 24 Aug 2004, Dan Sugalski wrote: 6) Division of two ints produces a bignum Surely it should only produce a bignum as a last resort. For instance, shouldn't: 4 / 3 produce a float? A float or a bignum, both are reasonable. There's that whole issue of speed, though. (And to some extent precision) Also, what about a case like: 4 / 2 Does that produce an int, a float or a bignum? Good question. 9) Any operation with a bignum produces a bignum Should there be some way to test whether a bignum can be downgraded into a float? Probably, yeah. At the moment I'm somewhat loathe to drop down to floats because of the loss of precision. The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. I don't have a choice I think is right, though I'm leaning towards an answer that's got a consistent output type, though I'm not sure what that type should be. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. Tangentially related: will promotion be suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for 64-bit support (whatever that may mean) in Parrot? -John
RE: Benchmark Stuff
Here is the modified parrotbench script along with the new data collection script and the script to make it into a web page. I don't know what kind of layout/data would be useful to people so let me know if you want something else. I will update every Tuesday morning. I guess it helps if I share the web page to look at: http://perlmonk.org/~limbicregion/parrot_bench.html good stuff. it seems that there are many more benchmark tests than runtimes. perhaps switching the axes would make it easier to read (or maybe it's just my preference for vertical scrolling over horizontal.) also, highlighting the lowest value for each bench test (perhaps by adding a little background color) might make the output easier to parse, at a glance. hrmm. looking some more, it seems 'total' is hard to interpret, since some runtimes don't run some bench tests. maybe also listing '# tests run', and 'total # tests' alongside the 'total' would help in the interpretation. ~jerry ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
Re: Numeric semantics for base pmcs
At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 6) Division of two ints produces a bignum Where bignum means both bigger than 32-bit integer and rational number? So 4 / 2 == Bignum(2/1) which doesn't get automatically downgraded to a normal int. Ok. 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. /s
Re: Numeric semantics for base pmcs
Dan Sugalski [EMAIL PROTECTED] wrote: At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) Pardon, sir? leo
Re: Numeric semantics for base pmcs
Dan Sugalski [EMAIL PROTECTED] wrote: Okay, so: 4) Addition and subtraction of ints produces an int ??? 5) Multiplication of two ints produces a bignum or an int, depending on the result Why that difference? Int op Int gives Bigint or Int (whatever fits) for op in (abs, neg, add, sub, mul) And don't forget corner cases. What about bitwise ops BTW, e.g. left shift. That seem reasonable? Else yes. leo
Re: Numeric semantics for base pmcs
At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) Pardon, sir? We've got the big number code, but I don't see much reason to distinguish between integers and non-integers at this level -- the only difference is exponent twiddling. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
At 8:56 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, so: 4) Addition and subtraction of ints produces an int ??? Yeah, that was wrong. Later fixed. :) 5) Multiplication of two ints produces a bignum or an int, depending on the result Why that difference? At this point I'm tempted to not have the difference and unconditionally produce a bignum. Int op Int gives Bigint or Int (whatever fits) for op in (abs, neg, add, sub, mul) And don't forget corner cases. I think we've got the corner cases dealt with. I think... What about bitwise ops BTW, e.g. left shift. Gah! Haven't gotten there yet. We're still working on basic math... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote: At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 6) Division of two ints produces a bignum Where bignum means both bigger than 32-bit integer and rational number? So Yes. 4 / 2 == Bignum(2/1) which doesn't get automatically downgraded to a normal int. Ok. 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. I'm still not sure about doing dynamic down-typing (or whatever it's called) to get the tighest possible type. I'm getting the distinct feeling that it's what most people want, though. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Return with no expression
On Tue, 2004-08-24 at 11:50, Dave Whipp wrote:
You're assuming that Ceither in a ternary operator. It
could be a binary operator, defined as {eval $RHS if $LHS; return $LHS}. For
that interpretation, one might choose a different name (e.g. Cimplies).
We could actually define ?? as a binary operator in much the same way.
Yep, and since ~~ auto-topicalizes its lhs for its rhs, your binary ??
is all you need. I wish I'd seen your message before I sent my recent
one, as I would have just started from there.
Precedence worries me a bit, since I don't know how ~~ and ?? would fit,
but it's certainly nice to have this construct use a generic Perl 6
operator like ~~ and not have to have any ternary constructs in the
language.
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
Re: Return with no expression
Dave Whipp [EMAIL PROTECTED] wrote:
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
The overloading of 'or' there is (IMHO) far more dangerous than the
overloading of '::' being discussed in this thread.
Not necessarily. You're assuming that Ceither in a ternary operator. It
could be a binary operator, defined as {eval $RHS if $LHS; return $LHS}. For
that interpretation, one might choose a different name (e.g. Cimplies).
We could actually define ?? as a binary operator in much the same way.
Even if Ceither is defined as a binary operator such that Cor
isn't truly overloaded, it's *semantically* overloaded in a dangerous
way. (That is, to humans, the Ceither/Cor construct has very
different behavior from a plain Cor, even though to the computer
it's just a couple of binary operators and some precedence.)
Further, Ceither/Cor is more dangerous because it will fail
silently (by branching down the wrong path), while C??/C:: will
usually fail loudly (by throwing a syntax error at comple time or by
throwing a subroutine not found error at runtime).
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
There is no cabal.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
There is no cabal.
Re: Numeric semantics for base pmcs
On Tue, Aug 24, 2004 at 03:08:21PM -0400, Dan Sugalski wrote: At 8:56 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: 5) Multiplication of two ints produces a bignum or an int, depending on the result Why that difference? At this point I'm tempted to not have the difference and unconditionally produce a bignum. 2 * 3 give a bignum. That feels evil. Except that the way that $a = 2 * 3 will work is that the assignment of the bignum temporary to $a will cause $a to drop it back to an int (for most languages' choice of target PMC) ? Nicholas Clark
Re: Numeric semantics for base pmcs
Nick writes: 2 * 3 give a bignum. That feels evil. Except that the way that $a = 2 * 3 will work is that the assignment of the bignum temporary to $a will cause $a to drop it back to an int (for most languages' choice of target PMC) ? Dan, any feeling about RISC vs. CISC? Because to me, this seems like a good place to punt, and provide two, maybe three mults: multbig: returns bignum, relies on PMC smart autounboxing multint: returns int-or-die, no unboxing multsmallest: returns parrot-defined 'smallest type that fits', balancing speed vs. compiler/interpreter autoboxing/ autounboxing hinting Most people in Perl would be happy with multbig, because frankly they don't care that their math takes .1 ms rather than .0001 ms (or whatever). But the set of people that really would rather have superfast math could drop over to multint. And, a notional Perl6 optimizing compiler could use multsmallest when it detects the conditions are right. Another concern besides speed might be sizeof(PMC) for each of the options...some of the genome/nasa guys could get kinda twitchy if bignum is 1k per, etc., etc. F.
Re: Return with no expression
On Tue, 2004-08-24 at 15:55, Adam D. Lopresto wrote:
On Tue, 24 Aug 2004, Aaron Sherman wrote:
Yep, and since ~~ auto-topicalizes its lhs for its rhs, your binary ??
is all you need. I wish I'd seen your message before I sent my recent
one, as I would have just started from there.
Precedence worries me a bit, since I don't know how ~~ and ?? would fit,
but it's certainly nice to have this construct use a generic Perl 6
operator like ~~ and not have to have any ternary constructs in the
language.
My problem is that then you can't get to the original topic. I think too much
topic-clobbering will be confusing.
say chars($_) 70 ~~ abbreviate($_) ?? $_; #oops, prints the length
You don't HAVE to use auto-topicalization. You CAN always write it
long-hand if you find that confusing:
for @words - $word {
given ($chars($word) 70) - $toolong {
say abbreviate($word) ?? $word;
}
}
But, I find:
for @words - $word {
say $word ~~ abbreviate($word) ?? $word;
}
much simpler! Overall, I would discourage the use of C$_ as topic in
most situations. We spent so long in Perl 5 wanting the ability to
default to whatever variable we wanted, to keep using C$_ in the
general case now that we have that is kind of a step backwards. I think
Perl 6 programmers are going to have to treat C$_ as more of a
second-class citizen and rely more on named topics.
Either way, the core idea that the third expression in C?: in Perl 6
should be the current topic is, I think, well worth using.
--
781-324-3772
[EMAIL PROTECTED]
http://www.ajs.com/~ajs
OT: SPF problem with the list?
Please let me know who is appropriate for this, and whatever you do, please don't reply to / CC the list. We don't need to bog down the works with discussion of spam filtering. I'm noticing that mail from perl6-* is showing up with this header: Received-SPF: softfail (mail.ajs.com: transitioning domain of perl.org does not designate 63.251.223.186 as permitted sender) client-ip=63.251.223.186; [EMAIL PROTECTED]; helo=lists.develooper.com; That is added by my local SPF-checker. It seems that x6.develooper.com [63.251.223.186], which is sending these out this mail is not in perl.org's SPF record (which would be fine if perl.org had no SPF record, but it does). There's an easy way to say and all of this other domain's MXes too in SPF, which is probably what was intended. This is causing my spam filtering to slightly bump p6 mail toward spam (though so far, I don't think I've gotten any false positives). I take a somewhat proprietary interest in perl.org working well for various historical/sentimental reasons, so I'd be happy to help with any debugging / diagnosing of this if that would help. -- 781-324-3772 [EMAIL PROTECTED] http://www.ajs.com/~ajs
Re: Numeric semantics for base pmcs
At Tue, 24 Aug 2004 15:19:52 -0400, Dan Sugalski wrote: At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote: At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. I'm still not sure about doing dynamic down-typing (or whatever it's called) to get the tighest possible type. I'm getting the distinct feeling that it's what most people want, though. :) This doesn't have to involve dynamic down-typing, only a string-to-numeric converter that returns the most specific type. After that, operations between two numeric objects are welcome to do whatever they want. I actually agree with you that it's just not worth it to check for possible down-conversions. /s
Re: OT: SPF problem with the list?
On Aug 24, 2004, at 2:45 PM, Aaron Sherman wrote: Please let me know who is appropriate for this, and whatever you do, please don't reply to / CC the list. We don't need to bog down the works with discussion of spam filtering. I don't think your SPF implementation is doing the right thing. I'll reply without CC'ing the list. - ask -- http://www.askbjoernhansen.com/
Re: Return with no expression
On 24 Aug 2004, at 22:14, Aaron Sherman wrote:
You don't HAVE to use auto-topicalization. You CAN always write it
long-hand if you find that confusing:
for @words - $word {
given ($chars($word) 70) - $toolong {
say abbreviate($word) ?? $word;
}
}
But, I find:
for @words - $word {
say $word ~~ abbreviate($word) ?? $word;
}
much simpler! Overall, I would discourage the use of C$_ as topic in
most situations. We spent so long in Perl 5 wanting the ability to
default to whatever variable we wanted, to keep using C$_ in the
general case now that we have that is kind of a step backwards.
But you are re-creating the same problem that we had in Perl 5.
By only allowing $_ to decide which expression to evaluate you are
prohibiting the use of anything that acts on the default topic of
the enclosing block in those expressions. This is exactly the problem
of nested maps etc. in Perl 5.
Don't get me wrong, I like the idea. But it does not come without its
own set of limitations.
Graham.
Re: Return with no expression
On Tue, 24 Aug 2004, Aaron Sherman wrote:
On Tue, 2004-08-24 at 11:50, Dave Whipp wrote:
You're assuming that Ceither in a ternary operator. It
could be a binary operator, defined as {eval $RHS if $LHS; return $LHS}. For
that interpretation, one might choose a different name (e.g. Cimplies).
We could actually define ?? as a binary operator in much the same way.
Yep, and since ~~ auto-topicalizes its lhs for its rhs, your binary ??
is all you need. I wish I'd seen your message before I sent my recent
one, as I would have just started from there.
Precedence worries me a bit, since I don't know how ~~ and ?? would fit,
but it's certainly nice to have this construct use a generic Perl 6
operator like ~~ and not have to have any ternary constructs in the
language.
My problem is that then you can't get to the original topic. I think too much
topic-clobbering will be confusing.
say chars($_) 70 ~~ abbreviate($_) ?? $_; #oops, prints the length
--
Adam Lopresto
http://cec.wustl.edu/~adam/
[MacGyver] is the Martha Stewart of action.
--Patrick J. Mooney
Re: Test::Harness with modules that output to STDOUT
On 24 Aug 2004, at 16:04, Peter Kay wrote: I am attempting to write tests (using whichever Tests::...) for a module that will use Test::Harness. The module outputs to STDOUT (it just does). You might find http://www.mail-archive.com/[EMAIL PROTECTED]/msg01690.html of interest. [snip] So far, I've come up with 2 ideas: 1. Hack something up to snatch away STDOUT and hope Test::More handles it correctly. [snip] This is what I normally do. Test::Builder dups the filehandles at compile time so it's perfectly safe as long as T::B loads before your filehandle munging occurs. Cheers, Adrian
Re: Test::Harness with modules that output to STDOUT
--- Peter Kay [EMAIL PROTECTED] wrote:
Ok, what's the elegent way to ignore/dispose of the output the tested
module produces?
What I do whenever this happens is to move the printing code to a subroutine or method
and
override that to capture the output. So if I have something like this:
sub Foo::_print {
print shift;
}
In my test, I have something like this:
my $_print;
*Foo::_print = sub { $_print = shift };
is($_print, $expected, Foo::_print output the correct data);
This has several benefits. Not only do you not worry about how Test::Harness will
react, you also
have the ability to test the printed data, something which is frequently not done.
Also, I've
found that by refactoring such functionality into one subroutine, I later have a
convenient place
to alter the behavior, if necessary, rather than hunt through the code. I've found
this to be
very useful if I need to send the data to different destinations or add behavior such
as emailing
critical error messages or reports.
If you hate using typeglobs:
use Sub::Override; # disclaimer: I wrote it.
my $_print;
my $override = Sub::Override-new('Foo::_print' = sub { $_print = shift });
(You can later restore the subroutine, if needed)
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
