Re: Markup wars (was Re: Proposal for groups)
Russ Allbery wrote: I've fiddled with this before and can do text to HTML; the rest is just a question of picking different backends and shouldn't be *too* hard. All the heuristics for parsing text are inherently fragile, but if you follow a standard text formatting style, it works reasonably well. Which is precisely the reason for suggesting XML - it doesn't rely on 'fragile heuristics' to get the parsing right. POD suffers from the same problem to some extent, and I really can't see how typing =head1 is better than typing head1 - well apart from being one character shorter, that is. However, having previously been told to shut up on this subject, I now will. Alan Burlison
Re: Perl6 in Java? (was Re: Meta-design)
"Bradley M. Kuhn" [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: However, I don't think we should dismiss it out of hand because people don't do a lot of systems programming C. some of the things we are going to build for C (if that's what we pick), are already there automatically in Java, such as: * garbage collection for internal data structures I'm not sure that Java's GC does what we need Perl's GC to do. Particularly the timely calling of DESTROY and friends. And, it will make the barrier for entry for new internals hacker lower. Err. How do you get to that conclusion? The thing that really stops me mucking about with perl's internals is the fiendish complexity of said internals. Changing the programming language will not, of itself, reduce that complexity. 1) Targeting a single compiler, no matter whose it is, is a bad idea. We're writing in a *language*, not for a compiler. Targeting a specific compiler restricts us even more than choosing a language. I would note that if we write in Java, we aren't targeting a single compiler, although at the moment, the only efficient compiler for Java might be GCJ. Hmm... Up to a point, Lord Copper. 2) GCC produces slow code on all platforms where there's an alternative. This is likely going to change with the release of GCC 3.0, based on current benchmarks of test releases of GCC 3.0. Err, are you seriously suggesting that we implement Perl 6 using a language which currently only has one 'efficient compiler' (to native code), when said compiler isn't actually there yet? I think that that would be a 'courageous' decision. -- Piers
Re: Meta-design
On Thu, Dec 07, 2000 at 01:22:08PM +0100, Roland Giersig wrote: How about a two-step requirement? 1) Native compiler must support ANSI-C. 2) If 1) doesn't hold, gcc can be required, which fulfills ANSI-C. strictly and really pedant point no it doesn't quite, as ANSI specifies the compiled language and the library functions. eg gcc on SunOS 4.1.1 doesn't give an 100% ANSI C because the C library sprintf() returns a char* pointing to the buffer rather than the number of characters written to the buffer. [I remember things that bite me. Also, don't pick up squirrels. The pointed end bites] Not that that's important. But fflush(NULL) is, and we still seem to run into that one on one current platform But I agree with what you're saying. Nicholas Clark
RE: Meta-design
(whoops, correcting my own post!): sva-refcount=0; sva-refcount++; // these first 2 combined if we get the implemention right svb-refcount=0; svb-refcount++; // ditto sva-refcount++; ... if (--sva-refcount == 0) ... // branch not taken if (--svb-refcount == 0) ... // branch taken, if (--sva-refcount == 0) ... // branch taken which I calculate as 7 writes and 5 reads. make that 8 and 6.
Re: Opcodes (was Re: The external interface for the parser piece)
On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
All the math is easy if the scalars are of known types. Addition and
multiplication are easy if only one of the scalars involved is of known
type. Math with both of unknown type, or subtraction and division with the
right-hand operand of unknown type, is rather more difficult. :(
I'm not clear with your scheme how addition works if one of the scalars
(the adder) is of unknown type. ie
given sv1 of type NUM, sv2 of type UNKNOWN; $sv1 + $sv2 would invoke:
sv1-add[UNKNOWN](sv2),
which somewhere will cause a function in the vtable for NUMs to be called, eg
NUM_add_UNKNOWN(sv1,sv2) { }
Now, how does does this function perform its calculation?
I'm guessing that Dan is planning to take advantage of addition and
multiplication being commutative.
sv1-add[UNKNOWN](sv2)
swaps to
sv2-add[NUM](sv1)
(It's "obvious" in the usual way - not obvious until you see it. I've been
prodding in pp_add in perl5, so I've been thinking about these sort of
things)
Nicholas Clark
Re: Opcodes (was Re: The external interface for the parser piece)
Nicholas Clark [EMAIL PROTECTED] wrote:
On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
All the math is easy if the scalars are of known types. Addition and
multiplication are easy if only one of the scalars involved is of known
type. Math with both of unknown type, or subtraction and division with the
right-hand operand of unknown type, is rather more difficult. :(
I'm not clear with your scheme how addition works if one of the scalars
(the adder) is of unknown type. ie
given sv1 of type NUM, sv2 of type UNKNOWN; $sv1 + $sv2 would invoke:
sv1-add[UNKNOWN](sv2),
which somewhere will cause a function in the vtable for NUMs to be called,
eg
NUM_add_UNKNOWN(sv1,sv2) { }
Now, how does does this function perform its calculation?
I'm guessing that Dan is planning to take advantage of addition and
multiplication being commutative.
sv1-add[UNKNOWN](sv2)
swaps to
sv2-add[NUM](sv1)
(It's "obvious" in the usual way - not obvious until you see it. I've been
prodding in pp_add in perl5, so I've been thinking about these sort of
things)
My original suggestion was that scalar types provide a method that says
how 'big' it is (so complex bigreal real int etc),
and pp_add(), pp_sub() etc use these values to call the method associated
with the biggest operand, swapping args if necessary (and passing a flag
indicating that arg swapping has taken place).
Re: Opcodes (was Re: The external interface for the parser piece)
At 02:01 PM 12/7/00 +, David Mitchell wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
On Thu, Dec 07, 2000 at 01:14:40PM +, David Mitchell wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
All the math is easy if the scalars are of known types. Addition and
multiplication are easy if only one of the scalars involved is of
known
type. Math with both of unknown type, or subtraction and division
with the
right-hand operand of unknown type, is rather more difficult. :(
I'm not clear with your scheme how addition works if one of the scalars
(the adder) is of unknown type. ie
given sv1 of type NUM, sv2 of type UNKNOWN; $sv1 + $sv2 would invoke:
sv1-add[UNKNOWN](sv2),
which somewhere will cause a function in the vtable for NUMs to be
called,
eg
NUM_add_UNKNOWN(sv1,sv2) { }
Now, how does does this function perform its calculation?
I'm guessing that Dan is planning to take advantage of addition and
multiplication being commutative.
sv1-add[UNKNOWN](sv2)
swaps to
sv2-add[NUM](sv1)
(It's "obvious" in the usual way - not obvious until you see it. I've been
prodding in pp_add in perl5, so I've been thinking about these sort of
things)
And all that was what I was thinking.
My original suggestion was that scalar types provide a method that says
how 'big' it is (so complex bigreal real int etc),
and pp_add(), pp_sub() etc use these values to call the method associated
with the biggest operand, swapping args if necessary (and passing a flag
indicating that arg swapping has taken place).
Right, but that only works when the two scalar types are in the same line.
If, for example:
my Complex $s1 = 4 + 4i;
my Image $s2 : filename(foo.gif);
$s3 = $s1 + $s2;
how would you handle the addition if perl doesn't know about complex types?
You've got two entirely different scalars that really have no basis for
comparison to judge which is really 'bigger' than the other.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Guaranteed object destruction (was Re: Meta-design)
At 11:17 AM 12/7/00 +, Piers Cawley wrote:
Buddha Buck [EMAIL PROTECTED] writes:
It seems to me that there are three types of thingies[1] we are
concerned about, conceptually:
A) Thingies with no DESTROY considerations, which don't need refcounts.
B) Thingies with DESTROY methods, but aren't timing-sensitive. They
can be destroyed anytime after they die. These don't really need
refcounts either.
C) Thingies with DESTROY methods which need to be DESTROYed as soon as
they die. These would seem to need refcounts.
I think that distinguishing between B and C is a syntax issue out of
scope here. Although B could be lumped with A if we could tell B and
C apart, I'll assume that we must lump B and C together.
I wonder if a syntax wart like:
sub DESTROY : immediate {
...
}
wouldn't be a good idea. Only catch with this is with inherited
DESTROYs, compounded if Damian's RFC about hierarchically called
DESTROY methods gets accepted. Hmm... the more I think about it, the
more I think it would be a bad idea. Though it might be nice if the
programmer can use ' : immediate ' as a 'hint' that may not get taken
in the initial versions of Perl6...
I think I'd just as soon always call DESTROY in a predicable manner and not
do *anything* perlish at GC time. If nothing else it means that we don't
have to worry about having a valid perl context handy when the GC runs.
(Since threading the thing is a possibility we might run into issues otherwise)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Meta-design
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 that's a big beast. My concern is *can* we support it on architectures that don't have a native C compiler (i.e., the JVM). So port GCC to the JVM, solving all your problems and a lot more besides. It seems like everyone has their axes to grind on this one: Bradley thinks the world must be built in Java, Nate thinks the world must be made of objects, I think the world must be made of Unicode, I'm sure there's *at least* one XML axe-grinder out there, and everyone else has got their axes that we haven't found out about yet. The game is to build Perl without getting our heads chopped off. -- I wish my keyboard had a SMITE key -- J-P Stacey PGP signature
Re: Guaranteed object destruction (was Re: Meta-design)
Dan Sugalski [EMAIL PROTECTED] writes: I think I'd just as soon always call DESTROY in a predicable manner and not do *anything* perlish at GC time. If nothing else it means that we don't have to worry about having a valid perl context handy when the GC runs. (Since threading the thing is a possibility we might run into issues otherwise) So objects that get caught up in a circular reference chain don't get their DESTROYs called? I'm not sure I'd be up for that. In fact, I'm sure I *wouldn't* be up for that. Or are we gonna still need 'use WeakRef'? -- Piers
Re: Guaranteed object destruction (was Re: Meta-design)
At 05:55 PM 12/7/00 +, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: I think I'd just as soon always call DESTROY in a predicable manner and not do *anything* perlish at GC time. If nothing else it means that we don't have to worry about having a valid perl context handy when the GC runs. (Since threading the thing is a possibility we might run into issues otherwise) So objects that get caught up in a circular reference chain don't get their DESTROYs called? I'm not sure I'd be up for that. In fact, I'm sure I *wouldn't* be up for that. Or are we gonna still need 'use WeakRef'? The problem there is that there's no good deterministic way to catch that short of doing a full mark and sweep (or something similar) each time we toss a pad that's got references in it. I suppose we could track pad references and variable references separately and do a quick walk through things when we trash a referring variable or pad, but I can see that getting expensive. Maybe. (On the other hand, if it's correct...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Meta-design
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 BETTER to code in. And WAY WAY LESS FAMILIAR to most coders here, at a guess. C is a lingua franca. Let's try and deliberately *lower* the barrier of entry, rather than forcing people to pole-vault. That said, C++ does have *something* going for it. Or at least, I suppose it must have. -- As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie
Re: Perl6 in Java? (was Re: Meta-design)
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 language. Uhm. I can't work this out. If we target a particular compiler, we only get the platforms that supports. If we target a particular language, we get all the platforms from all the compilers of all the implementations of that language. (... she had to walk into mine.) -- "There is no statute of limitations on stupidity." -- Randomly produced by a computer program called Markov3.
Re: OO AV/HV's and tie (was Re: Meta-design)
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-length)() which seems to be what you want above. Currently the only difference between accessing an AV's member's value, an HV's member's value, or an SV's value is an extra argument to the vtable call. I wasn't thinking about accessing values, (which obviously should be as you say) but things like methods to implement $#array, keys %hash, and so on. -- "He was a modest, good-humored boy. It was Oxford that made him insufferable."
Re: Meta-design
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 seen some hard data like this in a while) Freeing SVs does appear to be inexpensive but called often. What the *hell* is wrong with modulo? Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls us/call us/call name 6.78 0.24 0.24 103395 2.32 3.44 Perl_pp_entersub 6.50 0.47 0.23 293 784.98 785.60 Perl_yyparse 5.08 0.65 0.18 240946 0.75 1.07 Perl_sv_upgrade 4.80 0.82 0.17 358052 0.47 0.47 Perl_sv_free 3.95 0.96 0.14 414761 0.34 0.35 Perl_av_fetch 3.95 1.10 0.14 129276 1.08 1.08 Perl_leave_scope 3.95 1.24 0.1480278 1.74 2.13 Perl_yylex 3.39 1.36 0.12 100035 1.20 1.20 Perl_pp_rv2av 3.11 1.47 0.11 101561 1.08 1.37 Perl_pp_leavesub 2.54 1.56 0.09 187966 0.48 0.52 Perl_sv_clear 2.54 1.65 0.0999979 0.90 1.42 Perl_pp_subtract 2.54 1.74 0.0925857 3.48 4.28 Perl_fold_constants 2.26 1.82 0.08 136689 0.59 0.59 Perl_pp_gvsv 2.26 1.90 0.08 112675 0.71 0.71 Perl_pp_lt 2.26 1.98 0.0872402 1.10 1.10 Perl_pp_and 1.98 2.05 0.07 403317.3660.47 Perl_runops_debug 1.69 2.11 0.06 304563 0.20 0.20 Perl_pp_aelemfast 1.69 2.17 0.06 204203 0.29 0.29 Perl_pp_gv 1.69 2.23 0.0698023 0.61 0.61 Perl_pp_aelem 1.69 2.29 0.0644511 1.35 1.35 S_new_xpv 1.69 2.35 0.0611710 5.12 5.12 Perl_newSVsv 1.69 2.41 0.06 9561 6.28 6.28 Perl_pad_free 1.41 2.46 0.05 100926 0.50 0.50 Perl_pp_cond_expr 1.41 2.51 0.05 7517 6.65 8.07 S_scan_str 1.13 2.55 0.04 194962 0.21 0.21 Perl_safemalloc 1.13 2.59 0.04 168220 0.24 0.24 Perl_pp_nextstate 1.13 2.63 0.04 126366 0.32 0.32 Perl_push_scope 1.13 2.67 0.04 119018 0.34 0.34 Perl_save_int 1.13 2.71 0.0487550 0.46 0.46 Perl_sv_mortalcopy 1.13 2.75 0.0439416 1.01 1.01 Perl_pp_gt 1.13 2.79 0.0413139 3.04 3.04 Perl_pp_or 1.13 2.83 0.0411415 3.50 3.59 Perl_sv_catpvn 1.13 2.87 0.04 105437.9537.95 S_reg 0.85 2.90 0.03 103658 0.29 0.29 Perl_pop_return 0.85 2.93 0.0312285 2.44 2.44 S_null 0.85 2.96 0.0310968 2.74 2.74 Perl_linklist 0.85 2.99 0.03 9734 3.08 3.08 Perl_pad_alloc 0.85 3.02 0.03 6611 4.54 4.54 Perl_cast_i32 0.85 3.05 0.03 4510 6.65 6.65 Perl_save_I16 0.85 3.08 0.03 201614.8814.88 S_regatom 0.85 3.11 0.03 68243.9946.95 Perl_peep 0.85 3.14 0.03 55354.2554.25 S_cl_anything 0.85 3.17 0.03 main 0.56 3.19 0.02 285176 0.07 0.07 Perl_pp_const 0.56 3.21 0.02 173286 0.12 0.45 Perl_sv_setnv 0.56 3.23 0.02 126149 0.16 0.16 Perl_pop_scope 0.56 3.25 0.02 125933 0.16 0.99 Perl_sv_setsv 0.56 3.27 0.02 111495 0.18 0.18 Perl_save_vptr 0.56 3.29 0.0280051 0.25 1.00 S_op_clear 0.56 3.31 0.0219783 1.01 1.53 Perl_pp_add 0.56 3.33 0.0218407 1.09 1.09 Perl_av_store 0.28 3.34 0.01 145323 0.07 0.07 Perl_pad_sv 0.28 3.35 0.01 138211 0.07 0.07 Perl_pp_pushmark 0.28 3.36 0.01 103776 0.10 0.10 Perl_push_return 0.28 3.37 0.0189857 0.11 0.11 Perl_scalar 0.28 3.38 0.0152614 0.19 0.37 Perl_sv_grow 0.28 3.39 0.0133650 0.30 0.30 Perl_free_tmps 0.28 3.40 0.0133022 0.30 0.93 Perl_sv_2nv 0.28 3.41 0.0124868 0.40 1.67 Perl_sv_setpvn 0.28 3.42 0.0119506 0.51 0.51 S_dopoptosub_at 0.28 3.43 0.0117778 0.56 1.67 Perl_gv_fetchpv 0.28 3.44 0.0117724 0.56 1.08 Perl_block_gimme 0.28 3.45 0.0111338 0.88 1.09 Perl_newUNOP 0.28 3.46 0.01 9651 1.04 1.04 S_new_xpviv 0.28 3.47 0.01 9471
Re: Meta-design
often. What the *hell* is wrong with modulo? It does sort of stand out, doesn't it...floating point divide? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Meta-design
Simon Cozens wrote: On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote: [C++] It's nearly as portable, Uhm. Is this actually true? I don't know. Sounds reasonable! :-) Aside from lame-o solutions like C-front and cross-compiling, I'd say, screw 'em if they don't have a C++ compiler. Are there any non-fragile implementations of C++ yet? What do you mean by fragile? Certainly there are solid, "industrial-grade" C++ compilers for some platforms. As an example, (and yes it pains me to say it), Microsoft's C++ compiler is amazingly good in just about every conceivable way. (O.k., there are some stupidnesses wrt its idea of a shared library, but that's irrelevant to the C-vs-C++ issue.) nearly as fast, Why have nearly as fast, when you can have as fast? I can think of several things I'd be willing to trade a little bit of speed for. Would I be using Perl if I didn't feel that way? and WAY WAY BETTER to code in. And WAY WAY LESS FAMILIAR to most coders here, at a guess. Is that so critical? Then maybe we really *should* write perl in Perl. That said, C++ does have *something* going for it. Or at least, I suppose it must have. Qt? (Or is it GTK?) In my "real" life, I work on a large system (around 100,000 lines), and I truly shudder to think how much more grotesque and difficult to maintain it would be if it were written in C instead of C++. -- John Porter I saw the final vicar make confession to a dancer We stood upon the bridge at dawn and the dancer kissed my cancer
Re: Meta-design
On Thu, Dec 07, 2000 at 02:33:53PM -0500, John Porter wrote: Simon Cozens wrote: On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote: [C++] It's nearly as portable, Uhm. Is this actually true? I don't know. Sounds reasonable! :-) What did Chip learn from Topaz? (IIRC that was C++) That's hard experience of trying to write perlguts in C++ perl5 is hard experience of trying to write perlguts in C (or C Pre Processor) What was Sapphire's implementation language? What were its lessons? Probably more useful than backwards-forwards polite, well reasoned but ultimately theoretical arguments. [Was it medieval scientists who preferred reasoning to experiments?] Nicholas Clark
Re: Meta-design
Sam Tregar wrote: Which also brings up another point - choosing anything but C is likely to have a direct impact on our existing userbase. I have a suggestion - if a system compiled and ran Perl 5 then it should be able to compile and run Perl 6. No upgrades required. The Backwards Compatibility Beast rears its slathering, kerotic heads... -- John Porter I saw the final vicar make confession to a dancer We stood upon the bridge at dawn and the dancer kissed my cancer
Re: Meta-design
On Thu, Dec 07, 2000 at 02:33:53PM -0500, John Porter wrote: Simon Cozens wrote: On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote: [C++] It's nearly as portable, Uhm. Is this actually true? I don't know. Sounds reasonable! :-) Aside from lame-o solutions like C-front and cross-compiling, I'd say, screw 'em if they don't have a C++ compiler. I restrain myself from the obvious vulgar reply. What do you mean by fragile? Certainly there are solid, "industrial-grade" C++ compilers for some platforms. So you plan on limiting Perl to be running only on those platforms? Good luck on your crusade. Why have nearly as fast, when you can have as fast? I can think of several things I'd be willing to trade a little bit of speed for. Would I be using Perl if I didn't feel that way? You seem hell-bent to gain popularity and support, don't you. In my "real" life, I work on a large system (around 100,000 lines), and I truly shudder to think how much more grotesque and difficult to maintain it would be if it were written in C instead of C++. I believe you, I'm happy for you, but that's really irrelevant. I wish all the people suggesting 'Perl 6 should be written in X' would read carefully the 'Supported Platforms' section in perlport (5.6.0) and make a checklist: does their wonderful X (a) exist (b) work (c) work effectively on all those platforms? If the answer is 'no', you are taking Perl away from the people who want to use Perl on that platform. As simple as that. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Meta-design
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
Re: Meta-design
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.
Re: Meta-design
Jarkko Hietaniemi wrote: You seem hell-bent to gain popularity and support, don't you. Do I? "Hell-bent"? When it comes right down to it, the likelihood that I personally will contribute to the core is vanishingly small, regardless of language. So, I guess you can defend your own choice of poison. I believe you, I'm happy for you, but that's really irrelevant. Well, yes; one data point is statistically irrelevant, without a doubt. you are taking Perl away from the people who want to use Perl on that platform. As simple as that. Almost. You're potentially taking away Perl6, which is vaporware. I wonder: In what order will the following exist on Handheld Device Foo: - C - C++ - Java - Perl6 -- John Porter
Re: Meta-design
Simon Cozens wrote: Great. When it comes down to it, what are you doing here? Excellent question. -- John Porter
Re: OO AV/HV's and tie (was Re: Meta-design)
At 07:02 PM 12/7/00 +, Simon Cozens wrote: 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-length)() which seems to be what you want above. Currently the only difference between accessing an AV's member's value, an HV's member's value, or an SV's value is an extra argument to the vtable call. I wasn't thinking about accessing values, (which obviously should be as you say) but things like methods to implement $#array, keys %hash, and so on. Well, I've had evil ideas that $#array would look like: array-get_int[IV](SCALAR); or array-set_int[IV](12); depending on whether it's used in an rvalue or lvalue context. Seems sensible to use the scalar versions of the vtable calls if the AV's used in scalar context. Things like keys and each on hashes would likely need extra vtable entries, but that's fine. (I can see crocking the get_* entries for keys and each, but there are limits... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Call for apprentice: was Re: Meta-design
I would like to do this, but I think its a bigger job than you imagine, and... "I tend towards insanity from time to time. Good thing its only perl." (you can quote me) (It comes from stresses developing sysadm apps around the single largest depository of human wealth. They actually smothered a pregnent woman to death here rather than open a fire door in a valult room, by way of example--- I really need a new contract.) There is a new group forming from milder NY mongers called Perl-Seminars organized by guinevere liberty [EMAIL PROTECTED] one of the few female mongers and someone who I put a lot of effort into bringing into the monsters, err mongers. I got really excited by the possibility of crossing over between Python, Blackdown Java, and Perl in terms of internal pieces. Maybe this is the place to start that process. That would make three layers: top-ten, really-experienced-VM-coders(kibbitzers), and the apprentices. I also think that an organization like Hewlett Packard would be a huge benefit because of their commitment to QA. John On Wed, 6 Dec 2000 17:05:30 +, Simon Cozens [EMAIL PROTECTED] wrote : On Wed, Dec 06, 2000 at 11:48:45AM +, Nicholas Clark wrote: (Is maintaining such a document an "apprentice" job? (see perl6-meta)) I'd certainly like someone to take on the maintainance of the document I posted last night, because I hope that one of its functions will be to explain to apprentices a little of some of the concepts that we're dealing with; I tried to do that in places, but it got late. So, anyone want to volunteer? What maintainance would involve would be, I think, receiving forwarded messages from perl6-internals-design (or whatever) with bits marked "We need to remember to think about this more!", and making sure those bits are covered on the meta-design, with an option on learning about the topic and writing a short summary for everyone to gain from. It would probably also need updating when we settle one of the issues on 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
Supporting architectures without native C support (was Re: Meta-design)
At 07:49 AM 12/6/00 -0800, Daniel Chetlin wrote: Simply deciding that `eval STRING' is "unimplemented" on these theoretical ports and binary compiles is the best idea I've heard yet, but we should remember that `require' is built on `eval STRING'. On Wed, Dec 06, 2000 at 08:30:06PM -0500, Bradley M. Kuhn wrote: I see no reason to ghettoize powerful non-C-based systems just because we Jarkko Hietaniemi [EMAIL PROTECTED] wrote: Powerful? Java? Excuse me, I have must have picked the wrong reality. I certainly understand the average Perl hacker's distaste for Java, and I don't blame you for it. Comparing Perl to the Java language itself isn't fair to Perl nor Java, and I agree Perl is much better, anyway. However, the JVM is a powerful environment for generalized bytecode and for allowing bytecode of different languages to communicate. Also, it is gaining some support in embedded circles. Motorola is releasing a unit that will have a JVM in the device. PocketLinux, a new product, is completely JVM-based. Perl should be able to run in these environments. Regardless of our personal feelings about Java, we should not refuse to support JVM-based architectures. This would be like saying: "We won't support Microsoft, because many Perl hackers don't like it." Soon, there will likely be JVM systems that can run eval($string) quickly enough, but not if it is written in C (as there is no C-JVM compiler). I have seen a real Java implementation by Sun. It was written in C. Yes, when you are running on a canonical computer, there will be little reason to run Perl on a JVM. However, IMO, we should not ignore the possibility of: * embedded devices based around the JVM or other virtual machine architectures (like C#, or IBM's virtual machine project). * the usefulness of using Java interfaces for an integrated scripting environment for many languages (for example, Kawa). * the desire for people to reimplement parts of perl6 in a language of their choice for some reason we haven't thought of yet! Why should we center our entire design around C? Sure, the canonical perl6 implementation will be in C, but do we really want to be as sharply tied to the C implementation of perl6 as we are tied to the C implementation of perl5? -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: Supporting architectures without native C support (was Re: Meta-design)
On Thu, Dec 07, 2000 at 10:23:55PM -0500, Bradley M. Kuhn wrote: At 07:49 AM 12/6/00 -0800, Daniel Chetlin wrote: Simply deciding that `eval STRING' is "unimplemented" on these theoretical ports and binary compiles is the best idea I've heard yet, but we should remember that `require' is built on `eval STRING'. On Wed, Dec 06, 2000 at 08:30:06PM -0500, Bradley M. Kuhn wrote: I see no reason to ghettoize powerful non-C-based systems just because we Jarkko Hietaniemi [EMAIL PROTECTED] wrote: Powerful? Java? Excuse me, I have must have picked the wrong reality. I certainly understand the average Perl hacker's distaste for Java, and I I hope you don't think me as a Perl hacker, I'm a Perl internals hacker... no, I'm serious. For good or bad, I don't actually much program in Perl, I don't have the time. In my day job I nowadays do C, Java, JNI. don't blame you for it. Comparing Perl to the Java language itself isn't fair to Perl nor Java, and I agree Perl is much better, anyway. However, the JVM is a powerful environment for generalized bytecode and for allowing bytecode of different languages to communicate. Words, words, words. I still haven't seen a platform where Java runs anywhere near native code, I still haven't seen Java being as portable a Perl scripts. Also, it is gaining some support in embedded circles. Motorola is releasing a unit that will have a JVM in the device. PocketLinux, a new product, is completely JVM-based. Perl should be able to run in these environments. Regardless of our personal feelings about Java, we should not refuse to support JVM-based architectures. This would be like saying: "We won't support Microsoft, because many Perl hackers don't like it." I didn't say that we shouldn't be friendly to JVM, PyVM, .NET, or whatever. It was just the mere thought of implementing Perl in Java that scared my out of my wits and I proceeded hastily to shoot the bad thought down before it grows, like a cancer... Why should we center our entire design around C? Sure, the canonical perl6 Because that's what we got. Because that's what we have in the maximal number of platforms. Because that's what works. implementation will be in C, but do we really want to be as sharply tied to the C implementation of perl6 as we are tied to the C implementation of perl5? If we can't do it in C, we can't do in Java. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Perl6 on handhelds (was Re: Meta-design)
John Porter [EMAIL PROTECTED] wrote: Almost. You're potentially taking away Perl6, which is vaporware. I wonder: In what order will the following exist on Handheld Device Foo: - C - C++ - Java - Perl6 I know of at least one hand-held on the market (PocketLinux) that is basically Java-based. (My understanding is that they run enough of Linux to make the JVM work. ;) As mentioned elsewhere in the thread, Motorola has a JVM-based device coming out, too. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: Supporting architectures without native C support (was Re: Meta-design)
On Thu, Dec 07, 2000 at 10:23:55PM -0500, Bradley M. Kuhn wrote: However, the JVM is a powerful environment for generalized bytecode and for allowing bytecode of different languages to communicate. So's Microsoft vaporware ".NET platform". And the second version of that bytecoded runtime will be even more so. And the third version of that bytecoded runtime even *more* so, almost to the point of being useable. Perl should be able to run in these environments. Yes. That's an argument for being [A-Z]VM friendly, not [A-Z]VM centric. Why should we center our entire design around C? Because Perl is a write-once-run-anywhere platform, and C is the only viable way of maintaining Perl support on all of the platforms currently supported. Because most (all?) of the people interested in implementing Perl6 are extremely fluent in C. Because C doesn't have Java's unnecessary complexities which hindering large-scale projects. Because the Python folks didn't have a problem basing JPython off of CPython. Because it's looking like a Perl6 program will parse Perl6 code, forcing any Java-, Smalltalk-, Python-, C++-, or INTERCAL-based reimplementations of the Perl runtime to reimplement the just runtime ops and support as appropriate, not the nasty parsing bits. Because it's a Simple Matter Of Programming to reimplement a C program as a Java program, given enough tuits. Now, can we put this JVM thread to bed? Please? Z.
Re: Perl6 on handhelds (was Re: Meta-design)
At 10:46 PM 12/7/00 -0500, Bradley M. Kuhn wrote: John Porter [EMAIL PROTECTED] wrote: Almost. You're potentially taking away Perl6, which is vaporware. I wonder: In what order will the following exist on Handheld Device Foo: - C - C++ - Java - Perl6 I know of at least one hand-held on the market (PocketLinux) that is basically Java-based. (My understanding is that they run enough of Linux to make the JVM work. ;) As mentioned elsewhere in the thread, Motorola has a JVM-based device coming out, too. There are going to be two classes of perl systems--those that can turn perl source into something executable, and those systems that can execute that output. The handhelds, palmtops, and embedded systems (as well as most of the JVM targets, honestly) are in the latter class. Something somewhere eats the perl source and spits out either perl bytecode or something native to the platform. (Java bytecode, executable images, or something of the sort) You transfer the output over to the target system and execute it. Sure, the target can't do string eval, or compile it's own perl code, but that's not a big deal. The eval issues can be easily worked around if you know the target system doesn't support it, and the lack of a compiler in general's not a huge deal, since nobody sane would try and scribble in any perl source of consequence. (And no, I won't take bets that nobody on this list would ever try... :) (I should point out that lots of folks manage to run a lot of code written in C without having an embedded C compiler in each of those apps) The former class will initially consist of systems that can run the reference version of perl we put out, but one of the big goals I have is to get everything specified enough that someone can produce another version of perl from scratch. That may be one written in Java, and that's fine, or it may be some nutcase that produces a perl front-end for GCC, or it might be IBM deciding that they can just do it better than we can. Any one, or all, of those is fine. (I, for one, would be thrilled if someone with some serious engineering talent produced their own perl...) The final specs that define those bits of perl's internal behavior that are user-visible (like the hooks in the parser, or how you write scalar vtable functions in perl) will be either language neutral or perl-centric. The parts that aren't user-visible (like how the GC is implemented (as opposed to its existence), or the internal format of scalars) will likely be C-centric. Or eccentric. Or both. Regardless, it's not important, since they're pieces that won't need to be emulated by anyone writing their own version. That should, I think, be enough to put this to rest. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
