Dan Sugalski wrote:
> Plus I can see each being used more often if we extend it to be valid for
> sparse arrays, or used more under the hood with iterators and lazy lists
> and suchlike things. Each, when used on a sparse array, would presumably
> return a list of offset/value pairs of valid entri
Larry Wall wrote:
>
> I expect that we'll get more compile-time benefit from
>
> my HASH sub foo {
> ...
> }
>
> %bar = foo();
Ah, the Return Value Optimization so loved in C++...
For those who haven't seen it before, you can optimize this by passing
in a reference to %bar
On Thu, 24 Aug 2000 09:38:28 +0100, Hildo Biersma wrote:
>> I expect that we'll get more compile-time benefit from
>>
>> my HASH sub foo {
>> ...
>> }
>>
>> %bar = foo();
>
>Ah, the Return Value Optimization so loved in C++...
>
>For those who haven't seen it before, you can
Bart Lateur writes:
: On Thu, 24 Aug 2000 09:38:28 +0100, Hildo Biersma wrote:
:
: >> I expect that we'll get more compile-time benefit from
: >>
: >> my HASH sub foo {
: >> ...
: >> }
: >>
: >> %bar = foo();
: >
: >Ah, the Return Value Optimization so loved in C++...
: >
:
At 08:02 AM 8/24/00 -0700, Larry Wall wrote:
>Bart Lateur writes:
>: On Thu, 24 Aug 2000 09:38:28 +0100, Hildo Biersma wrote:
>:
>: >> I expect that we'll get more compile-time benefit from
>: >>
>: >> my HASH sub foo {
>: >> ...
>: >> }
>: >>
>: >> %bar = foo();
>: >
>: >Ah, t
Dan Sugalski writes:
: Chicanery's on the big To Do list. I'm really wanting to defer list
: flattening as long as possible, and skipping it all together.
And I'm wondering whether it's better in general to explicitly force a
context in which we treat @foo and %bar as objects, rather than trying
On Thu, Aug 24, 2000 at 03:43:41PM -, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Remove socket functions from core
>
> =head1 VERSION
>
> Maintainer: Stephen P. Potter <[EMAIL PROTECTED]>
> Date: Aug 24
> =item *
>
> "safe" renamed to "trans"
Still not good. "trans" is too overloaded word. "transaction"?
"transactional"? (a bit too long...) "atomic"?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
>Remove socket functions from core
Why? What is the justification? I can think of some, but you
haven't given them.
In general, the misplaced zealotry to strip Perl down into someting
where nothing is predefined is hardly a good investment. It's not
like it will make anything appreciably sma
Jarkko Hietaniemi wrote:
>
> Still not good. "trans" is too overloaded word. "transaction"?
> "transactional"? (a bit too long...) "atomic"?
"acid"?
http://www.cs.duke.edu/education/courses/cps212/fall98/slides-html/recover/tsld002.htm
http://www.byte.com/art/9504/sec11/art3.htm#fouracid
T
>At 10:26 AM 8/24/00 -0600, Tom Christiansen wrote:
>> >Remove socket functions from core
>>
>>Why? What is the justification? I can think of some, but you
>>haven't given them.
>There are a number of good reasons to do this from an internals standpoint,
>enough that I'd like to do it.
Is one
Tom Christiansen writes:
> >There are a number of good reasons to do this from an internals standpoint,
> >enough that I'd like to do it.
>
> Is one allowed to know that number, and those reasons? :-)
No idea what the internals reasons are. Here are my reasons:
* the current socket(), bind(),
>No idea what the internals reasons are. Here are my reasons:
It would be a good idea to work over the way sockets are used and maybe come
up with a better model than the C/Unix like way things are now. Having
sockets in the core makes as much sense as having the ability to open and
read disk
>up with a better model than the C/Unix like way things are now. Having
>sockets in the core makes as much sense as having the ability to open and
>read disk files (early Pascal anyone?) in todays world of networked
>computers.
>From what Larry's said about making open work on URLs, he's
in you
I would actually further this sort of activity.
I admire micro-kernel-type systems. C and Java give you no functions out of
the box. Keywords are just that, keywords. I believe python is like this
as well. The idea being that everything has to come from a module.. This
limits how much a new de
>I admire micro-kernel-type systems. C and Java give you no functions out of
>the box. Keywords are just that, keywords. I believe python is like this
>as well. The idea being that everything has to come from a module.. This
>limits how much a new developer has to learn, and it doesn't pollute
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> implicit references internally. Consider how you'd implement
LW> push(@foo, @bar);
LW> vs
LW> push(@foo, \@bar);
LW> If you defer the decision to flatten into the function, then you have
LW> to distinguish those two kinds of refe
At 11:38 AM 8/24/00 -0600, Tom Christiansen wrote:
> >At 10:26 AM 8/24/00 -0600, Tom Christiansen wrote:
> >> >Remove socket functions from core
> >>
> >>Why? What is the justification? I can think of some, but you
> >>haven't given them.
>
> >There are a number of good reasons to do this from a
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>*) It makes optionalizing (now there's a good word... :) the functions
>easier for platforms that just don't have 'em. Like, say, the Palm, or
>embedded gadgets. (Most teddy bears aren't likely to come with a network
>stack...)
Most everything will h
At 07:28 PM 8/24/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >*) It makes optionalizing (now there's a good word... :) the functions
> >easier for platforms that just don't have 'em. Like, say, the Palm, or
> >embedded gadgets. (Most teddy bears aren't likely
On Thu, Aug 24, 2000 at 03:49:01PM -0400, [EMAIL PROTECTED] wrote:
> At 07:28 PM 8/24/00 +, Nick Ing-Simmons wrote:
> >When a Palm "is" a WAP Phone it will have one, and while Teddy Bears may
> >not I am sure Furbie-II will...
>
> I'm picturing a WAP-enabled cellular furbie with an R2D2-style
On Thu, Aug 24, 2000 at 08:29:21PM -, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Remove geometric functions from core
>
> =head1 VERSION
>
> Maintainer: Stephen P. Potter <[EMAIL PROTECTED]>
> Date: Aug
Dan Sugalski <[EMAIL PROTECTED]> writes:
> I'm picturing a WAP-enabled cellular furbie with
> an R2D2-style projector thingie for the video.
> It's not a pretty sight...
"Help us Lawrence Wall, you're our only hope..." bzzp!
"Help us Lawrence Wall, you're our only hope..." bzzp!
"Help us Lawr
Lightning flashed, thunder crashed and "Michael Maraist" whispered:
| >From this, socket, and virtually all IPC methods should go the wayside.
| This includes pipes, shell environment ops ( the get and set functions ),
| and even the file-io (open, close, and possibly even printf, sprintf). At
|
>I have several RFCs I need to write about removing certain functionality
>out of the core (math functions, IPC, networking, "user"). I don't want to
>go too overboard. I don't know that we want to go so far as to remove
>printing and such. It might be nice to generalize some functions (like th
A friend pointed out, technically most are trigonometric functions,
not geometric. atan2, cos, sin, acos, asin and tan are all trig.
exp, log, sqrt are... just math I guess.
So I suppose the proposed module would be Math::Trig or some such. Or
maybe, as the source code suggests, Math::High:Falu
>A friend pointed out, technically most are trigonometric functions,
>not geometric. atan2, cos, sin, acos, asin and tan are all trig.
>exp, log, sqrt are... just math I guess.
>So I suppose the proposed module would be Math::Trig or some such. Or
>maybe, as the source code suggests, Math::High
bkuhn wrote:
> >I *think* that the consensus is that we should make it easy for people who
> >want to port to the JVM, or the so-called ".NET Implementation Language".
> >As the JVM porter, I'd like my life easy, but I don't expect perl6 to hand
> >me a JVM implementation---I just want to right co
> >I admire micro-kernel-type systems. C and Java give you no functions out of
> >the box. Keywords are just that, keywords. I believe python is like this
> >as well. The idea being that everything has to come from a module.. This
> >limits how much a new developer has to learn, and it doesn'
>Perhaps it would be better to have Perl support all of perlfunc(1) in the
>core still, but allow users to turn subsets off?
>Or, perhaps the core functions could be syntactic sugar for access to
>modules, and have a transformation happen automagically in the parser? (My
>gut says "here there be
Ok, time to head back to planet Earth and the story of perl6.
Back to the grindstone!
Nat
(party pooper)
At 03:34 PM 8/24/00 -0600, Tom Christiansen wrote:
> >I have several RFCs I need to write about removing certain functionality
> >out of the core (math functions, IPC, networking, "user"). I don't want to
> >go too overboard. I don't know that we want to go so far as to remove
> >printing and su
Dan Sugalski writes:
> One of the current plans is for the parser to have access to a list of
> functions that trigger autoloading modules.
Isn't dynamic loading really slow? If they're going to incur the
penalty of dynamic loading, you might as make them request that
slowdown by 'use'ing the m
At 06:24 PM 8/24/00 -0400, Bradley M. Kuhn wrote:
>Dan Sugalski wrote:
> > Having a solid and correct reference doc for the output bytecode is
> > probably the single most helpful thing we can do for folks writing things
> > that munch the bytecode.
>
>Actually, I don't think that munching Perl by
I'm missing what you are trying to say. Are you suggesting that
$foo = @bar no longer mean ($foo = scalar(@bar)) == 3 ?
I wasn't suggesting going that far. Just a little more DWIM.
So that
($foo, @bar, $baz) = (1,2,3) # $foo = 1 @bar=(2,3), $baz = undef
# o
At 10:26 AM 8/24/00 -0600, Tom Christiansen wrote:
> >Remove socket functions from core
>
>Why? What is the justification? I can think of some, but you
>haven't given them.
There are a number of good reasons to do this from an internals standpoint,
enough that I'd like to do it.
From an exte
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 24 Aug 2000
Version: 4
Mailing List: [EMAIL PROTECTED]
Numbe
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Remove socket functions from core
=head1 VERSION
Maintainer: Stephen P. Potter <[EMAIL PROTECTED]>
Date: Aug 24 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 146
=head1 ABSTRACT
Move
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)
Woul
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
>>
Chaim Frenkel wrote:
> ($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)
Actually? How about it becoming
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Remove geometric functions from core
=head1 VERSION
Maintainer: Stephen P. Potter <[EMAIL PROTECTED]>
Date: Aug 24 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 155
=head1 ABSTRACT
Mov
Chaim Frenkel writes:
: LW> P.S. I think we *could* let @foo and %bar return an object ref in scalar
: LW> context, as long as the object returned overloads itself to behave as
: LW> arrays and hashes currently do in scalar context.
:
: Isn't this an internals issue?
Not completely. The scalar
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Dan Sugalski writes:
LW> : And do we want to consider making this (and its ilk) Do The Right Thing?
LW> :
LW> :(@foo, @bar) = (@bar, @foo);
LW> We certainly want to consider it, though perhaps not in -internals.
LW> You can talk about
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> 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
45 matches
Mail list logo
