Date: 23 Jul 2002 09:16:20 +1000 From: Andrew Reilly <areilly@bigpond.net.au> To: Mark Valentine <mark@thuvia.demon.co.uk> Cc: jos@catnook.com, freebsd-arch@freebsd.org Subject: Re: Package system flaws? Message-ID: <1027379780.648.51.camel@gurney.reilly.home> In-Reply-To: <200207151718.g6FHIkof007662@dotar.thuvia.org> References: <200207151718.g6FHIkof007662@dotar.thuvia.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1027379780.648.51.camel>