On 30/06/2013, at 8:42 PM, srean wrote:
> The two problems I see it are these
>
> i) val x = f(a,b)
>
> if f is not pure x can have different values.
.. depending on when f (a,b) is evaluated.
> Here you would say dont use val, use var. That is certainly somewhat better.
Roughly, if f depends on a var, the result should go in a var.
However: there is an argument f should be declared:
acc f (.. ) ..
where "acc" means "accessor". I've also heard these named observers.
The simplest case of these has a common name: they're called get functions:
var x = 1;
fun get_x () => x;
So there's a question whether to add a new binder. This doesn't help
tell what's going on from the usage of f, but at least you can look it up.
It's the same with generators.
So, I agree there's an issue here, but I'm not sure what the resolution
should be. Certainly without use cases to consider, I'm inclined to
do nothing.
If you want to see what a language with much more *precise* control
looks like I recommend ATS. I guess about 50% of ATS code is about
proving by way of the dependent typing, that contracts are met.
Type systems, necessarily, are never complete: by definition
they're approximations (abstractions). So the real question is
always how precise to make the typing, and, given some
system (eg Felix) how it could be changed to retain the
same level of approximation but serve common cases better.
Which gets back to: actual use cases. Theoretical arguments in a
approximate setting are useful to help define logical pathways
but have little input into the weighting of choices.
I've had more trouble recently with the fact that
a + b
is not only used to concatenate string,s but also lists,
and element to lists. So:
Empty[string] + "Hello" + "World"
is a lits of two words .. and if you have 10 words its hard to remember
that you're adding to a list, not concatenating strings. The problem
is neither interpretation is a type error. Maybe + is a bad choice
for so many types.
The thing is, the semantic confusion due to evaluation strategy only
occurs in *high level code* using closures, etc where the programmer
has to think hard to design the code in the first place. OTOH strings
and lists of strings are THEM two most common data structures in
a scripting language.
Which problem is most important?
> ii) the other problem is
>
> g(c,d)
>
> or
>
> var y = g(c,d)
>
> can get completely elided when y is not used, even though the programmer did
> not want the call to get elided, i.e. he/she wanted the side effect.
Side effects are supposed to live in procedures.
When a generator is used it will usually encapsulate the mutations inside
itself,
and in this case elision is no problem.
The only problem occurs when you have a badly designed entity
coded as a generator when it SHOULD have been a procedure.
Unfortunately, this is comonplace with bindings of badly designed
C libraries, in particular the whole of Unix and most of the standard
C library (all of which are badly designed).
So there is indeed a problem for Felix, because Felix tries
to use a sane designed AND retain compatibility with C/C++
libraries and here there is a conflict created by these two
goals.
Again, I have no good solution, in fact I don't think there is one.
Just for those that missed the problem:
(1) Badly designed C functions modify external state like the file system
and return error codes (i.e. as a return value).
(2) C allows you to ignore return values, without even a cast,
although some programmers shut warnings up with a cast to (void).
(3) Felix does NOT allow you to ignore return values, its a type
error. So you MUST do something with the return value.
(4) If you put the return value in a variable but never access
the variable, the variable is unused and can be elided.
Eliding the variable eliminates the initialiser, and, if it is
a badly designed generator that has external side effects,
then those side effects disappear.
The core of the problem is that the side-effects disappear
SILENTLY.
(5) Even worse, the rules do NOT enforce error checking.
For example:
var e = f1 ( a );
e = f2 ( a);
if e do ...
sure, we checked for an error .. in the call of f2.
But not f1.
So .. i do not particularly like this. Originally Felix did not have
any generators. Adding them solved some problems but
broke a whole lot of principles in the process.
I have no good solution to this either.
I'll examine your proposals in the next email.
Suffice it to say that like quite a lot of other objections raised
by Dobes like uninitialised variables, I agree there are issues
but find no convincing solutions at this time;.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
