The properties are the following: 1: programs are expressions, not commands 2: functions are values I'm sorry you found this unclear, if I can help I'm here :)

Hi, what specifically do you need help with? If you want an ascii table, google "ascii table" and you will find it

Dashes? Now that's fancy :)

I don't understand what you mean. I define list[n] as "the n-th program that does not use while loops, according to some arbitrary enumeration". The function f(n) = list[n](n) + 1 fits the definition of computable function (because it calls a computable function and applies a computable operation to it), yet by a diagonal argument it is shown not to be in the list. The proof is quite standard, and it is mentioned in several books, among which Godel Escher Bach by Hofstadter, who used a slightly different formalism for the proof: en.wikipedia.org/wiki/BlooP_and_FlooP. The proof also relies on the fact that the set of (finite length) programs that do not use while loops is countable (i.e. it is in a bijection with the naturals), whereas the set of countable functions is not. Therefore, these cannot be in a bijection, hence there are some computable functions that cannot be expressed without using while loops. Edit: Here is a further example of a diagonal argument: en.wikipedia.org/wiki/Cantor's_diagonal_argument Further edit: I probably now understand what you mean. You are saying that making it so that a function in the list can call another function in the list would make the definition circular. It is an understandable objection, and the reason why it is not valid is a bit deep. - As mentioned before, we define the list[n] as "the n-th program that does not use while loops, according to some arbitrary enumeration". - Once we have defined the list, we can define the function f(n) = list[n](n) + 1, and we can ask whether or not such a function is or is not in the list. The one key point is that we're asking *if there is a function in the list that is equal to f*. In order for two functions to be equal, they need not have the same "body", they just need to return the same output whenever provided with the same input. As an example, the two functions "g (x) = sqrt (x^2)" and "h(x) = abs(x)" are not written in the same way, but are **the same function**. So, the function that we are looking for in the list is not one that "calls a list element", but one that behaves in the same manner as the function f(n) = list[n](n) + 1, and is not written using while loops. Is it clearer now?

@@DaedalusCommunity Thanks for you explanation. Now I know where I misunderstood the proof. I mistook the same functions for those with the same body, so i mistakenly thought there's some list[n] call itself and cause infinite recursion. You explained very well. I'm very grateful.

@@dying476 thanks! Your question was very good, too!

Could you make a repo and share your code?

Nevermind. I fixed it. Now i need help with including bin files in c.

kzbin.info/www/bejne/imi4opt6qJ2toJY

👀

Quite :))

I was explaining the usage of "times" to pad the program with zeroes. 3 bytes is the length of the program so far, hence (510 - 3) is the length of the zero bytes we need to pad the program with. These add up, obviously, to 510.

@@DaedalusCommunity Thank you for the quick response! So if I understood you correctly, hypothetically, one could "hard-code" 510, i.e. "times 510 db 0", right? But that would be bad practice, right?

You forgot there's no LIBRARIES.

And no size_t

Yeah a few sequences had definitely too much text. That's what happens when one runs out of ideas for animation :( Thanks for the feedback, I'll try to work on that!

You mean the amount of memory allocated in general?

@@solidnywonsz In C, if you call malloc(), the compiler saves some space in the allocated memory to keep track of how many bytes were allocated in that space. This way, you can call free() without needing to specify how many bytes you want to free, since the compiler already knows.

You can always allocate sizeof(size_t) more bytes, and store the size there, while returning the address just after the size. Free() then looks at ptr-sizeof(size_t) to get size

Yes, we discussed this in another comment. You are correct, with this implementation and using pointers natively defragging is impossible. The solution with an additional indirection level could be implemented in C adding an additional field to the bitmap that holds a pointer to its currently assigned block; in this case the programmer would only keep a pointer to the bitmap entry, and whenever the defrag takes place, the second level of dereference changes. One drawback would be that the memory ends up all jumbled up and the adjacency of blocks would only be virtual.

Yeah smart pointers are pretty cool :) However, this video is more focused on the OS implementation of dynamic memory. Without a kernel malloc implementation, you can't have smart pointers, garbage collection, or pretty much anything else :)

you missed the whole point of the video. dont regurgitate what you have seen online without understanding what it means first 🥺👉👈

@@lack_of_awareness i know the video was talking about a lower level approach, I forgot to mention that in my original comment, but in a more general use case, my comment is still correct

Is it the interpreter? It seems very cool, I'm thinking of doing it too :)

@@DaedalusCommunity I don't think that's the September one, but it seems it is free for now! I'll check it out

JIT

By literally copying each block along with the bitmap values That's why it takes so long, it's not only the pointers. One would need a different approach, like a linked list of tuples (bit, pointer, next) to defrag only the references.

@@DaedalusCommunity At this point, you’re a third of the way through writing a compacting Garbage Collector, you “just” (idk how) need to scan the stack for roots to ensure you update pointers when defragmentation happens

@@DaedalusCommunity I get the copying part, but my point is, that you have a local program that allocates a memory with system or other malloc. In C program the value of pointer won't change by itself and still points to the same memory location, even when the malloc would quitely defrag stuff in the background. Which would make the pointer invalid.

@@Antagon666 Ah yes, you're correct! With this implementation, you just can't defrag :) It's not quite advisable anyway in general, it's best to use a better allocation policy (maybe a las vegas style random algorithm to have a better compromise between fragmentation and time complexity, idk)

@@kgibbershnoxss Yeah, I guess one could extend it enough to apply some form of reference counting. Not the best sort of garbage collection, but better than nothing :)

You're right, some implementations use linked lists as a support structure. It's really a matter of tradeoffs, for example bitmaps offer random access, hence for example one can check if a block is free in O(1) as opposed to O(n) for lists, but a free-space bitmap occupies more space compared to freelists. I've seen both approaches, but I believe that bitmaps lend themselves better as a didactic tool in our case :)

​@@DaedalusCommunityalso a bitmap may allow for some advanced algorithms to cheaply determine best fit. While you can combine continuous blocks of memory in a free list to 1 node requiring a simple O(n) answer to best fit. Rather the complex algorithm could theoretically and or practically outperform the free list is something I think would be interesting to find out.

free lists themselves would require allocations OUTSIDE of your allocator. complicates things. also any type of linked-list structure is usually slow in practice

@@lack_of_awareness The advantage of free lists is that they *do not* require allocations outside the allocator. When a block is free, you can store the metadata in the free chunk of memory itself. And this strategy is used by glibc malloc so it’s definitely not too slow!

@@lack_of_awareness the freelist is usually somewhat deterministic in size as it's (not strickly) coupled to the memory it holds. And the free list is more than capable of governing over itself. About linked structures. Often you can unroll linked structures to a dynamic array and indices cutting the cost past the benefit point. On the fly I could just find gnu libstdc++ stating they are using a freelist. In fact a number of freelists for threads. Therefore I guess the cost of the freelist seems to be outweight by the benefits.

Yes

Paging and segmentation are independent ways to access memory. The relevant difference in this case is that paging is managed by the OS, whereas segmentation must be managed at compile time. In our community OS we have implemented paging, hence we do not use those registers anymore.

In real mode there is an interrupt vector table starting at memory location 0 and consisting of 256 entries that is used to resolve the BOS interrupts. As for teletype mode, it's simply one name of the procedure called by executing int 0x10 with ah = 0x0e.

There are right tools for the job (ocaml for interpreters, matlab/octave for computation...), js is just not the right tool for any job lol

Feelings have no place in science and engineering. Everything you just said is complete nonsense. :-)

Keep learning every day :)

…some of the other threads here have touched on this, but I’m still kind of curious about how using it in everyday situations rather than rarefied ones would be like. I’ll have to think on this/eventually try it, I guess

I think there are two main reasons to use functional languages or featutes. The first one, that I've talked about in other responses, is that functional features make for neater and less error-prone code. If you've ever used rust, you'll know what I mean. Pattern matching is extremely useful even when mixed with imperative-style code; using optionals instead of Null makes it impossible to write code with certain errors, such as null references; using immutable variables (or rules for mutability) also avoids certain errors regarding references. These are real, everyday reasons for using functional features, that improve the quality of life of the programmer significantly. My most common mistakes just vaporized away, leaving me with easier-to-debug code. The second reason is that functional languages can be used as a formal basis to construct languages that look familiar to those acquainted with imperative and OOP languages, but are functional under the hood and come with all the advantages of funlangs. Examples of this are, again, rust, but also the do-notation from Haskell. Other concepts that were borrowed from FP to other languages are typeclasses, which are a much neater way to divide code into classes than traditional classes. These are the same as rust traits. Can't really produce any code examples rn because I'm on the bus, but if you have any questions I'll gladly help :)

@@DaedalusCommunity Rust is a complete abomination. It's a language that patches training wheels to training wheels. Pattern matching is only useful if you have patterns to match, which I almost never do for the programs that I have to write, so that argument is simply user dependent. I have no idea where something like a null-reference would come from. Bu definition a reference always points to a valid memory location. Are you talking about null-pointers? Pointers are simply arbitrary absolute or relative addresses. One can't program hardware dependent software without them. Try writing an operating system without pointers. It's not going to happen. How about something as trivial as a round-robin scheduler? Nope. Not a chance. All you are telling me here is that you have never taken a computer science class and you have also never written a non-trivial program that operates on something beyond user-space.

You can use them in functional programming as well in a way, they're just not quite "variables". E.g. you can do let x = e in e' where e' is an expression that uses x. The main difference is that the value of x is immutable, which is very convenient and is, as you may know, a key feature of rust. The reason I say it's covenient is that using temp variables to move information within your program makes for very error-prone code (especially if you're dealing with pointers and particularly null pointers), whereas you'll find that, if you program in rust or ocaml, there will just be fewer ways in which your code *can* be wrong. You'll eliminate a bunch of kinds of errors that are common for code written in an imperative style.