Re: %_ - is it available for use?
Damian Conway [EMAIL PROTECTED] writes: From a Perl 6 perspective, it seems likely that C%_ will be the name commonly used for the slurpy hash of a subroutine. Just as C@_ will often be the name used for the slurpy array. See Exegesis 6 for more details. Indeed, when it comes to object constructors (all of which implicitly have a slurpy hash), C%_ might well be the automatically provided name for that hash. See Exegesis 12 for more details. ;-) Hence, making C%_ mean something different in core Perl 5 might possibly be forwards incompatible. This wouldn't have been a core Perl 5 thing but a (module) Tk thing. But if Perl 6 is giving it a meaning I will avoid it (unless a slurpy hash is what I meant - I haven't kept up the Perl6 jargon.)
%_ - is it available for use?
We have been discussing how to pass data to Tk callbacks. In particular Entry widget validation routines. There are a number of items that they _might_ be interested in but a typical routine would only use a few. Currently it passes them all as positional parameters. One idea that occured to me/us is to have a localized hash for this purpose (which might be tied/magical). One choice of name for this is %_ - which fits neatly with @_ for positional args and $_ as current thing. Also *_ glob already exists to have its GvHV entry (ab-)used. What does p5p think of this use ? Basically @_ says how you been called $_ is what you are working on, and this idea gives %_ the meaning of why. (Caller gives the who ;-) )
RE: Perl5 Compatibility, take 2 (Re: Perl, the new generation)
David Grove [EMAIL PROTECTED] writes: Well, I think we should take a step back and answer a few key questions: 1. Do we want to be able to use Perl 5 modules in a Perl 6 program (without conversion)? For a while, quite possibly, I'd say. When 5.6 came out, I was in module hell, trying to get 5.005 modules to compile with 5.6. Most of the ones giving the most trouble were the most popular/demanded. That's not something I'd like to see repeated. Perl5 modules which make use of XS will be more of a pain to support, and most of the perl5.6 fails were due to XS-ness tweaks (PERL_POLLUTE). -- Nick Ing-Simmons http://www.ni-s.u-net.com/
Re: Schwartzian Transform
Simon Cozens [EMAIL PROTECTED] writes:
On Mon, Mar 26, 2001 at 10:50:09AM -0500, Uri Guttman wrote:
SC it? That is, @s = sort { f($a) = f($b) } @t
because that would require the PSI::ESP module which isn't working
yet. how would perl intuit exactly the relationship between the records
and the keys extraction and comparison? the ST defines that by the first
map and the comparison callback. just providing the comparison would
entail perl parsing an arbitrarily complex piece of code and then
autognerating the map that would produce an anon array that fits it. not
a simple task.
No, it wouldn't, don't be silly. The ST can always be generalized to
ST(data, func, compare) =
map { $_-[0] } sort { compare($a-[1], $b-[1]) } map { [$_, f($_)] } data
In fact, you can implement it in LISP just like that:
(defun Schwartzian (list func compare)
(mapcar
(lambda (x) (car x))
(sort
(mapcar
(lambda (x) (cons x (funcall func x)))
list
)
(lambda (x y) (funcall compare (cdr x) (cdr y)))
)
)
)
So can you write that in perl5 rather than LISP?
If not what does perl6 need so we can write it in perl6.
sub Schwartzian
{
...
}
Do you see any ESP there? Do you see any parsing of arbitrary pieces of
code? No, me neither.
--
Nick Ing-Simmons [EMAIL PROTECTED]
Via, but not speaking for: Texas Instruments Ltd.
Re: PerlIO - what next? - (should getc get a character?)
Uri Guttman [EMAIL PROTECTED] writes:
"NI" == Nick Ing-Simmons [EMAIL PROTECTED] writes:
p5p removed
NI I have guts of a stack-of-layers PerlIO scheme coded now
NI (//depot/perlio/... for those with perforce access - merge to 5.7.0
NI will occur as soon a Jarrko likes.)
does it support multiple instances for threads
Not yet.
and async i/o?
If I can find a system that has async IO I will give it a try.
I may do Win32 system that way ...
what about
event handling and such?
What I have so far is "sfio like" except that the "vtable" that disciplines
define (which I call layers) is larger and it is coded in a more object-oriented
style (and of course is under perl's license).
There is nothing stopping an event system doing
splice(@perlio::layers,1,0,@layers_to_handle_blocking);
but the mechanism to mess with per-handle layer stack is not really there yet.
Right now we only have unix (read), stdio (fread) and perlio (buffer layer).
I/we need to code a few more "layers" to get a feel for
i think we need to make a proper api spec on
how the i/o subsystem looks to the outside world and also how it
interacts with the perl6 kernel. as the kernel hasn't been spec'ed or
whatever, we have to wait on that some more.
but i am glad to hear of code that we can use as a first draft.
I am not sure this code is a "draft" for perl6 - more of an experiment
so we can see what does('nt) work. The OO ANSI-C with vtable stuff I
used is also and experiment to see what it costs before we start wholesale
coding of perl6.
--
Nick Ing-Simmons
Re: RFC - Interpolation of method calls
Michael G Schwern [EMAIL PROTECTED] writes: print "Today's weather will be $weather-temp degrees and sunny."; This does not DWIM. Instead of interpolating C$weather-temp as a method call, it comes out as C$weather.'-temp' and is usually followed immediately by the question "What does 'Weather=HASH(0x80d4174)-temp' mean??" Most programmers learning OO Perl expect this to work and are surprised to find that it does not. I think $- is unlikely enough in a string that this is worth considering. Work arounds abound: print $weather-report; being the one I like best - avoids the un-meritted assumption it will be sunny ;-) -- Nick Ing-Simmons [EMAIL PROTECTED] Via, but not speaking for: Texas Instruments Ltd.
Re: RFC 127 (v1) Sane resolution to large function returns
Dan Sugalski [EMAIL PROTECTED] writes: At 02:25 PM 8/24/00 -0400, Chaim Frenkel wrote: But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) Wouldn't that be $baz = 3, since the middle list would be taken in scalar context? Which has sanely become the length of the list rather than last element. -- Nick Ing-Simmons
Re: RFC 95 (v2) Object Classes
Hildo Biersma [EMAIL PROTECTED] writes: =head2 Inheritance As with the existing Cuse base/Cuse fields pragmata, Perl 6 classes should support single, linear inheritance only. Multiple inheritance is generally more trouble than it's worth. Yuck. MI is useful though sometimes abused, and even (cough) Java supports multiple inheritance of interfaces. There is existing perl5 code using mulitple inheritance that we should be able to support in perl 6. Multiple inheritance is useful for 'mixins'. For example Tk has a 'mixin' class Tk::Wm which is used as a prefix to the @ISA list of widgets which are "toplevels" and thus should respond to methods relating to the "Window Manager". These "mixin" classes typically add extra methods which are defined in terms of methods of the "core" object. As such they do not _usually_ require attribute space in the object. -- Nick Ing-Simmons
Re: RFC 106 (v1) Yet another lexical variable proposal: lexical variables made default
J . David Blackstone [EMAIL PROTECTED] writes: I may be making a bad assumption here, but since a package is usually (but not always) defined one per file, I'm assuming that in several of these places where you said "package" we should perhaps think "file." It is common practice in perl5 to do both of these: A. Multiple packages in one file, using lexicals at file scope to communicate bewteen them. B. Package split accross multiple files (classic case being AUTOLOADed subs) with package variables to communicate between the parts. You need to be able to represent both schemes to tanslate perl5 code (but it can be "moderately awkward" to discourage new weirdnesses). -- Nick Ing-Simmons
Re: RFC 14 (v2) Modify open() to support FileObjects and
Chaim Frenkel [EMAIL PROTECTED] writes: What about native extensions? I think VMS (and the old TOPS10) had versions as part of the file name. Do URIs have this capablity? And what does a read of a directory return? URIs or Native? Relative URIs I assume - what are (hopefully) indistinguishable from native in the UNIX case at least. -- Nick Ing-Simmons
Re: RFC 30 (v2) STDIN, STDOUT, and STDERR should be renamed
Michael Fowler [EMAIL PROTECTED] writes: On Sat, Aug 12, 2000 at 08:49:00AM -, Perl6 RFC Librarian wrote: In addition, this RFC recommends deprecating select(), since it is no longer needed with the new fileobject approach described in RFC 14. You should probably mention here that the single-arg form of select() is the one you're suggesting for deprecation, and not the four-arg form. The 4 arg form will be deprecated somewhere else. Splitting the function is a good idea... -- Nick Ing-Simmons
Re: RFC 83 (v1) Make constants look like variables
John Porter [EMAIL PROTECTED] writes: Nick Ing-Simmons wrote: Ed Mills [EMAIL PROTECTED] writes: There are many logical reasons for and against the RFC's here, but saying "it looks like c so it doesn't make it for me" is a weak argument at best. I don't think anyone made that argument - they have all been "I hate that in ..." type comments. You forget... There have been numerous cases of people saying things like "that's what Python [or Java] calls those functions, so we should call them something else." You may be right - though as I recall those were "that's what X calls those functions, ours don't work the same so we should call them something else" My point was if experienced folk don't like something somewhere else we should think twice before borrowing it. The _names_ don't matter much at this stage - Larry can change them but if "making things const like C++" is a bad idea then it is a bad idea - A midden by any other name would smell as foul. -- Nick Ing-Simmons
Re: RFC 84 (v1) Replace = (stringifying comma) with =
Peter Scott [EMAIL PROTECTED] writes:
At 07:29 PM 8/10/00 -0700, Glenn Linderman wrote:
Thanks for the clarification in your intentions, but isn't _any_ bareword is
converted to a string, unless it is in some particular context where a
bareword is
meaningful (such as filehandle)? So that seems to be nothing unique to
=. You
could just as well say
bareword, $whatever
and get the same effect in perl5!
Have you used strict lately? :-)
It also matters in this case:
sub bareword { }
foo(bareword,4);
vs
foo(bareword = 4);
--
Nick Ing-Simmons
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
Bart Lateur [EMAIL PROTECTED] writes: On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote: @foo = @bar * @baz; Given that the default action of the multiply routine for an array in non-scalar context would be to die, allowing user-overrides of the functions would probably be a good idea... :) [Is this still -internals? Or should we stop CC'ing?] One problem: overloading requires objects, or at least one. Objects are (currently) scalars. You can't make an array into an object. We are thinking of adding "objects" in the implementation of perl. i.e. perl's primitive "things" (scalars, arrays, hashes) will have 'vtables' (table of functions that do the work). So in that sense an array as in @foo can be an "object" at some level of meaning while not being an "object" at the perl level. -- Nick Ing-Simmons
Re: RFC: Higher resolution time values
Dan Sugalski [EMAIL PROTECTED] writes: Why - the 1/10 of second is not exact anyway (unless you happen to have an atomic clock in an appropriate physical enviroment attached to your machine). A double's mantissa is better than your typical oscillator. While it may not be correct, at least it's exact. The importance of the distinction escapes me - where the errors come from does not matter in the real world. If we go with an inexact representation, we run the risk of accumulating errors and eventually ending up with a number that's both inexact and incorrect. But computer time is always inexact and incorrect - thats why we need NTP. -- Nick Ing-Simmons
Re: RFC 14 (v2) Modify open() to support FileObjects and
Graham Barr [EMAIL PROTECTED] writes: On Wed, Aug 09, 2000 at 11:41:42AM -0500, Jonathan Scott Duff wrote: How about this? open '/etc/passwd'; # file OK open '/usr/local/bin/'; # directory (note the trailing '/') Portability, not all platforms use / Allowing URI/URL syntax can perhaps dodge the "portability" issue URLs use / so if user thinks URL they think /. -- Nick Ing-Simmons
Re: Ramblings on base class for SV etc.
Dan Sugalski [EMAIL PROTECTED] writes: Well, compactness for one. With a scalar on one side it's less odd (it was a bad example). When funkier, though: @foo = @bar * @baz; the expansion becomes less obvious It is "obviously" a cross-product ;-) With perl's $s and @s we can actually make sensible choice between mathamaticians · (dot) and X (cross) produducts from context. Whether that is a good idea is another matter. and quite a bit larger, especially if the arrays are multidimensional. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk -- Nick Ing-Simmons
Re: Overloading ||
Peter Scott [EMAIL PROTECTED] writes:
At 06:23 PM 8/9/00 +, Nick Ing-Simmons wrote:
Damian Conway [EMAIL PROTECTED] writes:
Operator overloading is scheduled to be revamped.
While I remember - it would be good if overload mechansim
could be extended to cover and ||
Yes.
as well as and |
with the class deciding if short-circuit happens.
No. I don't want to see or || and not know whether it short-circuits
without looking in the class interface. My brain is conditioned through
years of C and Perl to expect that they always short-circuit. This is too
venerable a semantic to change. Please.
The reason I want the class to decide is not to change the semantic meaning
but the implementation - i.e. _when_ it short circuits.
I have an application which overloads all the ops and builds a little parse
tree of objects. When you "look" at the tree it returns the value.
my $a = new Thing;
my $b = new Thing;
my $cond = $a $b; # an object
sub foo
{
if ($cond)
{
}
}
$a-bind($a_value);
$b-bind($b_value);
foo();
If things worked as I wanted then when foo is called and "looks" at $cond
then overloaded "boolean" operator of $cond would walk the tree and see
if $a should be considered "true" with its current binding if not
it would short-circuit tree traversal, if it was it would go look at $b's
trueness.
Currently it is completely hosed by and || as perl will not give me
access to the short-circuited operand so I cannot put it in my tree so
when it evaluates I get the wrong answers.
(To make app. work I use and | and make _those_ short circuit - but
my users and I keep forgetting ...)
I don't think giving overload control over short-circuit is any more
surprising than allowing overloaded '+' to subtract.
--
Nick Ing-Simmons
Re: Overloading ||
Dan Sugalski [EMAIL PROTECTED] writes:
I have often wondered whether a language could allow user-defined
operators. The fact that none have done it should be a clue :-)
What, like C++? ("I don't believe in it?" "What, C++? Just a conspiracy of
computer programmers?")
You cannot as far as I aware define new operators in C++ - just redefine the
ones you have. I cannot decide that '|' is now an operator.
I guess it's getting too incestuous with the lexer.
That is the root of the problem.
--
Nick Ing-Simmons
Re: Language RFC Summary 4th August 2000
Dan Sugalski [EMAIL PROTECTED] writes: At 11:40 AM 8/5/00 +, Nick Ing-Simmons wrote: Damian Conway [EMAIL PROTECTED] writes: It definitely is, since formats do things that can't be done in modules. Such as??? Quite. Even in perl5 an XS module can do _anything at all_. It can't access data the lexer's already tossed out. A source filter can, but not elegantly. That's where the current format format (so to speak) runs you into trouble. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk -- Nick Ing-Simmons
Re: perl 6 requirements
Alan Burlison [EMAIL PROTECTED] writes:
"Randal L. Schwartz" wrote:
Graham sub def { my @a = (9,8,7); return @a; }
That's not returning the array. That's returning a copy of the contents
of @a in a list context, and the number of elements of @a in a scalar
context, using the "@a" operator. You still haven't "returned the array".
So then in fact it is impossible to return an array - yes? You can
either return a single scalar or a list. The closest you can come to
returning an array as an entity is to return a reference to it - \@a.
Have I got that straight?
At the perl level yes. The core C can push an AV * on the stack
but perl does not know what it means. (Tk did this for a while
internally before I decided to comply with the perl semantics.)
--
Nick Ing-Simmons
Re: RFC: lexical variables made default
John Porter [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Perl's similarity to English is one of the things that makes it Fun. OTOH, being fun (which I admit it is) is one of the reasons many people don't want to think Perl is a serious language. English had the same problem for 100s of years - all the serious stuff was done in latin (or even french). -- Nick Ing-Simmons
Re: Recording what we decided *not* to do, and why
Michael Mathews [EMAIL PROTECTED] writes: Jonathan Scott Duff said Status: tabled # shelved, put away for now Please avoid 'tabled' - it means near the opposite in the UK. To table something is to put it "on the table" i.e. open for discussion. -- Nick Ing-Simmons
Re: RFC 15 (v1) Stronger typing through tie.
John Porter [EMAIL PROTECTED] writes: Michael Fowler [EMAIL PROTECTED]: use typing; # place your fingers on the home row.. my integer $quux = 4; I believe that would have to be integer my $quux = 4; at least in perl5... Well Larry has been using my Dog $spot; for a while. But I just realized if $ is one of something, @ sereral etc. then do we need a magic char to designate 'type' (class or whatever). I suppose: my ¢Dog $spot; # That is "cent" i.e. c with line. might do ;-) -- Nick Ing-Simmons
Re: RFC: lexical variables made default (revised)
Nathan Wiger [EMAIL PROTECTED] writes:
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of this change
First off, I think this is a great idea in principle. However, I don't
think it goes nearly far enough in the implementation. I'd like to
propose something radical.
Consider code like this, which is not uncommon:
use strict;
my $var1 = 'some val';
my $var2 = 'some other val';
sub mysub {
my($arg1, $arg2) = @_;
(my $result = $arg1) =~ s/some/every/g;
return ($result, $arg2);
}
my @stuff = mysub($var1, $var2);
You get the idea. Dang there's a lot of my()'s in there! The only thing
I see this RFC changing is the need for the "use strict" statement.
However, the code is still littered with what I would argue are
"useless" my()'s that serve as workarounds for a fundamental flaw in the
langauge: all variables are global by default.
Go look at some Tcl/Tk code for what happens if you make everything
innermost lexical by default.
You get liberal sprinkling of
upvar 2 foo
global fred harry
etc.
The problem is you quite often whant variables to cross {} boundaries,
if any mention of thing on left declares it in current scope you
end up with "upvar" and "global" to say "no I don't mean that".
--
Nick Ing-Simmons
Re: RFC 27 (v1) Coroutines for Perl
Dan Sugalski [EMAIL PROTECTED] writes: At 01:17 PM 8/4/00 +0500, Tom Scola wrote: [I think this belongs on the language list, FWIW, Cc'd there] I like this, but I'd like to see this, inter-thread queues, and events all use the same communication method. Overload filehandles to pass events around instead, so: I'm proposing that events and threads be dropped in lieu of coroutines. Not gonna happen. Tk and signals, at the very least, will see to that. As far as I am aware any multi-processing problem can be reduced to message passing and these "co routines as IO" are just one stab at that. For example occurance of a signal could just "print" down the handler "pipe", Likewise mouse click could just "print" down the Tk-ish ButtonPress-1 pipe. It is the "return path" that bothers me - and of course the thread behind the co routine still has locking issues if it updates "global" state. -- Nick Ing-Simmons
Re: date interface (was Re: perl6 requirements, on bootstrap)
Simon Cozens [EMAIL PROTECTED] writes: On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote: I like perl's smart built-in IO just fine, thanks. :) Don't mind making it better, but I do mind making it optional. If we're going to do line disciplines, we need a built-in stdio replacement. Full ground-up rewrite, like sfio but Perlish. I think that is almost a given - we have been on verge of doing it for perl5 for years. -- Nick Ing-Simmons
Re: perl6 requirements
Chaim Frenkel [EMAIL PROTECTED] writes: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 10:42 PM 8/1/00 -0400, Chaim Frenkel wrote: We may need that all variables are by default lexical. Without the explicit declaration of cross-thread visible variables, doing threading may well be difficult (on one's fingers) DS The two things are orthogonal. Threading doesn't place any sort of DS requirements on lexical or package variable visibility. We could do a deep DS clone ala 5.6.0's ITHREADS, or a partial clone, or start new threads with DS empty package stashes. Or any (or all) combinations of the above. Please explain what the utility of having unshared variables? Thread local storage - is often what you want most of. I might as well just fork(). That assumes you can fork() ... chaim -- Nick Ing-Simmons
Re: formats and localtime
Chaim Frenkel [EMAIL PROTECTED] writes: "LW" == Larry Wall [EMAIL PROTECTED] writes: LW But yelling that formats are essential to the core reminds me of my LW kids, who sometimes act as if they're being excoriated when we're LW merely trying to get them out of their dirty clothes and into some LW clean clothes. As humans we identify too closely with our clothes. What do you mean by core? Core users or core perl engine? I assume 'core perl engine' i.e. /usr/bin/perl or perl.exe they will of course be provided in perl6.tar.gz We need a quick glossary: perl core: perl.exe + perl.dll or .../bin/perl + libperl.so perl distribution anything from perl6.tar.gz Optional module things in CPAN -- Nick Ing-Simmons
Re: type-checking [Was: What is Perl?]
Alan Burlison [EMAIL PROTECTED] writes:
No, I disagree. Perl gains a lot of its expressive power from being lax
about typing. I suspect it will also impose an unacceptable overhed for
the vast majority who don't want it - at the very least every variable
access will have to check an 'are you typed' flag.
Cross posted to internals ('cos it is...)
We should consider using "vtables" to avoid the cost of the conditional
branches (and running out of flag bits).
Thus this function would call variables "type check" "method" -
which for normal case would be pointer to blue-white-hot "NoOp" function
which is near always in-cache, for a typed var it could be a slow
as you wanted...
--
Nick Ing-Simmons
