On 27/01/2014, at 11:49 AM, srean wrote:
> Hi John,
>
> whats the intended behaviour for the following (note the use of i).
>
> proc f (i:int, n:int)
> {
> for var i in st upto n - 1 do
> println$ i;
> done
> println$ i;
> }
> f(0,42);
It should be an error, duplicate definition of i (parameter and loop variable).
Parameters are ordinary local variables in the same scope as non-parameters.
Ignoring that it should print the last value the control variable had
before exit, in particular it should NOT go "one past the end".
[So the final i should be n - 1 not n]
The reason for that is simple enough: if you're scanning the full finite
range of some type, you cannot go past the end, it would be an illegal
operation.
But see below....
> I find it a little disconcerting that loop variables can be accessed
> outside.
Standard C. The "var" is just a convenience to avoid
var i:int; for i in ...
which has an uninitialised variable and you have to say its type.
You can jump into a for loop, and an if then else chain. Remember
these are *low level macros* and they're always constructed
with gotos.
You need to understand that Felix does not have "blocks" like C or C++.
Blocks use up the machine stack for local variables, which is what
protects the loop control variable in C++.
Felix hates the machine stack. It prevents use of channels and all other
service calls (because these are implemented by returning control to the
scheduler, which implies the machine stack must hold the return address
of the scheduler).
If you want to you can do this:
begin for var i ... end
begin .. end is a block. more precisely its a procedure which is called
exactly like
{ ... };
in particular it means:
(proc () { ... }) ();
If you do this you can NOT return from the containing procedure, that is:
begin for i in 0 upto 10 do
return; // returns from the begin/end block NOT the containing
function
end;
println "Hello";
> Seems a like an inviting trap for me to fall into.
You're too used to C++. This is standard C. Loop variables are
accessible outside loops, in fact you have to declare them outside
loops. This is useful. You can do this in C++ too.
> Also a
> summary of when are ranges "right" inclusive and when are they right
At the moment ranges are inclusive EXCEPT in string slices which follow
Python.
And the handling of 0 is therefore suspect!
I would like to change all this to be consistent (no matter what it breaks).
The problem is I don't know how. In general a loop which can handle:
(a) empty case
(b) the full range of the type
(c) signed values
(d) unsigned values
(e) both up and down counting
(f) doesn't even make the counter go to an illegal value
cannot exist with just two limits and a single specifier (upto, downto).
C loops can handle it because the user choses the comparator,
but this is fraught with difficulties. Its a common source of error.
And it is very hard to optimise (because such a loop has no semantics).
I have been tempted to do
for i in 0 to n exclusive do ..
for i in 0 to n inclusive do ...
or
for i in [0,n-1) do ..
for i in [0,n-1] do ..
or something (like math ranges) but really the lack of balanced parens there
would
make a serious mess of syntax highlighting.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
