[julia-users] Re: A non-breaking Julia control-flow change to separate the One language from mortal languages, doomed to die

2015-12-09 Thread Seth
Seems to me that this is just a more complex repeat...until or do...while 
bottom-conditional loop, which has already been discussed and rejected (to 
my disappointment).

On Wednesday, December 9, 2015 at 7:05:43 AM UTC-8, Dan wrote:
>
> *A non-breaking Julia control-flow change to separate the One language from *
>
> *mortal languages, doomed to die
> *
> From a design patterns and DRY perspective it seems `for` loops together with 
> the `break` statement 
>
> are serving as a useful `try`/`catch` mechanism for non-error situations. A 
> common pattern defines 
>
> a variable before a `for` loop and tries to discern, using said variable, the 
> circumstances of exiting 
>
> the `for` loop. Leveraging the embedded mental construct of `try`/`catch` 
> blocks, we can simplify 
>
> this repeating pattern and make it easier and more readable.
>
> The syntax can look as follows:
>
> for ...(loop vars here)... 
>
> ...(local vars here)...
>
> ...
>
> if ...
>
> break 
>
> end
>
> ...
>
> catch 
>
> ...(access local/loop vars and  here)...
>
> 
>
> finally
>
> ...(access local/loop vars here)...
>
> 
>
> end 
>
>   Syntax changes worthy of consideration should be self-explanatory to 
> many, as I hope this suggestion is.
> But an example should help:
>
> After change:
>
> for line in eachline(f) 
>
> fields = split(line) 
>
> status = fileds[2] 
>
> if status=="FAIL" 
>
> break 
>
> end 
>
> catch 
>
> println("Test $(fields[1]) failed with reason $(fields[3])") 
>
> finally 
>
> println("Test successful!") 
>
> end 
>
> Before change:
>
>  
>
> fields = [] 
>
> didfail = false 
>
> for line in eachline(f) 
>
> fields = split(line) 
>
> status = fields[2] 
>
> if status=="FAIL" 
>
> didfail = true 
>
> break 
>
> end 
>
> end 
>
> if didfail 
>
> println("Test $(fields[1]) failed with reason $(fields[3])") 
>
> else 
>
> println("Test successful!") 
>
> end 
>
>   The above example does not use the `break ` suggestion. 
> With multiple `break` circumstances it should
>
> be useful to have separate code for each circumstance. One option is to 
> replicate the `try`/`catch` form 
>
> with a `` passed as ``, another would be to use `catch 
> ` to run catch block 
>
> if "`break  == catch `" (the `` can be a human readable 
> symbol). A direct jump in the 
>
> LLVM code to the appropriate `catch` block would be an easy optimization to 
> implement.
>
> Another issue to consider is the return value of a `for` block. The 
> suggestion above adds the option to change 
>
> the current default `nothing` return with `` in the new optional 
> blocks.
>
> Notice that the `catch` and `finally` blocks are completely optional and 
> therefore backward compatibility 
>
> is easy. Additionally there are no additional keywords and block nesting 
> would not conflict with `try`/`catch`.
>
> Hey, Julia is still < 0.9 so there is still time for some change.
>
> Obligatory Disclaimerism:
>
> 1. This has already been considered before by **name**/**issue**.
> 2. Before suggesting I should have studied past discussions more.
> 3. Other langauges actually already have this... bla bla.
> 4. This post is what it is.
>
>
> This suggestion is also readable in github markdown in the gist: 
> https://gist.github.com/getzdan/75136f130c6f8ffeb60e
>
>
> Feedback/Pointers/Gotchas welcome, of course.
>
>

Re: [julia-users] Re: A non-breaking Julia control-flow change to separate the One language from mortal languages, doomed to die

2015-12-09 Thread Erik Schnetter
One way to convince people that a new feature is worthwhile is to implement
an approximation of the feature, e.g. via a macro. If it then sees
widespread use, you have a strong argument in your favour.

Here's a possibility, using the customary "macro-in-front,
begin-end-around-everything" approach:

@loop begin for i in 1:10
...
if i==8 break end
end
finally
info("did not break")
end

I'm sure the syntax needs cleaning up.

-erik



On Wed, Dec 9, 2015 at 10:47 AM, Seth  wrote:

> Seems to me that this is just a more complex repeat...until or do...while
> bottom-conditional loop, which has already been discussed and rejected (to
> my disappointment).
>
>
> On Wednesday, December 9, 2015 at 7:05:43 AM UTC-8, Dan wrote:
>>
>> *A non-breaking Julia control-flow change to separate the One language from *
>>
>> *mortal languages, doomed to die
>> *
>> From a design patterns and DRY perspective it seems `for` loops together 
>> with the `break` statement
>>
>> are serving as a useful `try`/`catch` mechanism for non-error situations. A 
>> common pattern defines
>>
>> a variable before a `for` loop and tries to discern, using said variable, 
>> the circumstances of exiting
>>
>> the `for` loop. Leveraging the embedded mental construct of `try`/`catch` 
>> blocks, we can simplify
>>
>> this repeating pattern and make it easier and more readable.
>>
>> The syntax can look as follows:
>>
>> for ...(loop vars here)...
>>
>> ...(local vars here)...
>>
>> ...
>>
>> if ...
>>
>> break 
>>
>> end
>>
>> ...
>>
>> catch 
>>
>> ...(access local/loop vars and  here)...
>>
>> 
>>
>> finally
>>
>> ...(access local/loop vars here)...
>>
>> 
>>
>> end
>>
>>  Syntax changes worthy of consideration should be self-explanatory to 
>> many, as I hope this suggestion is.
>> But an example should help:
>>
>> After change:
>>
>> for line in eachline(f)
>>
>> fields = split(line)
>>
>> status = fileds[2]
>>
>> if status=="FAIL"
>>
>> break
>>
>> end
>>
>> catch
>>
>> println("Test $(fields[1]) failed with reason $(fields[3])")
>>
>> finally
>>
>> println("Test successful!")
>>
>> end
>>
>> Before change:
>>
>>
>>
>> fields = []
>>
>> didfail = false
>>
>> for line in eachline(f)
>>
>> fields = split(line)
>>
>> status = fields[2]
>>
>> if status=="FAIL"
>>
>> didfail = true
>>
>> break
>>
>> end
>>
>> end
>>
>> if didfail
>>
>> println("Test $(fields[1]) failed with reason $(fields[3])")
>>
>> else
>>
>> println("Test successful!")
>>
>> end
>>
>>  The above example does not use the `break ` suggestion. 
>> With multiple `break` circumstances it should
>>
>> be useful to have separate code for each circumstance. One option is to 
>> replicate the `try`/`catch` form
>>
>> with a `` passed as ``, another would be to use `catch 
>> ` to run catch block
>>
>> if "`break  == catch `" (the `` can be a human readable 
>> symbol). A direct jump in the
>>
>> LLVM code to the appropriate `catch` block would be an easy optimization to 
>> implement.
>>
>> Another issue to consider is the return value of a `for` block. The 
>> suggestion above adds the option to change
>>
>> the current default `nothing` return with `` in the new optional 
>> blocks.
>>
>> Notice that the `catch` and `finally` blocks are completely optional and 
>> therefore backward compatibility
>>
>> is easy. Additionally there are no additional keywords and block nesting 
>> would not conflict with `try`/`catch`.
>>
>> Hey, Julia is still < 0.9 so there is still time for some change.
>>
>> Obligatory Disclaimerism:
>>
>> 1. This has already been considered before by **name**/**issue**.
>> 2. Before suggesting I should have studied past discussions more.
>> 3. Other langauges actually already have this... bla bla.
>> 4. This post is what it is.
>>
>>
>> This suggestion is also readable in github markdown in the gist: 
>> https://gist.github.com/getzdan/75136f130c6f8ffeb60e
>>
>>
>> Feedback/Pointers/Gotchas welcome, of course.
>>
>>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/


Re: [julia-users] Re: A non-breaking Julia control-flow change to separate the One language from mortal languages, doomed to die

2015-12-09 Thread Dan
Good idea regarding macro.

Not really trying to convince people, just to entice them and gauge the 
response. The traditional method of achieving the same results is OK, but 
I'm just thinking this could be better. Having said all of this, stability 
of a language has much merit as well.

On Wednesday, December 9, 2015 at 6:27:00 PM UTC+2, Erik Schnetter wrote:
>
> One way to convince people that a new feature is worthwhile is to 
> implement an approximation of the feature, e.g. via a macro. If it then 
> sees widespread use, you have a strong argument in your favour.
>
> Here's a possibility, using the customary "macro-in-front, 
> begin-end-around-everything" approach:
>
> @loop begin for i in 1:10
> ...
> if i==8 break end
> end
> finally
> info("did not break")
> end
>
> I'm sure the syntax needs cleaning up.
>
> -erik
>
>
>
> On Wed, Dec 9, 2015 at 10:47 AM, Seth  > wrote:
>
>> Seems to me that this is just a more complex repeat...until or do...while 
>> bottom-conditional loop, which has already been discussed and rejected (to 
>> my disappointment).
>>
>>
>> On Wednesday, December 9, 2015 at 7:05:43 AM UTC-8, Dan wrote:
>>>
>>> *A non-breaking Julia control-flow change to separate the One language from 
>>> *
>>>
>>> *mortal languages, doomed to die
>>> *
>>> From a design patterns and DRY perspective it seems `for` loops together 
>>> with the `break` statement 
>>>
>>> are serving as a useful `try`/`catch` mechanism for non-error situations. A 
>>> common pattern defines 
>>>
>>> a variable before a `for` loop and tries to discern, using said variable, 
>>> the circumstances of exiting 
>>>
>>> the `for` loop. Leveraging the embedded mental construct of `try`/`catch` 
>>> blocks, we can simplify 
>>>
>>> this repeating pattern and make it easier and more readable.
>>>
>>> The syntax can look as follows:
>>>
>>> for ...(loop vars here)... 
>>>
>>> ...(local vars here)...
>>>
>>> ...
>>>
>>> if ...
>>>
>>> break 
>>>
>>> end
>>>
>>> ...
>>>
>>> catch 
>>>
>>> ...(access local/loop vars and  here)...
>>>
>>> 
>>>
>>> finally
>>>
>>> ...(access local/loop vars here)...
>>>
>>> 
>>>
>>> end 
>>>
>>> Syntax changes worthy of consideration should be self-explanatory to 
>>> many, as I hope this suggestion is.
>>> But an example should help:
>>>
>>> After change:
>>>
>>> for line in eachline(f) 
>>>
>>> fields = split(line) 
>>>
>>> status = fileds[2] 
>>>
>>> if status=="FAIL" 
>>>
>>> break 
>>>
>>> end 
>>>
>>> catch 
>>>
>>> println("Test $(fields[1]) failed with reason $(fields[3])") 
>>>
>>> finally 
>>>
>>> println("Test successful!") 
>>>
>>> end 
>>>
>>> Before change:
>>>
>>>  
>>>
>>> fields = [] 
>>>
>>> didfail = false 
>>>
>>> for line in eachline(f) 
>>>
>>> fields = split(line) 
>>>
>>> status = fields[2] 
>>>
>>> if status=="FAIL" 
>>>
>>> didfail = true 
>>>
>>> break 
>>>
>>> end 
>>>
>>> end 
>>>
>>> if didfail 
>>>
>>> println("Test $(fields[1]) failed with reason $(fields[3])") 
>>>
>>> else 
>>>
>>> println("Test successful!") 
>>>
>>> end 
>>>
>>> The above example does not use the `break ` suggestion. 
>>> With multiple `break` circumstances it should
>>>
>>> be useful to have separate code for each circumstance. One option is to 
>>> replicate the `try`/`catch` form 
>>>
>>> with a `` passed as ``, another would be to use `catch 
>>> ` to run catch block 
>>>
>>> if "`break  == catch `" (the `` can be a human 
>>> readable symbol). A direct jump in the 
>>>
>>> LLVM code to the appropriate `catch` block would be an easy optimization to 
>>> implement.
>>>
>>> Another issue to consider is the return value of a `for` block. The 
>>> suggestion above adds the option to change 
>>>
>>> the current default `nothing` return with `` in the new optional 
>>> blocks.
>>>
>>> Notice that the `catch` and `finally` blocks are completely optional and 
>>> therefore backward compatibility 
>>>
>>> is easy. Additionally there are no additional keywords and block nesting 
>>> would not conflict with `try`/`catch`.
>>>
>>> Hey, Julia is still < 0.9 so there is still time for some change.
>>>
>>> Obligatory Disclaimerism:
>>>
>>> 1. This has already been considered before by **name**/**issue**.
>>> 2. Before suggesting I should have studied past discussions more.
>>> 3. Other langauges actually already have this... bla bla.
>>> 4. This post is what it is.
>>>
>>>
>>> This suggestion is also readable in github markdown in the gist: 
>>> https://gist.github.com/getzdan/75136f130c6f8ffeb60e
>>>
>>>
>>> Feedback/Pointers/Gotchas welcome, of course.
>>>
>>>
>
>
> -- 
> Erik Schnetter > 
> http://www.perimeterinstitute.ca/personal/eschnetter/
>