I am sure that Larry won't be writing an apocalypse on licensing anytime
soon, but in the meantime I was reading over the Artistic-2.0 proposal and
noted a minor grammar error in it.
I can't update the RFC, but figured I'd post the bugfix here. Attached is
a unified diff and a full copy of the c
though, I have a procedural question:
Does anyone know if Larry is considering "leave it as it is" for all
options on RFCs? Chris noted that there wasn't a point in writing an RFC
that said: "perl's license stays the same", because it was implicit. I
wasn't clear that it was implicit. Have I misunderstood?
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
C to propose that Perl go under an
X11-style license, but no one picked up the ball.
(I personally prefer my (Artistic-2.0|GPL) proposal, and Larry already
teased me (friendly, of course ;) about writing RFCs that I didn't actually
agree with, so I didn't bother to champion X11-style
s tend to go right for the legal "heart of the matter",
friendly, non-legally binding statements accompanying licenses stating
intent can certainly go a long way in making people feel comfortable with
the licensing scheme. Lawyers are people too, after all. ;)
--
Bradley M. Kuhn -
was basically dead, except
for me posting revisions of RFCs. I hope that I properly caught the spirit
of the consensus properly, but without feedback, that was a hard job.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
many free software and open source licenses
for this problem to be easy to solve.
I hope the RFC to continue the life of this group will be accepted.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
off-topic, but if people are unclear about
why the RFCs were written as they were, then it's worth discussing it.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
> "Bradley M. Kuhn" <[EMAIL PROTECTED]> wrote:
> >The FSF surely wants Perl to be under a GPL compatible license (and,
> >(GPL|SOMETHING) is always GPL-compatible, by default). I don't think the
> >FSF has ever expressed a desire that Perl be GPL-only
rectly) is that
> he would not be by personality inclined to seek legal redress even if it
> were clearly within his rights to do so.
Well, I don't think there's much point in inferring what Larry will do. An
RFC concerning the trademark/service mark is under his advisement---we
g of the consensus is that we don't want Perl hackers at
companies to ever have to say: "I wanted to use and ship Perl, but the
company lawyers weren't comfortable with perl's license, so I didn't."
I think the proposed AL-2.0 will have better success in this regard than t
ense, and so that it
is completely clear that businesses who want to redistribute Perl for profit
can do so unfettered. I wrote an RFC to propose such corrections to the
Artistic license. We'll have to wait and see what Larry says about it.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
in Larry's
name, and have the trademark license require that if they call it "Perl", it
really is the canonical Perl implementation. (I believe I wrote an RFC that
proposed this; it's presumably currently under Larry's advisement).
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
discussions, please separate out your responses into multiple messages and
move the off-topic messagse to other lists and/or private email.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
one? It's sadly too late to make changes in this round, as it's Larry's
hands, but I would like to hear from you how we might make it more readable
and perhaps propose a modified RFC to Larry at a later time.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ing is designed,
in part, to prevent schisms by allowing each part of the community to get
what it wants.
The question was: "Did the old Artistic license do what we wanted?" I
argued "no" in my RFCs. Some folks argued "yes". We'll see what Larry
decides.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
> with a "least of all evils" solution, I think, and I feel very strongly
>
> Where can this summary be found?
See the RFC's produced by the licensing working group, and feel free to post
questions to <[EMAIL PROTECTED]>.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ink this makes a lot of sense.
Yes. I wrote an RFC about this, which you should be able to find in the RFC
archives. I don't have the number handy, but it is in the two-hundreds,
IIRC.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
that went in was (Artistic-2.0|GPL).
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
it.
As far as I can tell, this is FUD. Can you produce statements from these
lawyers? Every lawyer I have ever met things it is legally sound, including
those lawyers who are trying to find ways to violate it!
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
> At 12:29 AM 1/5/01 -0500, Bradley M. Kuhn wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > I'm beginning to loathe software licenses in a *big* way, and I'm a half
> > > step away from saying to hell with it all and going fully publi
> On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
>
> > I personally think that the relying on LGPL'ed code is completely
> > reasonable. Some will disagree, so we need to come to a consensus on this
> > as a community.
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> Liceses. Bletch.
Don't blame the licenses, blame the copyright law that makes them an
unfortunate necessity in many cases.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ensus on this
as a community.
Also, note that as long as our license is compatible with the LGPL (and
most licenses are). There are no licensing problems for us, but we might be
creating hassles for those who redistribute proprietary software versions of
perl.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
minated strings, blocks with lengths, other things
>native to other languages
> * files (by filename, file/socket handle, C FILE*, C++ istream, IO
>system appropriate to the language you're embedding in)
That seems like only sources I can think of
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
print "$PROMPT ";
$string .= ; chomp $string;
$parseTree = $interp->Parse($string, $handleError);
}
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
d to do", from a programming point a view, given that the
Turing indicated that it can be done by a program in polynomial time. There
is not a definitive way to "prove" coming up with that polynomial time
algorithm is hard. ;)
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
likely. Given that my "write it all in Java" proposal was
shot down with very good arguments, I wouldn't ask for these sorts of parts
to be anything but in C, and eccentric. ;)
Internals of scalars: C
API to scalars: language independent
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ou chapters of my Master's
Thesis that I am finishing up this month, that is making the detailed
arguments as to why it is a hard problem.
I believe the difficult that we've had porting perl5 to the JVM is a bug in
perl5's design. I am trying to encourage people to fix that bug in perl6.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
design doesn't have to center around the langauge we choose to
implement that design, though.
We've got C for the implementation and that's fine. But, why design it so C
is the only choice for a language?
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
t 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
choice other than to treat the JVM like "just
another processor". But the JVM isn't just a processor, it's also an object
model. If a port isn't aware of that object model, then the usefulness of
the JVM port is greatly reduced. I'd be happy to talk more about this with
you off-list if you are interested.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ember 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,
> On Wed, 6 Dec 2000, Bradley M. Kuhn wrote:
>
> > And, it will make the barrier for entry for new internals hacker lower.
Sam Tregar <[EMAIL PROTECTED]> wrote:
> Really? Do you honestly believe there are more Java programmers than C
> programmers? Particularily
`eval STRING'.
I see no reason to ghettoize powerful non-C-based systems just because we
write the canonical perl6 implementation in Perl.
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).
#x27;t have a native C compiler (i.e., the JVM).
I think that's the first and foremost concern with eval($string) (and hence,
the parser). Slow things can usually be made faster, but "can't get there
from here" is often hard to solve.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Sorry. I didn't mean those should be methods Scalars have! I was just
trying to show the kind of documentation I'd like to see. I wasn't trying
to produce said documentation. :)
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ace should be documented outside of the
implementation. I was just concerned because much of the internals has been
C-specific thus far.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
going to change with the release of GCC 3.0, based on current
benchmarks of test releases of GCC 3.0.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ith
both the performance and ease of use.
The argument is: "Computers do a better job at memory allocation than humans
do by hand, so let the computer do it!"
I think we should give this idea some serious consideration.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Some people who aren't on the design team may want to follow the progress,
but aren't particularly interested in the public list.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
is to use B:: to port Perl to the JVM, I think I'll
be satisfied.
(And, I should not that simply writing clear, well-defined APIs for all
internal data structures should be enough to reach that goal.)
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Simon Cozens <[EMAIL PROTECTED]> wrote:
> 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 co
discussion still quite abstract (i.e., we have no
APIs ;), I am unable to talk myself down that this won't be a problem. Can
someone else talk me down? ;)
(BTW, I'd like to be able to do the same thing in Scheme, too, for better
Guile integration, but that's more pie-in-the-sky. ;)
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
set of Perl. :)
(I was the only one who clapped, which either means:
(a) this is not a popular idea
(b) there weren't many Perl6 hackers in the crowd
(c) I am extremely over-exited about the prospect of writing the lexer
and parser in Perl. :)
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
the trademark, and the code copyrights,
> to Yet Another Society? (http://yetanother.org/) It's an independent
> society set up by Kevin Lenzo and some Perl luminaries to promote and
> protect Perl.
That's a good idea. I wish you'd have mentioned it while the RFC could
that come up. RFC
13 brings up this issue.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Nathan Torkington wrote:
> Bradley M. Kuhn writes:
> > It seems to me that the perl6-internals, perl6-qa, and perl6-licenses groups
> > should be able to produce additional RFCs after this. Of course, the
> > Language will be frozen, but these three groups may need to remai
renders this unenforceable" or "this is doesn't fit the open
source software defintion and/or isn't a free software license".
Other than that, it shouldn't change.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
-profit motives holding up a
> rebellion that was exclusively profit-motive based in support of their
> arguments is not lost on other non-US members of this list.
Indeed, it isn't lost on some USA members either. :)
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
l6-internals, perl6-qa, and perl6-licenses groups
should be able to produce additional RFCs after this. Of course, the
Language will be frozen, but these three groups may need to remain fluid
after the 14 October 2000 annoucement.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
I just froze the RFC that contains Artistic-2.0.
Here are the differences between beta3 and beta4 of the Artistic License.
I did the following things:
* clarified the "In addition," confusion that Dave brought up.
* Returned to saying "Freely Available" instead of "Exact License of". I
o
as far as we can and still permit proprietary software versions of Perl, as
long as they are called FooPerl.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
butable in source and binary if it's
> perl. Everything else is fine and dandy.
This is the case---if they call it the same name as Package, the source must
be Freely Available. They can still call it VisualPerl if they install it
to a different place. Only a trademark on Perl can stop that.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ense does the best it can to reach
this goal.
I have seen few comments on it, though.
Ben, how do you feel about it?
Chris?
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
> New Perl Mascot
>
> Maintainer: David Grove <[EMAIL PROTECTED]>
> Date: 28 Sep 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 343
> Version: 1
> Status: Developing
I basically agree that we need a mascot, and one that isn't encumbered by a
proprietary trademark license.
Howeve
> The Artistic License
> Version 2.0beta3, October 2000
I just realized that some of you might have read 2.0beta2 and don't want to
take the time to read beta3. Here's the change, so you can view them
quickly. I'll do the same for future ver
th a trademark on Perl;
but that would be up to Larry to decide to go for the trademark.
> This appears to provide such a loophole that needs to be closed.
I don't see the loophole you are describing, at least not in (7) and (8). I
realize that (5b) is a so-called "loophole" that allows PerlEX and
PerlScript, but I don't think the Perl community wants to close that
"loophole"; to do so would be going the full copyleft route.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ll note in the documentation to say:
"You can get the source of this if you want, upon request".
I did reword (6c) a bit to make it clearer:
(c) ensure that the Modified Version includes notification of the
changes made from the Standard Version, and offer the
ation describing how it differs from the
Standard Version, and rename your Modified Version so that the
name is substantially different from the Standard Version.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
claimed Larry should get a trademark on "Perl", in the area of computer
science, and license it freely to anyone who uses the Standard Version of
"Perl", but not to those who aren't using the Standard Version. This would
help reach the goal that the Artistic License tries for.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ure enough to give up the camel
image.
> OT: What's the history of the camel? Does it predate O'Reilly's involvement?
Larry Wall probably knows for sure, but I believe O'Reilly was the first to
use the camel in reference to Perl.
I started using Perl right a few months after the
n (7).
Version 2.0 addresses point (b) in (7).
Version 2.0 addresses points (c) and (h) in (8).
Version 2.0 addresses points (f) and (g) in (9).
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
In writing the last commentary, I noted some typos in my proposed Artistic
License.
I have corrected them, and here is 2.0beta2 of the license.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
The Artistic License
Version 2.0beta2, October
like this just give the copyright holders and
contributors a false sense of security, so I didn't add one. This issue
is addressed in libel and trademark law.
Ben's Section 2.11:
I am not sure what 2.11 is trying to do. It seems like it might be
trying to avoid licensing conflicts, which it really can't do with a
statement of that nature. Conflicts are conflicts, no matter what a
license says about trying to resolve them.
Ben's Section 2.12:
This seems to be rehash of the permissions already given, so I didn't
include it.
Ben's Section 3:
I used this almost verbatim. It seems good.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
al AL.
Late tonight, I plan to write an RFC proposal for the new proposed license.
Please post any comments on the new license that you have.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
The Artistic License
Versi
I got seriously sidetracked the last two days, and did not get to my
hacks of license Ben wrote. However, I think that it probably needs a full
rewrite. I am going to try to write a clearer text license that tries to
do what Bens seems to want, and post it tommorrow. I like the idea that
Ben propo
s
license and be able to understand it.
I will modify Ben's version, and will post my draft today or tommorrow
morning.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
, it seems like that group will just get started when
the language freezes, so there doesn't seem any reason to freeze
internals-RFCs by the deadline, either.
So, it'd probably be good if we changed some of the deadlines on the various
working groups to reflect reality. Comments?
--
subset of Perl that buys you a full
Perl parser.
So, I'd like to see the parser written in a simple subset of Perl or some
other small language that can be bootstrapped fast. And, if we pick a
simple subset of Perl, translating to efficient C probably shouldn't be too
hard.
Does this argument make sense? Comments welcome.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
cross Australia to deliver it, or a large fee may be "reasonable" just
> for the expertise to providing it on RTX11 8-inch floppies.
Have you taken a look at the RFC I posted after that? It redefines
"Reasonable Copying Fee" a bit better, I think.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
o agree with you, but I thought the "minimal change"
proposal had some merit, so I thought it deserved an RFC. Just because I
wrote the RFC doesn't mean I endorse that plan over some other one.
Perhaps I should say that explicitly in the RFC
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
> Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
> >I don't think this is completely out the question, either. I was actually
> >planning on writing an RFC that proposes that all contributions to the core
> >be copyright assigned to Larry.
Nick Ing-Simmons
g changes than he has to,
I still haven't seen your proposal on this issue exactly spelled out, but I
may have missed it. It sounds like an important proposal, and probably
deserves its own RFC, as these issues are seperate from actual license changes.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
t; could (after a specified period of public discussion with no remaining
> objections from copyright holders) relicense Perl really fly?
I am not sure I understand the question; perhaps I failed to read some of
the relevant discussion. Could you take a minute and point me to your
proposal in the archives?
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Nick Ing-Simmons wrote:
> Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
> >
> >(Think of it as writing a Last Will and Testament---you can do it on your
> > own in a pinch, but it's always better to write a draft and then have a
> > lawyer help you rewrite it
aw,
so I don't see the point in having it. This would be an issue for trademark
law.
With the addition of part e in section 5, I believe this is a free software
license, incompatible with the GPL. It's probably an open source license
too.
We'd need to run it by a lawyer to confirm that, though.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
ter off if a writer does. Lawyers are not well-versed, in
> >> general, in writing clearly.
> >
> >Comments like the above worry me a lot.
>
> And comments that are worried about such comments worry me a lot.
I agree with Chris on this point; I think it's ok if we right a license
draft, give it to a lawyer, get comments back, and iterate in that fashion.
As long as copyright lawyer tells us all the implications of our license,
there is no harm in writing it ourselves.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
opers to trust Larry
completely in matters of licensing, and thus copyright assign to him so he
can make changes as necessary.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Adams, Johnnie W wrote:
> Well, yesterday, after Bradley M. Kuhn wrote:
>
> "I have been talking with Eben Moglen, a prominent law professor at
> Columbia University, and he is willing to help us in developing some
> proposed new versions of
hould we try
to do it in a copyright license, or is trademark law a better approach?"
I will try to run this by Eben, if I can get some of his cycles (he is
helping pro-bono, so this might be hard). If anyone else has some lawyer
friends who are willing to help, that'd be great.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
meone else can find yet another lawyer to volunteer to help (and/or pay
one out of their own pocket), a second opinion is always useful.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
sion; we develop RFCs that Larry then
uses to make decisions about what should happen.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
anon CVS gateway be maintained.
Will this anonymous gateway have all the relevant meta-data? Will it look,
to a user of the gateway, like the live repository is CVS when they go
hunting through metadata?
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Adam Turoff wrote:
> On Wed, Sep 06, 2000 at 12:14:17AM -0400, Bradley M. Kuhn wrote:
> > Dan Sugalski wrote:
> > > The decisions should be based on technical merit and general availability.
> >
> > I would include "available under a free software licens
Dan Sugalski wrote:
> At 12:14 AM 9/6/00 -0400, Bradley M. Kuhn wrote:
> >Dan Sugalski wrote:
> > > The decisions should be based on technical merit and general availability.
> >
> >I would include "available under a free software license" as part of th
mous CVS access.
Finally, most free software and open source projects have standardized on
CVS. Do we really have a compelling reason to go against the standard?
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
it's
better to (a) stick with CVS or (b) wait for Simon's perforce-on-CVS hack or
(c) start with CVS, and add Simon's hack when it's available.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
M port to
support what they are doing out of the box. My concern is just that _other
parts of the core_ treat these vtable interfaces as a firewall, and do not
"reach in" past them.
If we find out they have to "reach in" later for performance, I see no
problem with that. I just don't want the design to depend on "reaching in".
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
that the more of the perl core that relies on
specific representations of data, the more complexity there is in porting to
other architectures.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
> arrays and hashes and wedge them in too.
Why not make the scalar, array, and hash vtables each be separate RFCs? Or,
am I over-engineering the problem?
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Dan Sugalski wrote:
> At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote:
> > > 2) Having a mechanism to automagically load in chunks of executable code
> > > only when needed would be nice
> >
> >I would take this one a bit further:
> >
> > 2a) It s
tion, and then we all came to a
consensus that it shouldn't be one. I never updated my patch, but offered
to. I will update my patch, if it's useful.
My patch had other changes, too, that we cam to a consensus on. Any chance
they'll be added, or is Ziggy just plain too busy? ;-)
y have gone beyond a subset of
Perl they sought to stay within.
This is primarily for compiling Perl to be run on embedded devices.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
epped out of the subset (see my other post on another
thread for more stuff about that).
My hope is that the perl6 (note case) will be able to provide me the hooks
I'd need to do that.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
27;t care much myself *how* it is done here, but something non-hokey would
be good. ;)
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
on happen automagically in the parser? (My
gut says "here there be dragons", but they don't seem like dragons that are
unslayable.)
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
For Perl5, I am
currently using Kawa as the Java IR and what B:: provides (for lack of
something better) as the Perl IR.
This is why I want such a clearly defined API for the IR and for any
internal data structures used by the IR---I'd like to write a backend that
morphs the Perl IR into the "Java IR" to generate JVM bytecode.
Dan, does that fit with your thinking?
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
> Internal String Storage to be Opaque
> Number: 131
> =item Why a single internal encoding?
FWIW, I would like to throw my support behind this proposal.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
nguage".
As the JVM porter, I'd like my life easy, but I don't expect perl6 to hand
me a JVM implementation---I just want to right components and interfaces so
it is not as hard as a job as it is for perl5.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
99 matches
Mail list logo