Re: [PATCH] Automatic variables

[Andrew Chambers <andrewchamberss@xxxxxxxxx>]

Concern 1:

How to appropriately free a value is very often, but not always linked to
the type of value. You could see this trait as expanding the meaning of a
type from being purely about data layout to being data layout and into the
realm of OO programming, which is a bit of creep.

For example - std.slfree may not always be the correct way to free a
byte[:]. e.g. if you did not want to use the standard library allocator,
but other code has installed this trait for some reason.

Concern 2:

Running code at exit is not purely about cleanup. Perhaps you just want to
increment a global counter, print some text or unlock a mutex. For this go
style defer is superior as you do not need to add boilerplate types to
perform an action, I call this nounifying verbs or objectifying processes
:) .

So...

There are two bits of sugar in this patch:

1. Avoiding copy paste of 'on exit' code, it should appear only once.
2. Automatically knowing the appropriate way to clean up a type so you
don't need to type it everywhere (life is too short).

I think go style defer serves 1. better, but totally ignores 2.

If anything 'auto ' is sugar for:

var x = foo(); defer dispose(x);

where dispose(x) is a generic function taking disposable.

therefore auto is higher level, but less flexible. Perhaps we should just
have both? :)




On Thu, Jul 27, 2017 at 7:01 PM, Ori Bernstein <ori@xxxxxxxxxxxxxx> wrote:

> 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
>
>