[Swift-devel] strange behavior evaluating function call as trace arg

[Mihael Hategan]

On Thu, 2009-02-05 at 11:57 -0600, Michael Wilde wrote:
> Thanks.
> 
> But regarding:
> 
>  >> Getting this into writing in a concise and correct form would be useful
>  >> for gaining a full understanding of Swift and also help in the language
>  >> paper.
>  >
>  > It's useful as far as there is usefulness in people besides us
>  > understanding how Swift works in detail at the expense of our time spent
>  > writing the document.
> 
> ...my intent is not to probe the internals but rather to understand how 
> to *use* the language. Its not how swift works, but how to work with 
> swift. I use it quite a bit and yet I'm continually discovering new 
> things about it, and finding that some of my understandings were incorrect.

In my experience, in particular with Tibi's workflows, understanding how
Swift works leads in most cases to bad results.

It turns out that the best way to use swift is to express the problem
formally and use the publicly defined interface to implement it. It goes
against the C/imperative school of thought, but allowing an automated
system to optimize a problem requires specifying the problem, not "the
way one thinks it works under the hood".

> 
> Thus I find it increasingly important to pin down the language 
> specification in a form that lets users understand it thoroughly. Its 
> not that complex, yet it has many subtleties and surprises, due both to 
> parallelism and to the handling of external data.

Right. Parallelism is one of the issues that should be completely
ignored by a swift programmer. Writing swift code in such a way as to
achieve parallelization in a certain way is, as mentioned above, mostly
going to yield bad results.

This is mostly because we can only achieve proper parallelization if
only a certain level of abstraction is used. That level of abstraction
is the level at which a swift code writer should work at. Perhaps
documentation on that needs improvement, but not circumventing.

> 
> Such a spec is also helpful in discussing changes and enhancements.

That it is.