Re: Backtracking through the source
then... "either in perl, or in C" better? >From my understanding, "API" is the set of functions internal to Perl and PerlXS that allow C to access Perl internal structures, functions, etc., for the purpose (or effect) of "writing" "Perl" in "C" (SvPV(whatsis)). I'm talking about either writing it so that the source filter (creole parser) is interpreted Perl, or compiled C: beginning with Perl, possibly moving to C for efficiency if needed. C being a yet-to-be-defined exposed API. I know what I'm talking about: whether I'm communicating it effectively has yet to be determined. If this is inaccurate, please make a correction rather than just pointing out that I'm wrong. I'll never learn anything unless you do and won't be able to contribute my best unless we're able to use the same terms in the same way. I've gone through extreme lengths to attempt to understand these terms as they are being used, and I thought I had it pretty well licked. Feel free to interject correct semantics where needed. "Contribute to my understanding and I will contribute to Perl." Maybe that should be a new Perl maxim. To me, more than any internal or linguistic changes, this is what Perl 6 has over Perl 5... a change in attitude of the enlightened toward the ones seeking enlightenment. It is a logical fallacy for the enlightened to moan and groan about wanting a person to contribute and needing more help, and then refusing to assist that person in his first steps of contribution. It creates an exclusionary catch-22. Dan: In any PDD generated from this group, we really need to define for the "semantically challenged" the terms that are used within it: the definitions already given, and those that pop up as necessary. One of the huge problems with p5p is the learning curve of terms used... and the problems caused by that training time, closing out the initiate. Otherwise, we might as well write the PDD in medieval southwestern Swahili. The official perl documentation has often been criticized for being written to exclude the initiate in the perl language. In 1996 I didn't understand much of it, but I do now. Even so, I don't completely understand the internal language used by the p5p. Mastering perldoc doesn't help there. Perhaps PDD's need a DEFINITION section altogether as a part of the PDD spec. Modern contract legalese requires this in certain contexts so a judge and jury can have a clue "what the heck those computer people are talking about". Simon Cozens <[EMAIL PROTECTED]> wrote: > On Thu, Nov 30, 2000 at 03:30:28AM +, David Grove wrote: > > For this, I'd probably look for it to be writable either in perl or in > api > > You keep using that word. I do not think it means what you think it means. > > -- > Pray to God, but keep rowing to shore. > -- Russian Proverb >
Re: Backtracking through the source
On Thu, Nov 30, 2000 at 05:07:32AM +, David Grove wrote:
> >From my understanding, "API" is the set of functions internal to Perl and
> PerlXS that allow C to access Perl internal structures, functions, etc.,
> for the purpose (or effect) of "writing" "Perl" in "C" (SvPV(whatsis)).
Uhm, no. An API is a *programming interface*. It tells you what functions are
available. That's all. It's the reference manual to a library. It's a way of
handing a programmer a black box; you don't need to care how the functions are
implemented, you're just told what they are and what they do. You can't write
anything "in API". You can write an API, or you can use an API.
> Dan: In any PDD generated from this group, we really need to define for
> the "semantically challenged" the terms that are used within it
You know why we have a reading list, right? It's so you can read books which
explain these things for you; this means that *WE DON'T HAVE TO*.
I categorically do *NOT* want perl6-internals to turn into a basic course in
compiler design, purely for the benefit of those who know nothing at all about
what they're trying to achieve. I'd like Perl 6 to be a masterwork, and
masterworks require master craftsmen. If you want to partake in compiler
design, it makes more than a little sense to find out how to do so.
--
\let\l\let\l\d\def\l\a\active\l~\catcode~`?\a~`;\a\d;{~`};!\a\d!{?;~}\l?\the;#
!;]!\l]\l;\.!;,!;\%!;=!]=\d],\expandafter;[!][{=%{\message[};\$!=${\uccode`'.
\uppercase{,=,%,{%'}}};*!=*{\advance.by}]#\number;/!=/{*-1}\newcount.=\-{*-};-
!]-\-;^!=^{*1};\ != {.`\ $};@!=@{,.,"#`@^$}.`#*`'$.!0-!$//$^$ .``^$*!$^$.!0-!/
$!-!^$@*!$ *!*!*!*!$@-!$ .!0-!-!$.``^$^^$.`<-!*`<$@*!$%}\batchmode
Re: Backtracking through the source
Simon Cozens <[EMAIL PROTECTED]> wrote: > On Thu, Nov 30, 2000 at 05:07:32AM +, David Grove wrote: > > >From my understanding, "API" is the set of functions internal to Perl > and > > PerlXS that allow C to access Perl internal structures, functions, etc., > > for the purpose (or effect) of "writing" "Perl" in "C" (SvPV(whatsis)). > > Uhm, no. An API is a *programming interface*. It tells you what functions > are > available. That's all. It's the reference manual to a library. It's a way > of > handing a programmer a black box; you don't need to care how the functions > are > implemented, you're just told what they are and what they do. You can't > write > anything "in API". You can write an API, or you can use an API. You're senselelessly arguing semantics, Simon. I fully realize that API is not a programming language in itself. However, since an API is a collection of functions that are used to address a central theme, in this case, Perl internals. Back when I was writing C code using an add-on library of C functions that specifically handled dBASE databases (I forget the name of the library), we considered ourselves to be writing in "LibraryX". Of course we knew we were writing C. We were also "writing in" an applied API of that language. If you really want to get semantically tricky, since a language is defined by the functions and keywords available to it, though it be a stretch, an API could from a point of view be seen as a "language". In practicality that's nonsense, but for the purpose of conversation and discussion, it's just semantics. You don't write "in DBI", of course, or "in Tk" (or even "tklib"), but you do write "DBI code". If you semantically object to my use of the word "in" with something like this, completely ignoring every other word in a 300-word email, then creating this masterwork will take a long, long, long time. > > Dan: In any PDD generated from this group, we really need to define for > > the "semantically challenged" the terms that are used within it > > You know why we have a reading list, right? It's so you can read books > which > explain these things for you; this means that *WE DON'T HAVE TO*. Take that up with Amazon.com. They have a peculiar habit of sending out a shipping notice, and giving UPS a shipping document, several days before actually handing the package over to UPS for delivery. When I get my books, I'll get my semantics in order. Until then, if I use an inappropriate preposition, or an ill-timed article, or even a slightly off-kilter pronoun, you'll simply have to figure it out from context. > I categorically do *NOT* want perl6-internals to turn into a basic course > in > compiler design, purely for the benefit of those who know nothing at all > about > what they're trying to achieve. I'd like Perl 6 to be a masterwork, and > masterworks require master craftsmen. If you want to partake in compiler > design, it makes more than a little sense to find out how to do so. There's a vast difference between an "introductory course" and "exclusionary linguistics", as there is a vast difference between professional skill and pompous elitism. I'm not asking for basics, just perl peculiarities and definitions of major terms as they are applied. Some of those definitions have already been sought and given, I'd just like them written into the PDD coming from this group. I don't think a bit of cut and paste is too much to ask. I've specifically skipped discussion of topics and branches that I've not understood because of a limited knowledge of compiler internals that will last until I've studied the topic further, but the subject turned to something that I was already working on, and something in which I have some contribution to offer, and some work and research already done, and some brainstorming already brought to a point of making sense. I don't think that semantic bickering is warranted. You've completely forked from the topic because of a two letter word. Can we get back to the topic, please? Is a "source filter" worth looking into for the creoles / "little languages", and, if so, does the method that I've proposed make any sense, regardless of what it's written IN? I would suggest that keeping this at a higher level would allow greater freedom for people to modify the input-language to suit their specific requirements or peculiarities. I wouldn't want to think that a person who wanted a "switch" statement to translate to an if-elsif-else ladder would have to go beyond Camel IV. I'd really hope they wouldn't have to wait for compiler books from Amazon or read mounds of material on perlguts to accomplish what we have an opportunity to expose as a very simple task. Could these creoles / "little languages" be effectively translated into Perl before interpretation, or must they translate directly into internals? Perhaps this is expressed as exposing a perl-based API to creole authors, where what they write fits into a defini
Re: Backtracking through the source
On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote: > I categorically do *NOT* want perl6-internals to turn into a basic course in > compiler design, purely for the benefit of those who know nothing at all about > what they're trying to achieve. I'd like Perl 6 to be a masterwork, and > masterworks require master craftsmen. If you want to partake in compiler > design, it makes more than a little sense to find out how to do so. Guh, I shouldn't have said that, because I know exactly what'll happen now: people will accuse me of being elitist and reactionary and trying to shut people out who want to help. Outside my room, some constructors are building a school. I'd like to help. I'd like to take part in the building; it'll be great! We'll have lots of classrooms, and a playground, and I think there should be an armoury, because all good schools have an armoury. Oh, that's military bases; but that doesn't matter, it should have one anyway. But for some reason, the constructors don't think much of my plans. They're saying something about the need for "foundations" or something or other that I can't understand. Look, it's not my fault I have no knowledge of engineering! I *really* want to help, and they're trying to exclude me. Horrible, elitist bastards! Are they? Are they being elitist? Of course not. Are they trying to exclude me? *No*. By my own lack of knowledge and utility, *I* *exclude* *myself*, and no amount of wanting to help makes up for that. Think about it. -- >Almost any animal is capable learning a stimulus/response association, >given enough repetition. Experimental observation suggests that this isn't true if double-clicking is involved. - Lionel, Malcolm Ray, asr.
Re: The external interface for the parser piece
On Mon, Nov 27, 2000 at 05:29:36PM -0500, Dan Sugalski wrote: >int perl6_parse(PerlInterp *interp, >void *source, >int flags, >void *extra_pointer); Count me in with the people who prefer: int perl6_parse(PerlInterp *interp, PerlIO *io); I understand the desire to reduce the number of API bits the external user needs to know about, but I think that the non-PerlIO API will lead to more complexity than it removes. Assuming the non-PerlIO interface is used, however, I believe there is a problem with the PERL_GENERATED_SOURCE option. ANSI/ISO C does not guarantee that a function pointer may be stored in a void*. I would suggest that Perl's external APIs, at the very least, should conform to standard C. - Damien
Re: Backtracking through the source
On Wed, Nov 29, 2000 at 02:57:23PM -0500, Dan Sugalski wrote: > My only worry is, how do we reconcile this with the idea of > >Perl having an easily modifiable grammar and being a good environment for > >little-language stuff? > > That's a good question, and it depends on what Larry's thinking of for > little languages. Smacking the perl parser around enough to handle, say, > something C or Pythonish shouldn't be a huge hassle. Making it handle > something Lisp-like, though, is another matter entirely. I think my worry was more general than that: if we've got a big monolithic parsebeast which is making lots of Perlish decisions, at what levels do we allow the user to modify that? Do they get to replace the whole thing and implement their own tokeniser, lexer and parser, or can we find a way to apply "hooks" to replaceable components? -- "Dogs believe they are human. Cats believe they are God."
Re: Backtracking through the source
It can be done any which way but loose, and I'm trying to keep my thinking
flexible for any applied use in this sense. What I'm _doing_ for my own
work at this point is simply making a creole filter (or source filter),
and spitting out perl5 which is then sucked into eval_pv(). For this, I'd
probably look for it to be writable either in perl or in api, and create
what amounts to a hash where input (keys) := output (hash) where output is
[(index|regex), output_code]. Naturally it's more complicated than that,
but I don't yet see it being _much_ more complicated. The (index|regex)
indicates how the source token is found, and the output_code is somewhat
of a predefined list of musts (the perl6 language definition, or perhaps
how the creole differs from it), along with a per-creole list of niceties
above and beyond perl6.
For example, in my own parser now, I have "class foo {" creating "package
Foo", collecting information about class-global variables and constants,
autogenerating a constructor, and in "scope" until the terminating /^\}/.
I'm currently using "public" and "private" variable members (for lack of
better keywords) that get turned into tied variables that can be read-only
when private (my definition of private in this sense). The gist is, what
my input is isn't relevant, what's relevant is that I'm spitting out pure
perl. If I were to make this generic enough for general purpose, it would
basically be a translation hash from input spec to perl spec.
If I go down this path, then, my creole parser doesn't need much for hooks
beyond what will be available in perl itself. I'm just making it more
legible to the programmer, which is the purpose of the creoles in the
first place. I'm a bit leery of making it more complicated for fear of
creating an unnecessary monster.
Let me explain that better...
For "Perl Spec", I'm referring to the generic:
if conditional := if(CONDITION) {BLOCK} [elsif {BLOCK}] [else {BLOCK}]
in pythonish I would make the above the value of a hash (speaking very
generically, and in high level terms, not in detailed specification) where
the key is
if conditional := if CONDITION NL IND BLOCK UND [elsif IND BLOCK UND]
[else IND BLOCK UND]
The "value" of the "hash" never changes. The value is the pure perl
version of whatever funky is defined. To my mind, I'm calling this the
"Pure Perl API" (meaning the set of commands available to my perl code,
though it could also be defined as sets of API in the sense that API is
actually defined) where I should be calling it the "Pure Perl 6 Spec".
Anything beyond translating the structure to pure perl could be defined,
but would be creole specific, such as expanding "private constant $foo :=
1" into several lines and making "public member $bar := undef;" into a
tied scalar with a default given within an autocreated constructor
(example only, from my current work).
The only thing I don't like about using this method is that when the user
runs the debugger, he/she will be debugging pure perl, and not the creole,
so he/she won't be seeing the original code, in this instance. I can only
provide that by "going off the deep end" into creating the "monolithic"
creole parsers that not only know how to translate to perl, but can
translate from debuggese back into the creole. But then, given some
thought, this might just be a reversed form of the translation
hash-type-of-thinking structure...
eval_pv() gots ta be smarter than just eval_pv, then, if we want to
reverse it. I believe this might be the "hooks" Dan wants. However, I'm
not looking to make the creole parser spit out syntax trees. For each
creole created, it would be necessary to have a _complete_ language spec
(where currently it's additive or at least replaces only what it
specifically defines) rather than a subset of perl output which is what
has the complete spec.
It's 3am, don't expect me to make too much sense. I'm also a bit
linguistically challenged as far as creating a parser/interpreter goes...
I'm basically getting in on the ground floor of a new language with people
who have done this all before, trying to comprehend major perl5 perlguts
and predefined terms (more or less specific to this purpose) in a perl6
sense. I'm not going to understand all of the words unless they're spelled
out, as Dan has done for a lot of them already (merci bien a lui).
David Grove
[EMAIL PROTECTED]
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 29, 2000 at 02:57:23PM -0500, Dan Sugalski wrote:
> > My only worry is, how do we reconcile this with the idea of
> > >Perl having an easily modifiable grammar and being a good
environment
> for
> > >little-language stuff?
> >
> > That's a good question, and it depends on what Larry's thinking of
for
> > little languages. Smacking the perl parser around enough to handle,
say,
> > something C or Pythonish shouldn't be a huge hassle. Making it handle
> > something Lisp-like, though, is another matter entirely.
>
> I think my worry w
Re: Backtracking through the source
On Thu, Nov 30, 2000 at 03:30:28AM +, David Grove wrote: > For this, I'd probably look for it to be writable either in perl or in api You keep using that word. I do not think it means what you think it means. -- Pray to God, but keep rowing to shore. -- Russian Proverb
Re: Backtracking through the source
On Thu, 30 Nov 2000, Bryan C. Warnock wrote: > You don't want the compiler design to be a 'hands-on experiment' for us > inexperienced folk? That's not elitist, that's pragmatic. > > You don't want this to be a learning experience - (corrections, observations, > answers) - to the same? *That's* elitist. Fair enough to a point, but please let's not overburden the experienced folk by also _expecting_ them to always supply "corrections, observations, and answers". -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: The external interface for the parser piece
On Wed, 29 Nov 2000, Dan Sugalski wrote: > At 09:51 AM 11/29/00 -0800, Dave Storrs wrote: > >I have a feeling this is a stupid question, but I have to ask anyway. > > > >Do we really need to pass in a PerlInterp pointer? Or can perl6_parse > >just create one for itself if/when it needs one? If created, it could of > >course be kept around so that it didn't need to be re-created later. > > Yup, we do. We'd call this (or something like it) when doing the whole > eval/do/require/use thing, so we may well be parsing into an existing > interpreter. Sorry, I guess I didn't phrase that well...I realize we're going to *need* an interpreter. My question is, does it have to be created outside of the perl6_parse(...) function? I just thought that if we could eliminate one more parameter, one more "magic cookie" that the caller (in an embedded situation) needs to work with, that would be a good thing. Dave
Re: Backtracking through the source
On Thu, 30 Nov 2000, Andy Dougherty wrote: > On Thu, 30 Nov 2000, Bryan C. Warnock wrote: > > > You don't want the compiler design to be a 'hands-on experiment' for us > > inexperienced folk? That's not elitist, that's pragmatic. > > > > You don't want this to be a learning experience - (corrections, observations, > > answers) - to the same? *That's* elitist. > > Fair enough to a point, but please let's not overburden the experienced > folk by also _expecting_ them to always supply "corrections, observations, > and answers". That's what books and quiet observation are for. We're trying to give, not take. Moderation in everything. :-) -- Bryan C. Warnock RABA Technologies
Re: The external interface for the parser piece
At 07:29 AM 11/30/00 -0800, Dave Storrs wrote: >On Wed, 29 Nov 2000, Dan Sugalski wrote: > > > At 09:51 AM 11/29/00 -0800, Dave Storrs wrote: > > >I have a feeling this is a stupid question, but I have to ask anyway. > > > > > >Do we really need to pass in a PerlInterp pointer? Or can perl6_parse > > >just create one for itself if/when it needs one? If created, it could of > > >course be kept around so that it didn't need to be re-created later. > > > > Yup, we do. We'd call this (or something like it) when doing the whole > > eval/do/require/use thing, so we may well be parsing into an existing > > interpreter. > > > Sorry, I guess I didn't phrase that well...I realize we're going >to *need* an interpreter. My question is, does it have to be created >outside of the perl6_parse(...) function? I just thought that if we could >eliminate one more parameter, one more "magic cookie" that the caller (in >an embedded situation) needs to work with, that would be a good thing. True enough, but the interpreter creation call seems to be the right place to pass in any special flags that'll change how the interpreter parses and runs--things like taint mode, or the -D debugging switches. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Backtracking through the source
On Thu, 30 Nov 2000, Simon Cozens wrote: > On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote: > > I categorically do *NOT* want perl6-internals to turn into a basic course in > > compiler design, purely for the benefit of those who know nothing at all about > > what they're trying to achieve. I'd like Perl 6 to be a masterwork, and > > masterworks require master craftsmen. If you want to partake in compiler > > design, it makes more than a little sense to find out how to do so. > > Guh, I shouldn't have said that, because I know exactly what'll happen now: > people will accuse me of being elitist and reactionary and trying to shut > people out who want to help. You don't want the compiler design to be a 'hands-on experiment' for us inexperienced folk? That's not elitist, that's pragmatic. You don't want this to be a learning experience - (corrections, observations, answers) - to the same? *That's* elitist. -- Bryan C. Warnock RABA Technologies
Re: The external interface for the parser piece
On Tue, Nov 28, 2000 at 04:47:42PM -0500, Dan Sugalski wrote: > At 09:05 PM 11/28/00 +, Nicholas Clark wrote: >>On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote: Not sure: Dan: > is treated as if it points to a stream of bytes, where the first four are > the length of the source to be read followed by the source. If set to Since you have a fourth argument couldn't that be used for the length of the byte stream rather than embedding that length into the byte stream itself? Makes more sense to me to separate the bytes from the length. >>> >>> I'd rather the stream be self-contained, rather than needing an extra >>> argument for the length. Counted strings aren't uncommon outside of C, and >>> there's no reason a Fortran or COBOL (or Java, or...) program can't >> embed perl. >> >> >>Why four? Surely that's imposing an arbitrary binary structure. If it's a >>parameter then it's (probably) a machine register and certainly a "natural" >>quantity for whatever's running the code (and automatically the correct >>endian-ness just in case perl is running in some (oddball partial) >>binary emulation environment. Erm. Or something like that. > > It's not necessarily in a register. In at least some of the languages I > named (and you can add BASIC and pascal to the list as well), a string > consists of a length and data pointer pair, usually together. What's handy > is a pointer to the data structure, not the length and a pointer to the buffer. > > Counted strings should probably just have either a platform-native int in > front, or a 32-bit int in network format, both of which should be doable on > any platform that perl deals with. I agree it's do-able. What seems to me a good idea not to do it has entered my head. We're trying to make this an easy embedding API. For the counted length version: If I'm being passed a (large) block of data and a length for that block from an upstream source which I can't change, then I have to malloc a new block of length+4, copy the length into the first 4 bytes, and all that data into the rest. If I'm being passed a counted length block, easy, I pass it onwards. For the 2 parameter version: If I'm being passed 2 parameters, a block and its length, I pass them on. If I'm being passed a counted block, I read the count into one variable, and use the address (counted block + 4) as the address of a vanilla block. No malloc or copy. (And I'm assuming that in C one would actually take the address of the structure member, no hacky pointer arithmetic) This only applies to external APIs. Internal APIs may well benefit from counted length systems (or doing things analogous to allowing the buffer to follow directly after the struct STRUCT_SV; in a single malloc()ed block in perl5) Nicholas Clark
Re: The external interface for the parser piece
On a related note: a wrapper not completely unlike
union sv_any_aligned_s {
IV iv;
NV iv;
PV pv;
void *vp;
int (*dummy)(void) *fp;
/* any others? */
};
should be used around SVs to ascertain that everything fits everywhere.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: The external interface for the parser piece
Nicholas Clark <[EMAIL PROTECTED]> writes: >> Counted strings should probably just have either a platform-native int in >> front, or a 32-bit int in network format, both of which should be doable on >> any platform that perl deals with. > >I agree it's do-able. >What seems to me a good idea not to do it has entered my head. > >We're trying to make this an easy embedding API. > >For the counted length version: >If I'm being passed a (large) block of data and a length for that block from >an upstream source which I can't change, then I have to malloc a new block >of length+4, copy the length into the first 4 bytes, and all that data into >the rest. >If I'm being passed a counted length block, easy, I pass it onwards. > >For the 2 parameter version: >If I'm being passed 2 parameters, a block and its length, I pass them on. >If I'm being passed a counted block, I read the count into one variable, >and use the address (counted block + 4) as the address of a vanilla block. >No malloc or copy. (And I'm assuming that in C one would actually take >the address of the structure member, no hacky pointer arithmetic) I agree completely. It should either be pointer,length or an abstract type (whatever SV is in new world, PerlIO of an in-core stream) which has pointer/length abstractions. The latter two have the advantage that you can tell the UTF-8-ness (if we care) by asking them. > >This only applies to external APIs. Internal APIs may well benefit from >counted length systems Sure we may as well re-use whatever-replaces-SV rather than invent another counted string type. -- Nick Ing-Simmons <[EMAIL PROTECTED]> Via, but not speaking for: Texas Instruments Ltd.
Re: The external interface for the parser piece
Nicholas Clark <[EMAIL PROTECTED]> writes: > >We're trying to make this an easy embedding API. Yes, and we are in danger of "premature optimization" of the _interface_. What we need to start with is a list of "what we need to know" - they may as well be separate parameters at this point - then we can decide how best to group them and provide wrapper(s) that call the zillion parameter version. If there turns out to be only one sensible wrapper then it can become _the_ interface. -- Nick Ing-Simmons <[EMAIL PROTECTED]> Via, but not speaking for: Texas Instruments Ltd.
Re: The external interface for the parser piece
On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> On a related note: a wrapper not completely unlike
>
> union sv_any_aligned_s {
> IV iv;
> NV iv;
> PV pv;
> void *vp;
> int (*dummy)(void) *fp;
> /* any others? */
> };
>
> should be used around SVs to ascertain that everything fits everywhere.
Uhhh. "around the actual data like the actual IV, NV, PV, etc inside SVs".
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: The external interface for the parser piece
At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > On a related note: a wrapper not completely unlike
> >
> > union sv_any_aligned_s {
> > IV iv;
> > NV iv;
> > PV pv;
> > void *vp;
> > int (*dummy)(void) *fp;
> > /* any others? */
> > };
> >
> > should be used around SVs to ascertain that everything fits everywhere.
>
>Uhhh. "around the actual data like the actual IV, NV, PV, etc inside SVs".
Huh? You're not talking about using this union around, say, the IV slot in
a scalar, I hope...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Backtracking through the source
At 05:07 AM 11/30/00 +, David Grove wrote: >Dan: In any PDD generated from this group, we really need to define for >the "semantically challenged" the terms that are used within it: No, I don't think that's appropriate. Any new terminology specific to the PDD should be defined, but that's it. Perl terms not specific to the PDD should be defined elsewhere (either in an RFC or PDD). For everything else, there's the bibliograpy. If you (and this is the generic you here) aren't up to speed on the basics of the field (parser design, optimizer design, interpreter design, whatever) it's best to get up to speed first. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The external interface for the parser piece
On Thu, Nov 30, 2000 at 11:23:11AM -0500, Dan Sugalski wrote:
> At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> >On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > > On a related note: a wrapper not completely unlike
> > >
> > > union sv_any_aligned_s {
> > > IV iv;
> > > NV iv;
> > > PV pv;
> > > void *vp;
> > > int (*dummy)(void) *fp;
> > > /* any others? */
> > > };
> > >
> > > should be used around SVs to ascertain that everything fits everywhere.
> >
> >Uhhh. "around the actual data like the actual IV, NV, PV, etc inside SVs".
>
> Huh? You're not talking about using this union around, say, the IV slot in
> a scalar, I hope...
You hope in vain :-) If we still want to in perl6 to do (disgusting)
things like (we do in perl5)
- "intercast" pointers and integers
- "intercast" integers and doubles
something like the above is needed (or, at least, is beneficial in
getting it right). How else can you guarantee that (a) the size
(b) the alignment are right?
All this assuming, of course, that the (basic implementation of)
perl6 SVs is somewhat similar to the perl5 SVs. If not, never mind
my rambling.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: The external interface for the parser piece
At 10:54 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
>On Thu, Nov 30, 2000 at 11:23:11AM -0500, Dan Sugalski wrote:
> > At 10:20 AM 11/30/00 -0600, Jarkko Hietaniemi wrote:
> > >On Thu, Nov 30, 2000 at 10:03:06AM -0600, Jarkko Hietaniemi wrote:
> > > > On a related note: a wrapper not completely unlike
> > > >
> > > > union sv_any_aligned_s {
> > > > IV iv;
> > > > NV iv;
> > > > PV pv;
> > > > void *vp;
> > > > int (*dummy)(void) *fp;
> > > > /* any others? */
> > > > };
> > > >
> > > > should be used around SVs to ascertain that everything fits everywhere.
> > >
> > >Uhhh. "around the actual data like the actual IV, NV, PV, etc inside
> SVs".
> >
> > Huh? You're not talking about using this union around, say, the IV slot in
> > a scalar, I hope...
>
>You hope in vain :-) If we still want to in perl6 to do (disgusting)
>things like (we do in perl5)
>
> - "intercast" pointers and integers
> - "intercast" integers and doubles
>
>something like the above is needed (or, at least, is beneficial in
>getting it right). How else can you guarantee that (a) the size
>(b) the alignment are right?
>
>All this assuming, of course, that the (basic implementation of)
>perl6 SVs is somewhat similar to the perl5 SVs. If not, never mind
>my rambling.
Generally not, I think. The vtable stuff and special-purpose scalars take
care of most of that nonsense, luckily.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: The external interface for the parser piece
> > > Huh? You're not talking about using this union around, say, the IV slot in > > > a scalar, I hope... > > > >You hope in vain :-) If we still want to in perl6 to do (disgusting) > >things like (we do in perl5) > > > > - "intercast" pointers and integers > > - "intercast" integers and doubles > > > >something like the above is needed (or, at least, is beneficial in > >getting it right). How else can you guarantee that (a) the size > >(b) the alignment are right? > > > >All this assuming, of course, that the (basic implementation of) > >perl6 SVs is somewhat similar to the perl5 SVs. If not, never mind > >my rambling. > > Generally not, I think. The vtable stuff and special-purpose scalars take > care of most of that nonsense, luckily. Presumably. But why are you then still talking about "the IV slot in a scalar"...? I'm slow today. Show me how $a = 1.2; $b = 3; $c = $a + $b; is going to work, what kind of opcodes do you see being used? (for the purposes of this exercise, you may not assume the optimizer doing $c = (1.2+3) behind the curtains :-) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Backtracking through meta swamp
On Thu, Nov 30, 2000 at 08:33:35AM -0500, [EMAIL PROTECTED] wrote: > "Bryan C. Warnock" <[EMAIL PROTECTED]> wrote: > > On Thu, 30 Nov 2000, Simon Cozens wrote: > > > On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote: > > > > I categorically do *NOT* want perl6-internals to turn into a basic > > course in > > > > compiler design, purely for the benefit of those who know nothing > > > > You don't want the compiler design to be a 'hands-on experiment' for us > > inexperienced folk? That's not elitist, that's pragmatic. > > > > You don't want this to be a learning experience - (corrections, > > observations, > > answers) - to the same? *That's* elitist. > > LOL > > Thanks, Bryan. An art that I haven't learned is to say so much with as few > words. Well, at least we're going nowhere more efficiently. :-) -- May the best description of competition prevail. (via, but not speaking for Deutsche Bank)
Re: Opcodes (was Re: The external interface for the parser piece)
At 05:59 PM 11/30/00 +, Nicholas Clark wrote: >On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote: > > (Moved over to -internals, since it's not really a parser API thing) > > > > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote: > > >Presumably. But why are you then still talking about "the IV slot in > > >a scalar"...? I'm slow today. Show me how > > > > > > $a = 1.2; $b = 3; $c = $a + $b; > > > > > >is going to work, what kind of opcodes do you see being used? > > >(for the purposes of this exercise, you may not assume the optimizer > > > doing $c = (1.2+3) behind the curtains :-) > >$a=1; $b =3; $c = $a + $b No, that's naughty--it's much more interesting if the scalars are different types. > > If they don't exist already, then something like: > > > > newscalar a, num, 1.2 > > newscalar b, int, 3 > > newscalar c, num, 0 > > add t3, a, b > >and $c ends up a num? When the add line is fixed, yup. :) This is assuming the optimizer can spend enough time and see enough of the code to know that we're adding an int and num, so that $c must be a num. If not, the newscalar line would be: newscalar c, generic, NULL to set it to be a generic empty scalar. >why that line "newscalar c, num, 0" ? >It looks to me like add needs to be polymorphic and work out the best >compromise for the type of scalar to create based on the integer/num/ >complex/oddball types of its two operands. Yup. What add does is based on the types of the two operands. In the more odd cases, I assume it's type stuff will be based on the left-hand operand, but I wouldn't bet the farm on that yet, as that's a Larry call. >[Oh. but I'm blinkered in this because I'm attempting to make pp_add in >perl5 do this sort of thing, so I may be missing a better way of doing it] vtables make it a lot nicer. Whether they make it faster is still up in the air... :) > > But that probably doesn't help much. Let me throw together something more > > detailed and we'll see where we go from there. > >Hopefully it will cover the above case too. What, the "what if one of the operands is really bizarre" case? Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Opcodes (was Re: The external interface for the parser piece)
At 01:51 PM 11/30/00 -0500, Buddha Buck wrote:
>At 05:59 PM 11-30-2000 +, Nicholas Clark wrote:
>>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
>
>(Note, Dan was writing about "$a=1.2; $b=3; $c = $a + $b")
>
>>$a=1; $b =3; $c = $a + $b
>>
>>
>> > If they don't exist already, then something like:
>> >
>> > newscalar a, num, 1.2
>> > newscalar b, int, 3
>> > newscalar c, num, 0
>> > add t3, a, b
>>
>>and $c ends up a num?
>>why that line "newscalar c, num, 0" ?
>>It looks to me like add needs to be polymorphic and work out the best
>>compromise for the type of scalar to create based on the integer/num/
>>complex/oddball types of its two operands.
>
>I think the "add t3, a, b" was a typo, and should be "add c, a, b"
D'oh! Yup. Cut'n'paste error.
>Another way of looking at it, assuming that the Perl6 interpreter is
>stack-based, not register-based, is that the sequence would get converted
>into something like this:
>
> push num 1.3 ;; literal can be precomputed at compile time
> dup
> newscaler a;; get value from top of stack
> push int 3;; literal can be precomputed at compile time
> dup
> newscaler b
> push a
> push b
> add
> newscaler c
That looks about right, though I'm not sure we should use a stack-based
instead of register-based model. (Well, register and stack) I can see going
either way, but that's a different argument. (Unfortunately all the
stack-based interpreters I've used are all-software, while all the
register-based ones are all hardware (i.e. real assembly) so I don't have
an even basis for comparison)
>The "add" op would, in C code, do something like:
>
>void add() {
> P6Scaler *addend;
> P6Scaler *adder;
>
> addend = pop(); adder = pop();
> push addend->vtable->add(addend, adder);
>}
>
>it would be up to the addend->vtable->add() to figure out how to do the
>actual addition, and what type to return.
Yup. I think it'll be a little more complex than that in the call,
something like:
addend->vtable->(add[typeof adder])(adder);
The extra level of indirection may hurt in the general case, but I think
it's a win to call the "add an int scalar to me" function rather than have
a generic "add this scalar to me" function that figures out the type of the
scalar passed and then Does The Right Thing. I hope. (Yeah, I'm betting
that the extra indirect will be cheaper than the extra code. But I'm not
writing that in stone until we can do some benchmarking)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Opcodes (was Re: The external interface for the parser piece)
At 02:27 PM 11-30-2000 -0500, Dan Sugalski wrote: >At 05:59 PM 11/30/00 +, Nicholas Clark wrote: >>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote: >> > (Moved over to -internals, since it's not really a parser API thing) >> > >> > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote: >> > >Presumably. But why are you then still talking about "the IV slot in >> > >a scalar"...? I'm slow today. Show me how >> > > >> > > $a = 1.2; $b = 3; $c = $a + $b; >> > > >> > >is going to work, what kind of opcodes do you see being used? >> > >(for the purposes of this exercise, you may not assume the optimizer >> > > doing $c = (1.2+3) behind the curtains :-) >> >>$a=1; $b =3; $c = $a + $b > >No, that's naughty--it's much more interesting if the scalars are >different types. OK, how would this sequence convert to opcodes? $a=1.2; $b=5; $c = ($a.$b)*4; Something like (using a load/store paradigm for the opcodes, for variety): setnum 1.2, r1;; $a = 1.2 store r1, $a setint 5, r2 ;; $b = 5 store r2, $b load $a, r1 ;; ($a.$b) load $b, r2 append r1, r2, r3 mulr3, int 4, r4 ;; $c = ($a.$b)*4 store r4, $c This is before obvious optimization (the loads are completely unnecessary, but are here as an example) The append would do something like r1->vtable->append[int](r2), as per your last example, and would be responsible for coercing r2 to a string. mul would do something like r3->vtable->mul[int](int2P6Scaler(4)), and the mul[int] associated with strings would do the necessary conversions. What I'm curious about is the following sequence: use MyRomanNumerals; $a = MyType->new(4); print $a;# should print "IV" $b = 4; print $a + $b; # should print "VIII", maybe... print $b + $a; # should print "8", maybe... The execution of the two additions should be, based on what was said before, something like: a->vtable->add[typeof b](b); b->vtable->add[typeof a](a); How does b->vtable->add[] get an entry for MyRomanNumerals? I seem to remember a suggestion made a long time ago that would have the vtable include methods to convert to the "standard types", so that if the calls were b->vtable->add(b,a) (and both operands had to be passed in; this is C we're talking about, not C++ or perl. OO has to be done manually), then the add routine would do a->vtable->fetchint(a) to get the appropriate value. Or something like that. Have I confused something? >Yup. What add does is based on the types of the two operands. In the more >odd cases, I assume it's type stuff will be based on the left-hand >operand, but I wouldn't bet the farm on that yet, as that's a Larry call. That's what I assumed above, but who knows? >> > But that probably doesn't help much. Let me throw together something more >> > detailed and we'll see where we go from there. >> >>Hopefully it will cover the above case too. > >What, the "what if one of the operands is really bizarre" case? And with Perl6, I thought we were planning allowing some really bizarre cases? Has Larry indicated at all what his thoughts about fast powerful TIED variables were? > Dan
Re: Opcodes (was Re: The external interface for the parser piece)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> The "add" op would, in C code, do something like:
>>
>> void add() {
>> P6Scaler *addend;
>> P6Scaler *adder;
>>
>> addend = pop(); adder = pop();
>> push addend->vtable->add(addend, adder);
>> }
>>
>> it would be up to the addend->vtable->add() to figure out how to do the
>> actual addition, and what type to return.
DS> Yup. I think it'll be a little more complex than that in the call,
DS> something like:
addend-> vtable->(add[typeof adder])(adder);
DS> The extra level of indirection may hurt in the general case, but I think
DS> it's a win to call the "add an int scalar to me" function rather than have
DS> a generic "add this scalar to me" function that figures out the type of the
DS> scalar passed and then Does The Right Thing. I hope. (Yeah, I'm betting
DS> that the extra indirect will be cheaper than the extra code. But I'm not
DS> writing that in stone until we can do some benchmarking)
Is all that really necessary? Why not a non-vtbl function that knows how
to add numeric types?
I would have wanted to limit the vtbl to self manipulation functions.
Set, get, convert, etc. Cross object operations would/should be
outside the realm of the object. (It seems like trying to lift yourself
by the bootstraps.)
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Opcodes (was Re: The external interface for the parser piece)
(Moved over to -internals, since it's not really a parser API thing) At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote: >Presumably. But why are you then still talking about "the IV slot in >a scalar"...? I'm slow today. Show me how > > $a = 1.2; $b = 3; $c = $a + $b; > >is going to work, what kind of opcodes do you see being used? >(for the purposes of this exercise, you may not assume the optimizer > doing $c = (1.2+3) behind the curtains :-) Okay, assuming $a, $b, and $c alread exist, in pseudo-opcodes: newscalar t1, num, 1.2 newscalar t2, int, 3 scalar_assign a, t1 scalar_assign b, t2 newscalar t3, num, 0 add t3, a, b scalar_assign c, t3 If they don't exist already, then something like: newscalar a, num, 1.2 newscalar b, int, 3 newscalar c, num, 0 add t3, a, b But that probably doesn't help much. Let me throw together something more detailed and we'll see where we go from there. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Opcodes (was Re: The external interface for the parser piece)
On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote: > (Moved over to -internals, since it's not really a parser API thing) > > At 11:06 AM 11/30/00 -0600, Jarkko Hietaniemi wrote: > >Presumably. But why are you then still talking about "the IV slot in > >a scalar"...? I'm slow today. Show me how > > > > $a = 1.2; $b = 3; $c = $a + $b; > > > >is going to work, what kind of opcodes do you see being used? > >(for the purposes of this exercise, you may not assume the optimizer > > doing $c = (1.2+3) behind the curtains :-) $a=1; $b =3; $c = $a + $b > If they don't exist already, then something like: > > newscalar a, num, 1.2 > newscalar b, int, 3 > newscalar c, num, 0 > add t3, a, b and $c ends up a num? why that line "newscalar c, num, 0" ? It looks to me like add needs to be polymorphic and work out the best compromise for the type of scalar to create based on the integer/num/ complex/oddball types of its two operands. [Oh. but I'm blinkered in this because I'm attempting to make pp_add in perl5 do this sort of thing, so I may be missing a better way of doing it] > But that probably doesn't help much. Let me throw together something more > detailed and we'll see where we go from there. Hopefully it will cover the above case too. Nicholas Clark
Re: Opcodes (was Re: The external interface for the parser piece)
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> It looks to me like add needs to be polymorphic and work out the best
> compromise for the type of scalar to create based on the integer/num/
> complex/oddball types of its two operands.
>
> [Oh. but I'm blinkered in this because I'm attempting to make pp_add in
> perl5 do this sort of thing, so I may be missing a better way of doing it]
This sounds supiciously like an earlier discussion:
http://www.mail-archive.com/perl6-internals@perl.org/msg01532.html
Where I proposed that each numeric SV class should have a precison()
class method that indicates how 'big' that numberic type is:
Let d be the dimension of the variable (eg complex and bigrat numbers
would be 2); Let t be:
0 for integer
1 for floating point
let b be the bits of storage used (eg 32 for an INT32, 64 for a double)
then define the precision by (d<<24 + t<<23 + b) or similar.
Classes which allow arbitrary dimension or precision should set d or t
to its maximum value.
Then when pp_add wants to call the add() method of one of it's args,
it chooses the biggest of the two.
I gave some sample psuedo-code for pp_subtract:
pp_subtract {
SV *sv1 = POP;
SV *sv2 = POP;
SV *result;
if (
// if they're the same type (common case),
// avoid the overhead of calling precision() twice
sv1->vtable == sv2->vtable
|| sv1->precision() >= sv2->precison()
)
result = sv1->subtract(sv1,sv2,0);
else
result = sv2->subtract(sv2,sv1,1); // operands swapped
PUSH(result);
}
The implication was that arithmetic operations on mixed types get a result
equal to the type of it's 'biggest' operand.
So num + int gives num, bigrat + num gives bigrat, and so on.
A lot of issues were then discussed (but not resolved), such as:
* do values ever get demoted - eg an expression inolving bigints that evaluates
to 0: should this be returned as an int or a bigint?
* for the code '$c = $a + $b' - is the current SV type of $c thrown away
and replaced with whatever type ($a + $b) evaluates to?
* If we allow the syntax
my bigreal $c = $a + $b
[ this is an extention of the "my dog $spot" syntax, since that currently
advises that $spot is likely to hold a reference to dog object; I don't
believe there are yet any semantics defined directly for different SV types.]
In this case, is $a + $b evaluated then promoted to a bigreal; or does
$c end up being whatever $a+$b is, and not necesarily a bigreal?
Or is the expression ($a+$b) now evaluated in the context of knowing that
a bigreal is expected???
* How are scalar constants handled?
eg does this work as expected?
use bigreal;
my $br = 1E;
and can the parser be dynamically extended to allow
use complex;
my $twosqrtminusone = 2i;
Some of these issues affect the design of the SV vtable API; some have
wider semantic implications.
Dave M.
Re: Opcodes (was Re: The external interface for the parser piece)
At 05:59 PM 11-30-2000 +, Nicholas Clark wrote:
>On Thu, Nov 30, 2000 at 12:46:26PM -0500, Dan Sugalski wrote:
(Note, Dan was writing about "$a=1.2; $b=3; $c = $a + $b")
>$a=1; $b =3; $c = $a + $b
>
>
> > If they don't exist already, then something like:
> >
> > newscalar a, num, 1.2
> > newscalar b, int, 3
> > newscalar c, num, 0
> > add t3, a, b
>
>and $c ends up a num?
>why that line "newscalar c, num, 0" ?
>It looks to me like add needs to be polymorphic and work out the best
>compromise for the type of scalar to create based on the integer/num/
>complex/oddball types of its two operands.
I think the "add t3, a, b" was a typo, and should be "add c, a, b"
Another way of looking at it, assuming that the Perl6 interpreter is
stack-based, not register-based, is that the sequence would get converted
into something like this:
push num 1.3 ;; literal can be precomputed at compile time
dup
newscaler a;; get value from top of stack
push int 3;; literal can be precomputed at compile time
dup
newscaler b
push a
push b
add
newscaler c
The "add" op would, in C code, do something like:
void add() {
P6Scaler *addend;
P6Scaler *adder;
addend = pop(); adder = pop();
push addend->vtable->add(addend, adder);
}
it would be up to the addend->vtable->add() to figure out how to do the
actual addition, and what type to return.
> > But that probably doesn't help much. Let me throw together something more
> > detailed and we'll see where we go from there.
>
>Hopefully it will cover the above case too.
>
>Nicholas Clark
Re: The external interface for the parser piece
On Thu, Nov 30, 2000 at 04:15:24PM +, Nick Ing-Simmons wrote: > Nicholas Clark <[EMAIL PROTECTED]> writes: > > > >We're trying to make this an easy embedding API. > > Yes, and we are in danger of "premature optimization" of the _interface_. Amen. Tim.
Re: The external interface for the parser piece
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> On a related note: a wrapper not completely unlike
JH> union sv_any_aligned_s {
JH> IV iv;
JH> NV iv;
JH> PV pv;
JH> void *vp;
JH> int (*dummy)(void) *fp;
JH> /* any others? */
JH> };
JH> should be used around SVs to ascertain that everything fits everywhere.
I was under the impression that p6 was going to do away with p5's
incestuous knowledge of hardware bits. And go with a more OO style of
dispatch.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Perl apprenticing (was Re: Backtracking through the source)
At 01:23 PM 11/30/00 -0500, Buddha Buck wrote: >At 11:47 AM 11-30-2000 -0500, Bryan C. Warnock wrote: >>I forget who proposed it originally, but I thought it an excellent >>analogy, and >>an excellent model for Perl development. Like any tradecraft, there are >>masters, apprentices, and the common consumer. The apprentice shouldn't >>master, just as the common consumer shouldn't apprentice. Unfortunately, >>right >>now it's "choose your own category." I'll elect to choose low. I'm an "Perl >>apprentice wanna-be", in search of an opportunity to prove that I am >>apprentice >>material. (I think too many PAWBs are looking for opportunities to prove >>that >>they are master material. I'm not about to shoot myself in the foot that >>way. >>At least on purpose. Slap me around if I get too obnoxious.) > >Here here! Is there a place where PAWB's can sign up? Not at the moment, at least not formally. Want to set something up? (And yes, I'm serious. A good master/apprentice thing would help a lot of folks, I think) >I'm signed up for the -internals lists mainly as an educational >experience. It should be fascinating to see how a system as complex as >Perl 6 gets developed, even if I'm unable, through lack of skill, to >directly contribute. My hope is that if I'm not able to contribute to >Perl 6, then I should have learned enough to be able to contribute to Perl >6.1 (or Perl 7, whichever is next). Do be careful of selling yourself short. While you might not necessarily have the appropriate skill set to deal with parts of the perl core, that doesn't mean you can't contribute. (This is the generic rather than specific 'you' here) A good working knowledge of, say, the properties of complex numbers is as important as knowledge of the guts when building the complex number class. Or, to use the building analogy, you don't need to be an architect to say "shouldn't the bathroom have a door in it?" :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Backtracking through the source
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote:
> > I categorically do *NOT* want perl6-internals to turn into a basic
> course in
> > compiler design, purely for the benefit of those who know nothing at
all
> about
> > what they're trying to achieve. I'd like Perl 6 to be a masterwork,
and
> > masterworks require master craftsmen. If you want to partake in
compiler
> > design, it makes more than a little sense to find out how to do so.
>
> Guh, I shouldn't have said that, because I know exactly what'll happen
now:
> people will accuse me of being elitist and reactionary and trying to
shut
> people out who want to help.
>
> Outside my room, some constructors are building a school. I'd like to
help.
> I'd like to take part in the building; it'll be great! We'll have lots
of
> classrooms, and a playground, and I think there should be an armoury,
> because
> all good schools have an armoury. Oh, that's military bases; but that
> doesn't
> matter, it should have one anyway.
Logic error: False Allusion in this case, Simon. Nobody's talking about
throwing in the kitchen sink. In this case, I think we're basically saying
the same thing, just using different terms (although in this particular
threadfork we're fussing about a two-letter preposition). It's the terms
that are in question in this instance, not the knowledge. As far as
building the compiler is concerned, I'm keeping silent because I don't
know enough about what you're talking about. But where the creoles are
concerned (I'm using a linguistic term to describe a concept of a language
written by a linguist), I do have some things to contribute, and semantics
shouldn't be an issue as long as there is some level of basic
comprehension between the participants.
Point taken, however.
I'll add this since you've CC'ed meta...
I've seen several types of elitism in the P5P, and only one would I
consider appropriate. That one is when a person stumbles onto the group
thinking it's a basic discussion forum and asks something like "How do I
write a CGI?". I don't consider it elitist to tell that person to find a
better place to ask (although the reactions that are actually seen can be
beyond the limits of "acceptable rudeness"). The other types of elitism
are those that I hope don't carry into Perl 6, foremost among which is
thinking of one's own particular participation (talking about ancient
comments from Tom, not you) on the perl core itself on one's own OS on
one's own machine as the only valid contribution to the Perl language and
culture. Different people contribute different things, and hopefully in
Perl 6 they can be received as contributors as long as they bide their
time and toss in their contributions at an appropriate time and place
within a conversation. We are becoming a community-based heterogenious
environment, which 5.005 attempted but failed to do. Unix is not the only
way to build a house, and Win32 users aren't all idiots (those who are
generally know who they are and don't get involved in deep subjects). If
Perl is to evolve, we have to turn from that oligarchical and exclusionary
way of thinking to a culture that understands, encourages, appreciates,
and promotes contributions from all sides. The P5P is a tight-knit circle
of "high ranking" members of the perl community. In Perl 6, the culture
has been proposed to be one of universal equality, regardless of how many
beers a person has personally drunk with Larry Wall.
Let me give you a more realistic allusion that fits this case. When I was
a teenager, I worked for a while in the plumbing department at a hardware
store. I knew just about every product sold in the store, and basically
knew how to use or install each of them. One day, a rather older gentleman
came in and asked for a quarter-inch galvanized knee. We fussed a little
bit, because I had no idea what he was talking about, and he thought I
most definitely should since it was about the most common piece of
plumbing equipment available. He had to describe it before I understood
that he actually meant "elbow". As old as he was, he had probably been
plumbing since elbows were actually called "knees". I asked an older
associate, and he confirmed that way back when, "elbow" was synonymous
with "knee" in plumbing, especially in the south, though he hadn't heard
anyone actually use the word in years. Now, in constructing a building, we
either have to have a common word ("elbow"), or we have to accept two
common words ("elbow" and "knee") as synonymous. That one person doesn't
know that a knee is an elbow doesn't make him less able to contribute, nor
does having that knowledge, speaking STRICTLY of semantics and wordings,
make one superior. If both how to install a knee or elbow, no matter what
it's called, there's nothing to argue about unless you simply like
semantic bickering. Frenchmen aren't "stupid" because they "talk funny":
thinking so is childish.
Perl
Re: Backtracking through the source
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote: > On Thu, 30 Nov 2000, Simon Cozens wrote: > > On Thu, Nov 30, 2000 at 11:54:31AM +, Simon Cozens wrote: > > > I categorically do *NOT* want perl6-internals to turn into a basic > course in > > > compiler design, purely for the benefit of those who know nothing at > all about > > > what they're trying to achieve. I'd like Perl 6 to be a masterwork, and > > > masterworks require master craftsmen. If you want to partake in > compiler > > > design, it makes more than a little sense to find out how to do so. > > > > Guh, I shouldn't have said that, because I know exactly what'll happen > now: > > people will accuse me of being elitist and reactionary and trying to shut > > people out who want to help. > > You don't want the compiler design to be a 'hands-on experiment' for us > inexperienced folk? That's not elitist, that's pragmatic. > > You don't want this to be a learning experience - (corrections, > observations, > answers) - to the same? *That's* elitist. LOL Thanks, Bryan. An art that I haven't learned is to say so much with as few words. ;-))
Re: Backtracking through the source
At 10:07 AM 11/30/00 -0500, Andy Dougherty wrote: >On Thu, 30 Nov 2000, Bryan C. Warnock wrote: > > > You don't want the compiler design to be a 'hands-on experiment' for us > > inexperienced folk? That's not elitist, that's pragmatic. > > > > You don't want this to be a learning experience - (corrections, > observations, > > answers) - to the same? *That's* elitist. > >Fair enough to a point, but please let's not overburden the experienced >folk by also _expecting_ them to always supply "corrections, observations, >and answers". To carry Simon's analogy forward, it's the same as walking over to the construction site and asking the construction crew lots of questions. You can hope they'll answer and expect they'll be reasonably polite to a point, but they're not always going to answer, aren't obligated to educate you on how to design or build buildings, and some of them may tell you to go away if you pester them. That analogy, however, isn't applicable here. We're not building anything yet. What we're doing is *designing* the building. A more appropriate analogy is one where you walk into the architect's conference room and start commenting on and fiddling with the design of the building. While the sign says "Open Meeting", the expectation is that you're competent in the areas you'll choose to participate in. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl apprenticing (was Re: Backtracking through the source)
On Thu, 30 Nov 2000, Dan Sugalski wrote: > At 01:23 PM 11/30/00 -0500, Buddha Buck wrote: > >Here here! Is there a place where PAWB's can sign up? > > Not at the moment, at least not formally. Want to set something up? (And > yes, I'm serious. A good master/apprentice thing would help a lot of folks, > I think) If no one else steps forward, I'll at least make a proposal sometime this weekend. Well, I might make one in any case. We have strayed a little from the API discussion, however. (Unless API is Apprenticeship for Perl Internals :-) This is probably more of a meta item, and the distro has been modified as such. -- Bryan C. Warnock RABA Technologies
Re: Perl apprenticing (was Re: Backtracking through the source)
Today around 2:12pm, Dan Sugalski hammered out this masterpiece:
: At 01:23 PM 11/30/00 -0500, Buddha Buck wrote:
: >
: >Here here! Is there a place where PAWB's can sign up?
:
: Not at the moment, at least not formally. Want to set something up? (And
: yes, I'm serious. A good master/apprentice thing would help a lot of folks,
: I think)
As a guy who is franticlly digging into the core to "Figure it out", I
would love to be part of this, what ever 'this' is. I love working
with the Distribution, but I want to get into the core just as
much. I'll take a postion here ( for some value of 'position' ).
: Do be careful of selling yourself short. While you might not necessarily
: have the appropriate skill set to deal with parts of the perl core, that
: doesn't mean you can't contribute. (This is the generic rather than
: specific 'you' here) A good working knowledge of, say, the properties of
: complex numbers is as important as knowledge of the guts when building the
: complex number class.
I deffinitley agree.
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail=>'[EMAIL PROTECTED]',site=>
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig->{site})+6),"\n";
print map{$_.': '.$sig->{$_}."\n"}sort{$sig->{$a}cmp$sig->{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce
Re: Backtracking through the source
On Thu, 30 Nov 2000, Dan Sugalski wrote: > What we're doing is *designing* the building. A more appropriate analogy is > one where you walk into the architect's conference room and start > commenting on and fiddling with the design of the building. While the sign > says "Open Meeting", the expectation is that you're competent in the areas > you'll choose to participate in. Help, not hinder. Learn by doing, not by dooming. ;-) I am certainly hoping that folks on both sides of the fence will be fairly reasonable. Yes, we certainly shouldn't be asking why the architect is putting in all these, what are these? load-bearing walls? what the hell are they?, but it shouldn't be too unbearable to occasionally field questions such as why he's choosing to make the hallway ten feet wide, when it seems to be taking away from the space in the men's restroom. (A local ordinance, or maybe he's going to put in another restroom down the hall later.) I forget who proposed it originally, but I thought it an excellent analogy, and an excellent model for Perl development. Like any tradecraft, there are masters, apprentices, and the common consumer. The apprentice shouldn't master, just as the common consumer shouldn't apprentice. Unfortunately, right now it's "choose your own category." I'll elect to choose low. I'm an "Perl apprentice wanna-be", in search of an opportunity to prove that I am apprentice material. (I think too many PAWBs are looking for opportunities to prove that they are master material. I'm not about to shoot myself in the foot that way. At least on purpose. Slap me around if I get too obnoxious.) Apologies to David Grove: much longer winded this time -- Bryan C. Warnock RABA Technologies
Re: Backtracking through the source
At 11:47 AM 11-30-2000 -0500, Bryan C. Warnock wrote: >I forget who proposed it originally, but I thought it an excellent >analogy, and >an excellent model for Perl development. Like any tradecraft, there are >masters, apprentices, and the common consumer. The apprentice shouldn't >master, just as the common consumer shouldn't apprentice. Unfortunately, >right >now it's "choose your own category." I'll elect to choose low. I'm an "Perl >apprentice wanna-be", in search of an opportunity to prove that I am >apprentice >material. (I think too many PAWBs are looking for opportunities to prove that >they are master material. I'm not about to shoot myself in the foot that >way. >At least on purpose. Slap me around if I get too obnoxious.) Here here! Is there a place where PAWB's can sign up? I'm signed up for the -internals lists mainly as an educational experience. It should be fascinating to see how a system as complex as Perl 6 gets developed, even if I'm unable, through lack of skill, to directly contribute. My hope is that if I'm not able to contribute to Perl 6, then I should have learned enough to be able to contribute to Perl 6.1 (or Perl 7, whichever is next). >Apologies to David Grove: much longer winded this time > > -- >Bryan C. Warnock >RABA Technologies
Want to help.
Hello. I'm a CS student in Brazil, I'm almost done with my CS course, I like Perl very much and I would like to help in the Perl 6 effort, specifically with Perl/C/C++ programming, and if there's some OS specific thing for me to do, in Linux. If possible, I would like to work closely to data types and data representation in C/C++. Can I help you??? Thanks, Branden
