From owner-freebsd-arch Mon Jul 22 16:16:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3057F37B400 for ; Mon, 22 Jul 2002 16:16:35 -0700 (PDT) Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A39543E5E for ; Mon, 22 Jul 2002 16:16:33 -0700 (PDT) (envelope-from areilly@bigpond.net.au) Received: from areilly.bpc-users.org ([144.135.25.72]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15 mta04ps May 23 2002 23:53:28) with SMTP id GZOBB900.BNB for ; Tue, 23 Jul 2002 09:16:21 +1000 Received: from CPE-144-132-188-183.nsw.bigpond.net.au ([144.132.188.183]) by PSMAM02.mailsvc.email.bigpond.com(MailRouter V3.0n 74/13870938); 23 Jul 2002 09:16:20 Received: (qmail 901 invoked from network); 22 Jul 2002 23:16:20 -0000 Received: from localhost (andrew@127.0.0.1) by localhost with SMTP; 22 Jul 2002 23:16:20 -0000 Subject: Re: Package system flaws? From: Andrew Reilly To: Mark Valentine Cc: jos@catnook.com, freebsd-arch@freebsd.org In-Reply-To: <200207151718.g6FHIkof007662@dotar.thuvia.org> References: <200207151718.g6FHIkof007662@dotar.thuvia.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 23 Jul 2002 09:16:20 +1000 Message-Id: <1027379780.648.51.camel@gurney.reilly.home> Mime-Version: 1.0 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 2002-07-16 at 03:18, Mark Valentine wrote: > Beyond that there's a perfectly good C compiler. Here's another way to think about this problem, that just occurred to me (and with it, another theory for a solution): * Any new scripting language always runs into the problem of support for the entirety of the libraries of the base system (and whatever add-ons a site might have) until it becomes popular enough that wrappers will have been written for all of them, or auto-generated in some way. * The big things that make C more difficult than scripting languages are (IMO of course): + No high-level containers as basic types (dictionaries, multi-dimensional auto-sizing arrays, "stringy" strings. + No container-oriented flow control (foreach, etc). + No garbage collection. + Manual type definition. * It does, however automatically have access to facility of the system, because that's how the APIs are expressed (.h files). * There isn't (that I can see) a strong need for the dynamic features of scripting languages (the exec function, essentially) in "programs" like portupgrade and the build-assist things that used to be done in perl. So: what about a ratfor-style pre-processor for C, rather than a whole extra language? The C source could be shipped with the system to be compiled, so that the translator/pre-processor would not be a dependency in the build process. (SmallEiffel bootstraps this way.) I don't know of a language that does what I'm thinking, so perhaps there's something fundamentally difficult with it. SmallEiffel probably comes pretty close, but it doesn't do the type inference that you need to avoid manual definitions. It's also a bit painful to wrap external C functions. Showing it's age a bit there. Certainly there are string manipulation libraries that are much easier to use than stdlib, generic garbage collectors. Sure, it would make the programmer's job a smidgen harder, because they'd have to run the pre-processor and then compile the result, but that's not much of a chore. The system Makefiles could even be taught to do it automatically. On the same topic, (but perhaps in counterpoint) there was a post to comp.arch recently that said (in effect) that every programming project of sufficient scale grows a bad implementation of Common Lisp. Just how important _is_ the exec function to a scripting language? -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message