🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: no.unix
Article #5

Perl's fremtid

#5
From: Bjorn Hell Larsen
Date: Tue, 29 Sep 1992 07:18
121 lines
4841 bytes
En av tingene jeg har tenkt } si litt om p} Perl-kurset er
'Hvor g}r Perl?'.

Jeg vet ikke s} mye om hvor Perl g}r, s} jeg tenkte jeg skulle sjekke
med en som kanskje visste litt mer (:-)

Her er et brev jeg fikk i postkassa mi i dag:

> (Message inbox:92)
> To: bjla@statoil.no
> Subject: Re: Future of Perl
> Date: Mon, 28 Sep 92 09:42:46 -0700
> From: Larry Wall <lwall@netlabs.com>
> 
> : I'd be extremely pleased if you could give me any material on the
> : future evolution of Perl. You have given several indications on what
> : can be expected to be found in version 5.0 lately; I would really like
> : to hear a bit about your longer-term ideas/plans as well.
> 
> What I do beyond 5.0 is pretty nebulous, depending on what you count as
> part of 5.0.  For the most part I'm just hoping for stability.  In general,
> I'd like to make sure that Perl is usable in a multiprocessing environment,
> but a lot of the groundwork for that is happening as part of 5.0.  Likewise
> for objects--I'm laying down the groundwork for that in 5.0, but it remains
> to be seen how much I want to develop it after that.
> 
> My overriding concern is that I don't want to make Perl into just
> another C++, or just another Lisp, or whatever.  As they say, "If it
> ain't broke, don't fix it."  My intention is to make certain things
> *possible* in Perl without making them mandatory.  The trouble with
> something like C++ is that you pretty much have to know the whole
> language before you can use any of it usefully.  I don't want to fall
> into that tarpit.  I want people to continue liking Perl for the
> reasons they currently like it.  So while 5.0 will add references and
> objects, they'll look just like scalars most of the time.  I'm not
> going to break existing syntactic constructs in order to make it easier
> to do fancy things.  Hence 5.0 will support explicit referencing and
> dereferencing, but not implicit.
> 
> Perl (as a language) actually was pretty stable in the last year.  While
> 5.0 is partly about adding references and objects, it's mostly about
> scrapping a beast that grew helter skelter, and regularizing as much
> as can be regularized internally.
> 
> As for what IS intended for 5.0, here's part of the outline I talked
> from at BAYLISA:
> 
>     SYNTAX
> 	=> as synonym for ,  (examples from object editor)
> 
> 	Functions as unary or list operators (post parse semantics).
> 
> 	Subroutines as list operators.
> 
> 	all . + * etc. (maybe)  [APL, LISP reduce]
> 
>     RUNTIME
> 	Flattened interpreter.
> 	    Compare stack traces.
> 	    Compare inner loops.
> 		    run() { while ( op = (*op->op_ppaddr)() ) ; }
> 	    Show tree.  More optimization at node building time (constant
> 		folding, operator substitution, constant string hoisting.)
> 	    Threadability, schedulability.
> 
> 	Context stack.
> 	    Fewer longjmps.  (except in sort, sig handlers)
> 	    Avoids allocator.
> 
> 	Interpreted strings parsed at compile time instead of first use.
> 	    Transform to . and optimize to "all ."
> 
>     SEMANTICS
> 	Reference scalars.
> 	    No dangling references.  These AREN'T pointers.  Explicit
> 	    referencing and dereferencing.  Not intended to be
> 	    transparent.
> 
> 	Error propagation.  die if $@;
> 
> 	Return from eval.
> 
> 	Optional lexical scoping (probably) using "my" instead of "local".
> 
> 	Objects.
> 	    Object = Reference + Package
> 		(I don't much care what it's a reference to.)
> 	    Methods.  "method" instead of "sub".
> 	    Method invocation.
> 		$dog->give($bone);	# traditional
> 		give $dog $bone;	# indirect object syntax
> 	    Filehandles as objects.
> 
> 	Synthetic associative arrays.  Binding an associative array to a
> 	package that supplies fetch, store and iterator routines.
> 
> 	Access to ctype tables, or maybe extra \y widgies?
> 
>     INTERFACE
> 	Embeddability
> 	    Namespace protection (All globab variables * translated to PERL*
> 		via cpp.)
> 	    Multiple interpreters within a process.  (Per-interpreter struct
> 		of former global variables.)
> 	    Reentrancy
> 
> 	Dynamic linking (at least on Suns).  Perl as a shared library.
> 
> 	Existing bindings:
> 	    X Windows
> 	    Solbourne OI
> 	    CMIP
> 
> Hope this helps.
> 
> Larry
> 


Bj|rn
Technical Details
Message-ID: <M05751.92Sep29081807@foxtrot.data.st.statoil.no>
Path: arc1-ca.pugleaf.net!sparky!uunet!decwrl!sgi!fido!twilight!odin!sgigate!sgiblab!ifi.uio.no!nuug!statoil!foxtrot!m05751

Show Full Headers
Complete Article Headers
Newsgroups: no.unix
Path: arc1-ca.pugleaf.net!sparky!uunet!decwrl!sgi!fido!twilight!odin!sgigate!sgiblab!ifi.uio.no!nuug!statoil!foxtrot!m05751
From: m05751@foxtrot.data.st.statoil.no (Bjorn Hell Larsen)
Subject: Perl's fremtid
Message-ID: <M05751.92Sep29081807@foxtrot.data.st.statoil.no>
Sender: usenet@statoil.no
Nntp-Posting-Host: foxtrot.data.st.statoil.no
Reply-To: bjla@statoil.no
Organization: Statoil, Norway
Date: Tue, 29 Sep 1992 07:18:07 GMT
Lines: 121