Re: Matt versus Chris
- Posted by mattlewis (admin) Mar 13, 2009
- 1017 views
If you want something a little bit more concrete, here we go again: keep 'include' directive just for the purpose of joining files at the same level, no hierarchy, just seamless (monolithic) insertion. Keep 'global' directive for system wide, generally useful definitions, and the new 'import' 'export' combination could be used to bring in marked definitions just from 'import'ed files. All naming conflicts would have to be resolved with full qualifications.
I believe that the current solution is doing a pretty good job of keeping it simple, at least for the way most coders will use the language. The complications arise when building a multi-file library, which most coders probably will not do. However, they do rely on those libraries. And now the library author has some important tools to ensure that his end users can easily use his library without having to worry about it conflicting with other libraries he might wish to use.
The parser tries to use the information it has to determine coder intent with respect to symbol resolution. In other words, if it has a choice between two symbols, one of which is from a file that was included, and one of which isn't, the parser will choose the one that was included. It seems pretty clear that the author wanted to use that symbol.
The typical application coder should never have to worry about using anything other than vanilla includes. Alternative designs that Chris had proposed (and has threatened to post, but has not done so yet) added additional control features, which, IMO, did not Keep It Simple.
And while I am at it, perhaps one or two more (old!) ideas. Drop the stupid, quasi-religious 'declare before use' notion! It has no place in the modern world with fast and sophisticated tools combined with powerful hardware. It is an anachronistic obnoxious restriction of the program's logic flow without any palpable benefits. The compiler will bark at you in a fraction of a second if you forget to declare anything, even in relatively huge programs.
This has largely been dropped. Across file boundaries, there is no requirement for declare before use. For routines, there is no declare before use. Variables being used in the same file or routine, however, must be declared before use. So if you simply declare variables at the top of your code, you should never have an issue.
Use before declare really makes no sense within a routine (or smaller scope, such as an if/for/while/etc block), and it simplifies the implementation a great deal to enforce local variables to be declared. This could change in the future, but I believe that the main benefits of forward referencing have been achieved.
I think we will all agree the sequence is the main feature of euphoria, indeed the cornerstone of the language. It is a remarkably flexible, polymorphous beast, immune from any sort of typing. Strangely enough Rob designed a statically typed language with a weird typing system around it. I think that's one of the reasons why many dynamically typed languages of roughly the same vintage or younger (python, lua, ruby, etc) became vastly more popular. Their authors realized that the bug reduction claims for such systems were always grossly exaggerated. Simply ditch the type declarations altogether, or make them merely optional ('strict' or 'explicit' directive?) to pacify the ultra-conservative element, the retired submariners among us. That would substantially reduce the number of lines we have to write, with attendant improvement in the clarity of the code.
If you really want to, you could simply declare everything as object, and you'd have this. If, however, you mean no such declaration (as python has), then I doubt this will ever happen.
One benefit to declaring specific types is that the interpreter and translator use that information extensively to speed up execution.
And while I am talking about the code clarity, small doses of syntactic sugar in selected places would do wonders for the euphoria's taste. An example: a dot notation for simpler associative arrays with string keys, would be, I am sure, greatly appreciated.
Just one more, forever studiously ignored wish, before I go to bed - it is getting quite late down here in New Zealand. For goodness sake, get moving on those 'parameters by reference' perennials. For me Derek's recent adventure with stacks highlighted again how badly we need the feature...
Yes, there are many syntactic sugar ideas floating around. We're certainly interested in making them, but as Derek noted, they aren't the top priority right now. Pass by reference is another topic that I believe will be addressed in 4.1. It's going to need a lot of discussion to make sure we get it right. Then we'll have to figure out how to implement it...
Matt
