On 20/08/2012, at 3:24 PM, Dobes Vandermeer wrote:
>
> let ?x = expr in
>
> where you cannot refer to x until after it is initialised.
>
> RIght - just treat every var ... and val ... as if it is opening a new let
> starting at that point and continuing to the end of the block it is in. This
> isn't rocket science.
Unfortunately it is :-)
> It's not too late to get rid of goto, is it?
What do you mean? Conditional control transfer is fundamental.
Languages which do not provide it, providing loops or other stuff
instead soon become even worse spaghetti.
> One can be conservative in the presence of goto and labels - which label you
> are jumping to is always hard-coded so you can simply check whether it is
> even remotely possible a var or val is not initialized and ban its use at any
> point after the label. The use of gotos should be so rare that this should
> impact almost nobody.
You're misunderstanding what happens. by the time binding and type
checking is done, there's nothing left EXCEPT gotos.
Any blocks, loops, or whatever have already been replaced
by gotos. This is how compilers work. They reduce complex things
to simple ones.
[Re: no blocks]
> Are you saying you cannot do
>
> fun foo() = {
> if X then do
> return Y;
> done
> return Z;
> }
> ?
No, of course you can do that. But the body of a function isn't a block.
Nor is the do .. done part of the conditional a block. As in C,
you can jump right into the middle of a do .. done. It's all straight
line code.
See here:
{
var x = 1;
println$ x;
};
{
var x = 2;
println$ x;
};
You can do that. Do you see the blocks?
No you don't. There are no blocks there It is really this:
(proc () { var x = 1; println$ x; } ) ();
It's easy to see what this means:
fun () : int =
{
{
var x = 1;
return x; // ERROR, return value from procedure
};
}
>
> > I guess performance isn't THAT important to me.
>
> Oh yes it is, it is the ENTIRE reason for using computers!
>
> I meant I won't sacrifice the predictability of me code on the alter of
> performance.
You don't have to! You sacrifice the predictability
of ARBITRARY programs.
So its simple. Don't write arbitrary code.
Of course you don't anyhow :)
Use the functional programming technology because in general
its easier to reason about functional programs than imperative
ones, and easier to reason about general imperative code than
object oriented method spaghetti.
> You were justifying your solution where the runtime behavior of my
> application depended on decisions made by the optimiser (whether to inline or
> not). That's not a worthwhile trade-off.
So write Python instead. Its as slow as a wet week but that hardly
matters does it?
It's untyped, so its hard to reason about what will happen,
and its fragile meaning what happens is very sensitive to
non-local changes, but it is always deterministic, even if
the actual result is hard to predict.
>
> Define before use does not support recursion.
>
> This need only apply to vals and vars, functions can be recursive.
This is more or less impossible in the current compiler. It uses
a unified lookup model: all symbols all looked up by the same
algorithm. Note types can be recursive.
In general, order of initialisation cannot be determinate
with separate compilation. Felix doesn't have that, so in theory,
you could enforce a linear ordering.
Unfortunately its very hard if not impossible to do it, without
sacrificing something else. It may sound like it is not rocket
science but it is in fact very hard.
Consider:
var x = f 1;
Woops! x is initialised by a function! What if it's a generator?
What if it changes the value of something x depends on?
What if you don't even know which function it is because
its a closure?
Your simply "linear" ordering doesn't work.
It doesn't work in C or C++ either. Same problem.
Even within a single translation unit. Works better
with vals than vars (because they're not addressable).
Trivial with "vals not depending on vars:". If you write
pure code its no problem.
That's why I am thinking of "const" -- pure functions and
variables.
The problem is less in C because there are no nested functions,
and global variables can only be initialised by compile time constants.
But even in C, this isn't a solution because the *real* initialiser isn't
the dummy value you put in the global. And you have pointers!
> May or may not trigger a DIVBYZERO error depending on the optimizer's
> decisions at compile time. I don't want this function to work perfectly for
> years and then one day, due to some little optimizer tweak or someone
> exceeding the inlining threshold, it starts causing the program to abort.
Then do not use vals. User vars instead.
> That's just not what I would consider a "safe" programming language.
It's not meant to be entirely safe: that's impossible anyhow.
>
> It increasingly appears that you have little interest, however, in safety -
> your interest in types stems only from an interest in performance.
I'm very interested in safety. I have never disputed that any of the things
that you find disturbing are a problem.
They disturb me too. I just don't know how to fix them.
Slowing down unrelated things just to achieve safety
isn't a good compromise though. I have looked at quite a lot
of possible solutions and none of them work.
In addition, I don't have full control over everything due to a prior
commitment to stick to the C/C++ object model. Instead of,
for example, doing what the Ocaml team did: generate
machine code.
--
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
