labels within expressions?

2000-09-11 Thread David L. Nicol
John Porter wrote: > > Randal L. Schwartz wrote: > > > > Yes, I'd be in favor of making return() in a valued block (as opposed > > to a looping block) abort the block early and return the value. > > Imho, it should return the value, but not abort the block. That's > not very dwimmy. Loop block

Re: we already have barewords as variables if we want them Re: the C JIT

2000-09-08 Thread David L. Nicol
John Porter wrote: > undecorated variable names suffer from this showstopping weakness: > they can't be interpolated. Unless we change other aspects of perl's > syntax to support it, that is -- maybe s/${x}/5/. Now, maybe we can > live without variable interpolation; but I'd bet most perl progr

Re: $a in @b

2000-09-07 Thread David L. Nicol
Damian Conway wrote: > A C such as: > > @array = grep BLOCK LIST > > is equivalent to: > > @tmp = (); > foreach (LIST) { push @tmp, $_ if do BLOCK } > @array = @tmp; > > That similarity would not change in any way under the proposal > (except to be made stronge

Re: $a in @b

2000-09-07 Thread David L. Nicol
John Porter wrote: > heh. for a normal sub, > > sub foo { > return( 42 ); > } > > finds OMWTDI as > > sub foo { > 42; > last; > } > > Somehow, this seems like very natural perl to me. > > -- > John Porter I'd

Re: RFC 199 (v1) Short-circuiting C and C with C

2000-09-07 Thread David L. Nicol
The "assignment from a lazy list" section of RFC 123 suggests a system for requesting the first however many items out of a map or grep by making it lazy and then assigning it to an array of that size. "last" is more flexible, if you are looking for a condition more complex than the first one,

Re: RFC 181 (v1) Formats out of core / New format syntax

2000-09-07 Thread David L. Nicol
Johan Vromans wrote: > my $file_format = qf( > @<: @ > $name, $ssn > ); > > Now, $file_format would be a Format object (compare this with qr//, > that produces a Regex object). or the proposed qs// which would produce a packed structure definition

Re: XML/HTML-specific ?< and ?> operators? (was Re: RFC 145 (alternate approach))

2000-09-07 Thread David L. Nicol
Bart Lateur wrote: > > On 06 Sep 2000 18:04:18 -0700, Randal L. Schwartz wrote: > > >I think the -1 indexing for "end of array" came from there. Or at > >least, it was in Perl long before it was in Python, and it was in Icon > >before it was in Perl, so I had always presumed Larry had seen Icon

Re: we already have barewords as variables if we want them Re: the C JIT

2000-09-07 Thread David L. Nicol
John Porter wrote: > > David L. Nicol wrote: > > > > A bareword inside doublequotes is not interpreted, in Perl or C. > > No; a "bareword" in quotes (any kind) is not a bareword. > > -- > John Porter huh? --

Re: the C JIT

2000-09-07 Thread David L. Nicol
"Myers, Dirk" wrote: > $mode = 0755 ; > $file = "Foobar" ; > > #include > #include > > chmod($mode, $file) ; > > Which chmod gets called, perl or C? What are the rules for figuring this > out? > > Dirk Following the documentation at http://www.pe

Re: the C JIT

2000-09-06 Thread David L. Nicol
"Myers, Dirk" wrote: > I still find this whole idea confusing, though. Just out of curiosity, > though, would: > > #include a way for users to bail out gracefully > > be a syntax error? It is clear to us that that is a comment and not a preprocessor directive. The #include preprocesso

we already have barewords as variables if we want them Re: the C JIT

2000-09-06 Thread David L. Nicol
Nathan Wiger wrote: > > "David L. Nicol" wrote: > > > > s/x/5/; # this is still going to replace > > # all the eckses in $_ with fives. > > Why? This is an arbitrary decision if you've declared variables to be > barewords.

Re: the C JIT

2000-09-06 Thread David L. Nicol
Nathan Wiger wrote: > Intermingling it freely: > >my Dog $spot; >int x; >my int $y; >#include >char * name; >#do some regexp matching >s/x/5/;/* match the C value of x defined above */ > > Is really confusing, even for us humans. :-) > > -Nate Is it confusing?

Re: RFC 33 (v2) Eliminate bareword filehandles.

2000-09-06 Thread David L. Nicol
Buddha Buck wrote: > What advantage does this give None whatsoever. I should have selected a less contentious example that file handles to demonstrate my opinion that tagged barewords should be allowed to do anything, not in exclusion of, but in addition to, the syntactically tagged scalar

Re: Proposal for IMPLEMENTATION sections

2000-09-06 Thread David L. Nicol
"Bryan C. Warnock" wrote: > > It's hitting a moving target :-( I continue to explain myself until my mistakes become clear, that's why I'm often wrong.

Re: $a in @b

2000-09-06 Thread David L. Nicol
Garrett Goebel wrote: > grep { ref($a) eq ref($b) } @b) # Same type? > grep { $a == $_ } @b) > grep { $a eq $_ } @b) > grep { $a > $_ } @b) > > Garrett grep doesn't short-circuit; you can't return or exit or last out of the thing. Maybe we could add support for C to C

Re: RFC 33 (v2) Eliminate bareword filehandles.

2000-09-06 Thread David L. Nicol
John Porter wrote: > > David L. Nicol wrote: > > > > > > How about ALLOWING bareword everything-else? Start having > > filehandles work the way everyone expects them to at first, > > passing as arguments and so forth, without any special treatment?

Re: the C JIT

2000-09-06 Thread David L. Nicol
) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27600; Fri, 1 Sep 2000 14:52 Nathan Wiger wrote: > > "David L. Nicol" wrote: > > > > No, that would be > > > > dog $spot; > > No, it wouldn't: > > $r = new

Re: RFC 179 (v1) More functions from set theory to manipulate arrays

2000-09-05 Thread David L. Nicol
> > =head1 ABSTRACT > > When programming in perl we need really often to calculate > union, intersection, difference between arrays. It will be > cool if such functions could be part of the perl6 language. Arrays/Lists are ordered, sets are not. For sets, hashes are a better perl representati

Re: Change "($one, $two)=" behavior for optimization? (was Re:RFC 175 (v1) Add C keyword to force list context (likeC))

2000-09-05 Thread David L. Nicol
Peter Scott wrote: > > At 11:48 AM 9/3/00 +1100, Damian Conway wrote: > >> Ever consider then having > >> > >> ($a, $b, $c) = ; > >> or > >> @a[4,1,5] = ; > >> > >> only read three lines? > > > >I think this is a superb idea, and look forward to someone's RFC'i

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David L. Nicol
When you want to turn off an inherited delegation in an ISA situation? "David E. Wheeler" wrote: > > Damian Conway wrote: > > > Err, that *is* the default behaviour. Delegation doesn't occur unless > > you specify it. Or am I missing your meaning here? > > use delegation > attr1 =>

Re: RFC 145 (alternate approach)

2000-09-05 Thread David L. Nicol
David Corbin wrote: > > I've got some vague ideas on solving all of these, I'll go into if > > people like the basic concept enough. not just in regexes, but in general, a way to extend the set of bratches that Perl knows about would be very nice. for instance it is very difficult for people us

Re: RFC 91 (v2) Builtin: part

2000-09-05 Thread David L. Nicol
> In order to work with lists of arbitary size, it is often necessary to > split a list into equal sized sub-lists. A C function is proposed > that achieves this: Are the sublists copies or aliases? I imagine they are aliases, but this could be specified in the RFC --

Re: the C JIT

2000-09-01 Thread David L. Nicol
Nathan Wiger wrote: > > "David L. Nicol" wrote: > > > > They gain us compliance with the whims of the people who like barewords > > for variable names. You may or may not find that to be a good thing. > > It's not just that I don't think drop

Re: Proposed RFC for matrix indexing and slicing

2000-09-01 Thread David L. Nicol
Buddha Buck wrote: > > Boy, there are a lot of people on that CC: list... Anyone want off > this ride? > > How would you recommend the RFC breakdown? > > Use ";" for matrix index separator > Use named iterators for matrix indices > > anything else? Everyone else is way past brainstormin

Re: a syntax derived from constant-time hash-based n-dim matrices in perl 5

2000-09-01 Thread David L. Nicol
Nathan Wiger wrote: > I don't think array indices > are something that we should have to go to such lengths to get. I'd > rather have a somewhat-confusing ; or , based syntax than the above. If > anything that's *more* confusing and harder to read. > > -Nate you're right. What if they both wo

Re: A tentative list of vtable functions

2000-09-01 Thread David L. Nicol
Dan Sugalski wrote: > We're shooting for speed here. Any common operation that could be affected > by the type of the variable should be represented so a custom function can > be called that does exactly what needs to be done. > > Dan so if I want to make

Re: the C JIT

2000-09-01 Thread David L. Nicol
Sam Tregar wrote: > > On Thu, 31 Aug 2000, David L. Nicol wrote: > > > We're talking about making a faster Perl. C's syntax requires enough > > clarity to compile to something quick. it is a very short hop from > > my dog $spot; > > to >

Re: a syntax derived from constant-time hash-based n-dim matrices in perl 5

2000-09-01 Thread David L. Nicol
Nathan Wiger wrote: > Well, this is not bad, only it's not without its problems. Say you > wanted to get your indices implicitly: > > @a[getindices()]; > @a[$r->get_x, $r->get_y]; @a["@{\(getindices())}"]; @a[join $",$r->get_x, $r->get_y]; > Either of these could ret

Re: the C JIT

2000-09-01 Thread David L. Nicol
Nathan Wiger wrote: > > "David L. Nicol" wrote: > > > > my dog $spot; > > to > > dog spot; > > > > If we only allow this where enough info is available to allocate dog-sized > > pieces of memory directly, Perl can blaze t

Re: a syntax derived from constant-time hash-based n-dim matrices in perl 5

2000-08-31 Thread David L. Nicol
Nathan Wiger wrote: > > "David L. Nicol" wrote: > > > > @a["$i $j $k","$a $y $z"] # two points in DN n-dim syntax > > One problem that immediately jumps out at me is how to do this: > >@a[[@x], [@y]]; > >

Re: the C JIT

2000-08-31 Thread David L. Nicol
Ken Fox wrote: > . The real problems of exception handling, closures, dynamic > scoping, etc. are just not possible to solve using simple C code. > > - Ken I'm not talking about translating perl to C code, I'm talking about translating perl to machine language. C is babytalk compared to Perl,

Re: A tentative list of vtable functions

2000-08-31 Thread David L. Nicol
Dan Sugalski wrote: > > Okay, here's a list of functions I think should go into variable vtables. All the math functions are in here. Can the entries that my type does not use be replaced with other functions that my type does use? > Functions marked with a * will take an optional type offset

Re: the C JIT

2000-08-31 Thread David L. Nicol
Sam Tregar wrote: > > On Thu, 31 Aug 2000, David L. Nicol wrote: > > run-time efficiency > > C doesn't get run-time efficiency from its syntax, so we can't really > expect to get anything here. It gets it from its compilation > architecture. If you wan

Re: n-dim matrices

2000-08-31 Thread David L. Nicol
Christian Soeller wrote: > > No, at least 18. One more piece of semantics that would be appreciated > is optional omission of trailing dimensions in slices, e.g. for a 3-dim > @a: > > @a[0:1] == @a[0:1;] == @a[0:1;;] > > Christian this would be the * in my proposal made in mail w/ subject "

a syntax derived from constant-time hash-based n-dim matrices in perl 5

2000-08-31 Thread David L. Nicol
Jeremy Howard wrote: > That's true. I still think it's confusing to have such similar syntaxes mean > such different things. I'd also like to be able to say: > > @a[[$i,$j,$k], [$x,$y,$z]] > > to get two points. Just in case anyone isn't aware of this: using a "stuff'em into hash keys" N-d

Re: the C JIT

2000-08-31 Thread David L. Nicol
Ken Fox wrote: > Trolling? No, I'm not, it's the direction that RFC 61 ends up if you let it take you there. fast perl6 becomes, as well as slicing, dicing and scratching your back, a drop-in replacement for gcc. -- David Nicol 816.235.1187 [EMAIL PROTECTED]

Re: RFC 177 (v1) A Natural Syntax Extension For ChainedReferences

2000-08-31 Thread David L. Nicol
Peter Scott wrote: > > >Having the > >indices in one place saves a lot of characters. Compare > > > > $r->{{qw(a b c d e f g h)}} > > > >versus > > > > $r->{a}->{b}->{c}->{d}->{e}->{f}->{g}->{h} > > But I would compare it to > > $r->{a}{b}{c}{d}{e}{f}{g}{h} > > which is

Re: RFC 177 (v1) A Natural Syntax Extension For Chained References

2000-08-31 Thread David L. Nicol
Perl6 RFC Librarian wrote: > arsenal. The constructs are: > > $ref->[[LIST]] > $ref->{{LIST}} > > The proposed respective meanings: > > $ref->[$elem[0]]->[$elem[1]}->[...]->[$elem[-1]] > $ref->{$elem[0]}->{$elem[1]}->{...}->{$elem[-1]} why not just use single

Re: RFC 120 (v2) Implicit counter in for statements, possibly$#.

2000-08-31 Thread David L. Nicol
Chaim Frenkel wrote: > > This is making the index variable into an a wrapper object. No it isn't. Or at least it doesn't have to. Often there is a need to find the key an object was found in a container. More often in hashes than in arrays. And I think this discussion belongs in -data.

Re: the C JIT

2000-08-31 Thread David L. Nicol
David Corbin wrote: > A C JIT is an interesting idea. > > I think that a project works best when it has a set of goals (I haven't > seen one yet really for Perl 6). Unless this is one of the goals, I can > easily see how this could become a serious distraction to what I > perceive as the like

the C JIT

2000-08-30 Thread David L. Nicol
Dan Sugalski wrote: > I do want to have a set of C/XS/whatever sources as part of the test suite > as well--right now perl's test suite only tests the language, and I think > we should also test the HLL interface we present, as it's just as > important in some ways. I want to see Perl become a f

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

2000-08-30 Thread David L. Nicol
Uri Guttman wrote: > but we need a better syntax for s/// that doesn't modify its string but > returns a copy which has had the substitution applied to it. possibly a > s/// modifier? > > $new = $old =~ s/foo/bar/n ; > > n for new? if our internal string representation could grow from

Re: Do we really need eq?

2000-08-30 Thread David L. Nicol
Fisher Mark wrote: > * Units of measure are optional; > * Units of measure are fast; and > * Implementing units of measure don't appreciably slow down computations > that don't use units of measure. enforced types without automatic conversions does all this, the matches are made once at compile-

Re: RFC 146 (v1) Remove socket functions from core

2000-08-30 Thread David L. Nicol
Dan Sugalski wrote: > > > >Oh, and then they will be unloaded if we need the space for something > >else. I understand now, thanks. > > Well, probably not, though that could be reasonable for a particular > platform. It's only relevant for a persistent interpreter anyway--for ones > fired up fr

Re: RFC 132 (v3) Subroutines should be able to return an lvalue

2000-08-30 Thread David L. Nicol
Johan Vromans wrote: > > Hi David, > > [Quoting David L. Nicol, on August 29 2000, 19:27, in "Re: RFC 132 (v3) Sub"] > > > With the enhanced C operator, subroutines can dynamically decide > > > what to return. > > > > With context-b

Re: RFC 146 (v1) Remove socket functions from core

2000-08-30 Thread David L. Nicol
Nick Ing-Simmons wrote: > > David L . Nicol <[EMAIL PROTECTED]> writes: > >"overlay" is reminiscent of old IBM machines swapping parts of the > >program out because there isn't enough core. > > Which is exactly why I chose it - the places these thin

Re: RFC 33 (v2) Eliminate bareword filehandles.

2000-08-29 Thread David L. Nicol
How about ALLOWING bareword everything-else? Start having filehandles work the way everyone expects them to at first, passing as arguments and so forth, without any special treatment? -- David Nicol 816.235.1187 [EMAIL PROTECTED] Subroutine one-arg, him c

Re: RFC 2 (v3) Request For New Pragma: Implicit

2000-08-29 Thread David L. Nicol
> > I am lazy. I am spoiled by the implicit $_. I like the implicit > $_. Implicit $_ good. Ugh. (Conversely, some people abhor the I believe you mean "Ug." "Ug" means you are speaking pidgin, while "Ugh" indicates disgust. > =head1 IMPLEMENTATION > > The front-end would have to detect v

Re: RFC 168 (v1) Built-in functions should be functions

2000-08-29 Thread David L. Nicol
One function that takes an optional leading commaless arg: sub print(handle? $FH, @) or Two functions differentiated by their prototypes sub print(@); sub print(handle,@); I'm always forgetting the comma after the handlename in C statements because I learned "no c

Re: RFC 162 (v1) Filtering Here Docs

2000-08-29 Thread David L. Nicol
Richard Proctor wrote: > > This leads back to my original "remove all whitespace". Somehow there is a > compromise to extracted from this. Have we explored using a subset of regex for end-markers? $long_string_possibly_indented_later = <<\w*##ENDEND##\w*; .

Re: RFC 132 (v3) Subroutines should be able to return an lvalue

2000-08-29 Thread David L. Nicol
Perl6 RFC Librarian wrote: > With the enhanced C operator, subroutines can dynamically decide > what to return. With context-based polymorphism, the decision can be made staticly.

Re: no autovivify?

2000-08-29 Thread David L. Nicol
Tom Christiansen wrote: > > If you can no longer grow hashes or arrays on demand, does this > extend to strings not being able to get bigger, and to integers not > being able to become floats? > > --tom Exactly. What do you think :closed should do, Tom? -- David Ni

Re: RFC 155 - Remove geometric functions from core

2000-08-29 Thread David L. Nicol
Dan Sugalski wrote: > > Don't forget the fixup work that needs to be done afterwards. Loading the > library into memory's only the first part--after that the loader needs to > twiddle with transfer vectors and such so the unresolved calls into the > routines in the newly loaded library get resol

Re: RFC 146 (v1) Remove socket functions from core

2000-08-29 Thread David L. Nicol
Nick Ing-Simmons wrote: > We need to distinguish "module", "overlay", "loadable", ... if we are > going to get into this type of discussion. Here is my 2ยข: > > Module - separately distributable Perl and/or C code. (e.g. Tk800.022.tar.gz) > Loadable - OS loadable binary e.g. Tk.so or Tk.dll >

Re: RFC 122 (v1) types and structures

2000-08-29 Thread David L. Nicol
John Porter wrote: > > we should also support recursive data structures, > as in some functional languages. E.g. (pseudocode): > > define foo as { > short a; > foo b; # exists at first only "in potential". > long c; > }; > h

Re: RFC 120 (v2) Implicit counter in for statements, possibly$#.

2000-08-29 Thread David L. Nicol
I'd like to see a last-container-key attribute included as a possibilty; and that attribute called ":n" to match the argument of integer functions in introductory algebra. This approach gives us for $a @some_list { print "$a is located at position ${a:n}\n"; };

Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)

2000-08-29 Thread David L. Nicol
the semicolon after the hereis terminator thing might only work if the beginning of the hereis was the last thing on the line it appears on, that way there's no ambiguity $Goodone = < > I like it... I think I will add this to the next version. > > Richard > > -- > > [EMAIL PROTECTE

Re: RFC 110 (v2) counting matches

2000-08-29 Thread David L. Nicol
Mark-Jason Dominus wrote: > > It occurs to me that since none of the capital letters are taken, we > could adopt the convention that a capital letter as a regex modifier > will introduce a *word* which continues up to the next comma. Excelsior! -- David Nicol 816.2

pseudo-RFCs

2000-08-29 Thread David L. Nicol
[EMAIL PROTECTED] wrote: > DO NOT fill -language with discussions of pseudo-RFCs. Please. > I'm begging you. > > K. Then where is the proper forum for mere ideas, non focused enough to formalize into an Official Proposal? Or do you just mean those particular ones. --

drop type indicators for typed variables

2000-08-29 Thread David L. Nicol
> Christian Soeller wrote: > > > > The other problem with arrays is: how do we deal with functions that > > take multiple piddle arguments if they are arrays: > > > >@result = integrate @x, @y, @bounds; > > > > Won't those all be clumped into one big input array? if strongly typed bareword

Re: no autovivify?

2000-08-29 Thread David L. Nicol
I'm moving this to perl6-language-data Bart Lateur wrote: > > On Tue, 29 Aug 2000 20:21:39 +0800, Kenneth Lee wrote: > > >oday this just came up to my mind, we could have a pragma that disable > >`autovivification' of hash and array keys. Consider the follow code snippet: > > > > @arr = ( 0.

attributes definable as well as values Re: Do we really need eq?

2000-08-29 Thread David L. Nicol
Andy Dougherty wrote: > > On Tue, 29 Aug 2000, David L. Nicol wrote: > > > I'd like to see every number bundled with a "precision" attribute. > > While that might be useful for simple calculations, I expect it would > simply get in the way and sl

Re: RFC 155 - Remove geometric functions from core

2000-08-29 Thread David L. Nicol
Sam Tregar wrote: > > On Tue, 29 Aug 2000, David L. Nicol wrote: > > > Well then. It is impossible to rearchitect it to make it shared > > text? Perhaps the first instance of perl sets up some vast shared > > memory segments and a way for the newcomers to link i

Re: Multiple for loop variables

2000-08-29 Thread David L. Nicol
Exactly. We need a nondestructive slice. Some short piece of syntax which expands for [my](list of vars) (big list){ ... } to my @uniquelynamedcopy = (big list); while ( [my](list of vars) = splice(@u15y,0,(length of list of vars))){ ... } I think the absence o

Re: Do we really need eq?

2000-08-29 Thread David L. Nicol
Steve Simmons wrote: > IMHO the code > > $a = '3.14'; # from reading a file > $b = '3.1400'; # from user input > if ($a == $b) { ... } > > should see the two args being tested in numeric context, do the numeric > casting, get floats, and do a floating compare. Durned if I know what

Re: RFC 155 - Remove geometric functions from core

2000-08-29 Thread David L. Nicol
Well then. It is impossible to rearchitect it to make it shared text? Perhaps the first instance of perl sets up some vast shared memory segments and a way for the newcomers to link in to it and look at the modules that have been loaded, somewhere on this system, and use the common copy?

Re: Are Perl6 threads preemptive or cooperative?

2000-08-28 Thread David L. Nicol
Chaim Frenkel wrote: > > >>>>> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes: > > DLN> What if every subroutine tagged itself with a list of the globals > DLN> it uses, so a calling routine would know to add those to the list > DLN&g

Re: Are Perl6 threads preemptive or cooperative?

2000-08-28 Thread David L. Nicol
What if every subroutine tagged itself with a list of the globals it uses, so a calling routine would know to add those to the list of globals it wants locked?

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-28 Thread David L. Nicol
Nathan Torkington wrote: > > David L. Nicol writes: > > Any subroutine declaration, for instance > > > > sub Cmp:infix($$){ > > return uc($_[0]) cmp uc($_[1]) > > }; > > > > implicitly sets up a "catch unknown-keywo

Re: Are Perl6 threads preemptive or cooperative?

2000-08-25 Thread David L. Nicol
Markus Peter wrote: > > 6: release all mutexes when leaving it for > > any reason (and redoing 2 through 4 on reentry) these reasons would include doing subroutine calls. Which makes data loss possible, without explicit mutexes on check points and if we've got those why bother with implied one

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-25 Thread David L. Nicol
list of functions I've used very recently, or something like that. This Nathan Torkington wrote: > > David L. Nicol writes: > > If we use exceptions of some kind to handle > > syntax, encountering an exception of type "unknown-keyword:Cmp" could > &g

Re: Why except and always should be a seperate RFC.

2000-08-25 Thread David L. Nicol
perl5 sort of already has an C, in that DESTROY() methods are called on any blessed lexicals when the scope closes. Taking advantage of that for closing a file works if you hide your files in an object class or equivalent chicanery. Allowing user code into the list of things that perl does on s

Re: What makes Perl Perl?

2000-08-25 Thread David L. Nicol
David Corbin wrote: > In addition to the four I posted, originally, I've added two. Here's my > working list. > > native pattern matching; > list manipulation > aweswome text processing. > It's application glue (thanks Tim) > Ability to write powerful 1-line programs. > Make easy things easy a

Re: Structuring perl's guts (Or: If a function is removed from aninterpreter, but you can still use it transparently, is it reallygone?)

2000-08-25 Thread David L. Nicol
Dan Sugalski wrote: > If it's decreed that fork is > just there without having to do something special, then it will be no > matter what magic needs to be done. package refimpl::builtins; sub fork { $refimpl::threads::deepcopy_target = new refimpl::perprocglobal

Re: Something akin to ksh's <() and >() syntax

2000-08-25 Thread David L. Nicol
My largely ignored RFC about "shell style redirection" suggested pretty much this. perl5 has it as a feature hidden on the fourth page of the perldoc for "open" It also lets < neatly double as a compact print operator Chaim Frenkel wrote: > > With threading coming, would having a >() and

multidim. containers

2000-08-25 Thread David L. Nicol
You can make multidimensional containers in perl5 by settling on a syntax for combining all the dimensions into a key value and using that as the key in a hash. If arrays as we know them implement by using a key space restricted to integers, I think a reasonable way to get matrices would be to o

Re: RFC 159 (v1) True Polymorphic Objects

2000-08-25 Thread David L. Nicol
Nathan Wiger wrote: > > Oh geez! I'm sorry, I forgot to mention David Nicol in the REFERENCES, > who also gave great input, especially on the BOOLEAN accessor. Thanks > David! I swear I'll put you in v2. :-{ > > -Nate Whatever. You could overload FILE < STRING to be a print operato

Re: RFC 158 (v1) Regular Expression Special Variables

2000-08-25 Thread David L. Nicol
Tom Christiansen wrote: > There's also long been talk/thought about making $& and $1 > and friends magic aliases into the original string, which would > save that cost. I was distressed to discover that s///g does not rebuild the old string between matches, but only at the end. It broke my ran

Re: RFC 157 (v1) Delete C and C commands.

2000-08-25 Thread David L. Nicol
Michael G Schwern wrote: > Compare: > > dbmopen(%foo, 'somefile', 0644); > > with: > %foo:persistent(file=>somefile);

Re: Are Perl6 threads preemptive or cooperative?

2000-08-25 Thread David L. Nicol
Steven W McDougall wrote: > > Thread1 Thread2 > $a = $b;$b = $a; > > preemptive threading requires > - mutexes to protect $a and $b > - a robust deadlock avoidance strategy I think a robust deadl. avd. strat. is something like: 1: make a list of all variables

Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping

2000-08-25 Thread David L. Nicol
Looks like if we give the data type control over what the meaning of square brackets after it is, the rest becomes example code. I think this s covered in the horribly misnamed http://dev.perl.org/rfc/115.pod which covers overloading bracketing. @reshaped = reshape $x, $y, $i, @array [,

Re: RFC 146 (v1) Remove socket functions from core

2000-08-25 Thread David L. Nicol
Nathan Torkington wrote: > > moving getprotobyname() >to a module isn't the same as moving open(). And it can be transparent, if it isn't already. Why does perl need to be monolithic? I thought I selcted to build as shared libraries, splitting that into several shared libraries might be e

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-25 Thread David L. Nicol
Last week when I wrote "everything is an exception" this is what I was talking about. Nathan Torkington wrote: > This raises another issue, though: > > You'd obviously want to have a module that collected together your > favourite new operators. But if they were lexically scoped, they'd >

infix functions

2000-08-25 Thread David L. Nicol
Jarkko Hietaniemi wrote: > " e q " that breaks our long and glorious tradition of splitting tokens on whitespace. How about e_q for this one? > That is, an operator that ignores any leading, any trailing, and treats > all intraspace as equivalent. If the embedded space is confusing,

Re: RFC 143 (v1) Case ignoring eq and cmp operators

2000-08-25 Thread David L. Nicol
Perl6 RFC Librarian wrote: > =head1 IMPLEMENTATION > > Probably has to be added to perl internals... > > I wonder what will happen with overloads though - is eq/i a new operator > to overload or is the case-insensitivity somehow magically done by the > Perl interpreter even though eq was overl

Re: Are Perl6 threads preemptive or cooperative?

2000-08-25 Thread David L. Nicol
Dan Sugalski wrote: > > At 02:49 AM 8/25/00 -0400, Steven W McDougall wrote: > >Are Perl6 threads preemptive or cooperative? > > Perl 6 threads will use the native threading system on each platform. To do > otherwise means an enourmous amount of mostly useless work. It's just not > worth it. No

Re: McNamara's C<$#> as a property of any array element

2000-08-25 Thread David L. Nicol
Imagine a combined hash/array CONTAINER type. The difference between hashes and arrays becomes that arrays are restricted to non-negative integer key values. @grumpy and %grumpy can even have the same head node in their data structure, but the accessors will, unless told otherwise, only pick o

Re: rfc142

2000-08-25 Thread David L. Nicol
Glenn Linderman wrote: > Edwin's arguments against the idea seem reasonable; I think it would take some > compelling benefit to invest in implementing a C type & structure parser in perl, for > this use. Further, the C syntax doesn't provide for explicitly sized types, and what > would you do wi

Re: rfc142

2000-08-25 Thread David L. Nicol
Edwin Wiles wrote: > Maintainer Statement: > Okay, I've added a note that wholesale adoption of C structure > definitions, with appropriate modifications, has been suggested. > However, if you really want it seriously documented, you'll have to > write it up. I did. Three or four times

Re: 122 (v1): types and structures

2000-08-24 Thread David L. Nicol
David Corbin wrote: > > "int" and "float", vary greatly per > machine, though I believe ALL the numeric types can vary from one > machine to another. not _SPECIFYING_ just DECLARING. I imagine we'd default to "use native" for the internals of what the types meant, but "use java" would be one

Re: 122 (v1): types and structures

2000-08-24 Thread David L. Nicol
Tom Christiansen wrote: > > >Tom Christiansen wrote: > > >> C type declarations are pretty universally despised. > > >By whom? > > >This is news to me. I have always thought that the C type declaration > >is a concise and platform-independent way of declaring a packed > >structure, and effect

Re: 122 (v1): types and structures

2000-08-24 Thread David L. Nicol
Tom Christiansen wrote: > C type declarations are pretty universally despised. By whom? This is news to me. I have always thought that the C type declaration is a concise and platform-independent way of declaring a packed structure, and effectively hiding implementation details (offsets into i

perl6-all@perl.org

2000-08-23 Thread David L. Nicol
Buddha Buck wrote: > Perhaps someone should RFC the new special variable &ME, which is > predefined to be the whole program. Who knows? Perhaps it would then make > sense to use @_ at the top level, as if the program was invoked as > "&ME(@ARGV);"... on -objects it has been proposed that &ME i

working mnemonic for =~

2000-08-23 Thread David L. Nicol
Steve Fink wrote: > I couldn't for the life of me > remember whether it was ~= or =~. I've also observed one perl beginner > look up the symbol in a book every single time she needed it for a new > program. all the self-assignment operators are operator, then equal-sign. =~ is not a self-assig

extremely general top level threaded loop

2000-08-23 Thread David L. Nicol
John Porter wrote: > > "All flow control will implemented as longjumps." > > -- > John Porter # language description has a lot to do. # this is a general, threaded, top-level loop. # a no-brainer. $rearrange = sub{ # so this can be redefinied my $i, $t, $n; for (my $i =

Re: PROTOPROPOSAL FOR NEW BACKSLASH is still Re: implied pascal-like"with" or "express"

2000-08-23 Thread David L. Nicol
Thanks, the actual effects of \ in doublequotes slipped my mind. Nathan Torkington gracefully extolled: > I'd be more receptive to something that reuses existing or similar > Perl syntax (e.g., extend ->). with %container { ->$fieldname = $value; ${->destinationvaluename}

Re: RFC 133 (v1) Alternate Syntax for variable names

2000-08-23 Thread David L. Nicol
David Corbin wrote: > > > > For the remainder of the enclosing block, the barewords var, > > array and hash are to be interpreted as references to a scalar, an > > array, and a hash. > > I'm confused by this statement. Are you suggesting an alternative to > the original RFC? No, I was trying

Re: $ME in a method called as a subroutine

2000-08-23 Thread David L. Nicol
Piers Cawley wrote: > > In my opinion the contents of $ME should allow to determine wether it was > > called as a procedure or as a method, the easiest way to do that is undef > > for procedure, object for method and classname for class methods. > > Procedure reference for a procedure call pleas

Re: why not just use C /* ... */ ?

2000-08-23 Thread David L. Nicol
> If the prime argument for mlc is commenting out large blocks of code > then you'd better solve the nesting problem -- and do it well. vi substitution :.,+20s/^/##obsoleted Aug 22, 2000 ## / works really well for the large blocks of code problem, so do $BOGUS::Comment=<

Re: RFC 136 (v1) Implementation of hash iterators

2000-08-22 Thread David L. Nicol
Dan Sugalski wrote: > > Any variable that has a 'per-thread' component should be self-contained. > > Dan We don't know how many instances of iteration happening in the program there will be, or how many there can be. If each instance of hash iteration

<    1   2   3   4   >