Re: object(x) rethink
- Posted by Andy Drummond <andy at kestrel?e?e.com> Mar 04, 2008
- 739 views
Robert Craig wrote: > > All types in Euphoria, whether they are > built-in, like integer(), or user_defined, > can be used to either declare a variable, > or test if a value belongs to that type. > e.g. > }}} <eucode> > atom a > sequence s > my_special_type month > > if atom(9.9) then ... > if sequence(x) then ... > if my_special_type(11) then ... > </eucode> {{{ > > So, just for completeness, if you can > declare something as: > object y > it seems reasonable that you should > be able to say: > if object(z) then ... > even if that is rather pointless. > > As for detecting uninitialized variables, > this would be trivial to implement in the > interpreter as it is currently implemented. Which is why I thought a logical response rather than a program abort would be simple to implement. > > It would be harder to implement in the translator, > since the translator currently does no run-time > checking at all for uninitialized variables. > You would have to initialize variables to the > magic "NOVALUE", something that is currently not done. > This might waste a bit of time, in the case of > private variables that would have to be set to NOVALUE > each time a routine was called. (In some cases I > currently set certain variables to 0 to achieve > an optimization later on.) I had not appreciated that a translated and compiled program would not detect uninitialised variables. That does affect things. > > All future implementations of Euphoria, > interpreted, compiled, etc. would > have to support this, even if it proved to > be inconvenient for the implementor. Yes - but if trivial, OK > > Currently Euphoria can often detect *at compile-time* > that a variable is never assigned a value. > > I'd like to see some good examples of where > this would be useful. It seems to me you > could have code that detected that a variable > was not initialized, but then what would you > typically do? Probably either issue an error > message "Variable not initialized!", or quietly > set the variable to some default value. > > If the program was composed entirely of your own > code, it would be silly to add *error-checking* code > to test if a particular variable is initialized. > It would be easier just to initialize it. > If you wanted to test that it "hasn't really > been set to a meaningful value yet", e.g. a file handle, > in almost all cases you can just set it to some special > value that indicates that fact, like -1, or whatever. > > If you wrote a library used by others, they might > fail to initialize one of your global variables, maybe because they > made a silly mistake, or just didn't realize it was > required. So in that case you could either issue an error message > telling them they made a mistake, or quietly set the > variable to some default value. Your message might be > slightly more meaningful to them, than a generic > Euphoria-issued message, but probably not much. > You could also initialize the variable yourself to some > special value that means "not really initialized properly yet" > and issue the same kind of message. > > I don't think this is a good idea, > but I would not oppose it if a majority > wanted it, and someone were willing to > implement it. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> Reading your comments above, I understand where you are coming from. I agree that having object() is consistent with atom(), integer(), and sequence(), but it is rather a waste of effort if all it can do is cause an abort to occur. While atom(x) would return false if x was not an atom, it seemed reasonable that if object() exists then it ought to do something useful - so object(x) returning false - 0 - if x was not an object (and an uninitialised variable is not an object) is a rational response. I won't press this one. I merely rest my case. I have no idea how Euphoria as a language will develop in the future, but in the hope that there will be advances I thought this would be a valuable change. To have function which can only return a single value and changes nothing is pedantically pointless. Andy