RFC 146 (v1) Remove socket functions from core

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 <spp@ds.net>
  Date: Aug 24 2000
  Mailing List: perl6-internals@perl.org
  Version: 1
  Number: 146
  
=head1 ABSTRACT

Move the socket functions (C<accept>, C<bind>, etc) from the core language
to a loadable module.

=head1 DESCRIPTION

Several of the socket functions have already started to migrate from the
core to a module.  This RFC is proposing that all the socket functions should
move to the Socket.pm module and require a "use Socket;" in order to function
in perl 6.

The specific functions that would be covered under this proposal are:

=over

=item

C<accept>

=item

C<bind>

=item

C<connect>

=item

C<getpeername>

=item

C<getsockname>

=item

C<getsockopt>

=item

C<listen>

=item

C<recv>

=item

C<send>

=item

C<setsockopt>

=item

C<shutdown>

=item

C<socket>

=item

C<socketpair>

=back

=head1 IMPLEMENTATION

Move code for socket functions to Socket.pm, requyire "use Socket" to
enable use of socket functions.

=head1 REFERENCES

L<Socket.pm|the Socket module>

L<perlfunc>

0
perl6
8/24/2000 3:43:41 PM
perl.perl6.internals 7376 articles. 0 followers. Follow

56 Replies
912 Views

Similar Articles

[PageSpeed] 43
Get it on Google Play
Get it on Apple App Store

On Thu, Aug 24, 2000 at 03:43:41PM -0000, 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 <spp@ds.net>
>   Date: Aug 24 2000
>   Mailing List: perl6-internals@perl.org
>   Version: 1
>   Number: 146
>   
> =head1 ABSTRACT
> 
> Move the socket functions (C<accept>, C<bind>, etc) from the core language
> to a loadable module.

Agreed.  While doing this, add sendmsg() and recvmsg() (at last).
(And think about IPv6 (see Socket6 in CPAN))

-- 
$jhi++; # http://www.iki.fi/jhi/
        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen
0
jhi
8/24/2000 4:12:08 PM
>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 smaller or faster, as previous
studies have already proven.  There's no need to have Perl become
a language with merely seven keywords and everything else requires
loading a million libaries for.  You have but to look at Forth or
Tcl or Python for how much that is.  Perl has always had a lot
of functionality predefined.  Why would you want to break that??

--tom
0
tchrist
8/24/2000 4:26:56 PM
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 externals standpoint, though... I've yet to hear a compelling 
reason to require a "use thingies;" to yank 'em in. That being the case, 
I've a scheme that makes them external as far as the internals are 
concerned, but internal as far as the externals are concerned. Best of both 
worlds, more or less.



					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/24/2000 4:38:56 PM
>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 allowed to know that number, and those reasons? :-)

--tom
0
tchrist
8/24/2000 5:38:42 PM
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 developer has to learn, and it doesn't pollute the
global name-space pool.  Though I would advocate OO interfaces to
everything, I'm sure that it would defeat a lot of perl's flexibilty, and so
I'd support the simple Exporter method.

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
this point, it gets a little hairy, since arguably, everybody wants print
and <>.  I would suppose that most want open as well.  My personal taste is
to use IO::File, but that's just me.
Since these are just hooks into standard C libraries, I don't think that
they really take up any room.   But it is hard to justify keeping some of
these less used features while taking out others (like FORMAT).

-Michael


0
maraism
8/24/2000 5:42:13 PM
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(), connect() etc are based VERY closely
   around C, to the point of requiring C structures that are binary
   data which you have to build using a separate module.  So if you're
   using them, you *already* load a module.  Just put the bloody things
   into that module.  You wouldn't lose anything over how it's done
   now.
 * they take magic constants, just like the C function, that are mostly
   the same.  You know the difference between PF_INET and AF_INET, I
   know the difference, but many people do not.  And they shouldn't have
   to.  IO::Socket is a good start at Doing It Right instead of Doing
   The Old Way With Lots of Constants And Arguments.
 * the get*by* for networking stuff (hosts,services,etc) are so rarely
   used they should be moved out.  Yes, it's only a small win.  But
   every byte counts towards a smaller Perl, and moving getprotobyname()
   to a module isn't the same as moving open().

Nat
0
gnat
8/24/2000 5:51:51 PM
>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 the
>global name-space pool.  Though I would advocate OO interfaces to
>everything, I'm sure that it would defeat a lot of perl's flexibilty, and so

A very long time ago, when Perl first came out, people would try to 
make Perl "just like C".  That today the impetus is toward Java
is still really the same story.  Fortunately, Larry didn't do it
then, and I don't see it happening now.

Perl is not into minimalism or non-redunancy: diagonals and all,
eh?  And I don't see objects ever becoming in Perl the Way, the
Truth, and the Light without which no man cometh unto his data, for
that would be too dictatorial in its Thou-Shalt-nesses.  

We've already got lots of those sorts of languages, as you have
noted.  They're a long, long ways from what I would call "fun", an
essential element of Perl that doesn't get mentioned enough.

But we shall see;  perhaps Larry will get a new religion and set
about changing the world in a radically different fashion than his
previous style.

--tom
0
tchrist
8/24/2000 6:18:35 PM
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 an internals standpoint,
> >enough that I'd like to do it.
>
>Is one allowed to know that number, and those reasons? :-)

Nope, it's a secret! :-P

Seriously, they are:

*) Fewer opcodes to deal with. Fewer opcodes means fewer cases to deal 
with, and a potentially smaller (and more cache-coherent) dispatch table

*) Easy upgradability. To fix any issues with these functions as they 
currently exist means replacing perl. If they're a module of sorts, there 
can be a simple plug-in upgrade.

*) 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...)

*) Easy extension. Which is an extension of easy upgradeability, I suppose, 
but if you wanted to open, say, NetWare connections, or IPv6 connections, 
with the current interface it'd be nice to be able to do this without 
rebuilding perl.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/24/2000 6:41:02 PM
Dan Sugalski <dan@sidhe.org> 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 have a network stack if you believe the hype.
When a Palm "is" a WAP Phone it will have one, and while Teddy Bears may 
not I am sure Furbie-II will...



-- 
Nick Ing-Simmons

0
nick
8/24/2000 7:28:28 PM
At 07:28 PM 8/24/00 +0000, Nick Ing-Simmons wrote:
>Dan Sugalski <dan@sidhe.org> 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 have a network stack if you believe the hype.

Being the cynical sort I am (one of the handy side-effects of 
sysadminhood... :), I'll believe that when I see it work. :)

>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 projector 
thingie for the video. It's not a pretty sight...

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/24/2000 7:49:01 PM
On Thu, Aug 24, 2000 at 03:49:01PM -0400, dan@sidhe.org wrote:
> At 07:28 PM 8/24/00 +0000, 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 projector 
> thingie for the video. It's not a pretty sight...

"Help me Larry Wall, he's my only hope ... *static* Help me Larry Wall,
he's my only hope ..."

-- 
May the best description of competition prevail.
      (via, but not speaking for Deutsche Bank)
0
joshua
8/24/2000 8:13:24 PM
Lightning flashed, thunder crashed and "Michael Maraist" <maraism@ironhilltechn
ology.com> 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
| this point, it gets a little hairy, since arguably, everybody wants print
| and <>.  I would suppose that most want open as well.  My personal taste is
| to use IO::File, but that's just me.

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 the
discussion with open() that happened awhile back).

-spp
0
spp
8/24/2000 8:41:22 PM
>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 the
>discussion with open() that happened awhile back).

Unless that's done completely transparently, you'll pretty much screw the
pooch as far as "Perl is the Cliff Notes of Unix" notion.  Not to 
mention running a very strong risk of butchering the performance.

I don't understand this desire to eviscerate Perl's guts.  Having
everything you want just *there* is part of what's made Perl fast,
fun, and successful.  Good luck on preserving all three.

--tom
0
tchrist
8/24/2000 9:34:37 PM
--8jNwmpfkpox/fiJK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


> >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 the
> >global name-space pool. 

Tom Christiansen wrote:
> A very long time ago, when Perl first came out, people would try to make
> Perl "just like C".  That today the impetus is toward Java is still really
> the same story.  Fortunately, Larry didn't do it then, and I don't see it
> happening now.

I would like to chime in quickly on this thread to note that having lots of
stuff in the global namespace/core is not a problem from the "JVM port
camp".  I went down this road when I started working on the JVM port saying
to myself: "Darn it, if the Perl core was just smaller, this would be so
much easier."

I decided then that the JVM port must be done in subsets.  (One reason being
that if you want to target a tiny embedded JVM in a wrist-watch, you can't
ever really have all of Perl anyway).

I see the Perl->JVM compiler having a list of well-documented options that
say: "Ok, if you want this set of core features turned off, then use this
option".

To make this possible, the internals simply need a way via an API for a
back-end porter to tell the front-end that certain keywords are forbidden.
That way, the user can get messages like:

  "Sorry, you told me on the command line you wouldn't use core socket
   support, but you appear to have done so in the program.  Thus, your
   compile failed."

And, the more we of these we can catch at compile time, the better.
Shouldn't be too hard, I don't think.


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 dragons", but they don't seem like dragons that are
unslayable.)

-- 
Bradley M. Kuhn  -  http://www.ebb.org/bkuhn

--8jNwmpfkpox/fiJK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5paFK53XjJNtBs4cRAjXjAKCKSjNnG7Rf6ENySbaEdnt1gGT8GACgrNV2
cDFSh7SqQ6tPtaMDX/b1qD8=
=Cq/2
-----END PGP SIGNATURE-----

--8jNwmpfkpox/fiJK--
0
bkuhn
8/24/2000 10:27:22 PM
>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 dragons", but they don't seem like dragons that are
>unslayable.)

One might consider making CORE:: a real-er namespace.  In Python, for
example, with its semi-numbskulled non-nesting scoping levels,
you still have three resolutions: builtins (read: CORE), package, and
local.  These are all fully-fledged namespaces, and you could store
something in the builtins if you wanted.  Somewhat like CORE::GLOBAL.
Right now, of course, you can't usefully do much with \&CORE::dbmopen,
for example.  But if you could, perhaps more would be feasible.

However, I feel that I may run the risk of violating the following:

    "We do not define Perl as an improved version of some other
    language.  Nor do we define Perl as the next universal language.
    We're not trying to make Perl a better language than C++, or
    Pyuthon, or Java, or JavaScript.  We're trying to make Perl a
    better language than Perl.  That's all."
		--Larry Wall in his 1999 State of the Onion Address

But if I am doing so, then it is not without ample precedent in this 
and related threads. :-(

--tom
0
tchrist
8/24/2000 10:35:21 PM
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 such.  It might be nice to generalize some functions (like the
> >discussion with open() that happened awhile back).
>
>Unless that's done completely transparently, you'll pretty much screw the
>pooch as far as "Perl is the Cliff Notes of Unix" notion.  Not to
>mention running a very strong risk of butchering the performance.

One of the current plans is for the parser to have access to a list of 
functions that trigger autoloading modules. If, for example, it sees 
shmget(), that'll trigger the loading of the SysV::SharedMem module. (Or 
whatever module it lives in) There'll be a magic registry somewhere that 
can get added to when  a module is installed--think of it as @EXPORT on 
steroids. (You don't even have to use the module to get it loaded, as the 
mere mention of a name summons it. We'll probably have to come up with some 
name that has the acronym "hastur" or something...)

One of the other plans is to provide a way for people to write op-level 
functions that run at near-op speed. (The difference being an extra pointer 
deref, most likely) We want calling XS functions to be snappy too, of 
course, but this is a level deeper. Less safe and more prone to breakage 
from version to version of perl, but that's the risk you take when working 
under the hood.

>I don't understand this desire to eviscerate Perl's guts.

I do. I just don't understand the desire on the part of other people. ;-)


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/25/2000 4:05:23 AM
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 module.  The alternative is that they
memorize a long list of functions, some of which are slow and some
of which aren't.

Nat
0
gnat
8/25/2000 4:08:53 AM
Lightning flashed, thunder crashed and Tom Christiansen <tchrist@chthon.perl.co
m> whispered:
| Unless that's done completely transparently, you'll pretty much screw the
| pooch as far as "Perl is the Cliff Notes of Unix" notion.  Not to 
| mention running a very strong risk of butchering the performance.

I don't think there is any ruling from Larry that perl must remain the
"Cliff Notes of Unix."  In fact, there seems to be a bit of a concerted
effort (partly suggested by Larry, IIRC) to make perl *less* Unix-centric
and more friendly for other environments.

I'm not concerned with performance, per se.  I have confidence in the
people who will actually write the code to take care of that issue.
Performance will be a factor in deciding whether this can be implemented or
not.  If performance will suffer unacceptably, then this won't get
implemented.

| I don't understand this desire to eviscerate Perl's guts.  Having
| everything you want just *there* is part of what's made Perl fast,
| fun, and successful.  Good luck on preserving all three.

This desire stems from having a wonderful mechanism for making the core
more lightweight (hopefully improving performance) called loadable
modules.  Larry designed this feature for a reason, and has been saying
since the early perl5 alphas that we could/should migrate some things out
of the core.  I'm simply suggesting all the parts that I think reasonably
go together than could be migrated.  They can still be "there", just in a
module.  If the AUTOLOAD stuff that is being discussed works out, you won't
even know the internals have changed.

I don't understand this desire to not want anything to change.  This is an
opportunity to clean up the language, make it more useable, and more fun.
I would have a lot more fun if perl were a better performer and if it was
easy for me to expand it, contract it, reshape it, improve it, etc.

-spp
0
spp
8/25/2000 1:08:07 PM
At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote:
>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?

Not particularly, at least not as far as I know. There's some extra cost in 
finding the library and loading it that you wouldn't pay if you were linked 
directly to it, but AFAIK that's about it.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/25/2000 1:12:19 PM
>I don't understand this desire to not want anything to change.  

You misread.

>This is an
>opportunity to clean up the language, make it more useable, and more fun.
>I would have a lot more fun if perl were a better performer and if it was
>easy for me to expand it, contract it, reshape it, improve it, etc.

Bah.  You start from false premises, and go on to fantasize 
bucolically about motherhood and apple pie.

You will *not* improve the performance of the inner interpreter
loop by having fewer opcodes to switch on.  Whether the number is
20 or 200, it's the same thing--*think* aboutit.  Furthermore,  It's
been demonstrated that this supposed "gain", including in size, is
negligible.  I have yet to see one iota of justification for denuding
perl of its math functions.  If math functions should be removed,
then so too string functions.  And that binmode silliness is in
line before any of them, since it's absolutely useless because I
never use it.

See what I mean?  

Perl is *not* fun when it supplies nothing by default, the way C does(n't).

If you want a language that can do nothing by itself, fine, but don't
call it Perl.  Given these:

    * Scalar manipulation
    * Regular expressions and pattern matching
    * Numeric functions
    * Array processing
    * List processing
    * Hash processing
    * Input and output
    * Fixed-length data and records
    * Filehandles, files, and directories
    * Flow of program control
    * Scoping
    * Miscellaneous
    * Processes and process groups
    * Library modules
    * Classes and objects
    * Low-level socket access
    * System V interprocess communication
    * Fetching user and group information
    * Fetching network information
    * Time

Your brain-damaged Perl would likely end up having nothing in it but these:

    * Flow of program control
    * Scoping

Anything else would be fobbed off into back-of-the-bus modules.

But I tell you this: your whole language will get fobbed off as
a pain in the royal ass.

Since day 1, perl has been useful because it's had so much in it.
You don't want a language with a whole bunch of the commonly needed
functions *already* in it, fine -- but it's not going to be perl,
and it's not going to be useful.

--tom
0
tchrist
8/25/2000 1:18:41 PM
> >I don't understand this desire to not want anything to change.
>
> You misread.

I sympathise.  There are definate goals and focuses that each language is
built around.. Change these too much, and you have a different language,
while at the same time, alienating the people that chose that language
because of those met goals.

Perl is fun, functional, and efficient.  I can artistically scuplt a program
in one line at the command prompt and do things that wield incredible power,
and feel an incredible sence of happiness.  While at the same time, I can
write a massive program, and not have to worry about many of the mundane
details that we learn in algorithms / data-structures.

> >This is an
> >opportunity to clean up the language, make it more useable, and more fun.
> >I would have a lot more fun if perl were a better performer and if it was
> >easy for me to expand it, contract it, reshape it, improve it, etc.

> You will *not* improve the performance of the inner interpreter
> loop by having fewer opcodes to switch on.  Whether the number is
> 20 or 200, it's the same thing--*think* aboutit.

Well, not strictly true.  Though the raw code will not switch any faster,
the bloat of the core will hurt you with non-locality, through cache misses,
or worse memory-paging.  A highly tuned 50K core interpreter will do much
better than a 500K list of regularly used libraries.  Essentially, it should
be possible to perform profiling on suites of programs to find out what is
really most needed, and only allow them in the core.  The rest could be
delegated to slower dynamic linking or outer-edge statically linked code.
It's the general idea of RISC, of course.  I have no real backing to say
that this would actually improve performance, nor that it would even be
possible to stream-line the core of perl any further.. Hell, C++ is only
going to make the situation worse (performance lost to fun of development,
which is acceptible).  Typically, when the core does nothing more than
handle basic flow, and memory management, you can have a rock-solid kernel.
If you can build out apon this (all op codes seem identical, beit built-in
through statically compiled extensions, or linked in), then you will have a
much more solid development base.  This is the advantage of C, python, java,
etc.  Their extensions feel just like built-ins.  Granted, perl has come a
long way with giving keyword power to user-defines.

> Furthermore,  It's
> been demonstrated that this supposed "gain", including in size, is
> negligible.  I have yet to see one iota of justification for denuding
> perl of its math functions.

I would agree that math function should not be compromised.  If dynamically
linking them seriously decreases performance, then we're going to see a
massive slow-down in operation, since some crazed programmers actually like
performing fast fourier transforms.  Getting a 20-30% slow-down is not going
to be well accepted (I'm guessing at the over-head of dynamic linking;  I
just hear how bad it is).  As above, however, I don't see a problem with
keeping them statically linked, so long as they're not part of the core.

> If math functions should be removed,
> then so too string functions.  And that binmode silliness is in
> line before any of them, since it's absolutely useless because I
> never use it.

As in all things in life.. Moderation.. Profiling should decide what
compromises clean-ness of code for the benifit of optimization.  Many string
operations are close to memory management, such as array modification,
string concatenation, simple assignment, references.. I would advocate that
they be part of the memory management system, and thus part of the core.

> Perl is *not* fun when it supplies nothing by default, the way C
does(n't).

I hear ya.  Dynamic memory management (garbage collection, dynamic arrays,
etc), powerful string operations, powerful datatypes, etc.  These are what
attract me to perl the most.. Not so much readily available socket
functions.  Sure having java.util.* built into java would make it easier to
use out of the box, but it's more to learn about the internals, especially
since they may change over time.  I can more easily walk the lib-tree and
read pod-files about each library to learn what I can do.

>
> If you want a language that can do nothing by itself, fine, but don't
> call it Perl.  Given these:
>
>     * Scalar manipulation
>     * Regular expressions and pattern matching

At the very least, built-in reg-ex's allows the compiler to make incredible
optimizations which it simply wouldn't be able to do if it were a function
call:

$str =~ s/${var} xxx \s xxx/ abs( $1 ) /xegso;

would have to be:

$reg_ex = gen_regex_replace( expr => "${var} xxx \s xxx", subs =>
"abs( $1 )", modifiers => "xegso"  );
apply_reg_ex( regex => $reg_ex, str => $str );

It would be non-trivial to get a compiler to efficiently handle this.. Thus,
I don't support any removal of expressions.  I definately don't support
making one function for each possible modifier.

>     * Numeric functions
>     * Array processing
>     * List processing
>     * Hash processing

These things are what make perl so great.  They are also very common, so
profiling would most likely require them to be part of the core.

>     * Input and output

Since quick-and-dirty scripts make such heavy use of this, the worst I'd
advocate is auto-loading them.  They simply need to be globally accessible.

>     * Fixed-length data and records
>     * Filehandles, files, and directories
>     * Flow of program control
>     * Scoping
>     * Miscellaneous
>     * Processes and process groups

As was pointed out earlier. this can be a pain for migration.  True, perl
has always been the UNIX tool box; a sh on steroids.  I don't really know
how I feel about this.  The reduction of cryptic globals can only be a good
thing, IMHO, yet, unless we delegated access to this information more like
java / python (where you have a system or os module that handles the
specific details), I can't imagine how it could happen..  My guess is that
things will stay the way they are, and NT will continue to look more and
more like UNIX under perl.  There's just too much nostalgia (and general
geek pride).  I personally believe a seperate module would be the better
solution, pride aside.

>     * Library modules
>     * Classes and objects
>     * Low-level socket access
>     * System V interprocess communication

See, again, I can't really see the advantage of IPC at the low level.  I
can't imagine writing much useful code at the command-prompt that does IPC.
Anything that you might want to do, you could achieve with ipcs, or other
UNIX tools.  And command-line tooling is the main reason I advocate keeping
things global.  Does socket() run noticably slower if it's dynamically
linked?  Are you really going to run it in a tight loop?  Doubtfully, so I
would advocate autoloading here.

>     * Fetching user and group information
>     * Fetching network information

Again, following along the lines of system-specific IPC.  Profiling should
tell the tale.

>     * Time

Laugh, I'm biased.. I like this one.  It has always frustrated me in C when
I couldn't quickly get the time.  It's really IPC though (asking the system
for time).  It should also be trivial (minus the OS call).

> Your brain-damaged Perl would likely end up having nothing in it but
these:
>
>     * Flow of program control
>     * Scoping
>
> Anything else would be fobbed off into back-of-the-bus modules.
>
> But I tell you this: your whole language will get fobbed off as
> a pain in the royal ass.

So long as auto-loading (for legacy functions) makes it transparent, the
usefulness will not decrease one bit.  The only things that are affected are
the performance (which depends on how old-op-code auto-loading is achieved),
and what happens when you ship the perl executable without any libraries
(which I've had to do on occasion).

>
> Since day 1, perl has been useful because it's had so much in it.

Read, perl has soo much power through desirable and accessible features...
So long as those features are "easily" accessible, perl will not have
changed.

> You don't want a language with a whole bunch of the commonly needed
> functions *already* in it, fine -- but it's not going to be perl,
> and it's not going to be useful.

Once again, and in summary, perl is about making hard problems easy, and
impossible ones possible.  Having functionality immediately available is
desirable in so much as it removes the need to perform wasteful setup.  The
ultimate example of perl's power is command-line scripting.  If a task is
going to involve too much to fit on one line, either perl should be adapted
to handle the problem more efficiently, or a more verbose solution is going
to be necessary (which will involve some degree of setup).  At some point in
every problem, however, the solution is going to require scaling.  The
language needs to be able to scale with the problem.  This often means,
facilitating good programming practices, so a project can scale to multiple
developers.  At the one end, perl has little or no setup (I can complete an
entire perl program before the java interpreter even comes up, never mind
the savings of coding time).  At the other end, I can perform OO or modular
programming which allows easy integration of multiple developers (with
defined and protected interfaces ).  Anything that enhances perl on either
the simplification / lack-of-setup side, or on the large scale side is a
Good Thing(tm).

-Michael


0
maraism
8/25/2000 3:55:34 PM
At 11:55 AM 8/25/00 -0400, Michael Maraist wrote:
> > You will *not* improve the performance of the inner interpreter
> > loop by having fewer opcodes to switch on.  Whether the number is
> > 20 or 200, it's the same thing--*think* aboutit.
>
>Well, not strictly true.  Though the raw code will not switch any faster,
>the bloat of the core will hurt you with non-locality, through cache misses,
>or worse memory-paging.

That, as they say, turns out not to be the case, at least not in the 
general case. Code you don't call won't eat up any cache space, nor crowd 
out some other code. And if you do call it, well, it ought to be in the cache.

Now there are issues--if we have an indirect function table, it makes sense 
for the pointers for functions called in succession be close to one another 
to get a win from cache prefetching, but reasonable ordering of functions 
in the array (if we even have one) takes care of that.

>So long as auto-loading (for legacy functions) makes it transparent, the
>usefulness will not decrease one bit.  The only things that are affected are
>the performance (which depends on how old-op-code auto-loading is achieved),
>and what happens when you ship the perl executable without any libraries
>(which I've had to do on occasion).

Performance is king and queen here. Anything that slows performance down 
without a big functional win will go.


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/25/2000 4:19:24 PM
Tom Christiansen wrote:
> 
> >I don't understand this desire to not want anything to change.
> 
> You misread.
> 
> >This is an
> >opportunity to clean up the language, make it more useable, and more fun.
> >I would have a lot more fun if perl were a better performer and if it was
> >easy for me to expand it, contract it, reshape it, improve it, etc.
> 
> Bah.  You start from false premises, and go on to fantasize
> bucolically about motherhood and apple pie.
> 
> You will *not* improve the performance of the inner interpreter
> loop by having fewer opcodes to switch on.  Whether the number is
> 20 or 200, it's the same thing--*think* aboutit.  Furthermore,  It's
> been demonstrated that this supposed "gain", including in size, is
> negligible.  I have yet to see one iota of justification for denuding
> perl of its math functions.  If math functions should be removed,
> then so too string functions.  And that binmode silliness is in
> line before any of them, since it's absolutely useless because I
> never use it.
> 
> See what I mean?
> 
> Perl is *not* fun when it supplies nothing by default, the way C does(n't).
> 
> If you want a language that can do nothing by itself, fine, but don't
> call it Perl.  Given these:
> 
>     * Scalar manipulation
>     * Regular expressions and pattern matching
>     * Numeric functions
>     * Array processing
>     * List processing
>     * Hash processing
>     * Input and output
>     * Fixed-length data and records
>     * Filehandles, files, and directories
>     * Flow of program control
>     * Scoping
>     * Miscellaneous
>     * Processes and process groups
>     * Library modules
>     * Classes and objects
>     * Low-level socket access
>     * System V interprocess communication
>     * Fetching user and group information
>     * Fetching network information
>     * Time
> 
> Your brain-damaged Perl would likely end up having nothing in it but these:
> 
>     * Flow of program control
>     * Scoping
> 
> Anything else would be fobbed off into back-of-the-bus modules.
> 
> But I tell you this: your whole language will get fobbed off as
> a pain in the royal ass.
> 
> Since day 1, perl has been useful because it's had so much in it.
> You don't want a language with a whole bunch of the commonly needed
> functions *already* in it, fine -- but it's not going to be perl,
> and it's not going to be useful.
> 
> --tom


I would like to see a set of "requirements" that make Perl what it is. 
I think we all have a vague idea of what makes Perl great, but I'm also
sure there's a lot of variation.  With a SHORT list of requirements, it
becomes much easier to address some of these issues that are radical
changes to the language.

Here are some possibilities for inclusion in such a list:

native pattern matching;
list manipulation
aweswome text processing.
It's application glue  (thanks Tim)

Is this an reasonable idea? and a reasonable start?
-- 
David Corbin 		
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@machturtle.com
0
dcorbin
8/25/2000 4:46:09 PM
On Thu, 24 Aug 2000, Stephen P. Potter 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 such.  It might be nice to generalize some functions (like the
> discussion with open() that happened awhile back).

Hard things should be easy, easy things should be trivial. We should try
to keep the stuff that is commonly used in the core (excluding OS
dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(),
for instance). In my opinion, Perl6 should still be a language in which
it is easy to write powerful and useful programs on the command line.

 --- Joe M.

0
mcmahon
8/25/2000 5:34:19 PM
>Hard things should be easy, easy things should be trivial. We should try
>to keep the stuff that is commonly used in the core (excluding OS
>dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(),
>for instance). 

That's their problem.  Perl is extremely useful to Unix systems
programmers and administrators.  They are the target audience
that Perl was initially written for, whom it was made famous by,
and you will find that it continues to be very important to us.
If you relegate us to take a back seat behind a mob of Billduhs,
then you have betrayed your history and really pissed a lot of
people off.  

--tom
0
tchrist
8/25/2000 5:48:08 PM
Joe McMahon writes:
: On Thu, 24 Aug 2000, Stephen P. Potter 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 such.  It might be nice to generalize some functions (like the
: > discussion with open() that happened awhile back).
: 
: Hard things should be easy, easy things should be trivial. We should try
: to keep the stuff that is commonly used in the core (excluding OS
: dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(),
: for instance). In my opinion, Perl6 should still be a language in which
: it is easy to write powerful and useful programs on the command line.

We're fighting multiple definitions of "core" here.  Please distinguish
the core of the language from the core of the implementation--they're
two entirely different things.  What we're attempting to do here is
make it *not matter* whether something is in the core implementation or
not.  This gives us a great deal of freedom in how to implement the
core of the language.

For instance, if I'm running Perl on my Palm, I'd just as soon that
index() were implemented in Perl using repeated substr() comparisons.
Yes, that's slower than the C implementation, but the representation is
much more compact, and might have a hope of getting shoehorned into a
small memory.  A Perl distribution might implement index() much as it
does now in portable (more-or-less) C.  A distribution intended for a
high-powered server of known architecture might substitute in a
hand-coded assembler version of index().  A JVM implementation might
call out to some core JVM routine.  An .NET implementation might
delegate indexing to some object running on index.microsoft.com.  :-)

This should all be transparent at the language level.  Certainly
index() will continue to be supported in the core language.  But it
almost certainly belongs outside the core implementation.

Larry
0
larry
8/25/2000 5:50:01 PM
>I would like to see a set of "requirements" that make Perl what it is. 
>I think we all have a vague idea of what makes Perl great, but I'm also
>sure there's a lot of variation.  With a SHORT list of requirements, it
>becomes much easier to address some of these issues that are radical
>changes to the language.

That's a very good idea.  

Many if not most of these radical "let's make a new language"
postings mostly just keep making Python and Java look better and
better.  If you strip out the Perlishness from Perl, there's really
no reason to bother with the language anymore.

--tom
0
tchrist
8/25/2000 5:53:18 PM
Tom Christiansen writes:
: >Hard things should be easy, easy things should be trivial. We should try
: >to keep the stuff that is commonly used in the core (excluding OS
: >dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(),
: >for instance). 
: 
: That's their problem.  Perl is extremely useful to Unix systems
: programmers and administrators.  They are the target audience
: that Perl was initially written for, whom it was made famous by,
: and you will find that it continues to be very important to us.
: If you relegate us to take a back seat behind a mob of Billduhs,
: then you have betrayed your history and really pissed a lot of
: people off.  

Please don't monger these fears.

I am a Unix systems administrator.  I don't see much of a problem
leaving getpwent in the core language but out of the core implementation.
The issue of preserving the semantics of one-liners is a known
design constraint.

We are now beating a dead unicorn.  Please move it to the -language list.

Larry
0
larry
8/25/2000 6:06:32 PM
i cc'ed to language as this issue spans then as well as internals.

>>>>> "LW" == Larry Wall <larry@wall.org> writes:

  LW> We're fighting multiple definitions of "core" here.  Please distinguish
  LW> the core of the language from the core of the implementation--they're
  LW> two entirely different things.  What we're attempting to do here is
  LW> make it *not matter* whether something is in the core implementation or
  LW> not.  This gives us a great deal of freedom in how to implement the
  LW> core of the language.

the language vs. implementation core confusion has hit before. could we
come up with better terms which are not so overloaded? i suggest we drop
the use of core altogether for now and pick new terms. here are some ideas:

the Perl language base features

the perl binary/image/executable/main

i would use object but that is WAY too overloaded. i am sure we can pick
a pari of terms which are short and reflect our usage. we have too much
linguistic power on these lists to fight over core vs. core.

  LW> This should all be transparent at the language level.  Certainly
  LW> index() will continue to be supported in the core language.  But it
  LW> almost certainly belongs outside the core implementation.

i like that. but is that only platform implementation specific? i see a
possibility of requesting (via a pragma) an alternative implementation of
binary (see i used the new term!). something like this:

use library qw(Quantum::sort) ;

which would load the sort implementation with damian's constant time
sort and overload the sort function as well.

my advanced I/O rfc (to be released soon) uses something like that to
appease the language minimalists (sockets out of base language) and the
binary minimalists (sockets loaded as desired).

uri

-- 
Uri Guttman  ---------  uri@sysarch.com  ----------  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  -----------  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  ----------  http://www.northernlight.com
0
uri
8/25/2000 6:06:53 PM
At 02:06 PM 8/25/00 -0400, Uri Guttman wrote:
>i like that. but is that only platform implementation specific? i see a
>possibility of requesting (via a pragma) an alternative implementation of
>binary (see i used the new term!).

I'd like to get overridable opcode functions and function functions into 
perl 6. Whether (or how) that happens depends mainly on the speed penalty 
the overriding costs.


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/25/2000 6:19:40 PM
<Moved to perl6-language from perl6-internals> where it was "Remove
sockets from core"...

Tom Christiansen wrote:
> 
> >I would like to see a set of "requirements" that make Perl what it is.
> >I think we all have a vague idea of what makes Perl great, but I'm also
> >sure there's a lot of variation.  With a SHORT list of requirements, it
> >becomes much easier to address some of these issues that are radical
> >changes to the language.
> 
> That's a very good idea.

Thank you.

> 
> Many if not most of these radical "let's make a new language"
> postings mostly just keep making Python and Java look better and
> better.  If you strip out the Perlishness from Perl, there's really
> no reason to bother with the language anymore.
> 
> --tom

You're much closer to the language and the history than I could ever
hope to
be, so what do YOU think makes Perl Perl?

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 and hard things possible.  (paraphrased, I
suspect)
-- 
David Corbin 		
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@machturtle.com
0
dcorbin
8/25/2000 6:22:25 PM
>>>>> "TC" == Tom Christiansen <tchrist@chthon.perl.com> writes:

TC> Perl is *not* fun when it supplies nothing by default, the way C does(n't).

TC> If you want a language that can do nothing by itself, fine, but don't
TC> call it Perl.  Given these:


I'm not sure that we are talking about the same thing.

My understanding of -internals (and Dan) is that all the current perl
(or whatever Larry leaves) will continue to be there. It is an internals
issue where it really lives. 

So if socket() is removed from the core (the executable). Perl upon
noticing a socket() without a user specified use that might override
it. Will transparently make it available along with all the associated
constants.

If a performance hit arises, then -internals will address the issue. But
nothing in the language will change.

I made the suggestino a while back, that if this is true for core. It
might be feasible for non-core modules (assuming some sort of registry)
so that an implicit use might be performed. 

(I'm ignoring the problems of multiple versions or multiple conflicting
 routines of the same name.)

Are we still far apart?

<chaim>
-- 
Chaim Frenkel					     Nonlinear Knowledge, Inc.
chaimf@pobox.com				               +1-718-236-0183
0
chaimf
8/25/2000 6:48:17 PM
>I'm not sure that we are talking about the same thing.

Probably not.

>So if socket() is removed from the core (the executable). Perl upon
>noticing a socket() without a user specified use that might override
>it. Will transparently make it available along with all the associated
>constants.

I've read these all as "remove from CORE::", which is seriously
scarier.  This is rather different.  I don't see why anyone would
care, module performance, whether for example using dbmopen autoloads
Any_DBMFile or whatnot.

Just try reading through the last N-thousand  of these messages.
Things blend together, and the overall impression is one of, well...
you'll have to draw your own conclusions.

--tom
0
tchrist
8/25/2000 7:05:46 PM
At 02:48 PM 8/25/00 -0400, Chaim Frenkel wrote:
>My understanding of -internals (and Dan) is that all the current perl
>(or whatever Larry leaves) will continue to be there. It is an internals
>issue where it really lives.
>
>So if socket() is removed from the core (the executable). Perl upon
>noticing a socket() without a user specified use that might override
>it. Will transparently make it available along with all the associated
>constants.

This is the case, yep.

>I made the suggestino a while back, that if this is true for core. It
>might be feasible for non-core modules (assuming some sort of registry)
>so that an implicit use might be performed.

Yup, that's what I'm thinking of as well. It might as well be available to 
everyone if it's available to the core.  (And yes, I'm ignoring versioning 
issues here too... :)

I think it's time for me to go missing for a while and finish the RFC that 
details what I'm thinking about for this...

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/25/2000 7:06:08 PM
>>>>> "CF" == Chaim Frenkel <chaimf@pobox.com> writes:

  CF> I made the suggestino a while back, that if this is true for core. It
  CF> might be feasible for non-core modules (assuming some sort of registry)
  CF> so that an implicit use might be performed. 

i am proposing such a registry which is a pragma you use to load in
groups of namespaces just like with @IMPORT_OK and :standard groupings.
this serves 2 purposes, it tells the compiler which names are to be
placed in the function symbol table. the name groups could be 'sockets',
'math', etc.  and it may optionally load them from a library (which
could be in multiple forms).

so with one simple pragma we can simplify the namespace and still get
full backwards compatibility support. and we can control how real code
is loaded on an as needed basis. a given perl binary could be created
with various parts designated as always in and others are dynamically
loaded. this can be done at build time or even at run time with some
special startup file which could be triggered by a command line option.

uri

-- 
Uri Guttman  ---------  uri@sysarch.com  ----------  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  -----------  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  ----------  http://www.northernlight.com
0
uri
8/25/2000 7:24:52 PM
On Fri, 25 Aug 2000 12:19:24 -0400, Dan Sugalski wrote:

>Code you don't call won't eat up any cache space, nor crowd 
>out some other code. And if you do call it, well, it ought to be in the cache.

Probably a stupid question... But can't you group the code for the most
often used constructs? So that, if one of those things is loaded in the
cache, the others are in there with it?

If all the less needed stuff is more at the back of the executable, it
wouldn't even have to be loaded, most of the time.

Besides, I'm more worried about unnecessarily loading 600k from disk,
than from main memory to cache. For short-lived scripts, this loading
overhead could be quite significant.

-- 
	Bart.
0
bart
8/25/2000 7:28:47 PM
Dan Sugalski <dan@sidhe.org> writes:
>At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote:
>>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?
>
>Not particularly, at least not as far as I know. There's some extra cost in 
>finding the library and loading it that you wouldn't pay 

Unless you really messup the search it will be comparable to the search 
system does (LD_RUN_PATH etc.) to find "linked in" dynamic libraries.

The issue would be if you did two searches - one for Socket.so and then 
_that_ had to go look for libsocket.so 
So if the code is really just a thin wrapper on the system library then 
taking it out will be a (small) performance hit.

But it does mean we can plug in IPv7 in a twinkling, or a stub that re-directs
network traffic via the Furbie's infra-red link to the toaster...

-- 
Nick Ing-Simmons

0
nick
8/25/2000 7:45:25 PM
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 entirely painless.  So if my program has getprotobyname in it
clarifying that token will take a moment, but then all the other
weird socket calls will be there to use.


How about automatic library search before syntax error?


-- 
                          David Nicol 816.235.1187 nicold@umkc.edu
                       safety first: Republicans for Nader in 2000
0
david
8/25/2000 7:46:49 PM
>Besides, I'm more worried about unnecessarily loading 600k from disk,
>than from main memory to cache. For short-lived scripts, this loading
>overhead could be quite significant.

Why should that matter?  Your kernel's VM system should compensate.
It's not like running a 3-line program really reloads all those
text pages.  I think we're all past the chmod +t days.

    % repeat 20 time perl -e 0
    0.000u 0.018s 0:00.01 100.0%    0+0k 0+0io 0pf+0w
    0.006u 0.012s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
    0.006u 0.013s 0:00.01 100.0%    0+0k 0+0io 0pf+0w
    0.020u 0.000s 0:00.02 100.0%    0+0k 0+0io 0pf+0w
    0.000u 0.020s 0:00.01 200.0%    0+0k 0+0io 0pf+0w
    0.006u 0.013s 0:00.02 50.0%     0+0k 0+0io 0pf+0w
    0.006u 0.013s 0:00.01 100.0%    0+0k 0+0io 0pf+0w
    0.009u 0.009s 0:00.01 0.0%      0+0k 0+0io 0pf+0w
    0.010u 0.010s 0:00.02 100.0%    0+0k 0+0io 0pf+0w
    0.000u 0.020s 0:00.02 100.0%    0+0k 0+0io 0pf+0w
    0.006u 0.013s 0:00.01 100.0%    0+0k 0+0io 0pf+0w
    0.010u 0.010s 0:00.02 100.0%    0+0k 0+0io 0pf+0w
    0.000u 0.019s 0:00.02 50.0%     0+0k 0+0io 0pf+0w
    0.010u 0.010s 0:00.02 100.0%    0+0k 0+0io 0pf+0w
    0.010u 0.010s 0:00.02 100.0%    0+0k 0+0io 0pf+0w
    0.013u 0.006s 0:00.02 50.0%     0+0k 0+0io 0pf+0w
    0.006u 0.013s 0:00.01 100.0%    0+0k 0+0io 0pf+0w
    0.000u 0.020s 0:00.02 100.0%    0+0k 0+0io 0pf+0w
    0.009u 0.009s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
    0.000u 0.020s 0:00.02 100.0%    0+0k 0+0io 0pf+0w

--tom
0
tchrist
8/25/2000 8:16:13 PM
Bart Lateur <bart.lateur@skynet.be> writes:
>On Fri, 25 Aug 2000 12:19:24 -0400, Dan Sugalski wrote:
>
>>Code you don't call won't eat up any cache space, nor crowd 
>>out some other code. And if you do call it, well, it ought to be in the cache.
>
>Probably a stupid question... But can't you group the code for the most
>often used constructs? 

We can - and we will once we know what the "often used constructs" will be
in perl6.

Larry started will with pphot.c in perl5 - but over the years
the bells and whistles have got tacked on where it seemed easiest and 
now perl5 needs a re-write to clean it up - perl6 will be that thing
but while perl5 runs a language called Perl5, perl6 (being defined here)
will run a language called Perl6 - being defined on perl6-language@perl.org.

>So that, if one of those things is loaded in the
>cache, the others are in there with it?

That is the first approximation to what happens - but it is a start...

>
>If all the less needed stuff is more at the back of the executable, it
>wouldn't even have to be loaded, most of the time.
>
>Besides, I'm more worried about unnecessarily loading 600k from disk,
>than from main memory to cache. For short-lived scripts, this loading
>overhead could be quite significant.

Most mordern (and sane) OSes will keep "useful" pages in memory till 
they need them for something else. This would be _the_ win for 
true byte-compiled (not modified at runtime) scripts/modules - those
pages would not be re-loaded either.

-- 
Nick Ing-Simmons

0
nick
8/25/2000 8:53:12 PM
At 09:28 PM 8/25/00 +0200, Bart Lateur wrote:
>On Fri, 25 Aug 2000 12:19:24 -0400, Dan Sugalski wrote:
>
> >Code you don't call won't eat up any cache space, nor crowd
> >out some other code. And if you do call it, well, it ought to be in the 
> cache.
>
>Probably a stupid question... But can't you group the code for the most
>often used constructs? So that, if one of those things is loaded in the
>cache, the others are in there with it?

Sure, and as Nick's already said, perl 5 did that. How much of a win 
grouping is depends on the chunks fetched into cache. Data usually goes 
into the processor cache in small pieces--8 or 16 bytes at a time. The 
off-chip cache usually is loaded in larger pieces, but the size of those 
depends on the processor you're talking about.

Given the size of many of perl 5's opcode functions, I'm not sure 
grouping's really a win for code. That may change some for perl 6, though.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/25/2000 9:27:31 PM
At 07:45 PM 8/25/00 +0000, Nick Ing-Simmons wrote:
>The issue would be if you did two searches - one for Socket.so and then
>_that_ had to go look for libsocket.so
>So if the code is really just a thin wrapper on the system library then
>taking it out will be a (small) performance hit.

This is actually one of the spots I'm hoping to pick up a win from--if the 
only code that links against the system socket library is in the code 
that's not loaded by default, then that means one fewer system library to load.

Granted, odds are the library's in memory already, but we don't have to map 
it, and we don't need to do symbol resolution, and we generally just don't 
need to mess with it.

Big win? No. Small one. But for code that just rips through a disk file or 
something piped in on stdin, it might mean a few milliseconds shaved off 
startup.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/25/2000 9:30:39 PM
On Fri, Aug 25, 2000 at 09:12:19AM -0400, Dan Sugalski wrote:
> At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote:
> >Isn't dynamic loading really slow?
> 
> Not particularly, at least not as far as I know. There's some extra cost in 
> finding the library and loading it that you wouldn't pay if you were linked 
> directly to it, but AFAIK that's about it.

Dynamic loading can be noticeably slow if you are loading something
via NFS. In addition the PIC code and jump tables used for dynamic
linking result in a 10-15% slowdown in execution speed on SunOS and
Solaris (at least in my experiments). Not what I'd call really slow, but 
we've complained vigorously about smaller slowdowns.
-- 
Ed Mooring
0
mooring
8/26/2000 3:33:07 AM
Beware of dependencies between shared objects.  Let's assume 2 chunks of
core functionality are seperated off into say A.so and B.so.  This will
work fine as long as there are no interdependencies between A.so and
B.so.  Let's however assume A.so needs to call something in B.so.  That
means before A.so is loaded B.so must already have been loaded for its
symbols to be available in order to be able to resolve the references to
them when A.so is opened.  Also, on Solaris at least special flags must
be specified to dlopen to make symbols in B.so visible to the
subsequently dlopen'd A.so.  The other way of doing this is to specify a
linker dependency between A.so and B.so, but that will effectively cause
B.so to be loaded as soon as A.so is loaded.  In both these scenarios,
both .so files will end up loaded anyway, so it really seems fruitless
to seperate them.

The problem with this whole suggestion is that it will be very, very
easy to bring the whole edifice crashing down - one misplaced
cross-shared-object function call will result not in compile-time or
link-time errors, but in runtime linker errors.  In some cases I'm sure
it is possible to seperate out some bits of the core so that they don't
depend on anything else, but I'm far from persuaded the overall benefit
will be worth the extra complications.

Alan Burlison
0
Alan
8/26/2000 10:24:09 PM
Dan Sugalski wrote:

> This is actually one of the spots I'm hoping to pick up a win from--if the
> only code that links against the system socket library is in the code
> that's not loaded by default, then that means one fewer system library to load.
> 
> Granted, odds are the library's in memory already, but we don't have to map
> it, and we don't need to do symbol resolution, and we generally just don't
> need to mess with it.

Most modern runtime linkers do lazy linking, so references aren't
resolved until called.  On Solaris the runtime linker patches itself in
to the PLT, so that the first time a function is called it is resolved. 
Uncalled functions aren't linked.  I think you'll be dissapointed by the
difference.

> Big win? No. Small one. But for code that just rips through a disk file or
> something piped in on stdin, it might mean a few milliseconds shaved off
> startup.

You already have this win:

# Force symbol resolution on startup
$ LD_BIND_NOW=1  ptime perl -e 'exit(0)'
real        0.029
user        0.021
sys         0.007

# Default lazy linking
$ ptime perl -e 'exit(0)'               
real        0.019
user        0.010
sys         0.007

Alan Burlison
0
Alan
8/26/2000 10:37:06 PM
mooring@acm.org wrote:

> Dynamic loading can be noticeably slow if you are loading something
> via NFS. In addition the PIC code and jump tables used for dynamic
> linking result in a 10-15% slowdown in execution speed on SunOS and
> Solaris (at least in my experiments). Not what I'd call really slow, but
> we've complained vigorously about smaller slowdowns.

This is probably all true.  However what you are not taking into account
is the overall improvements in system performance due to the fact that
the shared libraries are only held in memory once (yes I know some bits
of a .so may not be shared, but most of it is).  Paging involves disks,
and they are orders of magnitude slower than the dynamic linking
overhead.  Repeat the excercise with a couple of hundred concurrent
copies of your test.  Drawing conclusions based on a single test can be
misleading.

-- 
Alan Burlison
0
Alan
8/26/2000 11:14:17 PM
I wonder if you could arrange things so that you could have statically
linked and dynamic linked executable. Kind of like what they do with the
Linux kernel. When your installation is configured in such a way as to make
the dynamic linking a problem, just compile a version that has (almost)
everything bolted in. Otherwise compile the features as modules.

0
arl
8/27/2000 12:57:48 AM
Al Lipscomb <arl@q7.net> writes:
>I wonder if you could arrange things so that you could have statically
>linked and dynamic linked executable. Kind of like what they do with the
>Linux kernel. When your installation is configured in such a way as to make
>the dynamic linking a problem, just compile a version that has (almost)
>everything bolted in. Otherwise compile the features as modules.

If we make it possible to move socket or math functions out of execuable
into "overlays" then there will always be an option NOT to do that
and build one executable - (and that will probably be the default!).

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
Overlay  - Tightly coupled ancillary loadable which is no use without
           its "base"  - e.g. Tk/Canvas.so which can only be used 
           when a particular Tk.so has already be loaded.  

Tk has these "overlays" - I think DBI has something similar. perl5 itself
does not as such (although POSIX.so is close).

_I_ would like to see RFC 146 mutate into or be replaced by an RFC 
which said perl should have a mechanism to allow parts of functionality
to be split out into separate binary (sharable) files.


-- 
Nick Ing-Simmons

0
nick
8/27/2000 8:51:46 PM
Michael G Schwern <schwern@pobox.com> writes:
>Like all other optimizing attempts, the first step is analysis.
>People have to sit down and systematically go through and find out
>what parts of perl (and Perl) are eating up space and speed.  The
>results will be very surprising, I'm sure, but it will give us a
>concrete idea of what we can do to really help out perl's performance.
>
>There should probably be an RFC to this effect, and I'm just visiting
>here in perl6-language so I dump it on somebody else.

Alan Burlison <Alan.Burlison@uk.sun.com> writes:

>Drawing conclusions based on a single test can be
>misleading.

Leaping to conculusions based on no tests at all is even worse...

Will anyone bite the bullet and write the "Internals Decisions should
be based on actual tests on multiple platforms" RFC ?

-- 
Nick Ing-Simmons

0
nick
8/27/2000 8:55:55 PM
I think the importance of splitting the core functionality into shared
objects is more general than that. There was some discussion a short time
ago about making a pared-down version for embedding, which would seem to
require some sort of functionality reduction. There is also the desire of
minimizing the footprint of the binary on heavily trafficked servers for
obvious reasons, and a shared object scenario would address this directly.

What I see as a typical installation would be similar to the means that
Apache uses, in which the administrator has the option of:
        1.) Statically linking all required objects
        2.) Loading required objects at run-time
        3.) Loading required objects as needed by the source.
Item 3 is the most difficult to implement efficiently, but is not
impossible. Item 1 is not all that different from the existing
implementation, and Item 2, could be implemented using the Apache 1.3.x
model.

I'm not sure if it's possible with the last option, but it would be nice if
the binary could have both Perl compile-time/run-time, and execution-time
loading, allowing the core to have heavily used objects loaded at run-time,
and allow less used objects to be loaded as needed.

Another option might be to allow the core to be loaded as a daemon and the
SO's to be loaded as necessary by the core. This could allow the core to
spawn child processes to handle the individual tasks at-hand, and free the
core to be a simple 'traffic cop' (Just a thought).
Grant M.
wizard@genomecorp.com


0
wizard
8/28/2000 11:40:47 AM
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=A2:
> =

> Module   - separately distributable Perl and/or C code.  (e.g. Tk800.02=
2.tar.gz)
> Loadable - OS loadable binary e.g. Tk.so or Tk.dll
> Overlay  - Tightly coupled ancillary loadable which is no use without
>            its "base"  - e.g. Tk/Canvas.so which can only be used
>            when a particular Tk.so has already be loaded.

I know I've got helium Karma around here these days but I don't like
"overlay" it is reminiscent of old IBM machines swapping parts of the
program out because there isn't enough core.  Linux modules have
dependencies on each other and sometimes you have to load the more basic
ones first or else get symbol-undefined errors.  So why not follow
that lead and call Overlays "dependent modules."

If a dependent module knows what it depends on, that module can be
loaded on demand for the dependent one.



-- =

                          David Nicol 816.235.1187 nicold@umkc.edu
                                               Yum, sidewalk eggs!
0
david
8/29/2000 11:36:08 PM
David L . Nicol <david@kasey.umkc.edu> writes:
>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
>> Overlay  - Tightly coupled ancillary loadable which is no use without
>>            its "base"  - e.g. Tk/Canvas.so which can only be used
>>            when a particular Tk.so has already be loaded.
>
>I know I've got helium Karma around here these days but I don't like
>"overlay" it 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 things makes sense are 
on little machines where memory is a premium. 

>Linux modules have
>dependencies on each other and sometimes you have to load the more basic
>ones first or else get symbol-undefined errors.  So why not follow
>that lead and call Overlays "dependent modules."

A. Name is too long.
B. That does not have same "feel" as what we have.

>
>If a dependent module knows what it depends on, that module can be
>loaded on demand for the dependent one.

But - like old-style overlays our add-ons are going to be loaded on need
by the parent and only depend on the parent.

e.g. perl discovers it needs to getpwuid() do it loads the thing
that has those functions.

We are not going to be in the middle of getpwuid() and decide we need perl...


-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

0
nik
8/30/2000 1:01:53 PM
Nick Ing-Simmons wrote:
> 
> David L . Nicol <david@kasey.umkc.edu> 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 things makes sense are
> on little machines where memory is a premium.
> 
> our add-ons are going to be loaded on need
> by the parent and only depend on the parent.


Oh, and then they will be unloaded if we need the space for something
else.  I understand now, thanks.

-- 
                          David Nicol 816.235.1187 nicold@umkc.edu
           Subroutine one-arg, him called no-arg, get $_-arg.  Ug.
0
david
8/30/2000 6:04:33 PM
At 01:04 PM 8/30/00 -0500, David L. Nicol wrote:
>Nick Ing-Simmons wrote:
> >
> > David L . Nicol <david@kasey.umkc.edu> 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 things makes sense are
> > on little machines where memory is a premium.
> >
> > our add-ons are going to be loaded on need
> > by the parent and only depend on the parent.
>
>
>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 fresh it doesn't matter, since they won't have anything loaded to 
start.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/30/2000 6:14:26 PM
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 fresh it doesn't matter, since they won't have anything loaded to
> start.


Still, if there was some networking code at the beginning but only the
beginning, and othe code later, explicitly marking the now-unreachable
code as recyclable could be a win, if it isn't much trouble.  But that's
what LRU paging does anyway -- what platfoms are we talking about, that
don't have LRU paging?



-- 
                          David Nicol 816.235.1187 nicold@umkc.edu
           Subroutine one-arg, him called no-arg, get $_-arg.  Ug.
0
david
8/30/2000 6:26:44 PM
At 01:26 PM 8/30/00 -0500, David L. Nicol wrote:
>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 fresh it doesn't matter, since they won't have anything loaded to
> > start.
>
>
>Still, if there was some networking code at the beginning but only the
>beginning, and othe code later, explicitly marking the now-unreachable
>code as recyclable could be a win, if it isn't much trouble.  But that's
>what LRU paging does anyway -- what platfoms are we talking about, that
>don't have LRU paging?

The Palm, WinCE (I think), various embedded devices (I don't think my car 
has a LRU paging scheme, for example), depending on how the translation 
goes a JVM port might not...

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

0
dan
8/30/2000 6:32:40 PM
Reply:

Similar Artilces:

RE: RFC 146 (v1) Remove socket functions from core
<cut> >No idea what the internals reasons are. Here are my reasons: <cut> 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 files (early Pascal anyone?) in todays world of networked computers. Being able to use them as easy as files would be the real goal: open(F,"\\server.yourdomain.net:2001"); while(<F>) { } close(F); The double slash giving a clue that...

Re: RFC 146 (v1) Remove socket functions from core #3
> At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote: > >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? > > Not particularly, at least not as far as I know. There's > some extra cost in > finding the library and loading it that you wouldn't pay > if you were linked > directly to it, but AFAIK that's about it. > > Dan There's also the issue t...

RE: RFC 146 (v1) Remove socket functions from core #6
>Leaping to conculusions based on no tests at all is even worse... > >Will anyone bite the bullet and write the "Internals Decisions should >be based on actual tests on multiple platforms" RFC ? BTW, I have access to Rational Software's Quantify (and PureCoverage and Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests. =============================================== Mark Leighton Fisher fisherm@tce.com Thomson Consumer Electronics Indianapolis IN "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_ ...

RE: RFC 146 (v1) Remove socket functions from core #8
>>BTW, I have access to Rational Software's Quantify (and PureCoverage and >>Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests. > >If you want to get "in the mood" it would be good to fire it up on >(say) perl5.6.0 and see where the hot-spots are. Planning on it as part of my upcoming perlhack doc patch on tools for debugging/testing perl. =============================================== Mark Leighton Fisher fisherm@tce.com Thomson Consumer Electronics Indianapolis IN "Display some adaptability." ...

Re: RFC 146 (v1) Remove socket functions from core #7
It's been strongly indicated that removing sockets (as well as any other Perl functions that are little but wrappers around libc calls) will not meaningfully reduce the size of Perl nor increase its speed. Various VM issues have been discussed, including risks of deadly embrace and egregious performance problems resulting from the running of numerous instantiations on some architectures. A simple run-once test on a single target platform, or even several, will not bring these matters to light. but this will all have to be addressed in exploring what can or cannot be done. Tha...

Re: RFC 146 (v1) Remove socket functions from core #2
--- "Stephen P. Potter" <spp@ds.net> wrote: > Lightning flashed, thunder crashed and Tom Christiansen > <tchrist@chthon.perl.co > m> whispered: > | Unless that's done completely transparently, you'll > pretty much screw the > | pooch as far as "Perl is the Cliff Notes of Unix" > notion. Not to > | mention running a very strong risk of butchering the > performance. > > I don't think there is any ruling from Larry that perl > must remain the > "Cliff Notes of Unix." In fact, there seems ...

RE: RFC 146 (v1) Remove socket functions from core #5
> For instance, if I'm running Perl on my Palm, I'd just as soon that > index() were implemented in Perl using repeated substr() comparisons. How small do we really need to go? Are we looking at implementing Perl for microcontrollers, or are we only worrying about Perl for PDAs? The difference is that PDAs are now shipping with much greater amounts of memory than they first started with. For example, my 2-year-old Palm III only had 2M of RAM, which isn't much RAM when perl consumes around 1M or so. But my new Handspring Visor comes with 8M, which looks much more ...

RE: RFC 146 (v1) Remove socket functions from core #4
<cut> >Perl is *not* fun when it supplies nothing by default, the way C does(n't). <cut> >If you want a language that can do nothing by itself, fine, but don't >call it Perl. Given these: <cut> I agree! Removing some of the things mentioned would turn Perl into an environment well suited for computer science projects, but a hard sell as a tool to get a job done. Let me take a look in my c:\\work directory for a second.... Just as I thought most (80%) are less than 1k in size. All but one huge 5k program are 2k or less. Yet these small (20 li...

RE: how small is small? (was Re: RFC 146 (v1) Remove socket funct ions from core)
How small? I'd like to get barebones Perl and Linux on a 1.44MB floppy... If it is currently possible, I'd like to know... Perhaps someone has already created such a single disk linux distro? Garrett P.S. I know one group of developers who'd be interested in putting Perl on a microcontroller. -Right now, they seem to think they'll have to use Python. From: Bradley M. Kuhn [mailto:bkuhn@ebb.org] > > Fisher Mark wrote: > > > How small do we really need to go? Are we looking at > > implementing Perl for microcontrollers, or are we onl...

RFC 155 (v1) Remove geometric functions from core
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 <spp@ds.net> Date: Aug 24 2000 Mailing List: perl6-internals@perl.org Version: 1 Number: 155 =head1 ABSTRACT Move the geometric functions (C<atan2>, C<cos>, etc) from the core language to a loadable module. =head1 DESCRIPTION The geometric functions currently included in the core language are of generally limited and specific value. This RFC is proposing that all the ...

Re: RFC 155
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:Falutin. However, since those funtions take up about 200 lines in the core, are very stable and relatively easy to document, what do we win by removing them? PS The idea of adding acos, asin and tan is good. -- Michael G Schwern http://www.pobox.com/~schwern/ schwern@p...

Re: RFC 155
Dan wrote: >At 09:12 AM 8/25/00 -0400, Stephen P. Potter wrote: >> As you say, 200 lines isn't much. But combine that with the IPC, the >>environment, the system, etc it all adds up. > >Not to much, though. We've been down this road for perl 5. You'd be >surprised at how little code gets removed if you yank most of the functions >under discussion. (They're generally trivial wrappers around library calls, >with very little code involved) so is all this concern about the size of perl due to the hope of making perl "embeddable&q...

RFC 155 (v2) Remove mathematic and trigonomic functions from core binary
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Remove mathematic and trigonomic functions from core binary =head1 VERSION Maintainer: Stephen P. Potter <spp@ds.net> Date: Aug 24 2000 Last Modified: Aug 28 2000 Version: 2 Mailing List: perl6-internals@perl.org Number: 155 =head1 ABSTRACT Move the mathematic functions (C<exp>, C<log>, C<sqrt>) from the core binary into a loadable module. Remove the trigonomic (C<atan2>, C<cos>, C<sin>) functions from the binary, they can alr...

RFC 168 (v1) Built-in functions should be functions
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Built-in functions should be functions =head1 VERSION Maintainer: Johan Vromans <jvromans@squirrel.nl> Date: 27 Aug 2000 Mailing List: perl6-language@perl.org Version: 1 Number: 168 =head1 ABSTRACT RFC 26 proposes to eliminate the distinction between functions and operators from a language perspective. This RFC proposes that all Perl built-in functions should be usable in all ways normal functions can be used. It is part of a big consipracy to remove the number o...

Web resources about - RFC 146 (v1) Remove socket functions from core - perl.perl6.internals

Talk:Trigonometric functions - Wikipedia, the free encyclopedia
This article is within the scope of WikiProject Mathematics , a collaborative effort to improve the coverage of Mathematics on Wikipedia. If ...

TV binging, exercise skipping linked to poor cognitive function
Bad habits early in life may affect brain power later, researchers suggest.

iPhone best tricks and functions - Business Insider
Your iPhone can do a lot more than you think.

Learning F# – The Thunderdome Principle for Functions
... One object enters, one object leaves! What I like about F# is that the language designers took a similar approach when they implemented functions. ...

HPE Offers Catalog of Virtual Network Functions for Telcos
The vendor's OpenNFV Solution Portal gives carriers a single place to find a range of VNFs that are pre-tested to run on their networks.

7 Useful Technical SEO Functions For Your E-commerce Website
This article was co-authored by Mate Dyekiss, SEO Strategist at IMI. An e-commerce website can create all the technical SEO issues onecan imagine: ...

Madras HC asks police to allow Tipu’s birth anniversary function
... Station on a petition filed by Ismail, General Secretary of Thamizhaga Makkal Jananayaga Katchi, seeking grant of permission to hold the function. ...

Colorado governor: This Planned Parenthood shooting may be a function of inflammatory rhetoric from bloggers ...
Via Grabien , skip to 4:45 of the clip below for the key bit. I naively thought we were (mostly) done with “climate of hate” stupidity after ...

Surprise: Binge-Watching TV May Cause a Decline in Brain Function
With the second season of Transparent only a few days away, some bad news awaits us: According to a recent study and common sense, probably, ...

1964 Archival Footage of British Soldiers Under the Effects of LSD Losing the Ability to Properly Function ...
1964 archival footage of British soldiers being given LSD-25 while training the the field. Over time they lost their ability to properly function, ...

Resources last updated: 12/26/2015 9:14:50 AM