It's odd to me that this is an issue because this is possibly the least deep feature of the language – it's literally just a way to put parentheses in less awkward places. But if Ruby's do blocks have any lesson to teach, it's that this relatively small syntax change can make higher order programming appealing and common, rather than niche.
On Mon, Apr 28, 2014 at 6:43 AM, Tim Holy <[email protected]> wrote: > The "do" block syntax was for me one of the more difficult aspects of > Julia's > syntax to wrap my head around, although now I use it frequently. I just > expanded this section of the manual, trying to incorporate elements of this > discussion. > > --Tim > > On Monday, April 28, 2014 12:57:23 AM Peter Simon wrote: > > Going back and rereading the 'open' documentation, it clearly states > that > > the method taking a function as its first argument will apply that > function > > to the file handle returned by the method without the handle. Thanks > for > > your patience. > > > > On Apr 27, 2014 9:41 PM, "Peter Simon" <[email protected]> wrote: > > > Ah, you just switched on the light for me. I thought that the example > was > > > illustrating a general principle, but in fact the essential feature > > > depends > > > on knowledge of the way that the 'open' method is coded. > > > > > > Thanks! > > > > > > On Apr 27, 2014 9:24 PM, "Amit Murthy" <[email protected]> wrote: > > >> The actual function as defined in base/io.jl > > >> > > >> function open(f::Function, args...) > > >> > > >> io = open(args...) > > >> try > > >> > > >> f(io) > > >> > > >> finally > > >> > > >> close(io) > > >> > > >> end > > >> > > >> end > > >> > > >> Just multiple dispatch at work. The 'open' variant without a file > handle > > >> is called first. > > >> > > >> On Mon, Apr 28, 2014 at 9:44 AM, Peter Simon <[email protected] > >wrote: > > >>> Right, I don't have a problem with that. I simply used "inner" as a > way > > >>> to refer to the function that is used as the first argument to the > other > > >>> ("outer") function. Sorry if I abused a conventional meaning of > these > > >>> terms. > > >>> > > >>> I would like to know how this anonymous function (in the "open" > example) > > >>> is passed the file handle. My confusion stems from the fact that > this > > >>> handle, to my knowledge, is not available until the "open" function > > >>> provides it as its return value. > > >>> > > >>> On Sunday, April 27, 2014 8:59:50 PM UTC-7, Amit Murthy wrote: > > >>>> It is just a way to define an anonymous function. It is not a way to > > >>>> define an "inner" function in that sense. > > >>>> > > >>>> On Mon, Apr 28, 2014 at 9:24 AM, Peter Simon <[email protected] > >wrote: > > >>>>> My question concerns where this handle comes from. Isn't the > handle > > >>>>> coming from the output of 'open'? Since 'open' is the "outer" > > >>>>> function of > > >>>>> the 'do' construct, then why doesn't the outer function in the > first > > >>>>> example also supply its output as input to its inner function? > > >>>>> > > >>>>> On Sunday, April 27, 2014 8:40:27 PM UTC-7, Amit Murthy wrote: > > >>>>>> Without using a do-block, you would need to pass in a function as > the > > >>>>>> first argument to 'map'. > > >>>>>> 'open' has a variant where the first argument is again a function > > >>>>>> that accepts an open handle. > > >>>>>> > > >>>>>> The do-block syntax in this case just allows you to define the > said > > >>>>>> function. > > >>>>>> > > >>>>>> On Mon, Apr 28, 2014 at 8:55 AM, Peter Simon > <[email protected]>wrote: > > >>>>>>> In the Julia manual, the second example in > > >>>>>>> block-syntax-for-function-arguments< > http://docs.julialang.org/en/lat > > >>>>>>> est/manual/functions/#block-syntax-for-function-arguments> > contains>>>>>>> > > >>>>>>> the following do block: > > >>>>>>> open("outfile", "w") do f > > >>>>>>> > > >>>>>>> write(f, data) > > >>>>>>> > > >>>>>>> end > > >>>>>>> > > >>>>>>> and the documentation states that "The function argument to open > > >>>>>>> receives a handle to the opened file." I conclude from this that > > >>>>>>> the return value (i.e., the file handle) of the open function is > > >>>>>>> passed to this function f -> write(f, data) that is used as the > > >>>>>>> first argument of open. So far, so good (I think). But now I go > > >>>>>>> back and take another look at the first do block example: > > >>>>>>> > > >>>>>>> map([A, B, C]) do x > > >>>>>>> > > >>>>>>> if x < 0 && iseven(x) > > >>>>>>> > > >>>>>>> return 0 > > >>>>>>> > > >>>>>>> elseif x == 0 > > >>>>>>> > > >>>>>>> return 1 > > >>>>>>> > > >>>>>>> else > > >>>>>>> > > >>>>>>> return x > > >>>>>>> > > >>>>>>> endend > > >>>>>>> > > >>>>>>> I try to interpret this example in light of what I learned from > the > > >>>>>>> second example. The map function has a return value, consisting > of > > >>>>>>> the array [A, B, C], modified by applying the function in the do > > >>>>>>> block to each element. If this example behaved like in the > second > > >>>>>>> example, then the output of the map function should be passed as > an > > >>>>>>> input to the function defined in the do block. Clearly this > > >>>>>>> doesn't happen, so the lesson I learned from the second example > > >>>>>>> doesn't apply here, apparently. Why not? Under what conditions > is > > >>>>>>> the output of the outer function passed as an input to the inner > > >>>>>>> function? > > >>>>>>> > > >>>>>>> I must be looking at this wrong and would appreciate some help in > > >>>>>>> getting my mind right :-). > > >>>>>>> > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> > > >>>>>>> Peter >
