On Mon, Aug 20, 2012 at 2:32 AM, john skaller <skal...@users.sourceforge.net
> wrote:
>
> >
> > 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?
>
Er, maybe?
> > 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.
>
They seem to have tackled it in Scala, but they lean on the existing class
initialisation system.
I don't think this is "too hard" to do in general, but I can't say for sure
its impact on optimizations.
> What's the problem? Maybe you're talking about the order of
> initialization of global variables?
>
> 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.
>
I can see real complications would crop up around mutual recursion... one
function must be able to "refer" to another one even though that one hasn't
been defined yet. So the lexical scoping can't apply to functions always.
I happen to know that in some cases Scala does allow you to reference an
unintialized val and I found it troubling there as well.
> 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.
>
Er, hmmm okay just different language I guess.
> 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.
>
So the secret spec says that jumping to an inactive label should be
prevented, or that it is undefined?
> Well, if they're on the "known issue" list I don't mind as much.
>
> Didn't I originally bring some of these up?
Heh you did indeed!
> It means that I could try to fix some of them if they get in my way.
>
> You load the latter for binding the libraries, then switch to the former
> for user programmers -- eliminating goto in applications
> (but not library code).
>
Sure ... I can just "not use" goto really. I'm just being opinionated here.
> > 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".
>
Yes, although performance measurement and benchmarking are something that I
don't entirely feel qualified to perform. The results are all too often
meaningless and/or irrelevant to real world applications.
> > ! 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.
>
Felix is not C++ in many practical aspects like tool chain (debugger, IDE)
and talent pool.
> > 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++.
>
Yeah, I think if someone already likes C++ they won't see much benefit from
Felix. Felix is good for people like myself - I want a language that
doesn't suck like C++ but interoperates with C/C++ so that I can target
other platforms. Honestly I probably would be happy enough with some JVM
based languages if the performance was there, but the JVM is banned from
iOS.
> Try telling someone OO is a fraud and they continue to act like
> Creationists, who think their beliefs deserve at least equal time.
>
Hey, I resemble that remark!
And besides, those creationists have a point. Having spent time around my
own children I think they prove that evolution is a fraud - there's no way
humans could have survived in the wild if not for the grace of a divine
being :-P
------------------------------------------------------------------------------
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
