C is crap

The next time I hear some idiot say ``an array is just a pointer'' I'm going to write an OS in Haskell and remotely install it on their computer.

an array index is just a pointer

A pointer is just an array index.

Arrays and pointers in C is kind of subtle thing that people can easily screw up or misunderstand if they aren't careful

The solution constituted the crucial jump in the evolutionary chain between typeless BCPL and typed C. It eliminated the materialization of the pointer in storage, and instead caused the creation of the pointer when the array name is mentioned in an expression. The rule, which survives in today's C, is that values of array type are converted, when they appear in expressions, into pointers to the first of the objects making up the array.

(https://www.bell-labs.com/usr/dmr/www/chist.html)

And for extra fun, below is an excerpt from the source code to the UNIX 7th edition C compiler (c01.c):

/*
* A mention of an array is turned into
* a pointer to the base of the array.
*/
struct tnode *
disarray(ap)
struct tnode *ap;
{
register int t;
register struct tnode *p;

p = ap;
/* check array & not MOS and not typer */
if (((t = p->type)&XTYPE)!=ARRAY || p->op==NAME&&p->tr1->hclass==MOS
|| p->op==ETYPE)
return(p);
p->subsp++;
*cp++ = p;
setype(p, decref(t), p);
build(AMPER);
return(*--cp);
}

アッラーアクバル

>>5
ユ　メナ　アレイアクバル

The C language didn't even realize what a BOOLEAN was until they officially introduced it in c99 (or was it c98)...

As for writing an OS in Haskell - a clue to you: operating systems have something called side effects, all sorts of them, at all times - Haskell tries to wish away side effects and pretend they can be magically isolated (out of site, out of mind) when obviously this is not the case. Imagine a file system that has no side effects (sorry user, you can't save your file to your hard disk - we don't allow side effects - oh wait, we just implemented a file system using MONADS with our GONADS ten years later after we realized the OS now needs side effects!)

Recursion is just goto.

Goto is just continuations.

>>9
I fucking hate this idiot shit

it's so wrong

so wrong

in super mario bros one for nintendo, a continuation was the pause button on your remote control. You could pause the game and then continue it later. Someone from the Ivory Tower decided to turn this into a programming language feature.

"What are they good for?

There is more to continuations than just a parlour trick to impress Haskell newbies. They make it possible to explicitly manipulate, and dramatically alter, the control flow of a program. For instance, returning early from a procedure can be implemented with continuations. "

GOTO exitlabel;
....
exitlabel: goto considered harmful but ivory tower panzies reinvented the wheel and claimed it as their own.

http://c2.com/cgi/wiki?ContinuationsAreGotos

>>11,12
Time was when neither goto nor anything else was considered harmful.

>>10
Reality is like that. You can't always like it, but it catches onto you, and you end up spewing butthurt on textboards, which doesn't change the fact that continuations and GOTO are the same thing under different names.

>>14
they are not the same at all

>>14
thinking this is proof you don't understand them

>>15-16

Which is essentially what continuations are--GotoStatement?s that are "cleaner" with regard to the underlying machine (goto statements where the label can be saved in a variable).

http://c2.com/cgi/wiki?ContinuationsAreGotos

>>17
no they're not

>>10,15,16,18
thinking this is proof you don't understand them

>>14

Reality is like that. You can't always like it, but it catches onto you

"It's very foolish to think reality is normal." - Terry Davis

>>17
Nice link to Know Your Meme, brogrammer bro.

>>22
check my dubs

>>18-19
Multiple shitposting won't change the fact continuations are GOTOs, samefag.

>>23
it's not shitposting and thye are not gotos

>>23
Some say shitposting shapes one's own reality.
If one shitposts that it's not shitposting and shitposting shapes one's own reality, is it still shitposting?

>>24
You still haven't declared a single difference between continuations and gotos, you just keep shitposting in the hope that that will magically affect reality.

LISP

is Defer in Golang just a goto that goes up, and makes it hard to reason about the prog? In fact pretty much everything is just a goto. Break is a goto, return is a goto, continue is a goto, exit is a goto, exceptions are intraprocedural gotos or COMEFROMS, traps are gotos, HALT is a goto...

Continuations are LISP's alternative to setjmp/longjmp. And they're fine. But it's still not ``goto''.

>>26
difference between continuations and gotos: continuations have natural semantics in terms of the theory of lambda calculus and are relevant to the foundations of computing science, goto doesn't have any theory except in terms of the execution model of instruction pointer based computers

>>28
this is the deluded and confused mind of a "continuations are just goto"-believer. they are not.

>>7

As for writing an OS in Haskell - a clue to you: operating systems have something called side effects, all sorts of them, at all times - Haskell tries to wish away side effects and pretend they can be magically isolated (out of site, out of mind) when obviously this is not the case. Imagine a file system that has no side effects (sorry user, you can't save your file to your hard disk - we don't allow side effects

I know, right? Gets me every time when I attempt to say add two numbers in HASCAL and can't because allocating memory for a new number is a side effect and I need a NOMAD for that. Curses!

I think HASCAL fans need to reevaluate their assumptions if they think that they can add numbers or create lists in their toy language.

>>30

goto doesn't have any theory

This is the kind of ignorant motherfucker who gets a CS degree these days.
You aren't fit to scrub toilets at McDonald's.

>>33
show me the theory?

p.s. http://community.schemewiki.org/?call-with-current-continuation-for-C-programmers

"Not a goto"

reified continuations are much more similar to setjmp/longjmp than goto. Only an idiot would compare them to goto.

if you can implement a continuation in a procedural language and emulate continuations, then goto does have theory, because you just created continuations in C language.... Also just because it has theory behind it doesn't mean it's good. Consider the theory of evolution, which is correct - this doesn't make it good. Evolution requires 99 percent of species going extinct. It's correct, but not good. Haskell means 99 percent of haskell programmers go extinct.

>>34

comparing them to goto was just being nice. Intraprocedural gotos are even worse than local gotos. Comparing them to setjmp/longjmp is being honest, while comparing them to a goto is being nice. But since setjmp and longjmp are also known as intraprocedural gotos with more features, you can in fact use "goto" to describe continuations. You're just using LaynesLaw to try and win an argument, but it's not helping.
See
http://c2.com/cgi/wiki?LaynesLaw

https://en.wikipedia.org/wiki/Setjmp.h

"When a "non-local goto" is executed via setjmp / longjmp ,"

See, people view setjmp and longjmp as non local gotos.. so it's perfectly fine language to say continuations are like gotos, or more specifical non local gotos (intraprocedural).

"non local gotos" is a retard name for something that completely isn't a goto, at all - it's the same idotism that thinks continuations are related to goto.

>>38
You are going to a different part of the code, even worse so than a local goto where at least it is local which is much safer. Someone who continually brings up LaynesLaw has lost the argument, even though they tried to win it.

It goes something like this:
The first stage is denial.
The second stage is..
The third stage is...
Then it is accepted as self evident, that continuations are non local intraprocedural gotos.
Note: the first stage is denial. This is the most important stage.

Any advice on selling a rewrite and/or challenges as one nears 1B daily queries for which Haskell would be uniquely advantageous?

Haskell's just really good at anything enterprise really. Frontend JS, API, traditional web backend. As long as you avoid weird/unpleasant libraries and you're proficient/comfortable in Haskell it can be a great experience. Libraries in Haskell are generally pretty opinionated so you need to make sure you know what you like. HLearn is a good example of that opinionatedness being very fecund but also unusual to people accustomed to more ordinary ML libraries. HLearn is super cool :)

>>30
So continuations are just theoretical semantics for GOTO.

>>34,36,38
The Algol and PL/I goto and Lisp's tagbody/go unwind the stack to the correct point.
These were universally considered to be gotos several years before C or setjmp/longjmp existed.
Landin's paper was about interpreting the goto in Algol 60 in lambda calculus, including non-local gotos, using continuations.

"setjmp/longjmp" had to be invented because C doesn't have nested procedures.
We get to that same thing about limitations in C confusing people again, but this time it's goto.

>>41

--Insert Any Language Here--'s just really good at anything enterprise really.

>>43

In some cases nested procedures seem useful, and are almost like closures.. but they can also encourage hierarchies like OOP trees of this junk inside this junk, inside this, inside this, and your code wiggles off the screen with a bunch of nests. Whereas C code goes down the screen one procedure at a time without any trees of procedures nested in trees of procedures. So I'm not convinced either way that nests of procedures are a good thing, although sometimes they are. Richard Stallman is a fan of nested procedures and allowed C to have them in GCC, if you turn that feature on with a compiler option, I think. I don't know if many people use this feature. Also, Lisp suffers a similar problem of functionsinsidefunctionsinside(functions(insidefunctions))

https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

>>42
that's exactly what they're NOT

>>43
good post

>>47
"Landin's paper was about interpreting the goto in Algol 60 in lambda calculus"

becomes "Landin was an academic trying to justify goto by pretending it was somehow justified inside lambda calculus by moving the goal posts and pretending that somehow gotos could become the emperor in new clothes by renaming them to continuations. All this beating around the bush really meant, that functional programmer were envious of imperative languages so they needed to implement imperative programming into functional programming while pretending that it was still functional."

Wikipedia: "Continuations are the functional expression of the GOTO statement"

that's exactly what they ARE. Bad post.

>>48
If that is what it says then wikipedia is wrong in this case. I'm sooooooooooooooo sorry but even wikipedia can be wrong on occasions.

Anyone citing wikishit as a credible source is trolling.

There are theoretical GOTO is changing the instruction pointer. One generalization is the procedure call which is a GOTO (set the instruction pointer to the function body) that also passes parameters. Half of the time at least one parameter is a continuation. The continuation is implicitly passed at a procedure call unless you code in CPS.

A continuation is a closure - a pointer to instructions and an environment. When procedure foo calls procedure bar, it creates a closure of the local variables and the address of the next instruction, and passes this continuation together with other arguments to bar. When bar is done it calls the continuation with the value(s) it computed, which means that the variable environment of the continuation is entered and the instruction pointer is changed.

A common optimization is to use a stack to allocate the continuation closures. The local variables, the return address and the arguments are pushed when calling a procedure, and the stack and instruction pointers are restored when you return. This works because in most programming languages a callee has a shorter activation duration than a caller, so closure allocation occurs in FIFO order. This also makes some people confuse a continuation and a call stack. A tail-call when a caller doesn't create a closure and instead passes the one it received when it was called.

Another take on continuations come from the actor model. We can consider a function call to be the creation of an actor, where the parameters form a message and the function body its script. Then the act of returning from a procedure is passing a message back to the parent actor. Each actor has one parent (the one that created the actor) and can create zero or more child actors. An actor receives one message from its parent and sends one message back.

Each actor has its own instruction pointer that advances independently from others. Potentially actors could act in parallel, but in practice a parent almost always waits for a child to respond before continuing. This means that only one actor runs at a time, and every other actor waits for its child to respond.

Also in this case is it possible to allocate actors on a stack. When an actor is created we save the instruction pointer of the current actor on the stack along with the message we send to the child and begin executing the script of the child. When we send a message back to the parent we save the return values in a designated location and restore the parent's instruction pointer.

A continuation in the actor model is an actor waiting for a child to respond. If an actor A passes a reference to its parent as part of the message when it creates a child actor, then the child actor can send a message to the actor A's parent directly, bypassing A entirely.

We can also interpret first class continuations in this context. It is an actor that waits for a message from any actor that happens to know of it.

"At its heart, call/cc is something like the goto instruction (or rather, like a label for a goto instruction); but a Grand High Exalted goto instruction... The point about call/cc is that it is not a static (lexical) goto instruction but a dynamic one (David Madore's A page about call/cc)" --HaskellWiki

But I guess anything from a "wiki" is considered trash by the progrider "experts". Since haskell uses a wiki for a lot of their documentation, that must mean haskell is trash (sarcasm)

>>53
You're confusing Wikipedia with MediaWiki, which is like saying because one book is garbage then anything from a printing press must be. Fucking moron.

dubs

>>53

The point about call/cc is that it is not a static (lexical) goto instruction but a dynamic one

Those are usually called exceptions (but not the only kind of exception).

>>53

letting hasktards explain anything

heh

>>57
Whom are you quoting?

Are there any other contexts where an array identifier doesn't decay into a pointer of its first element than sizeof arr and &arr?

>>59
No.

I think much of the confusion wrt arrays and pointers that novice C programmers have is that books and lectures tend to conflate the concepts of identifiers, objects and types. Every object has an address, whether they have automatic, static or dynamic extent. An identifier for a variable is a symbol that refers to an object. Text, like natural language, is serial so we give names to things so that we can easily refer to them. But the identifier is not the object.

Using the address of operator we get a pointer value that refers to the object. Now we can use either the identifier or the pointer to access the object, but neither of them are the object.

An array is a type, which signifies that the object is large enough to hold N elements of type T. We can use the name (identifier) of the array with to refer to the object, but there is very little we can do with an array (sizeof/alignof, and address of). Instead we operate on it through pointers, and the compiler makes this convenient to do. But the array type is not the object, the pointer to the first element is not the object and the identifier is still not the object.

But maybe this is too hard to learn during your first exposure.

>>1
An identifier referring to an array, under some circumstances, is treated as a pointer to the first element of an array. Likewise, ANY pointer can be dereferenced using array notation, ptr[5] means to read data at an offset of 5 * (sizeof whatever data type the pointer is using) from the pointer itself.

However, it's important to know that arrays are allocated on the stack like ordinary non-global, non-static variables, not on the heap like the blocks returned by a call to the standard memory allocation function malloc(). Because of this, you cannot declare an array within a function, and then return it to the caller via pointers - when the function returns, the array will go out of scope and be destroyed, leaving you with a pointer to nothing (i.e. undefined behavior). Arrays instead can be thought of as using the alloca() allocator, which allocate data on the parent function's stack.

So
int * getarray(void) {
int a[5];
return a;
}
and
int * getarray(void) {
int * a = alloca(5 * sizeof (int));
return a;
}
basically do the same thing (though the first will issue a compiler warning, due to the implicit conversion of an array to a pointer, which is clearly suspicious if it happens while returning a local variable). And neither will do the obviously intended behavior of usefully returning a pointer to an array. What would do that is
int * getarray(void) {
int a * = malloc(5 * sizeof (int));
return a;
}
This works because malloc() allocates memory on the heap, not the stack, and so it persists even when the function goes out of scope.

>>7
Not having a boolean type != not knowing what a Boolean is. Having an explicit boolean type in a language where the smallest unit of storage is the byte is silly anyway, unless it's implemented as bitfields and packed so _Bool bools[8] takes up one byte. As long as you have a sane way of handling numerical values as input to the if statement or similar, there's no need for explicit booleans.

>>8
Everything is goto, jump/branch is the only control flow statement found in most instruction sets, and it's basically a goto. Even C, which tries to divorce itself from the goto statement, uses it directly in its switch statement. And if "for", "while", "do", "switch", and "case" were removed from the language, you could duplicate their functionality with gotos.

Even function calls are gotos, paired with a stack to hold local variables and a return address. The old GOSUB statement in BASIC was basically a primitive version of that: store the current line number in a special variable, GOTO the beginning of a subroutine, and when you hit RETURN go back and pick up where you left off. Later on a single variable to hold return addresses was replaced with a stack to allow nested subroutine calls, then finally the stack allowed functions to hold their own local variables in the stack as well. Ultimately, it's still all GOTOS though.

Does LISP have an equivalent to 'computed goto'?
https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

>>63
in implementations that use a CPS transform, all function calls are equivalent to goto, so all functions are equivalent to "labels as values".

in implementations that implement proper tail calls but not a CPS transform, all function calls in tail position are equivalent to goto.

>>64

all function calls are equivalent to goto

this is completely false, why do you keep saying this?

>>64

function calls in tail position are equivalent to goto

no they are not

every instruction that affects control flow is equivalent to goto. to solve this problem, we should compile everything with the only acceptable compiler: movcc

>>63
Not that I'm aware. That's a bitch of a feature to add to a language whose GC can move code blocks around in the middle of execution. I presume that's also a GCC-specific feature? Leave it in statically compiled languages.

>>68
Its actually a FORTRAN feature.
https://en.wikipedia.org/wiki/Computed_goto#Computed_GOTO_and_Assigned_GOTO

>>65
Function calls are a specific mechanism implemented with goto. In addition to executing GOTO to the start of the function code, it also pushes the current instruction address onto the stack, and also reserves sufficient space in the stack frame for all the function's local variables. When the function returns, the local variables are deallocated and the return address is popped off the stack and assigned to the instruction pointer, so execution can pick up where it left of.

>>66
They are, with tail-call optimization. Tail recursion provides functionality equivalent to a loop, while if unoptimized will use up unnecessary stack space. TCO transforms it into a loop, which is implemented in machine code with a jump or branch instruction, which is the same as a GOTO.

>>68

I presume that's also a GCC-specific feature?

It's a GNU extension, so not part of any C standard. TCC supports it as well, but most C compilers do not. And the standard switch statement can be considered a form of computed goto.

>>66
why did you cut off the first part of that sentence?

in cps, function calls are implemented with a goto

>>70

TCO transforms it into a loop, which is implemented in machine code with a jump or branch instruction, which is the same as a GOTO.

No. TCO doesn't transform anything into a loop, it transforms a call into a jump. If it's a jump to the current function, that effects a loop. If it's a jump to any other function, it's not a loop.

If you can only transform calls to the current function, your language is SHIT.

>>68
In languages with proper tail calls, a function value is equivalent to "labels as values".
Dumb shitposter

>>70
no they are not.

>>71
"function calls are implemented with a goto" is true, but they are not gotos.

"tail calls are gotos" is the kind of idiotism i expect on reddit and hacker news, not /prog/. nu/prog/ is much stupider than old/prog/, back when we were on 4chan. It's disappointing.

All branching constructs are just gotos with additional features added.

(stopping the dubsquatter from dubsquatting)

dubs+1

>>72
Tail recursion is different from tail call optimization, in that the stack frame can be handled differently between the two. Tail recursion can work with the new parameter values in-place.

>>79

Tail recursion can work with the new parameter values in-place.

which is a poor implementation

proper tail calls should be implemented by garbage collecting unecessary stack frames ala chicken

>>80
what you said is daft

why should it be done your favorite way? thats just one way of implementing this..

>>80
That is demonstrably the most shit way of implementing it. Why the fuck would you eliminate all possibility of optimization? Especially when tail recursion is used for inner fucking loops!