Nim: Alloc functions have side effects, makes it hard to use side effect tracking with destructors

[cooldome]

The following function have sideeffects which makes it difficult to use side effect tracking with destructors, new for references does not have sideffects for example:

    proc alloc*(size: Natural): pointer {.noconv, rtl, tags: [], benign.}
    proc createU*(T: typedesc, size = 1.Positive): ptr T {.inline, benign.}
    proc alloc0*(size: Natural): pointer {.noconv, rtl, tags: [], benign.}
    proc create*(T: typedesc, size = 1.Positive): ptr T {.inline, benign.}
    proc realloc*(p: pointer, newSize: Natural): pointer {.noconv, rtl, tags: [], benign.}
    proc resize*[T](p: ptr T, newSize: Natural): ptr T {.inline, benign.} 
    proc dealloc*(p: pointer) {.noconv, rtl, tags: [], benign.}
    proc allocShared*(size: Natural): pointer {.noconv, rtl, benign.}
    proc createSharedU*(T: typedesc, size = 1.Positive): ptr T {.inline, benign.} 
    proc allocShared0*(size: Natural): pointer {.noconv, rtl, benign.}
    proc createShared*(T: typedesc, size = 1.Positive): ptr T {.inline.} =
    proc reallocShared*(p: pointer, newSize: Natural): pointer {.noconv, rtl,benign.}
    proc resizeShared*[T](p: ptr T, newSize: Natural): ptr T {.inline.} 
    proc deallocShared*(p: pointer) {.noconv, rtl, benign.}
    proc freeShared*[T](p: ptr T) {.inline, benign.} 

IMO, it make sense to hide the memory allocation sideeffect for allocation functions as well.
Let me know if you agree with memory allocation hiding idea or not.

[mratsim]

Or maybe add an allocate effect/tag.

This would be useful to have the compiler track allocations for memory restricted devices, parallelism and high performance need. (i.e. detecting a myseq.add instead of myseq[].

This way you can have allocating functions and your side-effect free functions for processing.

Unless assignment is overloaded it shouldn't allocate for non-ref types.

[Araq]

Well you know my opinion about Nim's effect system. ;-)

[alehander92]

If we won't use the effect system, shouldn't it be removed? (I personally want to use it more, but not sure about the +/-s)

[cooldome]

I really like effect system of Nim. It is a bit unfinished/unpolished yet already much better than what other languages provide.

[Araq]

Anyhow, we should do that. Allocation is not an effect.

[alehander92]

I also like the effect system, that's why I hope it can be used for more things, like the @mratsim example.

Allocations are not side effects, but they can be still viewed as effects/tags/resources (either boolean: allocates, doesn't allocate or maybe even richer(it does n allocations/it allocates >= n bytes)). The mechanics of the effect system can kinda model resources: (e.g. boolean: false except if we have a call with such effect/resource, or integer: if we can prove that in each branch the sum of max resources from each call is <= n, the overall sum is <= sum[n])

[krux02]

In my personal opinion, allocation is an unwanted sideeffect that I would want to have tracked if there is an effect system. Allocation is often costly, lots of allocations and deallocations cause memory fragmentation, and big allocations are not returned to the OS. But I know that this opinion isn't compatible with the view on side effects of functions programming languages. It is a conflict that does not have a good solution.

[alehander92]

Maybe effect is not the best name: the Nim effect system can track trackableStuff, there is no reason to not use this machinery for tracking things, that are not effects, only because of the original name of the system.

[krux02]

Well, I know in functional programming, people don't care about memory allocation, Function programming should be free of side effects according to their definition of side effects. This means actual changes in the date. Functional programming works only because functions are allowed to allocate arbitrarily. For real time systems, this is much worse, here it might be much more important to track allocations, and ensure that certain functions only operate in the provided memory area. Mutating the arguments isn't a problem here. Maybe it should be optional (as in a compile time flag) to see allocation as a side effect. But then the discussion remains, what should be the default.

Not sure if my words help you at all, I have far too little experience with the effect system for a qualified answer.

[alehander92]

@krux02 makes good points, I just want to clarify again that we should
differentiate

Side effects
Other effects (tags? trackable function values?)

Allocations are not exactly side effects, but there is no reason to use
nim's effect mechanism for non-functional purposes: in this case func would
just care for side effects, but not for the other effect

On Mon, Nov 26, 2018, 20:15 Arne Döring [e-mail] wrote:

Well, I know in functional programming, people don't care about memory
allocation, Function programming should be free of side effects according
to their definition of side effects. This means actual changes in the date.
Functional programming works only because functions are alloced to allocate
arbitrarily. For real time systems, this is much worse, here it might be
much more important to track allocations, and ensure that certain functions
only operate in the provided memory area. Mutating the arguments isn't a
problem here. Maybe it should be optional (as in a compile time flag) to
see allocation as a side effect. But then the discussion remains, what
should be the default.

Not sure if my words help you at all, I have far too little experience
with the effect system for a qualified answer.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nim-lang/Nim/issues/9746#issuecomment-441741576, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAys-yAJgdrAtg11jGn5vuIIZ0OZT5lGks5uzC_LgaJpZM4YoF3f
.

[andreaferretti]

I agree with @alehander42: we can both track allocations with effects and make func only care about certain effects, of which allocation is not one