Sunday 21 July 2002 21:34, Dan Sugalski wrote:
>
> No. They are not. You're missing the important case where the data
> structure is inherently and intrinsically multidimensional.
>
>my int Array @foo : dimensions(3);
>@foo[1;2;3] = 12;
>
> Or whatever the syntax is in perl to declare a 3
Sunday 18 August 2002 00:38, Simon Cozens wrote:
> [EMAIL PROTECTED] (Dan Sugalski) writes:
> > Has someone looked at and maybe committed this?
>
> The reason I asked which pieces of Parrot were prototypes was
> because optimizing the hell out of something that's only a
> prototype is nothing shor
> I still prefer infix notation to prefix notation for an intermediate
> language. I don't understand why it is so hard to adopt. imcc is supposed
> to be a step closer to higher level languages, which is why I went that
> way.
Hi,
I think we all agree that since parrot can have dynamic oplibs
>
> Sure, I have no problem with it. At one
> time someone suggested making a separate
> list for Parrot compilers, so I took it as
> a hint that maybe we were spamming.
>
I am all for the creation of a new list for stuff such as imcc, and perl6
compilers. ([EMAIL PROTECTED]?)
So people interes
> c) imcc becomes a "middle" level language.
> I never meant it to be an assembler. In practice
> intermediate languages provide other constructs
> such as aggregate type definition that are not
> available in the assembler.
>
> type i : packed int[32]
> type r : record { foo : int, bar : string }
Hi,
Now that we've got ICU in, I thought it may be time to revisit the
encodings implementation. I am a clamorous ignorant is
unicode/encodings issues, so please be patient with me. :)
>From what I have asked people at IRC, and what's on the list archives,
my understanding of how parrot will
Hi Leo,
>
> This should be - from my (imcc) POV - reflected by these IN/OUT
> settings:
>
> op set(in PMC, in INT)
> op set(in PMC, in STR)
> op set(in PMC, in NUM)
> op set(out PMC, in PMC) # ok, $1 points to $2 now
>
> # P[i] = x
> op set(in PMC, in intkey, in x)
> # P[KEY] = x
>
Dan Sugalski wrote:
> At 7:40 AM -0400 9/4/02, John Porter wrote:
> >
> >Some folks seem to think that sufficient reason exists now.
>
> That's fine. You don't have to convince some folks. You have to
> convince me.
Being ultra-pragmatic, the name change:
- costs nothing
- might make some folks
Larry said:
> BTW, latest leaning is toward = rather than //= for parameter
> defaults, ...
Horray!
Sorry. Couldn't resist. :-)
-angel
"Simple men are happy with simple presents"
Hi,
Many thanks Michael, this is very useful, really. I had lost all the
OO discussion and this document is very helpful.
I really like the part of context transformations, I hope something
like this gets in.
Just a silly note:
> Recipe 1.9: Using Subroutines as Objects
>
> Problem:
> You w
> Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate
> in the set of rational numbers. The IEEE may say otherwise.
Mathematically, 1/0 is whatever you define it to be.
And it is perfectly correct to assume that operations happen in the
extended real line, and thus that 1/0 i
>
> > Mathematically, 1/0 is whatever you define it to be.
>
> Well, sure. That's as axiomatic as saying, "mathematically, the
> number one is whatever you define it to be." But a mathematical
> system that has a definition which is inconsistent with the rest of
> the system is a flawed one. If
Speaking about macros, I renember reading somewhere something about
Scheme hygenic macros, but i didn't really understood it.
Do they solve the maintenance problems of Lisp macros? Would they be
applicable to perl?
Thanks for any tips,
-angel
>
> At the moment I like "like" the best, actually...
>
"like" is beautiful for old-style regex matching, but I find it
confusing for the new smart abilities:
$varlike Class:Foo # $var is instance of Class:Foo
$item like %hash # %hash{$item} is true
$digit like (0..10)
> And maybe:
>
> A bitwise operator is just a logic operator scoped to a set of
> bits.
>
> That's why I can't accept a characterization of
>
> +&+|+X - bitwise operations on int
> +&= +|= +X=
>
> ~&~|~X - bitwise operations on str
>
LW said:
>
> :<...>- readline
>
> Iterate interator.
>
Couldn't we go the python way and assume that <..> is implicit in
"for" statments:
$fh = open(..);
for $fh { # instead of for <$fh>
print $_;
}
For explicit iteration, we could well do just with a ".next" me
Wednesday 30 October 2002 22:08, Michael Lazzaro escribió:
> On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
> > for @a; @b -> $x is rw; $y { $x = $y[5] };
>
> I agree that it's an eyeful. How many of your issues could be
> solved if the above were just written:
>
> for
> We started off with an intense RFC process. This produced many good
> ideas, not-so-good ideas, and ideas with potential but desperately
> needing polish. If you'd like a recap, you might try MJD's article
> on the subject (http://www.perl.com/lpt/a/2000/11/perl6rfc.html).
> One of the major thin
>1) We find a team of volunteers who are willing to "own" the
> task of converting each Apocalypse into a complete design. If
> nobody wants to write the Perl 6 user manual, then we might as well
> give up and go home now. So far we only need to find four, though,
> so it Might Just Work.
I w
>
> Should start small. No tutorials until docs & tests are done. No
> working on A3 until A2 behaviors are *locked*, to whatever extent that
> proves possible.
>
> Comments?
>
I think that the best way would be to create an schema of a language manual,
and fill the documents as we proceed revi
>
> I very much dislike XML for writing. It'd be nice to use some kind
> of "extended POD" or something. Something that's mostly content,
> little structure. Formats with a lot of structure tend to be
> unproductive, and although the structure is useful, much of it is
> redundant and can be bypa
In my opinion, this outline puts too much weight on the first section.
I would prefer it to be made of just the basic concepts and have
forward references to the apropiate sections.
For example: I wouldn't put the list of methods supported by each of
the types in Section 1. Instead of this, I
Monday 11 November 2002 20:40, Garrett Goebel wrote:
> The only consist support for something different than POD... was
> for something that is in fact very similar to, and in fact based
> upon POD: SDF.
>
> http://www.ifi.uio.no/in228/scripting/doc/sdf/index.html
>
>
> And the major arguments for
> Hmm wouldn't the JIT benifit from a pre knowledge of basic
> blocks and types or some information ? ... (I seem to think so
> ...).
I would think so, because if, for example, the JIT wants to do a full
register allocation to map parrot registers to machine registers, it
would certainly nee
I've written a frist version of the "1.1 - Literal Values" subsection
(in Michael's schema).
It discusses the different ways of creating literal numbers and
strings in perl6.
There are no tests, and the format may be outdated. I will gladly
resubmit this in a more complete form.
I have direc
Hi,
Many thanks for all the feedback about the literals document.
This new version integrates most of the changes. I've also added a
subsection about Inf and NaN, directly coming from Michael's
perlval.
I've also changed the pod syntax to =section, as suggested. I've used
the:
=section **
Looks good.
I'll rewrite the literals section to match this better outline.
-angel
> bin/oct/hex literals:
>
> 0b0110 # bin
> 0c0123 # oct
> 0x00ff # hex
> 0x00fF # hex, == 0x00ff
> 0x00FF # hex, == 0x00ff
>
> 0xf_f # ok
> 0x_ff # ok
>
I thought that bin/oct/hex literals where deprecated in favour of
explicit rad
Michael Lazzaro escribió:
> We should talk about this. My original proposal was to do this:
>
> (Case 1) base 2-10: use 0..9
>
> (Case 2) base 11-36: use (0..9, a..z), but allow A..Z such that
>
> 0x00ff == 0x00FF
>
> which seems necessary, IMHO.
>
> (Case 3) base 37-62: use (0..9,a..z,
Hi all,
This is the numeric literals part, reformated to follow Michael's
outline.
It has some additions:
- Complex numbers
- Further explanation of NaN/Inf, with a tentative algebra table.
- Caveats when using BigInts/BigRats
There are some open questions, but I think I am finally not fo
Larry Wall escribió:
> : 1_2_3_4__5___6 (absurd, but doable)
>
> Nope, _ is allowed only between digits (counting a-f as digits in
> hex).
>
> Larry
Mmm.. I thought that the whole purpose of creating a new mailing list
was to prevent you from reading it.
Not that I am against your pre
>
> Why would C be a keyword? Its not in perl5, and I don't
> remember any discussion where non-real numbers would
> be part of the core language.
>
My fault.
For some strange reason I had a false idea that this had been said
somewhere, and didn't check. Shame on me.
-angel
Damian Conway wrote:
>
> The formulation of coroutines I favour doesn't work like that.
>
> Every time you call a suspended coroutine it resumes from immediately
> after the previous C than suspended it. *And* that C
> returns the new argument list with which it was resumed.
>
> So you can write th
>
> (E) We need to finalize what happens when a string isn't a number,
> or has additional trailing stuff. Damian gave his initial
> preference, but we need to verify & set in stone:
>
> my int $i = 'foo'; # 0, NaN, undef, or exception?
> my int $i = '5foo'; # 5, NaN, undef, or exce
A few questions, about stuff I am not sure I got right. Sorry if this
has already been resolved.
- What is the default behaviour (without using any pragma) of 1/0?
NaN or exception?
- Are these correct? What will they do?
my Int $i is bigint = 777_666_555_444_333_222_111;
print $i;
my
Hi,
This in an updated version of the numeric literals document. Hopefully
it is consistent with Michael's summary, and with discussions on the
list.
The portions that were wrong (complex numbers, etc..) have been
removed. Other parts (NaN, etc..) are still there, but I think that
they shou
Michael G Schwern wrote:
> and that's just entirely too much work. I'd love to be able to do
> it with a grep like thing.
>
> (@switches, @args) = seperate /^-/, @ARGV;
>
> seperate() simply returns two lists. One of elements which match,
> one of elements which don't. I think Perl 6 will
>
> The best partial solution to early finalization is compile-time
> tracing of possible references by the compiler which can explicitly
> generate the appropriate DESTROY calls.
>
What about refcounting + real GC?
refcounting will free most of the objects as soon as possible, and the
real GC s
> I have to wonder how many people actually like this syntax, and how
> many only say they do because it's Damian Conway who proposed it.
> And map/grep aren't "specialized syntax", you could do the same
> thing with a sub with a prototype of (&block, *@list).
I have to say that I am not speciall
I explained very badly. The issue is not spilling (at the parrot
level)
The problem is: if you only pick the highest priority parrot registers
and put them in real registers you are losing oportunities where
copying the date once will save you from copying it many times. You
are, in some sense
Saturday 22 February 2003 16:28, Leopold Toetsch wrote:
> Gopal V wrote:
> > If memory serves me right, Leopold Toetsch wrote:
> >
> >
> > Ok .. well I sort of understood that the first N registers will
> > be the ones MAPped ?. So I thought re-ordering/sorting was the
> > operation performed.
>
>
> [ you seem to be living some hors ahead in time ]
Yep, sorry about that.
> The problem stays the same: spilling processors to parrot's or
> parrots to array.
>
Thinking a bit more about it, now I believe that the best way to do it
would be:
(1) First, do a register allocation for machine re
Friday 14 March 2003 20:06, Michael Lazzaro wrote:
> 3) If an "untyped" var is used for a typed parameter, a simple
> dataflow analysis is used to determine whether the compiler can
> guarantee that, at that point, an "untyped" var will _always_
> contain values of a known, specific type. If so, t
Damian Conway wrote:
> But large projects -- where typing will be most important --
> *can't* deal with that. That's the point of typing: to specify and
> enforce interface contracts. At compile-time if at all possible.
One quick question about this. If I write:
sub foo (Bar $f) {..}
my $x
> block. Perhaps we should just go with that:
>
> property $foo = 0;
>
> Or whatever word we choose, I don't care:
>
> prop $foo = 0;
>
What about:
prof $foo;
$foo = 0;
Is this equivalent to "prof $foo = 0"? If it is not, I would claim
this to be a major violation of the principl
Monday 14 July 2003 05:56, Robert Spier wrote:
> > Sorry for a slightly off-topic post, but will Larry's State of
> > the Onion be posted online soon?
>
> Yes.
>
> http://dev.perl.org/perl6/talks/
>
> -R
Really? I can't find anything about TPC7 in this page..
-angel
Miércoles 14 Abril 2004 14:18, Juerd wrote:
> I propose to use ` as a simple hash subscriptor, as an alternative
> to {} and <<>>. It would only be useable for \w+ keys or perhaps
> -?\w+. As with methods, a simple "atomic" (term exists only in
> perlreftut, afaix, but I don't know another word to
A good register allocation algorithm will always have problems with
big subs, there is nothing that we can do about it.
I think that what "real compilers" do to solve this problem is
implement two different algorithms: one for normal subs which tries
to generate optimal code, and a naive one f
Friday 13 February 2004 15:02, Dan Sugalski wrote:
>
> If you're *really* looking to get fancy, why not just allow the
> sort specification to be done with SQL? Comfortable,
> well-understood, already has a decade or so of stupid things welded
> into it [...]
>
> Heck, you could even unify map, gr
Viernes 19 Marzo 2004 13:08, Andy Wardley wrote:
> I'm so happy! I just found out, totally by accident, that I can
> type the « and » characters by pressing AltGr + Z and AltGr + X,
> respectively.
>
> Apologies if this is common knowledge, but it was news to me, and I
> thought I'd share this lit
something very similar to what we would
need for parrot/perl6.
Just my half a cent,
Angel Faus
[EMAIL PROTECTED]
vLex.com
ession to lower case on compile time, and
then converting the string to lower case just at the begining of the match.
(The former is actually propsed by Jeffrey Friedl in the Mastering Regexs
book claiming that it would be much faster)
How agressive are we going to be with this kind of optimi
Brent Dax :
> Okay, this bunch of ops is a serious attempt at regular expressions. I
> had a discussion with japhy on this in the Monastery
> (http://www.perlmonks.org/index.pl?node_id=122784), and I've come up
> with something flexible enough to actually (maybe) work. Attached is a
> patch to
Hi Brent,
># I have been uncapable of expressing nested groups or
># alternation with your model, and I would say that this
># is because the engine needs some way to save not only
># the index into the string, but also the point of the
># regex where it can branch on a backtack.
>I've been a bi
A fresh checkout (both after and before Dan's portability patch) gives me a
lot of failed tests on cygwin.
¿Is it me or is it really a problem? Dan said it's tested on cygwin...
$ make test
Failed TestStatus Wstat Total Fail Failed List of Failed
-
Sincerly,
-------
Angel Faus
[EMAIL PROTECTED]
1814a1815,1882
>
>
> AUTO_OP matchexactly(sc, s, i, ic){
>
> STRING* temp;
>
>
> if (string_length($2) <= $3) {
> RETREL($4);
> }
>
> temp = str
>next->id();
}
}
sub BabyRegex::close::pasm {
my $self = shift;
my $id = $self->id;
my $cnt = $self->{GROUP}->{COUNT};
cry $id, "#end of group $cnt";
if ($self->{GROUP}->quant eq "*" or $self->{GROUP}->quant eq "+") {
http://homepages.ulb.ac.be/~arigo/psyco/ ; they have some very
nice documents that explain all with a great detail.
I wonder whether Parrot could stole some ideas of this..
Just mi half a cent.
-Angel Faus
[EMAIL PROTECTED]
t.
>
Cool. ¿Could you send it to me? I would like to make a try to speed my
proposal... Probably there is no way to catch up, but I would like to see it
anyway.
Meanwhile, I'll shut up my mouth and update regex.pod to reflect your
proposal.
Sincerly,
---
Angel Faus
[EMAIL PROTECTED]
ws us to add new methods in vtable.tbl, without worrying about old
..pmc files.
btw, sorry for that silly Text::Balanced dependency. I stupidly assumed it
was a standard module without checking.
Sincerly,
---
Angel Faus
[EMAIL PROTECTED]
pmc2c.pl
Description: Binary data
gt; and the like working.
This patch should make it. I have not included STRING arguments, because I
don't know which multimethod should be called (native, unicode or other).
Tests are updated too.
Sincerly,
----
Angel Faus
[EMAIL PROTECTED]
Vtable.p
tors, and perl6 is doing a great job of taking the coolest things
of other languages and integrating them into a choerent design, so i do
have a hope. [:)]
This is of course related to Ruby's iterators, that take a somehow
opposite solution to solve a similar problem.
----
Sorry for the 4 times posts, i was testing a new mail program and it
didn't prove too good.
Now i feel so ashamed :-[
-angel
by_size =
@files.map -> $file { [$file, -s $file] }
.sort -> @a, @b { @a[1] <=> @b[1] }
.map -> @pair { @pair[0] }
--
Angel Faus
[EMAIL PROTECTED]
ur perfomance.
And using too much stacks (as the usage of exceptions would probably
require), will also be too slow (as Brent Dax showed me when we
where discussing our two regex opcodes designs).
Just my 2 cents (of euros) :)
---
Angel faus
[EMAIL PROTECTED]
Simon wrote:
:> Have you an idea about what will be the 'final'
:> parser for the Perl 6 compiler ? (LALR(1), like Perl 5 ?)
:
:Yep, LALR1, probably yacc generated.
I recall reading somewhere that Perl6 was going to be parsed by something
very much like Parse::RecDescent, just that faster.
¿has
r Parrot, (I am
particulary interested in the third one) I would volunteer to contribute a
patch attempt for it.
Angel Faus
[EMAIL PROTECTED]
>
> These methods are provided so that we can play with "native" types in our
> bytecode then send them to our pmc, as otherwise every constant in our
> code would have to be a PMC, which is a little excessive.
>
> Things like a complex number will be represented by either a PMC class
> (very lik
Simon said:
> > I see. ?But what's the rational to have Bigints / Bigfloat be native
types
> > instead of PMCs?
>
> They're useful and predictable. And also, you may want to automatically
> promote integers to bigints; you probably don't want to automatically
> promote integers to complex types.
Dan wrote:
>Yep, I've seen their plans. It's less an issue for us, at least as
>far as globals are concerned, since we'll be doing that with
>lexicals. (Python not having lexicals, after all) Globals are a bit
>more interesting, since bytecode-loaded modules can't guarantee
>global positions, sin
> my Complex $c = 3+4i;
> my Complex $d = 4i;
> my $plain = $c / $d;
>
> Does $plain (which is actually '3' after reducing) get promoted to
> Complex, or does the result from the division get demoted?
In a related matter, computer languages with Symbolic Mathematics
capabilities, like Mapple, le
>> my $plain = $c - $d : Math::Complex # 3.0 + 0i
>> sqrt(2 : Math::Integers) # -> exception or not-a-number
>Not a bad idea,. I beleive that the perl6 adjective operator
>(for functions) will be a semicolon, not a colon. I'm not
>sure how it is planned to apply it to operators.
>
>Its a
Hello,
>If people have different opinions on intermediate code generation, I'd
>like to hear them, since I've only done toy compilers in school which
>always used 3address or quadruples.
I have been working in a compiler for an intermediate language that I call
P-- (obviously inspired in C--) fo
Hi,
I was reading Damian's new excellent diary entry in which he explains the
new currying syntax for Perl6.
(For the lazy ones it's reachable at
http://www.yetanother.org/damian/diary_latest.html)
This new feature allows to partially fill place-holder functions, such as:
my &div = {$^x / $^
74 matches
Mail list logo
