Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alloc functions have side effects, makes it hard to use side effect tracking with destructors #9746

Closed
cooldome opened this issue Nov 18, 2018 · 11 comments

Comments

Projects
None yet
6 participants
@cooldome
Copy link
Member

commented Nov 18, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

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

@alehander42

This comment has been minimized.

Copy link
Member

commented Nov 22, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Nov 25, 2018

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

@Araq Araq added the RFC: Accepted label Nov 26, 2018

@Araq

This comment has been minimized.

Copy link
Member

commented Nov 26, 2018

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

@alehander42

This comment has been minimized.

Copy link
Member

commented Nov 26, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Nov 26, 2018

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.

@alehander42

This comment has been minimized.

Copy link
Member

commented Nov 26, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Nov 26, 2018

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.

@alehander42

This comment has been minimized.

Copy link
Member

commented Nov 26, 2018

@andreaferretti

This comment has been minimized.

Copy link
Collaborator

commented Nov 27, 2018

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

@Araq Araq closed this in e1d17ec Mar 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.