On 18/08/2012, at 6:33 AM, Dobes Vandermeer wrote:
>
> It's not a bug. You DID tell them to. The default for parameters is "val".
> By using a val parameter you're allowing the compiler to choose
> the evaluation strategy. That's the specification. Its not a bug.
>
> The unwritten specification?
There are notes about this in various places. We know the docs are deficient.
> The material that I read specifically says: "Values are constants: they
> cannot be modified".
>
> Later it shows an example of how to create a "lazy" value:
> val f1 = {x + y}; // lazy expression
>
> I inferred from this that "val" was not lazy. Otherwise, why introduce a
> special syntax for lazy values?
Because val isn't lazy. It can be lazy OR eager, at the whim of the compiler.
Using closures (or fun like variable) enforces laziness.
Using var enforces eagerness.
>
> There are two major problems identified in this thread that should be
> addressed:
>
> 1. Felix is not safe.
Correct. No language can be both safe and Turing complete.
> You can trivially dereference a pointer to random memory by using a val of a
> pointer type before it is initialized.
Yes, you can.
However unlike C, there is support for preventing dereferencing of NULL
pointers,
and unlike C there is support for preventing dangling references (garbage
collection).
Felix fixes a lot of problems that C/C++ have. It doesn't fix all of them!
> 2. Felix is unpredictable. You don't know by looking at the source code
> whether a parameter was passed by reference or by value.
True. This is true in most languages.
In C, you cannot predict whether a value is stored in a variable except at
sequence points.
In Ocaml, you do not have referential transparency, and the order of
evaluation of arguments is indeterminate.
In Haskell I think it is determinate what happens but you need
to be a genius to figure it out and the performance of simple
looking code is unpredictable even if the semantics are known.
Please note I agree there's an issue here. It's not ideal,
its not even nice. I would like to fix it. But I do not know HOW
at the moment. My inclination is to introduce more refined semantics
so at least some parts of the system become more easily reasoned about.
However rather than make vals eagerly evaluated, I was considering
banning initialising them with vars. But that seemed draconian,
so the replacement idea is to introduce "const", a "val which can't
be initialised from vars".
Maybe the solution is elsewhere. In most language several things are
conflated into one thing that shouldn't be. For example in Felix
"var" has two properties: its addressable and it uses eager evaluation.
What if we separated these properties? [instead of refining val,
refine var]
--
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
