On Fri, Aug 17, 2012 at 8:21 PM, john skaller <skal...@users.sourceforge.net
> wrote:
>
> On 18/08/2012, at 6:33 AM, Dobes Vandermeer wrote:
> >
> > Does the spec guarantee that a procedure without noinline will be
> inlined, that its vals will be passed by value?
>
> Nope. Don't use vals if you want eager evaluation. That's what vars do (at
> the moment).
>
> vars are optimised away too, but it is done conservatively.
> vals are optimised away aggressively.
>
> A val names a value. You should not expect a named value to work the
> same as a variable, which names a storage location.
>
A "value" would be the result of a computation - thus eager evaluation.
Instead you are treating the val as the computation itself, potentially
deferred.
This means that in fact a val is not a value, but a function that takes no
parameters. There's nothing inherently wrong with that but it's a
confusing use of the term.
Visitors coming from other languages that use the word "val" to refer to a
value (i.e. something with a predictable value) would thank you to keep a
familiar semantic for it - that it's an unchanging value computed at
initialization, or at least appearing so.
The keyword "fun" is used to define functions, it may be suitable for this
as well. If you allow one to define a type of function that takes no
parameter and doesn't require any parameter (not even unit) to be passed:
fun x => y + z;
fun y => 3;
fun z => 7;
You'd probably back on better footing as this is pretty clear in terms of
what you are doing. People would be surprised if these functions are
evaluated eagerly, though - so you'd still be a bit stuck. You could add
an adjective for people to enable this flexibility, like "pure":
pure fun x => y + z;
The "pure" would be a promise to the compiler that the function can be
evaluated at will without any change in semantics, whether to advance,
defer, repeat, or eliminate evaluation.
> 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.
>
> That's the C++ specification, with one exception: copy constructors.
> Consequently C++ is slow and cannot be easily optimised.
>
I don't think there are a lot of people running away from C++ because it is
too slow ... I certainly haven't noticed that. In fact, the opposite is
true, C++ is considered the "fast but hard to program" language, whereas
people are flocking to languages like RUby, Scala, Java, Javascript, and so
on because they are "slow to run but fast to program".
If you want to attract a following, it might help to consider that "fast to
program" is in vogue, whereas "fast to run" is relegated to niches like
scientific computing.
> Semantics matters. People still use Fortran because it is up to 30% faster
> than C doing the same calculations, because of rules you'd be horrified by!
>
Sure, some people are using Fortan. I sure as hell am not!
> How do we mix functional and imperative programming in a
> comprehensible way?
>
You seemed to be doing OK, but you're losing me with these ambiguities that
you have introduced for the sake of performance.
> ML is purely functional, but throws in just one extra thing:
> references. The functional system treats them as if they're
> just ordinary values. It total ignores side-effects. This means
> to predict what an ML program using references does you have
> to know implementation details. generally programmers avoid
> situations where you need to know them in detail, and just rely
> on a few obvious rules.
>
Programmers at large to seem to avoid ML altogether. I can't say exactly
why but I'm sure this plays into it.
> Felix has some surprises as a consequence of radical semantics.
> It's an experimental language. You shouldn't be surprised that there
> are a few surprises :)
>
Ah I suppose I wasn't thinking of it as a kind of "tinkering around in the
back yard" kind of thing when I first encountered, but I'm increasingly
realizing that is what this is, and what the drawbacks of using such a
thing might be.
------------------------------------------------------------------------------
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
