Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread c . soeller
Nathan Wiger wrote: > what people would want to use the ops for, and it's also more usable to > us non-PDLers. I'd like to suggest that it is not a very good idea to start dividing the world into PDLers and non-PDLers. There are a multitude of reasons but I am not keen to go into details. Chr

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread c . soeller
Doug Hunt wrote: > You might also look at APL, a language which has been doing really funky > N-dimensional > array manipulation for longer than anyone... I'd say PDL has probably been influenced quite strongly by APL/J in its PDL threading notion. And with more and more "funny characters" makin

Re: The Future

2000-09-09 Thread Chaim Frenkel
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes: NT> Chaim Frenkel writes: >> Would it be worthwhile to 'waste' some time on writing caller and callee >> stubs? This would flesh out the final api and give the module writers >> something of an environment to work with? NT> Yes, I'm app

Re: RFC 52 (v2) List context return from filesystem functions

2000-09-09 Thread Peter Scott
At 01:26 AM 9/10/00 -0400, Chaim Frenkel wrote: >Would returning the array of status be sufficient? > > @foo = chmod 755, "bar", "baz", "quux"; > # @foo == (0, 2, 0); > >How to convert them to error messages would be a challenge. >Unless passing them through $! would do the trick.

Re: RFC 52 (v2) List context return from filesystem functions

2000-09-09 Thread Chaim Frenkel
Would returning the array of status be sufficient? @foo = chmod 755, "bar", "baz", "quux"; # @foo == (0, 2, 0); How to convert them to error messages would be a challenge. Unless passing them through $! would do the trick. Hmm, perl -wle '$!=3; print $!' No such process Yup, w

Re: RFCs for thread models

2000-09-09 Thread Steven W McDougall
> SWM> If you actually compile a Perl program, like > > SWM> $a = $b > > SWM> and then look at the op tree, you won't find the symbol "$b", or "b" > SWM> anywhere in it. The fetch() op does not have the name of the variable > SWM> $b; rather, it holds a pointer to the value for $b. > > W

Re: Beefier prototypes (was Re: Multiple for loop variables)

2000-09-09 Thread Chaim Frenkel
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: >> my_while { pred() } { # don't gimme no Tcl flac. >> ... >> } # no semicolon needed here! DC> Just added to the RFC :-) How would the parser handle this? Some '}' would need ';' some don't. -- Chaim Frenkel

Re: Beefier prototypes (was Re: Multiple for loop variables)

2000-09-09 Thread Chaim Frenkel
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes: >> for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... } >> >> Probably we'll have to say that the user must explicitly zip if that >> is what is desired. PS> Yes, please. I view the flattening of lists as a feature, not a bug, and PS> it has made Pe

Re: RFCs for thread models

2000-09-09 Thread Chaim Frenkel
> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes: SWM> If you actually compile a Perl program, like SWM>$a = $b SWM> and then look at the op tree, you won't find the symbol "$b", or "b" SWM> anywhere in it. The fetch() op does not have the name of the variable SWM> $b; r

Re: The Future

2000-09-09 Thread Nathan Torkington
Chaim Frenkel writes: > Would it be worthwhile to 'waste' some time on writing caller and callee > stubs? This would flesh out the final api and give the module writers > something of an environment to work with? Yes, I'm appalled I forgot this. It's part of what I've been thinking about. By ha

Re: The Future

2000-09-09 Thread Chaim Frenkel
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes: NT> Once we have an API, we write test cases to exercise the API. NT> Then we code. Would it be worthwhile to 'waste' some time on writing caller and callee stubs? This would flesh out the final api and give the module writers something

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Chaim Frenkel
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes: NT> Actually, the only refinement I'd like to see is that boolean operators NT> (==, &&, ||) be excepted from the distributive rule. NT> This is to permit: NT> if (@a == @b) # shallow comparison NT> and NT> @a = @b ||

RFCs for thread models

2000-09-09 Thread Steven W McDougall
RFC 178 proposes a shared data model for Perl6 threads. In a shared data model - globals are shared unless localized - file-scoped lexicals are shared unless the thread recompiles the file - block scoped lexicals may be shared by - passing a reference to them - closures - declaring one s

Re: RFC 178 (v2) Lightweight Threads

2000-09-09 Thread Chaim Frenkel
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes: AB> Chaim Frenkel wrote: >> No scanning. I was considering that all variables on a store would >> safe store the previous value in a thread specific holding area[*]. Then >> upon a deadlock/rollback, the changed values would be restored. >>

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Jeremy Howard
Doug Hunt wrote: > Jeremy Howard wrote: > > > - Mathematica (combines functional, declarative, and procedural styles; > > implements memoization, lazy lists, and array notation) > > - Matlab (fast and simple array language) > > - C++ expression templates such as POOMA and Blitz++ (implicit loop

Re: RFC 178 (v2) Lightweight Threads

2000-09-09 Thread Chaim Frenkel
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Right, but databases are all dealing with mainly disk access. A 1ms lock DS> operation's no big deal when it takes 100ms to fetch the data being locked. DS> A 1ms lock operation *is* a big deal when it takes 100ns to fetch the data DS>

Re: Can perforce gateway to CVS without loss of metadata? (was Re: code repository)

2000-09-09 Thread iain truskett
* Nick Ing-Simmons ([EMAIL PROTECTED]) [10 Sep 2000 06:38]: [...] > This is a feature of perforce that is useful - it can warn you that > you are about to change a file that someone else is already working > on. As can CVS. cheers, -- \def\Koschei{Iain Truskett}% http://eh

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Doug Hunt
Jeremy Howard wrote: > - Mathematica (combines functional, declarative, and procedural styles; > implements memoization, lazy lists, and array notation) > - Matlab (fast and simple array language) > - C++ expression templates such as POOMA and Blitz++ (implicit looping and > generalised slicin

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Nathan Torkington
Jeremy Howard writes: > > @a = @b || @c; # @a=@b or @a=@c; # ish > Doesn't work in P5 (try it!) I know it doesn't, and I'm saying (yet again) that I'd like it to work in perl6. Nat

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Jeremy Howard
Nathan Torkington wrote: > Jeremy Howard writes: > > No, there's no arbitrary decision. *Every* operator is component wise on > > lists. It is internally consistent, and consistent with most other languages > > that provide array/list operators. It's easy to get stuck on the '*' > > example, becau

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Jeremy Howard
Nathan Wiger wrote: > My main fear is that while this RFC seems really good for math ops, but > seems too array- and PDL-specific. Here are some examples of mixed > contexts; how would these be handled under the RFC? > > @user_data = @empty || $user; > %files = scalar(get_files()) || @DEFA

Re: Can perforce gateway to CVS without loss of metadata? (was Re: code repository)

2000-09-09 Thread Barrie Slaymaker
Nick Ing-Simmons wrote: > > > I see no reason why the perforce changes cannot be 'checked in' to CVS > one-by-one so that CVS builds its own representation of the change history. I've got this working now in a program called 'vcp', I need to test p4->cvs updates using the perl5 repository next

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Jeremy Howard
Nathan Wiger wrote: > The only thing that *really* makes me nervous about the RFC is this > part: > > > > @d = @b * @c; # Returns (2,8,18) > > > > > > If the lists are not of equal length, an error is raised. > > I really don't like the "error is raised" part, at least not by default. > Maybe

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Nathan Wiger
Nathan Torkington wrote: > > Actually, the only refinement I'd like to see is that boolean operators > (==, &&, ||) be excepted from the distributive rule. > > This is to permit: > > if (@a == @b) # shallow comparison > > and > > @a = @b || @c;# @a=@b or @a=@c; # ish

New Perl rewrite - embedded Perl

2000-09-09 Thread Matthew Gillman
Dear All I wrote a large C++ program which used embedded Perl. Later, this was changed to embedded Python. The reasons for this included: 1) Python allows you to pass a pointer to an object from C/C++ to the embedded Python interpreter, wheras Perl makes you push and pop off the stack (as far

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Nathan Wiger
[EMAIL PROTECTED] wrote: > > I disagree. You end up with a situation where some > >@a * @b; > > are in scalar context, some not. No, everything would be in a scalar context. If you used tie() to specially tie a variable, then you might be able to overload +, *, -, etc, but this is no diffe

Re: A tentative list of vtable functions

2000-09-09 Thread Nick Ing-Simmons
Ken Fox <[EMAIL PROTECTED]> writes: >Short >circuiting should not be customizable by each type for example. We are already having that argument^Wdiscussion elsewhere ;-) But I agree variable vtables are not the place for that. -- Nick Ing-Simmons

Re: RFC 178 (v2) Lightweight Threads

2000-09-09 Thread Nick Ing-Simmons
Chaim Frenkel <[EMAIL PROTECTED]> writes: > >NI> Indeed that is exactly how tied arrays work - they (automatically) add >NI> 'p' magic (internal tie) to their elements. > >Hmm, I always understood a tied array to be the _array_ not each individual >element. The perl level tie is on the array. Th

Re: Event model for Perl...

2000-09-09 Thread Nick Ing-Simmons
Grant M. <[EMAIL PROTECTED]> writes: >I am reading various discussions regarding threads, shared objects, >transaction rollbacks, etc., and was wondering if anyone here had any >thoughts on instituting an event model for Perl6? I can see an event model >allowing for some interesting solutions to s

Can perforce gateway to CVS without loss of metadata? (was Re: code repository)

2000-09-09 Thread Nick Ing-Simmons
Bradley M . Kuhn <[EMAIL PROTECTED]> writes: >Adam Turoff wrote: > >> *: Sarathy tells me that Perforce sucks at maintaining thousands of >> anonymous checkouts, while CVS doesn't mind at all. This is a feature of perforce that is useful - it can warn you that you are about to change a file th

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Nathan Torkington
Jeremy Howard writes: > No, there's no arbitrary decision. *Every* operator is component wise on > lists. It is internally consistent, and consistent with most other languages > that provide array/list operators. It's easy to get stuck on the '*' > example, because different mathematicians have di

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Nathan Wiger
Jeremy Howard wrote: > > Not only do you lose consistency here (as Christian already pointed out), > but also speed. Array functions and operations would be tightly optimised > loops, and furthermore multiple operations would avoid redundant loops and > copies. Good luck finding a way of getting

Re: RFC 201 (v1) hash slicing

2000-09-09 Thread Bart Lateur
On 8 Sep 2000 04:57:46 -, Perl6 RFC Librarian wrote: >Instead of > > %subhash = map { f($_) ? ($_, $hash{$_}) : () } keys %hash; # lengthy > >one may now write > > %subhash = %hash{f($_)};# code block f($_) will be evaluated for Truth >over all the keys I almost like

Re: Pre-RFC: undef =~ s/def/initialize/

2000-09-09 Thread John Porter
Randal L. Schwartz wrote: > > uninit looks like a typo for "unit". > > Maybe we need "denit" for "de-nitialize" :)... Yuck. I dislike "de-" anything. "un-" is far more often the correct prefix. Anyway, the counterpart of "init" should be, I think, "exit". But seriously, the opposite of "ini