>> print "date" if $var.isa(int);
>> print "date" if isa $var: int;
>> print "date" if $var ~~ int;
>>
>> Those should all work. IMO the first reads the best. That will also
>> work for Cs, as C is a subclass of C (I think).
>
> These only determine if $var is of type int or Int. How
> (1)
>
> my size(4), human DNA ($alpha, $beta, $gamma, $delta ) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
>
> is so perfect, vs
>
> (2)
>
> my DNA ($alpha, $beta, $gamma, $delta) is human, size(4) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
If I were concerned about this, I would either do it the way
Now, I might be stupid, but I keep asking myself what you would need a
property for in this example. To me, it totally confuses the
underlying structure. When was the last time you asked an integer to
identify itself as a valid credit card number?
It is _not_ a property of the integer that it is
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #19729]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19729 >
This patch adds JIT support for restart and similar ops.
--
Jason
-- attachment 1
Murat Ünalan wrote:
And that shows precisely why Perl 6 does it the other way.
Prepending extended properties like that makes the
declaration almost unreadable. Because it separates the
I shoot in my own foot. My example was extremly bad. Give me a better
try:
(1)
my size(4), human DNA ($
On Sun, 5 Jan 2003, Murat Ünalan wrote:
> > Properties *can* be smart-matched:
> >
> > print "creditcard" if $var.prop().{CreditCard} ~~ 'VISA';
> > or:
> > print "creditcard" if $var.prop{CreditCard} ~~ 'VISA';
> > or:
> > print "creditcard" if $var.CreditCard ~~ 'VISA';
> >
> I think
Steve Fink wrote:
It's late here, but I'll try an answer ;-)
... I was thinking that it might be okay
to say that any single operation (even those that could conceivably
trigger many other operations) must fit all of its allocations within
the total amount of available memory when it starts.
> And that shows precisely why Perl 6 does it the other way.
> Prepending extended properties like that makes the
> declaration almost unreadable. Because it separates the
I shoot in my own foot. My example was extremly bad. Give me a better
try:
(1)
my size(4), human DNA ($alpha, $beta, $ga
> Why should you care? Perl 6 isn't going to be that strictly
> typed, is it?
Not even optional ?
Murat
On Jan-04, Gopal V wrote:
> So, workarounds are possible .. and neither the host nor the compiler
> is there yet ;) ...
Good point -- we'd better speed up on this Parrot stuff, so we can
push more of the really hard things onto you compiler guys. ;)
On Jan-02, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >Another (maybe silly) possibility suggested itself to me based on a
> >private mail re: infant mortality from Thomas Whateley: could we try
> >optimistic allocations?
>
>
> > if (alloc_object() == NULL) {
> >undo everything
Murat Ünalan wrote:
Then you're just not thinking in enough simultaneous dimensions:
my int ($pre, $in, $post) is constant
= (0,1, 2);
This could been written faster in a single line, without decorating with
extra newline+tab+tab+tab+tab:
It's source code. Four extra
> Properties *can* be smart-matched:
>
> print "creditcard" if $var.prop().{CreditCard} ~~ 'VISA';
> or:
> print "creditcard" if $var.prop{CreditCard} ~~ 'VISA';
> or:
> print "creditcard" if $var.CreditCard ~~ 'VISA';
>
> Damian
>
I think this is similar to "John Williams" su
FYI
--- Forwarded Message
Date:05 Jan 2003 00:41:55 +
From:Josh Wilmes <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: cvs commit: parrot/tools/dev rebuild_miniparrot.pl
cvsuser 03/01/04 16:41:54
Modified:config/auto jit.pl sizes.pl
config/gen/m
> Yes, but
>
> my int $foo is constant;
>
> Is self-explanatory for many language-speakers. If I recall,
> the set of cross-language-programmers is a proper subset of
> the set of language-speakers. It is clear which is clearer :).
You do "proof by best case scenario". In my previous posti
> > where the distance grows with property-syntax-complexity.
>
> Oh, *that's* what you're concerned about?
> Then you're just not thinking in enough simultaneous dimensions:
>
>
> my int ($pre, $in, $post) is constant
> = (0,1, 2);
This could been written faster i
Murat Ünalan wrote:
print "creditcard" if $var ~~ CreditCard( 'VISA' );
Brought to a point: Properties could be also smart matched.
Properties *can* be smart-matched:
print "creditcard" if $var.prop().{CreditCard} ~~ 'VISA';
or:
print "creditcard" if $var.prop{CreditCard} ~~ 'VISA';
or:
pr
On Sat, 4 Jan 2003, Murat Ünalan wrote:
>
> print "creditcard" if $var == CreditCard( 'VISA' );
>
> wich should do a mod10 on $var and then match a regex or something.
>
> I think one could say "CreditCard( 'VISA' )" is then the property. And
> after
> reading further seeing it could be smart matc
Murat Ünalan wrote:
Oh yes. Psycho-affectivly it is disturbing seeing the group of variables
($pre, $in, $post) teared apart from the initilizing (0..2). This is my
second step in the brain when analysing it. And this is prone to
problems like in:
my int ($one, $two, $three, $four, $five, $six,
Luke Palmer wrote:
> In Perl 5,
>
> my int ($one = 0, $two = 1, $three = 2);
>
> is a fatal error. I could argue for this to change, as to support
> better readability (and it would). It's obvious WIM, so why doesn't
> it DWIM (disclaimer: cannot be used as an argument for arbitrary
> featu
Steve Fink wrote:
I was assuming the generation would be automatically incremented per
op, either in the runops loop or (if that is too slow) in the
implementation of selected ops.
In the runops loop would be slow, and not very practical for e.g. JIT or
CGoto. But e.g. branch instructions wo
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:51 AM -0800 1/3/03, James Michael DuPont wrote:
> >Can someone tell me if anyone uses packdump from cvs? is that an
> >equivalent to ildasm in dotnet? It seems to be broken.
> >Can I dump an set of instructions from a program into a file, and
> >
> my $var = 0;
> # or my $var = "0";
> # or my int $var = 0;
> # or my num $var = 0;
>
> # all 4 cases should print "is integer"
> print "is integer" if int $var == $var;
>
> This should work as a more generic method to test Integer
> *value*, rather than type, which IMHO is more useful (and
>
> From: =?iso-8859-1?Q?Murat_=DCnalan?= <[EMAIL PROTECTED]>
> Date: Sat, 4 Jan 2003 14:50:22 +0100
>
> > > my int ($pre, $in, $post) is constant = (0..2);
> > >
> > > Two things "type and property" that belong so together
> >
> > Do they? Surely the type and constancy of a variable are
> > ent
> > In the above case int($var) == $var returns true when I
> would want it
> > to return false.
>
> print "date" if $var.isa(int);
> print "date" if isa $var: int;
> print "date" if $var ~~ int;
>
> Those should all work. IMO the first reads the best. That
> will also work for C
> > It's also far slower. Constructing a 31-element list, junctionizing
> > it,
>
> This might well be done at compile-time. And/or, lazily. So
> the cost of these two steps is likely to be negligible.
>
> > then testing against each element vs. 2 numeric comparisons.
>
> Yes. That's a signifi
If memory serves me right, Erik Bågfors wrote:
> > >> would a be able to modify itself ? (unfortunately C# allows that)
> > >
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public void Modify(){ val=
> > my int ($pre, $in, $post) is constant = (0..2);
> >
> > Two things "type and property" that belong so together
>
> Do they? Surely the type and constancy of a variable are
> entirely orthogonal to each other.
Oh yes. Psycho-affectivly it is disturbing seeing the group of variables
($pre, $
On Sat, 2003-01-04 at 04:05, Dan Sugalski wrote:
> At 7:27 PM +0100 1/3/03, Erik Bågfors wrote:
> >On Sat, 2003-01-04 at 00:28, Gopal V wrote:
> >> If memory serves me right, Dan Sugalski wrote:
> >> > language-level "we're object-oriented dammit!" objects, not the
> >> > lower-level stuff we're
- {active,total}_{PMC,BUFFER}S are calculated now on demand and
therefore always valid, not only after a DOD run (active)
- these vars are no more in the interpreter struct
- removed duplicate printing of interpinfo
Accessing info from these interpreter stat fields shall be done only via
the int
Leopold Toetsch wrote:
Leopold Toetsch wrote:
$ time parrot -j stress.pbc
A total of 9 DOD runs were made
real0m0.708s
But this still could go faster:
$ parrot -j stress.pbc # w/o pmc->synchronize (-10% size)
A total of 9 DOD runs were made
real0m0.635s
$ time parrot -j stress.pbc
[EMAIL PROTECTED] (Joe Gottman) writes:
> In the above case int($var) == $var returns true when I would want it to
> return false.
Why should you care? Perl 6 isn't going to be that strictly typed, is it?
--
I wish my keyboard had a SMITE key
-- J-P Stacey
Dan Sugalski wrote:
At 10:08 PM +0100 1/3/03, Leopold Toetsch wrote:
- No stackwalk,
I think we're always going to have to walk the stack, no matter how much
I'd rather not. It's an expensive walk too, alas.
This depends on. I think a mixed strategy of:
- code reordering (e.g. $1=pmc_new
Dan Sugalski wrote:
At 10:25 PM +0100 1/3/03, Leopold Toetsch wrote:
As programs tend to have much more scalars then aggregates and
probably more scalars w/o properties then with, this would win a lot
of precious cache mem.
Fair enough, though there's something just so bizarre about havin
Damian Conway wrote:
Piers Cawley wrote:
Acknowledgements
But, of course, modesty forebade him from thanking the tireless Perl 6
summarizer himself, for his sterling efforts wading through the morasses
that are P6-language and P6-internals
Remembering e.g. perl6 operator threads, brrr, I
At 9:35 PM -0500 1/3/03, Mitchell N Charity wrote:
I'm not willing to go so radically to start, but I did have an idea.
I think part of the extra cost is just in cache fluffiness--the sync
info just isn't being used much. I don't think that it, or the
property info, will be used most o
At 10:08 PM +0100 1/3/03, Leopold Toetsch wrote:
Ok. Here ist the rest.
- No stackwalk, as already sent by separate #19668, which is included
if this is a problem for $architecture, please enable
trace_system_areas in dod.c again - feedback still welcome
I think we're always going to have to
At 10:25 PM +0100 1/3/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
I'm not willing to go so radically to start, but I did have an
idea. I think part of the extra cost is just in cache
fluffiness--the sync info just isn't being used much. I don't think
that it, or the property info, will be u
At 10:51 AM -0800 1/3/03, James Michael DuPont wrote:
Can someone tell me if anyone uses packdump from cvs? is that an
equivalent to ildasm in dotnet? It seems to be broken.
Can I dump an set of instructions from a program into a file, and
reassemble them?
If not, is there a way to dump a parrot p
Luke Palmer wrote:
>>> From: "Joe Gottman" <[EMAIL PROTECTED]>
>>> Date: Fri, 3 Jan 2003 22:25:16 -0500
>>>
>>> "JG" == Joe Gottman <[EMAIL PROTECTED]> writes:
>>>
>>> JG> Speaking of which, is there a run-time test to check if a variable
>>> JG> is of
>>> JG> integral type? Somethin
40 matches
Mail list logo
