On Fri, Aug 17, 2012 at 12:39 PM, john skaller <
skal...@users.sourceforge.net> wrote:
>
> On 18/08/2012, at 4:28 AM, Dobes Vandermeer wrote:
> >
> > Parameters are not supposed to behave this way unless you tell them to
> ... this is ridiculous. If you don't think this is a bug, you are insane.
>
> It's known I'm insane :)
>
> 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? 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?
I agree it leads to surprises, the question is: how do we fix it
> WITHOUT losing optimisation opportunities?
>
Just let people do lazy values explicitly. Only some parts of a program
need to be fully optimized, and it'll lead to fewer surprises for people
like me. The dumb unwashed masses you are hoping will adopt your language.
if you need eager evaluation:
>
> proc b(var i:int)() = {
>
Sure, but that should have been the default.
Or:
>
> noinline proc b(i:int)() = {
>
//^^^^^^
> // i += 1;
> println$ "b, i = "+i;
> }
> proc a() {
> var i = 0;
> bb := b(i);
> i = 10;
> bb;
> }
> a();
> // prints b, i = 0
>
Can't you see how wrong it is that this behaves differently than the one
without noinline?
Otherwise I might write some code that relies on the value being passed by
value and then later if the function isn't inlined for whatever reason that
code will stop working!
You should note that inline has semantics precisely because
> it controls evaluation strategy.
>
Does the spec guarantee that a procedure without noinline will be inlined,
that its vals will be passed by value?
This does make things more complicated and confusing, though.
In Felix its the same, evaluation strategy of vals/functions
> is unspecified (eager or lazy) by default, or explicitly val,
> but you can control it as in C -- rewrite you code using
> var, noinline, pointers, or some other mechanism that
> resolves it.
>
I don't think I have ever encountered a feature of C or C++ where its
behavior depended on whether a function was inlined or not. Such a
variance would be considered a compiler bug.
In C++ I can explicitly pass something by reference, and it will be passed
by reference regardless of whether the called function is inlined.
There are two major problems identified in this thread that should be
addressed:
1. Felix is not safe. You can trivially dereference a pointer to random
memory by using a val of a pointer type before it is initialized.
2. Felix is unpredictable. You don't know by looking at the source code
whether a parameter was passed by reference or by value.
------------------------------------------------------------------------------
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
