Author: simon
Date: Sat Jan 19 21:55:18 2008
New Revision: 25030
Added:
trunk/docs/pdds/draft/pdd28_character_sets.pod (contents, props changed)
Changes in other areas also in this revision:
Modified:
trunk/MANIFEST
trunk/MANIFEST.SKIP
Log:
[docs] A start on the charsets PDD. Will
Author: simon
Date: Wed Jan 23 05:05:28 2008
New Revision: 25172
Modified:
trunk/docs/pdds/draft/pdd28_character_sets.pod
Log:
[docs][pdds] A little bit more. Implementation section next week.
Modified: trunk/docs/pdds/draft/pdd28_character_sets.pod
Author: simon
Date: Sat Jan 26 04:58:44 2008
New Revision: 25243
Modified:
trunk/docs/pdds/draft/pdd28_character_sets.pod
Log:
Nits picked by Mark Reed, David Romano and Larry
Modified: trunk/docs/pdds/draft/pdd28_character_sets.pod
On Tue, Oct 03, 2000 at 04:06:00PM +0100, Piers Cawley wrote:
> Personally I'm betting that the volume we've seen on -language will
> pale into tiny insignificance compared to the volume on -internals
> once Larry has made his announcement.
I doubt it; I think we've a lot of people who want to ta
On Tue, Sep 26, 2000 at 02:06:47PM -0400, John Porter wrote:
> > Since when do parentheses make things less readable?
>
> Can you say "lisp"?
"lisp".
(defun Schwartzian (func list)
(mapcar
(lambda (x) (car x))
(sort
(mapcar
(lambda (x) (cons x (funcall func x)))
list
On Fri, Sep 29, 2000 at 09:47:51PM -, Perl6 RFC Librarian wrote:
> I am a fan of Perl and like what I see of the core C# _language_.
> What I propose is to move Perl in the C# direction.
So, this is the comedy RFC, eh?
--
DEC diagnostics would run on a dead whale.
-- Mel Fer
On Wed, Sep 27, 2000 at 09:52:57AM +0100, Piers Cawley wrote:
> You know, I'm trying to see what's annoying about all those
> parentheses in the lisp function and what do you know, I can't see
> anything wrong. Okay, so it's not Perl syntax, but it's still clear
> what's going on.
I'd go further
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
> The concept of C as opposed to C is sometimes difficult for
> people to understand.
"People" in this context being the people who are reading perl6-language and
purporting to be able to know what Perl 6 needs. People who ought
On Wed, Sep 27, 2000 at 10:34:32AM +0100, Piers Cawley wrote:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> > Which is what I'm working on. You'll all be extremely pleased to know, I'm
> > sure, that I have notes here for another 12 RFCs. After that, I have to
On Sat, Sep 30, 2000 at 11:52:40AM -0500, David Grove wrote:
> That's the current running hope, I'll change the RFC to match it shortly.
> However, since I can't realistically expect this to happen, it wouldn't make
> sense to do more than suggest it as a first course of action.
I don't think i
On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote:
> Don't change "use less" to "use optimize". We don't
> need to ruin the cuteness.
"use less 'rolled_loops';" sounds really weird.
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you f
On Wed, Sep 27, 2000 at 10:30:36AM -0500, David Grove wrote:
> Although I have no interest in saying anything supportive of this idea, I think
> it would be dreadfully funny if Python suddenly lost its primary point of
> advocacy against the Perl language just because we allowed (not required)
On Mon, Sep 25, 2000 at 11:10:04AM -0700, Nathan Wiger wrote:
> Indeed. It is also worth noting that people on -flow have been hashing
> out safe signals through a "use signal" pragma, which would remove %SIG
> altogether.
Oh, well, OK. Then this RFC's necessary, dammit! :)
> I like it! But I'm
On Thu, Sep 28, 2000 at 08:17:40AM +0200, H.Merijn Brand wrote:
> Can I forward this to perl.comp.lang.misc and perl.comp.lang.moderated?
Please feel free.
> Maybe it's more in brian's lane to spot these messages and react on them,
Well, yes, Perl 6 has been getting a bit of a bad press, and,
On Mon, Sep 25, 2000 at 02:49:29PM -0400, Uri Guttman wrote:
> and how do they nest or get localized? with use signal you can install a
> lexically scoped handler or a package level handler. with WARN it looks
> like a global handler to me.
They're special subs. They nest and get localized like s
On Mon, Sep 25, 2000 at 03:10:47PM -0400, Uri Guttman wrote:
> in what order? like BEGIN and END?
Whatever, yes.
> what if you wanted a block scoped warn handler?
What about it? (Or did someone eat the "local" keyword already?)
> i think it would be better to have some explicit way of
> sett
On Mon, Sep 25, 2000 at 06:37:58PM -, Perl6 RFC Librarian wrote:
> This RFC proposes that the interface to Perl's source filtering facilities
> be made much easier to use.
Hm. I've just sent in the "line disciplines" RFC, which probably will end up
obsoleting a reasonable chunk of this.
--
On Thu, Sep 28, 2000 at 02:40:04PM -0400, John Porter wrote:
> Tom Christiansen wrote:
> > Perl's use of @ISA is beautiful.
> >
> > use base is, or can be, pretty silly --
> > think pseudohashes, just for one.
>
> I suppose you diddle @INC directly, Tom,
> instead of use'ing lib?
I call "non
On Thu, Sep 28, 2000 at 10:00:49AM -0400, Andy Dougherty wrote:
> On Wed, 27 Sep 2000, Nathan Wiger wrote:
> > Y'know, I couldn't have said this better myself. :-) I've always felt
> > that "use English" was a waste of time and effort, a bandaid trying to
> > act as a tourniquet.
>
> I think it's
On Sun, Oct 01, 2000 at 11:49:51AM -0700, Randal L. Schwartz wrote:
> Please take your paranoia elsewhere. I think if you actually sat down
> and had lunch with each of the parties involved, and those further out
> but well-informed, you'd find a consistent view of reality that
> doesn't match AN
On Fri, Oct 06, 2000 at 10:50:06AM -0500, David Grove wrote:
> I don't know it's affiliations
You know that word "independent"? Should have been a give-away, but...
> but I _seem_ to recall (such a "seem" that it's about 10% away from a guess)
> that it's "owned" by either the independent perl m
On Fri, Oct 06, 2000 at 12:27:31PM -0500, David Grove wrote:
> I've voiced my objections and given complete and concrete evidence and
> examples of why this should not happen. I think that's enough.
I think that's enough, too. So, you'll be shutting up now, then?
--
>God Save the Queen!
And let
On Fri, Oct 06, 2000 at 01:52:26PM -0400, Bradley M. Kuhn wrote:
> That's a good idea. I wish you'd have mentioned it while the RFC could
> still be changed. :)
Shouldn't be a problem; we don't have to stop having ideas now October first
is past, I hope.
--
There seems no plan because it is a
On Mon, Oct 09, 2000 at 01:10:57PM -0500, David Grove wrote:
> >Perl 6 Public Relations - brian d foy
>
> Public relations? Uh, who is the Perl 6 information officer?
I don't have the faintest idea.
--
"You can have my Unix system when you pry it from my cold, dead fingers."
On Tue, Oct 10, 2000 at 12:34:33PM -0700, Dave Storrs wrote:
> is there some way we can duplicate/adapt
> their process so that we can simultaneously put to rest both David Grove's
> concerns about elitism and Dan Sugalski's concerns about lack of planning?
No.
--
Everything that can ever be in
On Tue, Oct 10, 2000 at 03:11:54PM -0500, David Grove wrote:
> Perhaps, then, there should be one more officer, chosen by Larry himself.
> This person would be responsible for collecting public opinions and
> representing them to the developer group, who needs to follow that guidance
> as long as
On Tue, Oct 10, 2000 at 03:38:17PM -0500, Jonathan Scott Duff wrote:
> Perhaps it's just me, but I don't see a problem yet. If Perl were
> somehow being "taken over", then I expect the Perl community (at the
> very least, one David Grove :-) to be up in arms about it.
And then they could fork,
On Tue, Oct 10, 2000 at 05:40:04PM -0400, Dan Sugalski wrote:
> You're being too specific. There is no assumption possible that perl
> developers will do *anything*. Ever. This is a volunteer community. Any
> other assumption you might make is unfounded.
David also seems to miss the irony that
On Tue, Oct 10, 2000 at 06:01:16PM -0400, Dan Sugalski wrote:
> "General consensus" is best, but that can't be guaranteed. "Consensus of
> the ruling council" is more attainable, but there's that whole "ruling
> council" thing to contend with. "What Larry says" is best, but what happens
> if he
On Wed, Oct 18, 2000 at 10:32:32AM -0700, Larry Wall wrote:
> Rename the local operator? Yeah, I think we ought to do that. It
> confuses people when we call it local(). The problem is, of course,
> that this is not a perfect solution--they haven't come up with the
> right name here: savetmp, t
On Mon, Oct 23, 2000 at 02:51:40PM -0400, Dan Sugalski wrote:
> > PLEASE LET'S NOT GO THAT WAY
> A... you're no fun! :)
I am, but nurse says I'm not allowed to write INTERCAL any more.
> That is one of the scenarios. There are some issues with it for a project
> like this--spitting out
On Mon, Oct 23, 2000 at 03:37:02PM -0400, Dan Sugalski wrote:
> Well, maybe we can do it in befunge instead.
+!+!@@!!!
> Oh, without a doubt. I'd actually like to get things building such that the
> four main modules--parser, bytecode compiler, optimizer, and execution
> engine--are in separat
On Mon, Oct 23, 2000 at 04:03:12PM -0400, John Porter wrote:
> But we'll probably *implement* perl in Ada, of course.
Bzzt. Ada *used* to be the language that made the world turn. We believe that
the world-turning program was rewritten in Perl in 1997.
--
Thus spake the master programmer:
On Mon, Oct 23, 2000 at 07:44:15PM +0200, Gerrit Haase wrote:
> Perl, which allows object oriented syntax, written in C++ language,
^^
Did I miss something, or did the world go *totally* gaga overnight?
--
It's all fun and games until som
On Mon, Oct 23, 2000 at 02:39:14PM -0400, Dan Sugalski wrote:
> Got me. I'd planned on us writing perl 6 in INTERCAL.
PLEASE LET'S NOT GO THAT WAY
Incidentally, and just to try and raise the tone a little, are we planning on
compiling Perl 6 programs to native binaries?
--
These days, if
On Mon, Oct 23, 2000 at 04:38:12PM -0400, Dan Sugalski wrote:
> The one thing that just occurred to me is that we're going to need to
> support multiple interpreter targets simultaneously. Having the back-end
> emit C source isn't going to get those BEGIN blocks very far. :(
Don't forget that t
On Mon, Oct 23, 2000 at 04:51:24PM -0400, Uri Guttman wrote:
> only perl op calls in machine code
I can't make this make any sense. Could you try again?
--
And it should be the law: If you use the word `paradigm' without knowing
what the dictionary says it means, you go to jail. No exceptions.
On Mon, Oct 23, 2000 at 04:11:34PM -0600, Nathan Torkington wrote:
I'd just like to stoke the latent paranoia.
> Published by Microsoft Press
> Published by Microsoft Press
> Published by Microsoft Press
> Published by Wiley
> Published by Dorset House
--
Putting heated bricks close to the new
On Mon, Oct 23, 2000 at 08:33:23PM -0400, Uri Guttman wrote:
> so the TIL generated code would still to parameter setup, then an
> indirect function call and then result handling. it should still be
> faster than an interpreter and simpler to generate than fully compiled
> code.
Is this actually,
On Mon, Oct 23, 2000 at 03:40:26PM -0700, Peter Scott wrote:
> >Don't forget that those BEGIN blocks are *supposed* to be instructions
> >to the compiler.
>
> Er, but a lot of people seem to use them for other things :-)
Then they're going to have a shock. This isn't Perl 5 any more, Toto.
> Wh
On Mon, Oct 23, 2000 at 05:18:15PM -0400, Uri Guttman wrote:
> basically the emitted machine code for TIL is very simplified C
> routine calls and their argument setup and return. all the routine calls
> are to perl ops with just the minimal stack glue code in between them.
OK, you're re-inventin
On Tue, Oct 24, 2000 at 03:35:31PM +0100, Ajdin Brandic wrote:
> Uff!
Da.
> Why is there a mailing list for perl6 up and running before the version is
> out?
Someone's gotta *write* it. I hear there's a mailing list for Linux 2.4.
--
I _am_ pragmatic. That which works, works, and theory can g
On Tue, Oct 24, 2000 at 04:41:38PM -0700, Benjamin Stuhl wrote:
> It seems to me that one thing that the perl6 bytecode
> implementation _should_ do (in the interests of being light
> and fast, as well as meshing well with MT) is be
> position-independant.
Fancy offering a patch to RFC310?
--
I
On Tue, Oct 24, 2000 at 02:52:53PM -0500, Garrett Goebel wrote:
> > It's a good idea, but it really Isn't There Yet.
>
> Fair enough...
Hey, I'm not Dan. There should have been big tags around that
previous mail.
--
God gave man two ears and one tongue so that we listen twice as much as
we s
le
solution.) While Simon Peyton Jones is a storming guy and I appreciate his
work a lot, I don't think that C-- is the answer for Perl.
C-- doesn't have varargs. Or a decent, fast, portable implementation. And we'd
all have to learn C--.
It's a good idea, but it really Isn'
On Sun, Oct 29, 2000 at 01:36:48PM +, David Grove wrote:
> ana: no, not having, none, anti
> phalis: ...
It's the front part of your helmet which protects your nose.
--
"He was a modest, good-humored boy. It was Oxford that made him insufferable."
On Thu, Nov 02, 2000 at 10:11:56AM -0500, Mark-Jason Dominus wrote:
> My critique of the Perl 6 RFC process and following discussion is now
> available at
> http://www.perl.com/pub/2000/11/perl6rfc.html
Agree 100% to every point.
--
"The best index to a person's character is a) how he t
On Thu, Nov 02, 2000 at 11:12:50AM -0500, John Porter wrote:
> As an RFC author and persistent discutant, I always assumed that
> all/most/many of such qualified internals folks would be reading
> the perl6 lists, and would squawk when appropriate.
On the whole, driving a spike between language
On Wed, Nov 01, 2000 at 05:35:17PM -0800, Steve Fink wrote:
> Algorithm Inline? OptimizationTime (sec)
> GOTO- -O3 1.35
> FUNCALL_HYBRID yes -O3 4.20
> FUNCALL_PREDICTABLE no -
On Thu, Nov 02, 2000 at 10:42:08AM -0700, Nathan Torkington wrote:
> But what really pisses me off is that the harshest critics are people
> who bowed out or were silent during the stage where we were setting up
> the RFC process.
I'm trying to say this carefully, but the first few days of the pr
On Thu, Nov 02, 2000 at 11:44:50AM -0600, Jarkko Hietaniemi wrote:
> Firstly, now, for the first time in the Perl history, we opened up the
> floodgates, so the speak, and had at least some sort of (admittedly)
> weakly formalized protocol of submitting ideas for enhancement,
> instead of the shar
On Thu, Nov 02, 2000 at 06:07:14PM -0500, Bennett Todd wrote:
> I'd really hate it if the sort of people who use Java were to join
> the perl camp, then we'd be tainted by their work.
You miss the point. *We already are*. Now what?
--
Hi, this is Ken. What's the root password?
On Thu, Nov 02, 2000 at 02:01:45PM +, David Grove wrote:
> Absolutely and double the vulgarity. I can't imagine that the article was
> posted at all. Several of us (you guys) have _some_ pull at O'Reilly...
> please suggest that the article be pulled.
Of course, because censorship is the onl
On Fri, Nov 03, 2000 at 11:18:01AM +0100, Bart Lateur wrote:
> Coming from someone whoe probably wrote more RFC's than anyone else (I
> count 33), I find that pretty ironic.
I had to inject some sense into the process somehow.
--
Morton's Law:
If rats are experimented upon, they will de
On Thu, Nov 02, 2000 at 10:14:25PM -0500, Dan Sugalski wrote:
> Not in the p5p sense, at least. Regardless of the levels of disapproval,
> generally the disapproval was voiced with at least some courtesy. p5p is
> rather less polite about things.
I think that's what they call a "false memory".
On Fri, Nov 03, 2000 at 04:42:34PM -0500, Stephen P. Potter wrote:
> Not to mention "revisionist history". There were any number of uncourteous
> voices during the RFC process.
Exactly. Dan, weren't you the very person who had to tell people on more
than one occasion to grow up and behave like a
On Wed, Nov 15, 2000 at 03:29:24AM +, David Grove wrote:
> If this should be a PDD, I'll be happy to propose it that way, but I will
> need some slight help in the specific implementation of the C code that
> does it.
I may have misunderstood the purpose of this group, but it's *API*, which
m
On Tue, Nov 21, 2000 at 10:37:23AM +, David Grove wrote:
> I'm not sure that it's possible to do this, or disirable. If Larry wants
> Perl to use different modes, creoles, or ways of interpreting or
> understanding the "perl" language, then we have to let the parser have a
> bit more informati
On Wed, Nov 22, 2000 at 12:45:50PM +0100, Bart Lateur wrote:
> Heh. In short: are there
> any more *practical* "how do I build my own compiler" books, that people
> can wholeheartedly recommend?
"Modern Compiler Design in C" (or "... in ML" if you so desire) by Appel.
Bit weird in places - excel
On Tue, Nov 21, 2000 at 07:36:11AM -0500, David Grove wrote:
> > 1) The API presented to the rest of the world. This is likely one call,
>
> These are almost two separate things entirely. (I don't get the "one call"
> thing. What do you mean?)
A parser does, essentially, one single thing: it ta
On Mon, Nov 27, 2000 at 11:49:30PM +, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Is there any reasonable case where we would need to backtrack over
> > successfully parsed source and redo the parsing? I'm not talking about the
On Tue, Nov 28, 2000 at 06:58:57PM +, Tom Hughes wrote:
> I didn't say that having infinite lookahead was better than allowing
> backtracking. I simply said that the two were equivalent and that any
> problem that can be solved by one can be solved by the other.
Fair enough.
> That's quite a
On Wed, Nov 29, 2000 at 09:51:07AM -0800, Dave Storrs wrote:
> I have a feeling this is a stupid question, but I have to ask anyway.
> Do we really need to pass in a PerlInterp pointer?
Yes. Threads. There's a reason for all the PERL_EXPLICIT_CONTEXT anxiety.
--
Old Japanese proverb:
T
On Wed, Nov 29, 2000 at 02:02:31PM -0500, Dan Sugalski wrote:
> I'm really thinking that the lexer, parser, and tokenizer can't be anywhere
> near as separate as we'd like. I think we're going to end up with a rather
> odd mutant beast. Hopefully one that's understandable by reasonably sane
> p
On Thu, Nov 30, 2000 at 05:07:32AM +, David Grove wrote:
> >From my understanding, "API" is the set of functions internal to Perl and
> PerlXS that allow C to access Perl internal structures, functions, etc.,
> for the purpose (or effect) of "writing" "Perl" in "C" (SvPV(whatsis)).
Uhm, no. A
On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote:
> I categorically do *NOT* want perl6-internals to turn into a basic course in
> compiler design, purely for the benefit of those who know nothing at all about
> what they're trying to achieve. I'd like Perl 6 to b
On Wed, Nov 29, 2000 at 02:57:23PM -0500, Dan Sugalski wrote:
> My only worry is, how do we reconcile this with the idea of
> >Perl having an easily modifiable grammar and being a good environment for
> >little-language stuff?
>
> That's a good question, and it depends on what Larry's thinking o
On Thu, Nov 30, 2000 at 03:30:28AM +, David Grove wrote:
> For this, I'd probably look for it to be writable either in perl or in api
You keep using that word. I do not think it means what you think it means.
--
Pray to God, but keep rowing to shore.
-- Russian Proverb
On Fri, Dec 01, 2000 at 08:42:57PM -0500, Bradley M. Kuhn wrote:
> I believe that to do a true port to the JVM (e.g., supporting
> eval($STRING)), we'll need to implement a bootstrapping parser for the
> parser code in Java.
Uhm, and then in every other language we port it to. Are you *sure* that
On Sat, Dec 02, 2000 at 09:23:42PM -0700, Nathan Torkington wrote:
> perl6-internals-design is for a team of no more than 10 people.
And we decide those ten... how? :)
--
We *have* dirty minds. This is not news.
- Kake Pugh
ng list (Yay! YAML!) to which people can
copy messages from the -design list and ask for clarification on technical
things they don't understand:
To: [EMAIL PROTECTED]
From: Simon Cozens <[EMAIL PROTECTED]>
Subject: Re: Parse tree tiling
Clever Bastard wrote in perl6-inter
a design
> spec for the implementation, but also the 'why we did it that way' is
> captured for posterity. Mailing lists are OK for having the discussion, but
> aren't very good for recording it for posterity. I'm inspired by the perl5
> digest produced by Simon, whi
On Tue, Dec 05, 2000 at 09:16:23AM +, Alan Burlison wrote:
> I still think that with the correct
> DTD writing the specs in XML would be doable.
DocBook strikes me as being made for this sort of thing.
--
Facts do not cease to exist because they are ignored.
-- Aldous Huxle
[Replies to perl5-porters, because it's more immediate.]
On Tue, Dec 05, 2000 at 11:00:06AM +0100, H . Merijn Brand wrote:
> Testing, plain.
> i.e. I'm now pretty involved in p5p, and cannot spare time for p6, though
> I'm following most of it. What I could offer is testing the `current state'
On Tue, Dec 05, 2000 at 10:23:46AM +, Tim Bunce wrote:
> As someone who had the option of writing a book in DocBook or POD
> I can tell you that it simply would not have happened in DocBook.
Horses for courses. My next book is going to be in DocBook, and I
do a bunch of documentation in it e
Patches welcome.
=head1 Introduction
This is not a design document; it's a meta-design document - that is, it
tells us what things we need to design, the things we need to consider
during the design process of the Perl 6 internals.
It's completely unofficial, it's completely my opinion, it's me
On Wed, Dec 06, 2000 at 08:31:07AM -0700, Nathan Torkington wrote:
> > Today's scary thought:
> >
> > use B; my $main_root = new B::OP;
> > ...
> > my $int = new B::Interpreter; $int->run($main_root)
>
> That's yesterday's scary thought. Today's scary thought is making
> a perl5 XS
Oh boy, it's OO syntax nargery time again. *sigh*.
On Wed, Dec 06, 2000 at 10:51:14AM -0800, Nathan Wiger wrote:
>@array->length
>%hash->keys
>
> Simply keeping @arrays and %hashes as buckets for SV's wouldn't let you
> do this.
I don't think that's true. At all.
> An "SV" would really
On Wed, Dec 06, 2000 at 10:51:14AM -0800, Nathan Wiger wrote:
> Don't forget we can mix-and-match C/C++ to some degree
for added portability!
--
If computer science was a science, computer "scientists" would study what
computer systems do and draw well-reasoned conclusions from it, instead of
it, with a brief note on what was decided.
Simon
--
Putting heated bricks close to the news.admin.net-abuse.* groups.
-- Megahal (trained on asr), 1998-11-06
On Thu, Dec 07, 2000 at 12:06:36PM +, Nicholas Clark wrote:
> > I think that that would be a 'courageous' decision.
>
> Making decisions now that make it hard to use anything other than 1 compiler
> are as wise as decisions that make it hard to use anything other than one
> implementation lan
On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote:
> [C++]
> It's nearly as portable,
Uhm. Is this actually true? C runs pretty much anywhere.
Are there any non-fragile implementations of C++ yet?
> nearly as fast,
Why have nearly as fast, when you can have as fast?
> and WAY WAY
On Wed, Dec 06, 2000 at 03:11:33PM -0500, Dan Sugalski wrote:
> >I'm in favour of the exact opposite: an AV is "just" an SV-alike vtable
> >with array methods instead of scalar methods and a pointer to some
> >storage, (probably an array of SVs) and likewise an HV. That would allow
> >(array->leng
On Thu, Dec 07, 2000 at 12:24:50PM +, David Mitchell wrote:
> In a Perl context, I find it hard to believe that reference counting takes
> up more than tiny fraction of total cycles.
On a vaguely related note, here's the flat profile from gprof run
cumulatively on the test suite. (I haven't
On Wed, Dec 06, 2000 at 08:28:14PM -0500, Bradley M. Kuhn wrote:
> Whether or not it is slow is not my concern.
Speed isn't (necessarily) the problem, although I'd prefer it if Perl wasn't
slow. *Size* is the problem. On-the-fly evaluation requires a compiler and its
associated environment, and t
On Thu, Dec 07, 2000 at 02:33:53PM -0500, John Porter wrote:
> I'd say, screw 'em if they don't have a C++ compiler.
No.
--
"The best index to a person's character is a) how he treats people who can't
do him any good and b) how he treats people who can't fight back."
-- Abigail Van Buren
On Thu, Dec 07, 2000 at 07:42:26PM +, Nicholas Clark wrote:
> What was Sapphire's implementation language? What were its lessons?
See http://www.perl.com/pub/2000/09/sapphire.html
--
Hildebrant's Principle:
If you don't know where you are going, any road will get you there.
On Thu, Dec 07, 2000 at 03:40:37PM -0500, John Porter wrote:
> When it comes right down to it, the likelihood that I personally
> will contribute to the core is vanishingly small, regardless of
> language.
Great. When it comes down to it, what are you doing here?
> I wonder: In what order will
On Thu, Dec 07, 2000 at 10:11:11PM -0500, Bradley M. Kuhn wrote:
> I believe strongly that we need to make sure the design does not become so C
> specific so as to leave us where perl5 has left us: "No C compiler on your
> platform? Sorry!".
Huh? There are platforms have Java VMs but not C compi
On Thu, Dec 07, 2000 at 10:42:31PM -0500, Bradley M. Kuhn wrote:
> Since we are starting from scratch, why not make these things possible if it
> isn't too hard? And, I don't think it is, if we are simply mindful to "not
> be C specific" as we design.
I think everyone's agreed this, many times o
On Fri, Dec 08, 2000 at 01:17:01PM +, Nicholas Clark wrote:
> We seem to be arguing about the best method for making it *im*possible
> to use anything but the initially-chosen-implementation language to
> implement perl. This feels like a bad thing.
I don't see that; I see that we're all agre
IMHO, the first thing we need to design and code is the API and runtime
library, since everything else builds on top of that, and we can design other
stuff in parallel with coding it. (A lot of it will be grunt work.)
So, before we start even thinking about what we need, it's time to look at the
On Fri, Dec 15, 2000 at 11:39:08AM -0800, Randal L. Schwartz wrote:
> Tell me how you can do that without breaking much existing code.
Pssst, Randal, this is Perl 6, not p5p.
--
"There are two major products that come out of Berkeley: LSD and UNIX. We
don't believe this to be a coincidence." -
On Fri, Dec 15, 2000 at 05:20:35PM -0500, Deven T. Corzine wrote:
> It's a pattern, not a program. Yes, it's straightforward to treat it as a
> step-by-step procedure for matching that pattern, but by doing so, you lose
> something of the gestalt of the whole.
You may deal in patterns, but com
On Sat, Dec 16, 2000 at 01:17:16PM -0600, Jarkko Hietaniemi wrote:
> > 1. Would probably be easier/safer to roll our own strtoq
> Which approach I heartily recommend for Perl 6, incidentally...
One for the API. Hopefully next week I'll have a chance to sit down and
think about what functions we n
completely relate.
That does relate, and isn't documented.
> Simon (?) brought up the problem that we might end up with a monolithic
> beastie
I don't recall saying anything about it being a problem. :)
> Reading what you say, "parser/lexer/tokenizer" (multiple things) &
On Sun, Dec 17, 2000 at 01:20:07AM +, Nicholas Clark wrote:
> I'm assuming we're all sort of thinking that input is certainly
> [good stuff]
>
> I don't think you can do that with eval in perl5, can you?
> If not, it represents something new the parser will have to be able to
> communicate wi
On Sun, Dec 17, 2000 at 09:45:30AM -0500, Andy Dougherty wrote:
> (yet-to-be-written perl-lex)
Wolfgang Laun may take issue with that adjective.
--
The trouble with computers is that they do what you tell them, not what
you want.
-- D. Cohen
Damn this is annoying. Is it perl.org that's dropping mail or me?
- Forwarded message from Simon Cozens <[EMAIL PROTECTED]> -
On Sat, Dec 16, 2000 at 08:09:23PM +, David Grove wrote:
> Thinking of just the parser as a single entity seems to me to be headed into
>
This is the fourth time I've sent this mail to perl6-internals-api-parser,
but it doesn't seem to be arriving. None of my other mail is affected, and
perl5-porters is, for once, behaving itself; why this list in particular?
- Forwarded message from Simon Cozens <[EM
1 - 100 of 1599 matches
Mail list logo
