I may be going to far here, but what about the ability to define new devices? Or composite devices.
define warpdisk cpu p3 # Warp disk controller include vendor/warpdisk_driver.inc end
mainboard vendor/model cpu p5 warpdisk ...config... end
Also I don't know if the current structure allows options.
superio vendor/model IDE2=0 # For setting #defines for this included device. warpdisk ID=0 MAXDISK=3 warpdisk ID=1 MAXDISK=2
Jordan
On Mon, 19 May 2003, Greg Watson wrote:
Defining the tree from bottom-up is somewhat non-intuitive and potentially confusing. It seems more natural to define the tree structure top-down as follows:
mainboard vendor/model cpu p5 southbridge vendor/model end southbridge vendor/model2 superio vendor/model ...config... end end end
OH, ok, you win. I had thought of this but hate the idea of writing a parser ... string handling in C is like walking on broken glass.
mainboard motorola/sandpoint pmc altimus/mpc7500 northbridge motorola/mpc107 end southbridge windbond/w83c553 superio NSC/pc97307 com1={1} com2={1} floppy=0 lpt=1 keyboard=1 hwmonitor=1 end end nvram flash end
agreed, it's pretty. But NOBODY is allowed to suggest lexical scoping from indentation. That's not allowed :-)
Greg, parser in the usual lex/yacc/C mode or .... I'll see if anybody's got parsers written in python.
ron
On Tue, 20 May 2003 jarcher@pobox.com wrote:
I may be going to far here, but what about the ability to define new devices? Or composite devices.
define warpdisk cpu p3 # Warp disk controller include vendor/warpdisk_driver.inc end mainboard vendor/model cpu p5 warpdisk ...config... end
Also I don't know if the current structure allows options.
superio vendor/model IDE2=0 # For setting #defines for this
included device. warpdisk ID=0 MAXDISK=3 warpdisk ID=1 MAXDISK=2
Jordan
well, at what point are we going overboard? but we'll look at it. It's an interesting idea.
There was a reason I made the original language so dumb ... :=) Once you make it a real language too many things are possible :-)
ron