From owner-freebsd-hackers Mon Nov 18 17:32:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA03753 for hackers-outgoing; Mon, 18 Nov 1996 17:32:42 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA03745 for ; Mon, 18 Nov 1996 17:32:31 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA25471; Tue, 19 Nov 1996 12:02:03 +1030 (CST) From: Michael Smith Message-Id: <199611190132.MAA25471@genesis.atrad.adelaide.edu.au> Subject: Who needs Perl? We do! In-Reply-To: from "Eric J. Schwertfeger" at "Nov 18, 96 11:08:31 am" To: ejs@bfd.com (Eric J. Schwertfeger) Date: Tue, 19 Nov 1996 12:02:02 +1030 (CST) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Eric J. Schwertfeger stands accused of saying: > > In this case, replace badly written with commonly written, and it does > become a fair comparison. There is no universally available hash array > library for C. Tcl makes for a pretty mean hash library, and look, it's even shipped as a standard part of the system! 8) (New thread starts here.) I'm aware that people will want to scream, but I _do_ believe that we should take some steps towards incorporating perl in the base system, as we have done (successfully, and IMHO very usefully) with Tcl. I would appreciate input from serious Perl backers on the following : - a means for optionally disabling the build of individual components of the base system, in such a fashion that the build may proceed without them. This should allow people who hate Perl and Tcl to set CONTRIB_NOPERL and CONTRIB_NOTCL during their builds for example, and have nuked the src/contrib/... directories involved. This dovetails nicely with the CVSup 'refuse' feature. - a contrib-ready Perl, at release quality. ie., not the 'patch de jour' but the equivalent of a -STABLE version. - an undertaking from several to keep an eye on Perl development, and update the in-contrib Perl as appropriate. - input on the modifications necessary (if any) to allow system libraries to be loaded and used by Perl. I have WIP on this for Tcl, and I feel that it is a highly desirable feature that should be allowed for. If we can meet the above requirements, I feel we have an excellent case for putting Perl in the main tree. I would also encourage anyone that is working on seperating the development tools from the 'base' system to consider carefully the distinction between 'development' and 'runtime', as that's kinda grey with these languages, but on reflection is a sensible attitude to take. I do _not_ feel that having Perl in the ports collection allows for it to be usefully considered a part of the system. If we have to go to a componentised/layered structure for the base, then so be it. A point to consider : I _loathe_ Perl. Reading it gives me a headache, and I would sooner snort powdered lithium than program in it. Understand that I think Perl is relevant for what it is, and not what I feel about it. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[