Re: licensing issues
Dan Sugalski [EMAIL PROTECTED] wrote: People who are going to steal the source will do so regardless of the license on the source, and the people who are going to respect the license will do so regardless of which it is. The license has to be sound, clear, and defendable legally---that makes a difference. That's why I proposed a dual license (Artistic-2.0|GPL) for perl6. The Artistic 2.0 is a rewrite. We'll see what Larry decides. given that it's [GPL] neither been tested in court, This isn't a valid litmus test for a license. In fact, there is a very good reason a well written license won't be tested in court. Namely, that when a violation is found, the copyright holders' statement that someone is in violation is enough. When violations are encountered and reported to the violator, the first thing they do is ask their lawyers. In many cases with the GPL, the lawyers immediately say: "The copyright holder is right; you are in violation". It never needs to go to court, precisely *because* the license is written so well. This recently happened with the EveryBuddy program. In the case of the Objective-C front-end for GCC, it didn't even get to lawyers. NeXT stated their intentions, and the FSF said: "that isn't legal", and NeXT said: "Well, I guess you are right". nor is it particularly well-regarded by a number of the legal folks that have looked at 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
public domain? (was Re: standard representations)
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 public domain. (Or at least pushing for it, as I don't control perl's licensing terms) Public domain has it's own troubles too. To be safe in doing a public domain license, we'll need to get copyright disclaimers from everyone who contributes code (and possibly their employers). Otherwise, someone could come along later and legally claim copyright on some part. Dan Sugalski [EMAIL PROTECTED] wrote: No worse than what we need now. Submitting code to perl places it under the license that perl uses, if it's to be included. I am not completely sure this is correct, but only a copyright lawyer could tell us for sure. My worry is that when you submit a patch to Perl, you've already seen and been made aware of its license it's a bit more clear that one agrees to release their software under that license. You still claim copyright, but you are at least implicitly licensing it under perl's license. Public domain is a disclaimer of copyright. It seems to me that it's much harder to infer that, by submitting a patch, someone meant to say: "I give up all copyright on this work" than it is to infer: "I am submitting this copyrighted work of mine to a project whose license I know, and therefore it's under the same license." But, this is a question for a copyright lawyer. OTOH, digital signatures are apparently now legally valid in the USA (although the details still aren't clear to me). We could just ask everyone to PGP or GPG sign a message that says: "I disclaim copyright", which isn't a hard task. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: standard representations
Andy Dougherty [EMAIL PROTECTED] wrote: (Does the LPGL and the existence of fgmp make it ok to distribute the interface/XS code and rely on the end user to install gmp if they so choose? Ick. I hate licensing problems.) This is actually one of the reasons I'd like to see the licensing working group to continue indefinitely. We need to decide: "Do we want perl6 to depend on libraries with somewhat stricter licenses?" 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. 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
Re: standard representations
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 public domain. (Or at least pushing for it, as I don't control perl's licensing terms) Public domain has it's own troubles too. To be safe in doing a public domain license, we'll need to get copyright disclaimers from everyone who contributes code (and possibly their employers). Otherwise, someone could come along later and legally claim copyright on some part. 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
A parser that can handle partial programs (was Re: Now, to try again...)
Nicholas Clark [EMAIL PROTECTED] wrote:
Something I though of:
If you're trying to write an interactive perl inputer - either a perl shell
or just the command prompt on the debugger it would be useful if you
could tell the parser that the chunk of source you're giving it may be
incomplete.
I really like this idea, although I am unsure of how we might implement it.
I don't recall any of the compiler texts I have read over the years talking
about formal methods for writing such a "partial programs are acceptable"
parser.
Lisp-like languages handle this, but s-expressions are so trivial to parse
that it's no help to simply "follow" their example.
Perhaps, since we are doing recursive decent, we could have a user-definable
error function. If all possible errors have well-defined types, the caller
could define an error function that informs rather than croaks and could
prompt like this:
foo$ print "Hello world RET
foo (unclosed double-quote)$
Inside, this would be something like (sorry for writing in pseudo-Perl,
instead of pseudo-C):
$PROMPT = "foo$";
$interp = new Perl::Language::Interpeter();
$done = 0;
my $handleError = sub ($) {
my($errorID) = @_;
if (! $errorID) {
$interp-Eval($parseTree); $done = 1;
}
if ($errorID == $UNCLOSED_DOUBLE_QUOTE) {
$PROMPT = "foo (unclosed double-quote)$";
}
[...]
}
while (! $done) {
print "$PROMPT ";
$string .= STDIN; chomp $string;
$parseTree = $interp-Parse($string, $handleError);
}
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
Re: Supporting architectures without native C support (was Re: Meta-design)
Jarkko Hietaniemi [EMAIL PROTECTED] wrote: [Re: Giving data about why it's hard to use B:: to port to the JVM] Yes, *PLEASE*. Some hard data is always nice, even when (or especially when) it's unpleasant to hear. I won't have "hard numbers", as it is always completely possible that some clever hacker could find a way that I couldn't. What I will do is document what I tried, why it isn't easy, and what would have to change to make it easy. It's always a subjective process when you try to make the case that something is "hard 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
Re: Supporting architectures without native C support (was Re: Meta-design)
Jarkko Hietaniemi [EMAIL PROTECTED] wrote: 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. The 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
Re: Supporting architectures without native C support (was Re: Meta-design)
bkuhn wrote: Why should we center our entire design around C? Adam Turoff [EMAIL PROTECTED] wrote: 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. These are all good reasons to implement perl6 in C, and I agree with them. Let's implement perl6 in C! However, my proposal is that we also design perl6 in a way such that is not intimately dependent on any particular language. Because it's a Simple Matter Of Programming to reimplement a C program as a Java program, given enough tuits. Of course it is. I wasn't trying to disprove Turing Completeness. ;) However, polynomial time can be really, really big, and the job of writing a polynomial time algorithm can be even longer. Why not make the job easier for those of us who have to do it by holding off on making language-specific design decisions at the higher levels? Because the Python folks didn't have a problem basing JPython off of CPython. Actually, this one isn't a good comparison. Python is substantially easier to parse, and, is a much simpler language. I like Perl because it is more complicated, but that also comes with a burden that we design its implementation more carefully. Larry worked for a summer trying to mold the C implementation of Perl into a JVM port. I have spent substantially more time than that on it than that. It's a hard problem. I'll be happy to send you 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
Re: Perl6 on handhelds (was Re: Meta-design)
Dan Sugalski [EMAIL PROTECTED] wrote: one of the big goals I have is to get everything specified enough that someone can produce another version of perl from scratch. [..] 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. Thank you! These are precisely what I am asking for! I am curious whether the heavy resistance was a misunderstanding or a true disagreement with these two points above. I really hope its the former, and that this discussion is over. 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. Both is fine and 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
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
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
Perl6 in Java? (was Re: Meta-design)
Dan Sugalski [EMAIL PROTECTED] wrote: More importantly, what we're doing is outside Java's area of competence. We're writing system-level code here. Java isn't a system-level programming language. This isn't a bad thing, but it means it's an inappropriate solution to the problem. We might as well write perl 6 in perl. I think that Java is closer to system-level programming than Perl, and certainly not as close as C. 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 * vtables And, it will make the barrier for entry for new internals hacker lower. I just don't think we should dismiss Java out of hand because it isn't traditionally used for systems-level programming. 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. 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. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
documenting interfaces (was Re: Meta-design)
Dan Sugalski [EMAIL PROTECTED] wrote: [vtable stuff snipped] I don't think it's too early to be dealing with the way variables are implemented, at least at some level. I agree; I didn't mean for it to sound like I was saying otherwise. Also, just because we do vtables under the hood doesn't mean that any port of perl needs to do it that way--all that's required is to support the exposed interface, and the vtable stuff is definitely in the "hidden guts" realm. That's really my point---the interface 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
this was only an academic example (was Re: Meta-design)
Nicholas Clark [EMAIL PROTECTED] wrote: 2 things the above reminds me to watch out for int32 toInt32() don't assume anything about integer sizes (or any machine native type sizes or precisions, or that floating point can (or can't) preserve integers) UnicodeString toString() # returns the scalar value as Unicode string ASCIIString toString() # returns the scalar value as an ASCII string C++ implementors will have fun with names that assume one can overload on return type. 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
Re: Meta-design
Why does string Ceval have to screw everything up? Nathan Torkington [EMAIL PROTECTED] wrote: It doesn't. String eval is the escape hatch from a language that can't do what you want it to do. As such it's okay for it to be slow--consider it incentive to fix the language :-) The runtime system should be able to load the compilation system and say "turn this SV into a CV in this lexical scope," and then call the CV. Whether or not it is slow is not my concern. My concern is *can* we support it on architectures that don'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
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'. 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). -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Re: Meta-design
Simon Cozens [EMAIL PROTECTED] wrote: Patches welcome. Well, this isn't a patch, but if you really meant patches literally and not figuratively, I can provide one if you let me know. ;) Of the suggestions that have been advanced so far, four are worthy of more consideration: C, C++, Java and a specially-designed Perl Implementation Language. (PIL) Java is portable and gives us OO, but it's slow and ugly. I am probably the biggest proponent of the "use Java to implement Perl" camp. And, on this front, I would like to comment. First, "ugly" is a matter of taste, and I don't think we should let that be a deciding factor. Every programming language is ugly in one way or another. As for "slow", this will be helped by GCJ, the new GCC 3.0 front-end for Java. Java will compile to native code, via GCC. GCJ is not yet ready for prime time, so I certainly understand reluctance on building on infrastructure that isn't done yet. However, if we, as a team, decide that Java is a real contender, I will volunteer to start monitoring GCJ's progress. It might turn out that GCJ will be ready "just-in-time" for us to use it to implement Perl. ;) I know there is great resistance to requiring GCC, and I remember those threads. I believe this was mostly from the VMS camp. So, is there a native-code Java compiler for VMS? We need to think about the data structures that will replace SVs, HVs and AVs. I predict that such structures will be extensively used by the internals themselves, so they need to be fast and efficient. One concern that I have about the data structure design thus far (and I believe I wrote an RFC about this) is that we should try to resist the temptation to "talk in C" too soon. Most of the ideas I have seen thrown around are filled with C-isms. Of course, that's totally reasonable, if it helps people think about the issues. However, I would like it to be possible for a programmer of language Foobar to take the specification of the data structures and implement them directly in Foobar without too much trouble. The fewer C-isms in the high-level spec, the easier such a task will be. As the RFC 125 discussed, I think the interfaces for data structures and other APIs to be somewhat object-oriented. Basically, something like: An SV must answer the following methods: UnicodeString toString() # returns the scalar value as Unicode string ASCIIString toString() # returns the scalar value as an ASCII string int32 toInt() # returns the scalar value as a 32-bit int. or something like that. We seem to have settled on a vtable model for SVs, which is cool. vtables are a strategy for implementing a particular OO-style interface. I'd like to see higher level documentation developed before we get too far into the detailed data structure design. Again, if we're going to make a Perl a platform for building languages, we need to make it easy to replace Perl's parser with a parser for other languages, and the way to do this is to have a clearly defined interface by which programmers can write their replacement. I think this is very important. It is also important that the specification of the Parser itself be clear. If the parser is to be written in a subset of Perl, that subset must be somewhat clearly defined. =head2 Memory Allocation Memory allocation's pretty much a solved problem, so this shouldn't need to require much thought. [...] =head2 Garbage Collection I would like to note that GCC has actually switched to using garbage collection to manage its *internal* data structures rather than a traditional C memory management system. The GCC team has been pleased with 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
Re: Perl's parser and lexer will likely be in Perl (was Re: RFC 334 (v1) I'm {STILL} trying to understand this...)
Adam Turoff wrote: to write the Perl tokenizer in a Perl[56] regex, which is more easily parsable in C. All of a sudden, toke.c is replaced by toke.re, which would be much more legible to this community (which is more of a strike against toke.c instead of a benefit of some toke.re). Larry brought this up in his talk. Of course, I believe that Larry was sleep-deprived at the time, too. ;) It was late though. Might have been sleep deprevation talking. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Larry's ALS talk
[dragged this thread to [EMAIL PROTECTED], where it is probably better discussed. Please honor Reply-To:] Leon Brocard wrote: Bradley M. Kuhn sent the following bits through the ether: It should be noted that in Larry's speech on Friday, he said that he wanted to write the Lexer and Parser for Perl in some subset of Perl. :) Is there a writeup somewhere for those who couldn't attend? I suppose I should do one---it appears that I may have been the only Perl6 hacker in attendance. However, Larry had good slides and some notes, I noticed (they flashed on the screen briefly while he was switching windows). Perhaps he could put those on his WWW site? (hint, hint, Larry. :) If he doesn't do that this week, this weekend, I will summarize the talk as I remember it and send it to Chris Nandor for use Perl. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Perl's parser and lexer will likely be in Perl (was Re: RFC 334 (v1) I'm {STILL} trying to understand this...)
Dan Sugalski wrote: At 07:48 PM 10/12/00 +, John van V wrote: * It also means we can write bits of perl in Perl, and similarly not have to care about this fact. Granted, some developers are thick as a brick... If you are writing perl in Perl, then, presumably, you would know this. But perl won't be written in Perl. It'll be written in C, most likely. It should be noted that in Larry's speech on Friday, he said that he wanted to write the Lexer and Parser for Perl in some subset 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
Re: Perl Implementation Language
[Please forgive me for chiming in late on this thread; I just got a chance to catch up on mailing list traffic.] On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote: That's fine for the VM and the support libraries, but I'd *really* like to see the parser/front-end in Perl. There are dozens of RFCs that require some non-trivial extensions to the parser. It would be nice to code these in Perl On Tue, 12 Sep 2000, Simon Cozens wrote: Are there any better reasons than "It would be nice?" Dan Sugalski wrote: It'd make things easier? (I'd rather write a parser in perl than C...) I have one argument to make for writing the parser in a subset of Perl. While it does make bootstrapping a bit harder the first time, it also makes bootstrapping more *possible* in other cases where it would be virtually impossible otherwise. In other words, I am arguing that writing the parser in a subset of Perl makes the easy jobs a bit harder, but the hard jobs possible. :) Someday, for the JVM port of Perl, I'd like to support eval(). The only way to do that on the JVM natively is to have a parser that compiles to JVM code, too. When I brought this problem to Per Bothner (well-known GCC hacker, and author of the Scheme to JVM port, Kawa), he said: "Well, the best way would be if a parser for Perl was written in a subset of Perl. Then, you could bootstrap a simple compiler in Java that supports that subset, and that would buy you the full parser." I really like that idea. While C is ubiquitous for most computing tasks, it isn't ubiquitous on native JVM platforms. You really need to have everything available in Java or a language that compiles to the JVM efficiently. C will likely eventually compile to to the JVM, but it'll never be as native as Java is. Consider, too, that people may want to implement Perl in another way, perhaps radically different ways, down the line. It will be a nice jump-start for them if there is some 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
Re: A tentative list of vtable functions
Dan Sugalski wrote: get_value set_value The get/set value functions are for when something knows what the SV (or whatever we call it) really is and can handle the raw data. For example, if my code knew a SV held a complex number (which doesn't map well to the int/float/char translation) and I could handle it, then I'd call get_value and get the raw data. Are you envisioning that a lot of the perl core will use these functions, or are they for special things like: my complex_number $ii; ? My reason for asking is 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
Re: Optional Separate Programs for Interpreter Passes
Dan Sugalski wrote: At 12:58 PM 8/29/00 -0500, Fisher Mark wrote: Although Perl interpretation is divided into several passes (parser/lexer, optimizer, tree/bytecode runner), all these passes are grouped together in one binary. Under some memory-constrained conditions, it could be better if each pass ran as its own program, passing the transformed data onto the next pass similarly to the way compilers usually work. This is a good idea, and I've had fuzzy thoughts along this line (more or less) myself. There's a proto-RFC in the works. For the world of the JVM port, it's imperative that hooks be provided so that the front-end can be run independently, and a different back-end can be run (to emit bytecode of some sort). This is done in perl5 by STOP blocks, and the mechanism is rather hokey. I don'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
how small is small? (was Re: RFC 146 (v1) Remove socket functions from core)
Fisher Mark wrote: How small do we really need to go? Are we looking at implementing Perl for microcontrollers, or are we only worrying about Perl for PDAs? On the other hand, microcontrollers still don't have a lot of RAM, at least as compared to PDAs. I heard that a major mobile telephone manufacturer might be putting a JVM chip in one of their future models. I would like to be able to compile Perl programs to JVM so that they can run on such a device. I don't know if that's as small as a what you mean by microcontrollers, but it's still pretty small (probably smaller than a PDA, since RAM on the phone will be taken up by lots of phone-related stuff :). Of course, all of Perl couldn't be supported, but I'd like to be able to define a subset of Perl that is permitted, and tell the developer at compile time that they have stepped 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
Re: ffcall GPL - LGPL
Tom Christiansen wrote: No, it's a CPAN module. Oh, good. Someone has a licensing list going--somewhere. I wrote http://tmtowtdi.perl.org/rfc/13.pod to propose that we create a licensing working group. It needs someone in authority to create the working group. Unfortunately, I have yet to find out how the process works to create new top-level working groups. Of course, it could be that no one has gotten time to figure out that procedure. That's understandable. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
Where to get RFCs?
It appears Dan posted some internals RFCs, and due to some trouble with my subscription request, I didn't see them. I realize that I can get them out of the archives if I dig, but is there a WWW site yet where all RFCs are being kept? I looked around http://www.perl.org/perl6, but didn't see them. -- Bradley M. Kuhn - http://www.ebb.org/bkuhn PGP signature
