Variables vs functions

Python is not garbage for not inlining trivial functions. A function is a function, when you write one that's what you get. Optimizations are by definition taking liberties with the written code, but this should never be relied on even in a compiled language.

>Are there any languages where functions are mutable?
In C (or any lang with first-class functions) you can have a function pointer and assign a different function to it, but that would be a variable so no applicable here. You can also have self-modifying code and just rewrite program's memory.

>Python is not garbage for not inlining trivial functions.
true, it's garbage for its various design choices. No optimizer in official implementation is one of them.

>duck typing is a garbage design choice
Python would be dead in the water without it.

Many languages have first class functions. Those languages tend to discourage mutability in general, but there are plenty that allow it.
Here is some scheme code demonstrating mutable functions (or rather mutable function bindings)
(define foo
(lambda () 1))
(foo) ; returns 1
(set! foo (lambda () 2))
(foo) ; returns 2

see V8 for reference if you think duck typing prevents something

What do you mean by a language where functions are mutable? You can have function pointers in C/C++ which you overwrite with the addresses of other functions at runtime, including other functions from runtime loaded libraries. You can overwrite functions in Python at runtime too, including with functions you've freshly generated from strings.
You could even do the same thing in C/C++ with some trouble, just receive string C code from somewhere, write it to a file, feed that file to a compiler by executing shell commands, link it into a shared library binary and then load that shared library into your program and access the new functions by their string name. Obviously this is a security minefield if the code you're receiving is untrusted, but in principle it's possible.
You can also use the OS' more direct memory API (if it has one) to provision a memory page marked executable and write bytes corresponding to your platform's assembly language directly into it, then call it from C by casting it to a function pointer.

>he thinks this is about duck typing

t. brainlet

>javascript
No thanks.
def foo(val):
return bar(val)
This function takes an anonymous object, passes it to another function, and returns the resulting object. Basically at no point does the function know what kind of object it's dealing with, nor what it's returning. val could be anything. Only the methods that work on the objects know its type.

but it has enough information to replace calls to foo() directly with calls to bar()

>>javascript
>No thanks.
it's a shit language but best interpreter around

>dynamic languages
High level languages don't have to be dynamic.

even when dynamic, good AOT/JIT can decide to compile an execution path for concrete type based on static or runtime analysis

>literally calling a fucking function to return 0

I don't program in whatever language this is ( I am not a pro either) but it seems to me that the top sets the var x as 0 which could then be added or subtracted from (or any other operation) whereas the bottom one is a clear instruction to always return zero and cannot be altered in any meaningful way except within the function itself, a value that would be lost outside of the function? Maybe I am just to noob to get it.

There are no languages where functions are mutable as a language feature. The closest you can get to this is using a closure generator to set the state of some internal function. So that during runtime you can generate different closures, effectively changing the 'output' of some function for some given input.
But that doesn't change the structure or flow of the function but simply its values.

In fact the only instance of a 'mutable' function would simply be a function that simply calls other functions based on its input where its input can include functions.
If you're talking about arbitrary instruction writing/overwriting then perhaps cyber security might be a path for you.

polymorphism?

OP here. What I really wanted to know is:
is theoretically possible to code without ever making use of variables, but only functions?

for example, the normal declaration/assignment/reassignment of variables looks something like this:

int x=0;
int y=1;
x=1;
x=x+y;

What I wanted to do is to change that into:

int x() [return 0];
int y() [return 1];
x() [return 1];
x() [return x()+y()];

P.S.: sorry idk how to write curly brackets so I used square ones instead...

Attached: hmm.gif (360x288, 3.47M)

yes, this is what the Lambda Calculus is all about.

semantically it's the same thing and if you do that in C, the compiler will optimize that away (I think)
You can play around with the idea here: godbolt.org/
write C code and watch for the differences in assembly output

>I want mutable functions
There goes poor user, rediscovering all the mistakes of computer science past, one dumb idea at a time.

Attached: 1481625047374.jpg (500x360, 151K)

Sounds like you're independently rediscovering lambda calculus. Some languages (e.g. Haskell) don't differentiate a function that takes zero arguments and a constant (this assumes your functions have no side effects, just like a mathematical function).

Everything in Haskell is a function.

You are wrong.

>is theoretically possible to code without ever making use of variables, but only functions?
There is such a magical, mathematical concept as lambda calculus.
In lambda calculus, there are only functions. Functions take functions as arguments and return other functions.
Lambda calculus is the second best known theory of computation, second to Turing machines. It happens that Turning machines were easier to implement, but there exists software implementations of lambda calculus.
And then there's the family of programming languages greatly influenced by lambda calculus, lisp.

>sorry idk how to write curly brackets so I used square ones instead
You could write M-expression lisp with that.

>Some languages (e.g. Haskell) don't differentiate a function that takes zero arguments and a constant
>Everything in Haskell is a function.
Yes, that's exactly what I needed
what other languages do this?

There are no languages where the single, underlying data type is a function. But there are languages where you can pass around functions arbitrarily.
Common Lisp, et al, is one of those languages. I consider it "The C of Functional Languages" because it can be functional but there are no rules that you must do things functionally, e.g. no mutation, can have side-effects, etc.
Haskell is the opposite: it is very restrictive but this has several benefits including being able to reason better about small parts of the code, the code produced is more safe, etc.

As said about a million times already, Lisp is literally lambda calculus on lambda calculus.
Install emacs and have at it

>Some languages (e.g. Haskell) don't differentiate a function that takes zero arguments and a constant (this assumes your functions have no side effects, just like a mathematical function).
And c++!

Unless you use the static keyword it won't optimize in case a separate compilation unit calls it.

int x=0; pushes 0 onto the stack and x is essentially a label representing its address.

Calling the function reserves some space on the stack for the return value, calls the function (along with everything that entails like setting up a stack frame), executes the code in the function, places the return value in the reserved space, then returns (along with everything that entails).

So clearly, one is more performant than the other, assuming no optimization is performed.

what if you enable LTO?

int x(){
int i = 0;
return i;
};

>>based

Have a fun time debugging that crap.

>no languages where functions are mutable as a language feature
technically it is possible in lisp to get the source of a function, change it, and call (read) to redefine the function. Generally not a very good idea to do however.

what the fuck is this question? I'm just gonna close my eyes and pretend this thread does't exist. I really hope this was your goal OP. fuck you. kill yourself.

Stop going over particular calling conventions and claiming that they're fact.
x86-64 ABIs return values in registers.

is this mutating the function or just assigning that symbol a different function?

it would be assigning the symbol to a mutated copy of the function
the only way I can think of mutating the original function would be to doing so in assembly by writing opcodes directly to the function location + offset

yes, that's a pretty cool idea. it would be a cool feature to build into a small compiler to play with but I don't want to take on all that work.
it would need the ability to compile down to machine code and also the ability to arbitrarily move memory as inserting one instruction would move all the others down.
sounds like the beginning of a new operating system.

No, because it will be compiled down to usage of registers which are essentially variables.

>crap
It makes program go fast tho

registers are just inputs to some function. the functions are very simple, but functions nonetheless.

But variables aren't real because it's all transistors and shit

Nigga transistors aren't real because they're all magnets and shit.

wtf

Attached: 1423784690421.jpg (640x631, 114K)