From owner-freebsd-chat Mon Jan 27 20:56:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17631 for chat-outgoing; Mon, 27 Jan 1997 20:56:41 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17604; Mon, 27 Jan 1997 20:56:26 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id PAA07513; Tue, 28 Jan 1997 15:26:17 +1030 (CST) From: Michael Smith Message-Id: <199701280456.PAA07513@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel config metasyntax In-Reply-To: from Warner Losh at "Jan 27, 97 09:29:43 pm" To: imp@village.org (Warner Losh) Date: Tue, 28 Jan 1997 15:26:17 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, chat@freebsd.org, config@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-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Warner Losh stands accused of saying: > : > : We are talking about a _metaconfiguration_ spec, for a tool which > : produces, as its end result, a traditional config(8) input file. > > Yes, but to add options to that tool, I'd have to write TCL. I > suppose cut and paste isn't so bad for doing that. I don't know TCL > very well, and it is hard enough to gork the config file config files > right now that any more would seem a burdon. In most cases, modifying the tool would not be required; the presence of the option and its attributes would provide the tool with all the information it needed to handle it intelligently. It would only be in the rare case that you had an option/driver/whatever that required abnormal treatment that Tcl-munging would be required. > However, that said, if TCL can be made to be unobstrusive enough to > hide most of the langauge and it would be a simple matter of cut and > past to add most things, then I'd have no problems with that.... That's the desired goal. > (option 'DDB :description "blah" :type 'boolean) > (option 'DDB_PANIC_REBOOT :description "blah blah" :type 'boolean > :depends-on 'DDB) > > which would be just a simple eval in lisp :-) Yup, but perhaps somewhat tougher to parse with 'normal' languages 8) > However, no matter what the language, I'm all for doing things as > easily as possible, and if that is TCL, then go for it. I've tried to make my stance on this clear; I use Tcl, and I would chose it if I were implementing this. (I may yet, depending on whether I can manage everything else 8( ) However, if someone else decides to implement in another language, that's not going to kill me. What _is_ important is that the syntax we chose is simple to parse in most languages, and it is open to simple extension without having to rewrite the parser. > As you may guess, I've been left with a bad taste in my mouth for > TCL over the years, so I tend to react negatively to it. I can appreciate this. Personally, I'd like to help you get over your aversion because I think you're missing out, and because I value your input, and having it coloured by a reflexive reaction is unhelpful. You point about the implementor's right stands however; if someone's there with code in their hands to do this stuff, I'm not going to dispute their language choice 8) > Warner -- ]] 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 [[