On 27/01/2014, at 1:56 PM, srean wrote:
>
> Thanks for the explanation.
>
> 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.
>
> I know and I like C++'s choice on this one. I really appreciate the tighter
> scope discipline it allows.
Only sometimes. Other times is a PITA, for example in a binary search.
But then you can declare the variable outside the loop.
Fact is block structure scoping sucks BIG TIME because it forces
uninitialised variables:
int i;
{
int k = 0; while (k<20) k = 2 * k;
i = k;
}
whereas ML let is vastly superior:
let i =
let var k = 0 in
while (k<20) k = 2 * k
in
k
in
(using C code but ML scoping).
>
> This is useful. You can do this in C++ too.
>
> Sure. One can access variables defined outside, but love the ability to put
> my precious variables in silos without much fuss. Also the fact that this is
> considered normal.
Today. It's a new feature. I was around when it was added :-)
in any case
for v in range (0,10) do
...
done
does hide v :) but this is a high level construction (using streams
and iterators).
It is of course possible to hide the control variable in a loop *without*
using a block, but I'd have to figure out how. Either change the compiler,
which currently doesn't recognize what a loop is (defined in user space
in the parser), or, add some scope control constructions (that don't
imply blocks).
>
> 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).
>
> Is it correct to say that apart from (c), (d) and (f)
> STL's half open intervals handles all the rest ?
No idea what they are ..
>
> As long as the loop variable is not 'dereferenced', isnt (f) safe ?
>
> for i in [0,n-1) do ..
> for i in [0,n-1] do ..
>
> This is pretty. Drooling already! As you said, syntax highlighting would be a
> mess.
You'd probably like
for i in { x | 0 <= x and x < 100 } do ...
or perhaps less verbose
for 0 <= i < 100 do
for i in 0..99 do
for i in 0:100 do
there are lots of possibiities, none of which are any good :)
the simplest is:
for var i = 0 while i < 100 next ++i; do
which is precisely the C for loop. Or
for var i = 0 until i == 100 next ++l; do
(the same but with negated condition).
==============
There are other inconsistencies in Felix. One of them is
let ?x = 1 in ... // pattern match
var x,y = 1,2 .. // that's ALSO a pattern match
fun f(x:int, (y:int,z:int)) // NOT allowed but should be
Ocaml is better. All function arguments are pattern matches,
as are all let bindings. Much cleaner.
--
john skaller
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
