Another case for open()!, I suppose, is the construction
fd, process = open(`command`)
which I wasn't able to fit in the do-block construction.
---david
On Tuesday, June 21, 2016 at 5:43:36 PM UTC+2, Stefan Karpinski wrote:
>
> I was not aware that you could do multiple `as` clauses on a single `with`
> line – that makes the construct considerably more useful since it reduces
> the indentation. However, it still doesn't address cases where you don't
> want to give the object to be finalized a name, e.g.
> readstring(open("file.txt")!), which we currently express with the somewhat
> awkward open(readstring, "file.txt") idiom.
>
> On Tue, Jun 21, 2016 at 11:25 AM, David van Leeuwen <[email protected]
> <javascript:>> wrote:
>
>> Hello,
>>
>> On Monday, June 20, 2016 at 5:38:04 PM UTC+2, Stefan Karpinski wrote:
>>>
>>> The reason as Cedric points out is that the do block syntax is just
>>> sugar for an anonymous function body. There is a plan to provide a more
>>> convenient mechanism for ensuring finalization: #7721
>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fissues%2F7721&sa=D&sntz=1&usg=AFQjCNFvIk415gxqk8bmc7yh5IjJ917dkQ>.
>>>
>>> So, pending syntax debating, you'd write this instead:
>>>
>>> Thanks for the link, I recall I had stumbled upon the discussion a while
>> ago
>>
>>
>>> fd = open(file)!
>>> a = read(fd, ...)
>>> b = read(fd, ...)
>>> # finalize(fd) called when the scope ends
>>>
>>>
>>> That would be great, also for simultaneous reading/writing of multiple
>> files as you wrote in the discussion.
>>
>>
>>> This would significantly reduce the number of situations where the do
>>> block syntax is used for straight-line code, which I think largely
>>> eliminates this issue.
>>>
>>> I believe in Python (which I only started using after Julia) you can say
>>
>> with open("one") as one, open("two", "w") as two:
>>
>> Cheers,
>>
>> ---david
>>
>>>
>>> On Mon, Jun 20, 2016 at 10:35 AM, Cedric St-Jean <[email protected]>
>>> wrote:
>>>
>>>> I'm not sure why assignments are local, but I'd guess that it's for
>>>> consistency. function foo(x, y) ... end is syntactic sugar for foo =
>>>> (x,y)->..., and likewise do syntax is also sugar for creating a function
>>>> and passing it as the first argument. Since
>>>>
>>>> function foo(x)
>>>> a = x
>>>> end
>>>>
>>>> does not modify foo's parent scope (the global scope), it seems
>>>> reasonable that local functions (do blocks) shouldn't modify their parent
>>>> scope either. Here are other ways of writing the code you quoted:
>>>>
>>>> local a, b
>>>> open(file) do fd
>>>> a = read(fd, ...) # will modify a and b in the parent scope
>>>> b = read(fd, ...)
>>>> end
>>>>
>>>> comprehension = map(collection) do i
>>>> ## compute element[i]
>>>> element
>>>> end
>>>>
>>>> Best,
>>>>
>>>> Cédric
>>>>
>>>>
>>>> On Monday, June 20, 2016 at 7:54:10 AM UTC-4, David van Leeuwen wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I regularly make the mistake described here
>>>>> https://groups.google.com/d/msg/julia-users/UyCSm5Shyww/Udt67boT3CsJ,
>>>>> i.e., i write
>>>>>
>>>>> open(file) do fd
>>>>> a = read(fd, ...)
>>>>> b = read(fd, ...)
>>>>> end
>>>>> ## a and b undefined.
>>>>>
>>>>> I get that the solution is
>>>>>
>>>>> a, b = open(file) do fd
>>>>> ...
>>>>>
>>>>> Great. I understand that you would want `fd` to be local, is this the
>>>>> reason that every assignment is local?
>>>>>
>>>>> If `a, b = open() do ... end` is the recommended way of dealing with
>>>>> this, I wonder if this approach could generalize to the for-block
>>>>>
>>>>> comprehension = for i in collection
>>>>> ## compute element[i]
>>>>> element
>>>>> end
>>>>>
>>>>> as a multiline alternative to the [element for i in collection]
>>>>> syntax.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> ---david
>>>>>
>>>>
>>>
>
