Re: [PATCH] Automatic variables

[Ori Bernstein <ori@xxxxxxxxxxxxxx>]

Thanks for doing the work!

In general, this kind of thing is something that should
definitely exist in the language. I've pushed this patch to a
new `autovar` branch so that we can play around with it, and
try improving our lives in existing code to see how it plays
out.

As is, it looks like a step forward over what exists, but
I'd like to see some code written to take advantage of it,
and get a feel for the way it goes together.

On Wed, 26 Jul 2017 18:28:24 +0000, Quentin Carbonneaux <quentin@xxxxxx> wrote:
> 
> The idea is that every "binder" of the language (var/const/
> fn args/match) offers the possibility to mark the variables
> it binds as "automatic" using the 'auto' keyword.

As I read this and think about it, I'm wondering if it makes
sense to generalize this and move towards treat `auto` as a
region hint, and allow regions to affect the selection of
traits. So, for example:


	trait disposable byte[:] $auto =
		const __dispose__ = {v
			std.slfree(v)
		}
	;;

would only apply to auto region variables. I think Cyclone may
serve as inspiration. I'm worried that it may become overly
complex, although if we punt up on guaranteed soundness we may
be able to simplify the system a lot.

If this does end up being something we decide is worth
exploring, I think we can get there incrementally from
this patch.

> 
> ~ Example Programs
> ~~~~~~~~~~~~~~~~~~
 
> 	const g = {auto x
> 		-> x++ - 1
> 	}
 
It seems a bit odd to me to allow `auto` on function
parameters, since I kind of think of destruction as paired
with an allocation and (at least in Myrddin) passing
arguments doesn't imply that.

I'm not against this, but I'm wondering if you had a specific
use case in mind.

> The following example shows that, using an ad hoc type,
> it is possible to execute arbitrary code at the end of
> a scope.

Theoretically, it doesn't even have to be an ad hoc type; the
impl can go over the function directly, and the cast can be
dropped. (This may hit a long-standing bug -- I'll have to
check and fix that.)

> ~ Discussion
> ~~~~~~~~~~~~
> 
> Multiple alternatives exist for resource management, and
> hopefully this mail starts an interesting debate.
> According to me, here are the pros and cons of the current
> proposal:
> 
>   - PROS -
> 
>   * Opt-in
>   * Backward compatible
>   * Simple
>   * The spirit of C's original auto
>   * It has an implementation
> 
>   - CONS -
> 
>   * No safety guarantees/compiler checks whatsoever
>   * Syntactic pollution: 'auto' keyword, 'disposable' trait

* Only one possible trait implementation for `auto`. This
  means no custom allocators can be with auto, for example.

* Discussion on IRC has hinted that it may be undesirable for
  libraries to provide default implementations of this, as I
  recall. I haven't fully read the scrollback here. (ac, care
  to summarize?)

* Syntactically heavy to implement a disposable trait, making
  it harder than necessary to do general scoped cleanup.

For the first issue, I don't think there are any semantic
difficulties with allowing scoping and shadowing traits. The
practical limitations are around name mangling in the
compiler, which should be surmountable.

The example I've given in the past was hash tables:

	const mkstrtab = {
		impl hashable byte[:] =
			/* case sensitive impl */
		;;
		-> std.mkhtab(hash, eq)
	}

	const mkistrtab = {
		impl hashable byte[:] =
			/* case insensitive impl */
		;;
		-> std.mkhtab(hash, eq)
	}

But this may be another place where this comes in.

> ---
>  mi/flatten.c    | 179 ++++++++++++++++++++++++++++++++++++++++----------------
>  parse/dump.c    |   1 +
>  parse/gram.y    |  15 +++--
>  parse/infer.c   |  32 +++++++++-
>  parse/parse.h   |  13 ++++
>  parse/stab.c    |   4 ++
>  parse/tok.c     |   1 +
>  parse/trait.def |   1 +
>  parse/type.c    |  30 ++++++++++
>  9 files changed, 219 insertions(+), 57 deletions(-)

Not going to comment on the code right now, other than to say
that I like it!

-- 
    Ori Bernstein