An issue with that is that the indentation if your style of indentation which may not be to everyones liking. (If you ever release it)

My own BASIC auto-indents and I got some very vocal messages over it. Some people have very strong opinions...

Another minor issue I found was with my own TinyBasic - the interpreter chomps leading spaces (at a cost of time) but the input code doesn't (and can't easily) so repeated save/load/save/load will increase the indentation level. i'll fix it one day. Maybe. It'll depend on the save/load means though. If you can save a binary image then good, but if you re-purpose e.g. the LIST command to save it as TEXT then who knows...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Yeah, I appreciate that the indent might not suit all, but it's an easy change; it's just incrementing a counter if it sees an indentable keyword and lines thereafter are indented; the outdents are similar on the matching words (endif, while, next).

This is going to be simple: one instruction to the line (hence the need for endif).

The memory storage is line by line, but the initial line number is compressed to a uint16_t and followed by an eight-bit length byte; then the text: keywords are compressed to single bytes unless they're in quotes; again, for ease of interpretation.

Here's a view of the storage - the lines that say 'line number' aren't keywords so they're stored directly; they're not an error unless they're executed.

But then again, I don't expect anyone except me ever to run this; and I don't expect to run it often! It's more of a learning exercise.

Neil

Rereading your message: if I use list it would save the spaces, then eat them and the line numbers when imported again, and then put back in by the next list command.

(Oh, and for those who like to type in upper case: it's happy with that, but it will always list in lower case because I don't )

Neil

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I would expect that the notion of TABs vs. Spaces and indention levels (or not at all) or if/when to move those braces around has start a good number of religious wars over the years.

One of my primary gripes about Python is that it forces you to indent, and heaven forbid you don't do it the way the interpreter wants you to, or you get a TAB mixed up with a space or something.

'cause you know, it's EASY to see when you have a TAB vs a few spaces in your text editor, right?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That's my major gripe with python - that, and a bizarre syntax which allows, for example, a function to return 3, 7, or "Thursday"...

Neil

TABs (OCCAM, Python, Makefiles), (* ... *) Old BCPL, Braces (C, Modern BCPL, Ratfor, etc.), Begin/End (Algol, Pascal etc.) Start/Finish (imp77) and what not. Something is needed in a structured programming language where blocks of code extend over multiple lines. The holy war here is where do you place them - on the same line, line below at the same indent level, or line below indented. Personally I like my {}s aligned vertically under the controlling statement with the code indented, but 40+ years ago spaces cost both disk space and compile time so removing spaces, using TABs and putting them (begin/end, etc.) on the same line made sense...



Indentation is to replace the block start and end constructs. See above. Also; Programmer are lazy - why type BEGIN or use a { when you can just hit the TAB key...



Why yes, it is. My editor of choice (vim) makes it very easy and even keeps the indentation. I can bind a key to a command that turns it on or off. I'm sure Emacs can do the same.

Note: I'm not a Python programmer - I really don't get it, but I do get the need for some sort of structure in our coding. I was taught that computers should make our lives easier - so in this case, the Python system ought to be able to work out the indentation level based on either spaces OR TABs OR any mixture of the 2 - but seemingly it doesn't. A failing IMO. It's a handful of lines in my own editor to de-tab a file - why can't python do that for you?

My own editor replaces TABs with spaces and the TAB key means: Take the cursor to the column position under the last non space character on the line above, OR move 2 spaces. It floats my boat.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Most decent editors do, but if you're a new programmer (of which I've had to deal with many), with some younger generations, I just get vapid stares when trying to explain the difference between a TAB and a space.



Structure is fine, and I don't have an issue with that, what gets me is that as I recall (from back in the day) the Python developer was intentionally trying to force people to indent in a way that they wanted. Which honestly seems like an absurd reason to make a major design choice in how a language functions; but that's my (not so) humble opinion.

The way I've seen Python's use of significant whitespace is that it aims to link the way we the human readers see the code with the way the computer sees the code. One can squash a C, ALGOL, PASCAL program into a single line (barring preprocessor lines of course.) In those languages, it's the matching braces or BEGIN END words which delineate the structure. And so, it's all to easy to indent the program in a misleading way, which can lead to bugs and to unmaintainable code.

Python code cannot be indented in a misleading way - that's the advantage.

The disadvantage is that we may have different preferences for indentation, including tabs and spaces and including tools which make tabs and spaces difficult to see.

(Another disadvantage is that it's difficult to embed a python program as text within another program or other textual format - there needs to be a way to preserve lines and indentation.)

Remember that Python derives from a teaching language, where the aim is to introduce least new confusion, indeed to reduce confusion. A teaching language is meant to be easy to learn, easy for beginners, and of course easy to teach. These are all good things, but they may not sit well in an environment where everyone is expected already to be an expert and where other considerations are in play.

Well, perhaps not, but there is still the issue of tabs vs spaces and the confusion that can arise therefrom.

We have inherited a curious writing system where white space is metadata (and that applies equally to printed prose).

Neil

My personal preference is never to insert or retain tabs in source code. Tab as a key on the keyboard, which the editor can use to insert an appropriate amount of space, is a good way to go, in my opinion.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I tend to agree. As mentioned earlier, my code ignores spaces between the line number and the first keyword, and indents automatically on list. But it maintains spaces thereafter. It doesn't even know what a tab is at this point.


both take 16 characters (2 bytes for line number, one byte line length, one byte each for 'for' and 'to', the text, and a terminating 0x0a. While

uses five characters fewer - the spaces, ignoring the first.

Neil