On 10/12/2012, at 12:58 PM, srean wrote:
>
> I am not disputing that, I no know programming language theory to say
> anything insightful. What I wanter to underscore is to have a syntax that
> will make users situp and pay attention. I for instance almost got lulled
> into complacency that vals are pure constants.
They are. That's the issue in fact. It's not that vals aren't pure constants,
its the fact you can abuse them by making them depend on variables
that change.
Making them depend on variables that do NOT change (after the val
is calculated) is another reason NOT to ban using vars in the RHS
of a val initialiser.
In fact this observation makes it quite hard to even issue a diagnostic
warning. You don't want to be warned when you did something perfectly
sane.
I have been toying with something related:
fun f (x:int) ==> ... pure, not allowed to depend on values
accessor f (x:int) ==> allows variables to be refered to
It seems sane, but it doesn't seem to hold up. You'd just use accessors
everywhere. And the compiler cannot easily check. Vals would become
useless. So there's no point.
The paper from Microsoft Research was more inspiring.
> Duh! Felix current rule is the safe rule!
> The safe rule is the one that tells you that you'd better
> only use vals when you're sure the evaluation strategy
> doesn't matter.
>
> Thats the thing, with C, I would expect that the programmer has done due
> diligence, with Felix I cant be so sure.
Felix is not as safe as a language could be, because performance comes first.
This means you need some attention to detail, and of course you need
to learn which details.
This isn't just true for you. Its true for ME as well.
I regularly make beginner mistakes!
I will try to improve safety. However the way forward IMHO is not
to worry at this time about low level details, but rather to build
some powerful high level abstractions. getting rid of the
low level housekeeping -- letting the parser, library and
compiler do that safely -- is a better way forward at this time IMHO.
Obvious example: get rid of loops by using slices etc .. :)
>
> > Have you thought separating the concerns,
>
> Of course. But it is not so easy. If you separate everything, you get extreme
> complexity.
>
> I see, too bad then.
An example: when Bjarne wanted to get rid of (casts) he make
static_cast
dynamic_cast
reinterpret_cast
const_cast
functional_cast_for_type_conversion (constructor call)
The problem is the factorisation is incomplete and inconsistent.
I use these sometimes but more often than not I use the totally
overloaded C style casts.
> Yeah but not too bad I think, C++ uses it with the pass by reference syntax.
> I dont like it because I cannot be sure at the call instance
Exactly. Which is one of the main reasons Felix doesn't do it.
Felix tells you to pass a pointer instead. Then you see
f (&a)
and you know you're passing by reference.
> , but oh well I can deal with that. So I will still encuouage you to give it
> a thought.
Of course, I have. As indicated below:
>
> I recently did something like this:
>
> f ( var something)
>
> which is supposed to be:
>
> var tmp = something;
> f tmp
>
> and so forces eager evaluation.
>
>
> Thats not bad. May be there should be a 1 character "evaluate it now"
> operator.
We're short of characters! "var" isn't too bad, given it isn't needed very
often.
And you can always explicitly write
var tmp = ...
anyhow. To find out what's *really* important you have to actually write
code. Theorising is fine, but weighting the thoughts requires experience.
It also helps when theorising if there are many people with varied backgrounds.
As in the C++ committee, this wasn't too bad. They stuffed up some things
BIG time, and stuffed up others a bit, and got quite a few things fairly right.
Despite my somewhat negative view of the committee, they didn't do so badly
considering they went way beyond the ISO mandate of "standardising
existing practice".
> oh yeah that one is tricky. Maybe have rules that disallow a particular order
> in which something is evaluated before having been assigned, and then pick
> one of the remaining orders. I guess this is not easy to do, otherwise C++
> should have done this for initializing globals.
Indeed. I thought about automatic re-ordering.
Also, it is possible to have a blanket rule "the programmer
is responsible" but then enforce the rule in some easy
cases. in particular for a sequence of initialisations:
val x = ..
val y = ..
val z = ..
etc Felix can and does do a limited kind of data flow analysis.
>
> These rules allow libraries to be organised arbitrarily. You can
> call any function from anywhere, if you don't like the breakup,
> just move a function from one place to another. You don't have
> to worry about where things are defined. Refactoring is a breeze.
>
> Yeah I can see that it can feel more dynamic, and may make the pythonistas
> happy.
It's much more flexible than Python as far as organisation goes.
BTW: Felix tries to copy some of Haskell, Ocaml/ML, C++ .. and Python.
Since they're the languages I know :) :)
The string literals follow Python.
The lack of char literals follows Python.
Substring operations follow Python too.
Even the comprehensions and iterators are inspired
by Python.
> For example pure functions seem like the holy grail,
> until you realise that they might not be total!
>
> I am not a purity freak, but at the same time I need some level of confidence
> in the semantics. The thing is I am not a smart programmer I make errors, so
> I prefer languages where it is less likely. Its a trade of between that and
> the speed you can get.
Less likely isn't equal to rigid semantics.
Remember, in Felix we have semantic issues at the low level.
But there are strong high level constructions too.
I believe the tradeoff is net positive right now,
and can be improved both by adding new high power
constructions -- such as futures and pipelines which
were added only recently (built on top of fibres and channels
to hide the dangerous stuff), and also by adding diagnostics
and modifying the semantics.
At least one "work in progress" on the latter front is the elimination
of assignment. The idea is that
px <- v;
is a procedure passed a pointer px, and that
x = v
is just sugar for
(&x) <- v;
This seems simple but we have to consider
a . i = 1;
for structure components and arrays too. You cannot reduce that to
&( a. i ) <- 1
because a . i isn't variable so it cannot be addressed. Instead:
(&a . i ) <- 1;
is what we have as the reduction. Now we defined
&a . i
to be a pointer formed from &a by adding the offset i.
But remember x . y is just reverse application:
i (&a)
has to mean that too. If we make this a function call we now risk
a clash with overloading the core meaning with a user defined
function! It happened to me :) :) I mean how do you reduce
f a = expr
The natural reduction:
&(f a) <- expr
doesn't work.
We also have to teach the compiler to *undo*
&a . i <- i
back into an assignment to a particular variable, otherwise we cannot
do various optimisations such as parallel assignments. For example:
x,y = 1,2
can be done with no temporaries by
x = 1
y = 2
but the "default" implementation is:
tmp = 1,2;
x = tmp . 0;
y = tmp . 1;
It's easy to apply parallel assigment when you have assignments but
hard to do it if the LHS is a pointer value (as opposed to the name
of a variable).
**BTW: parallel assignment is an algorithm that handles
a,b,c ... = f (a,b,c), g (a,b,c) ...
by minimising the number of temporaries required. For example
x,y = y,x
can be done with one temporary. This problem is known to
be NP-complete meaning there is no way to do an optimal
solution. Felix uses an algorithm out of a paper that claims
to be reasonable.
> yeah but some help from the compiler that I am not doing something stupid
> would help. So some restrictions on the order of executions, maybe in a
> particular "safe" mode. It wont be totally safe, just safer.
It may. But is it the best thing for me to spend time on?
I will be interested in your opinion AFTER you have been writing some
Felix for a while.
After all people are scared of flying and sharks. But in reality roads
are more dangerous than planes and dogs are more dangerous
than sharks. But people walk along the footpath all the time.
> Oh I see (well I dont, but I believe you when you say it), I naivley assumed
> that it would be possible because it does whole program analysis.
Felix does not do full blown data flow analysis.
It does pattern matching, and some lightweight analysis on sequences
of statements.
Doing data flow analysis is possibe but it is not an easy routine
to write and it is very expensive, if applied only to individual
functions it loses some utilitry and if to the whole program
the O(N^3) calculation time would blow everything out of
the water.
As it is LLVM does data flow analysis of some kind and
it cannot handle more than a few hundred lines of C++
code. I had to cut Felix back to -O1 using clang,
because Felix generates some quite big functions.
[It was taking hours to run the test suite, and almost all
the time was in the C++ compiler, not the Felix compiler,
even though Felix has some horrendously expensive
algorithms and the current compiler is hugely wasteful.]
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
