From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2d0d156f44bbb4ede967989982b99586@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] new compilers From: Charles Forsyth Date: Fri, 31 Mar 2006 10:43:49 +0100 In-Reply-To: <6cc27558710263342edab21d0db7e92a@lsub.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 29ea96c6-ead1-11e9-9d60-3106f5b1d025 > Type checking was also a concern. I think they did not > understand that a data type (or xml tree) is not a guarantee > to have the system know about "semantics". They got > even more scared when I replied that the system should > best not be involved in semantics (which is up to the user). i have heard that before. it's worth noting (just for the sake of it, not because anyone necessarily takes it in) that the system has got certain conventions. for instance, networks are in /net and their name spaces must adhere to some network-independent conventions, both in terms of names they present, and how those names behave with open/read/write. furthermore, control requests are checked by write and return an error if they are invalid. (that by the way is something they often don't realise unless you point it out.) this is not much different in practice from python (say) checking types of things at run-time. or javascript (and AJAX is all the rage, and note that the X in that is optional). actually, it is different, because in my experience run-time errors in python programs are not uncommon, but i never see /proc inadvertently confused with /net. it is easy to use the wrong instance of something (eg, an inside /net not the outside one) but then they would have the same type. if you have the need, you can put a contract-enforcing name space in the way of another name space. as a simple example, a few lines of code, easily validated, will enforce read-only access to the contents of any name space. that is quite hard to do with web services in general.