Currently, all memory a program written in kredenslang can access is one integer accumulator (size is implementation-dependent). This is acceptable if we don't expect the language to be particularly useful. However, given the community's desire for kredenslang to feature Turing completeness (see #1), it could be beneficial to consider including a mechanism for utilizing an arbitrarily large amount of memory. This could be done in various ways.
The simplest solution is to use an unbounded tape and a pointer to the current cell. This approach is close to the solution used by Brainfuck and can be easily added to our language while maintaining backward compatibility by modifying existing instructions to affect the currently pointed-to cell instead of the accumulator and adding instructions for moving the pointer.
For maximizing the utility of the language and making it easier to work with, the introduction of variables may be helpful. However, this introduces the necessity for multiple design decisions related to, for example, handling types.
Of course, there are many different ways to design memory access in a language; the sky's the limit here. Therefore, I invite everyone to share their thoughts on a suitable memory model for kredenslang.
Currently, all memory a program written in kredenslang can access is one integer accumulator (size is implementation-dependent). This is acceptable if we don't expect the language to be particularly useful. However, given the community's desire for kredenslang to feature Turing completeness (see #1), it could be beneficial to consider including a mechanism for utilizing an arbitrarily large amount of memory. This could be done in various ways.
The simplest solution is to use an unbounded tape and a pointer to the current cell. This approach is close to the solution used by Brainfuck and can be easily added to our language while maintaining backward compatibility by modifying existing instructions to affect the currently pointed-to cell instead of the accumulator and adding instructions for moving the pointer.
For maximizing the utility of the language and making it easier to work with, the introduction of variables may be helpful. However, this introduces the necessity for multiple design decisions related to, for example, handling types.
Of course, there are many different ways to design memory access in a language; the sky's the limit here. Therefore, I invite everyone to share their thoughts on a suitable memory model for kredenslang.