> > So write Python instead. > > I considered it, but I wanted a typed language so that it could help me avoid > errors and possibly enable some level of smartness in the IDE.
Oh. So basically, the type system is more important than some unsafety in control in complex code? > I realized that actually you have to restrict the use of nested functions as > well, Ah .. you're beginning to understand. Its actually a very hard problem. Been there done that .. the only way to do this properly requires full scale data flow analysis. Unlike many other languages, Felix can do this. because it is a whole program analyser it doesn't have to guess about external function behaviour, the only caveat is that C binding have sufficient annotation to describe them. > What's the problem? Maybe you're talking about the order of initialization > of global variables? > > That is trickier. Its the same problem. Given a set of assignments, we need to calculate an order in which no variable depends on one which is not yet assigned to: a simple dependency graph in principle. Then you can either (a) reorder the assignments to ensure the invariant holds, or (b) report an error if the programmer order doesn't meet the requirement. In both cases you have an error if its circular. Forcing a linear order with scope rules is a cheap and restrictive way to attempt to do this and it works just fine if you only call perfect functions (no side effects, not dependent on variables) in the initialisers and there's no aliasing. > In other places the globals are treated specially so there's two passes, one > to setup the globals and another to run your "main". In Felix you're just > putting everything at the top level so globals are kind of just "enclosed" > variables in a way. > > This would introduce some significance in the order in which modules are > "included" because you wouldn't be allowed to use certain variables unless > the "global code" that initializes them has already run. It doesn't seem too > unbearable but definitely a bit more of a pain. > > Reordering these things at the compiler level might not be acceptable if they > depend on a generator or something that modifies global state. For globals the moral of the story is .. DONT. Don't use them! If you have to have global constants, at least make sure the initialisation is simple enough to be able to see locally that everything is cool. > Well, not even particularly "safe"-ish. It is extremely safe compared to C or C++ or Java. The strict typing and garbage collection ensure that it trashes all three of these languages in safety. Heck, type classes even have specifiable semantics. There are some warts, as in any language today. Unspecified behaviour isn't a big one really. Bad control (non-local goto dead frames) is more of a worry (you don't even get a run time error!) However this is not used as much as exceptions in C++ and Java (and in Ocaml) which are much worse (even if you get a diagnostic). Felix doesn't eliminate null pointer derefs but the type system does if you bind stuff correctly. > Ah, hmm it seemed in a few cases you were saying that these were not a > problem ... No, I'm saying its not a bug. Its a consequence of the semantics. The compiler is doing the right thing. The semantics are also good. You just wrote bad code. Its your fault. The problem is one of psychology and ability to reason about code. The way it is at the moment it is hard to see when you're doing the wrong thing. The semantics and concrete syntax aren't immutable, we can change them (but not at the cost of a major performance loss! A bit, perhaps, but ideally we want to fix it without losing performance). This is not the case with the nonlocal goto a dead frame (or jumping across functions which isn't allowed either). That's a bug in the system. The semantics and compiler should prevent this happening but they don't. I don't know how to do it without restricting other features (like closures) so much they're unusable. > Well, if they're on the "known issue" list I don't mind as much. Didn't I originally bring some of these up? There are a lot of "known issues". Known to me at least :) Some are bugs. Some are a consequence of design choices. Some can be fixed. Some we can try to warn about. > It means that I could try to fix some of them if they get in my way. You could try. you could also consider changing the way the grammar is loaded slightly, then refactoring the grammar into safe-felix.flxh unsafe-lowlevel-stuff.flxh You load the latter for binding the libraries, then switch to the former for user programmers -- eliminating goto in applications (but not library code). > We may need to have some kind of definition or test case around how fast > things are so one could determine whether things had in actual fact been > slowed down. Then changes to turn on/off certain optimizations can be > measured for their effects, rather than taking a guess at the impact of an > optimization. It would be very cool to have a graph of Felix speed over a test suite versus the date. A kind of "performance regression test". > ! I'd go as far as using C++ if Felix doesn't work out for me, but not all > the way to Fortran. You cannot need to do that. Felix IS C++. if you write Felix like C++ it will do the same thing. You can even mix Felix and C++ code as you know. In fact if you want virtual function polymorphism at present you HAVE to write some of your code in C++ because Felix cannot generate that stuff. Felix is designed to bind to C++ and act as a top layer on top of C++. The fact it can generate even faster code than C++ itself sometimes, and has a superior, safer, type system, builtin DSSL support .. blah blah .. is all an added bonus. > So, some thought about who the primary audience is might be helpful. My thoughts are wasted. I made the mistake of thinking the audience would be C++ programmers. Stupid idea. C++ programmers have their own utterly bigoted partisan view of the world. They'd never consider moving to something else. They're so deeply enmeshed in the language they can't even conceive of anything else. Sum types? Funny I never noticed they weren't there. We seem to get on fine without them in C++. Try telling someone OO is a fraud and they continue to act like Creationists, who think their beliefs deserve at least equal time. -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
