BASIC - more harmful than useful?

Drop in for a chat and a cup of tea

899 posts   Page 27 of 36   1 ... 24, 25, 26, 27, 28, 29, 30 ... 36
by abishur » Mon Feb 04, 2013 5:31 pm
-rst- wrote:Abishur's idea about extending Nano sounds like worth taking a look. Or could we have a CLI version of IDLE (defaults to interactive mode, but easy way to open/save files)?


My initial research has shown that nano lacks the ability to run bash commands from within itself (which was how I was planning on doing it) vi has this ability, but in my opinion, vi is unsuitable as there are far too many key combinations to have to remember just to do basic operations with it. I'm trying to see if there's some modification to the source code I could make that would let it run bash commands (there should be right?), but it's admittedly low on my project list. I've thought about having it boot on of the gui IDE's as that loads much faster than full on X11... but I'd kinda like to keep it at the CLI level.
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4326
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by gordon@drogon.net » Mon Feb 04, 2013 5:36 pm
abishur wrote:
-rst- wrote:Abishur's idea about extending Nano sounds like worth taking a look. Or could we have a CLI version of IDLE (defaults to interactive mode, but easy way to open/save files)?


My initial research has shown that nano lacks the ability to run bash commands from within itself (which was how I was planning on doing it) vi has this ability, but in my opinion, vi is unsuitable as there are far too many key combinations to have to remember just to do basic operations with it. I'm trying to see if there's some modification to the source code I could make that would let it run bash commands (there should be right?), but it's admittedly low on my project list. I've thought about having it boot on of the gui IDE's as that loads much faster than full on X11... but I'd kinda like to keep it at the CLI level.


And before you know it, you end up with emacs ;-)

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1544
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by jamesh » Mon Feb 04, 2013 5:53 pm
DavidS wrote:Perhaps it is time to begin a thread on compiler design? It is part of CS so I feel hat it is a topic that needs to be addressed for the RPi.


Why? There are surely many sites out there dedicated to compiler design that could cover it much better - especially since there is nothing specifically Pi related in compiler design.

I never did compiler design as part of my CS degree btw! Not sure there was even a course on it at UEA when I was there, but then I did concentrate on graphics.

Eben might disagree - his PhD was in compiler stuff!
Volunteer at the Raspberry Pi Foundation, helper at Picademy September, October, November 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12343
Joined: Sat Jul 30, 2011 7:41 pm
by abishur » Mon Feb 04, 2013 7:42 pm
gordon@drogon.net wrote:
abishur wrote:
-rst- wrote:Abishur's idea about extending Nano sounds like worth taking a look. Or could we have a CLI version of IDLE (defaults to interactive mode, but easy way to open/save files)?


My initial research has shown that nano lacks the ability to run bash commands from within itself (which was how I was planning on doing it) vi has this ability, but in my opinion, vi is unsuitable as there are far too many key combinations to have to remember just to do basic operations with it. I'm trying to see if there's some modification to the source code I could make that would let it run bash commands (there should be right?), but it's admittedly low on my project list. I've thought about having it boot on of the gui IDE's as that loads much faster than full on X11... but I'd kinda like to keep it at the CLI level.


And before you know it, you end up with emacs ;-)

-Gordon

:lol:
Dear forum: Play nice ;-)
User avatar
Forum Moderator
Forum Moderator
Posts: 4326
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
by rurwin » Mon Feb 04, 2013 8:51 pm
It seems to me that you need the ability to edit source code and issue commands. Those are two modes and two windows, unless you go back to line numbers. You [i]can[/u] do "windows" in text mode; standard FORTH has the top two thirds of the screen as an editor window and the bottom as a scrolling command window. Something like that should be possible. On a GUI you end up with something not unlike IDLE, but hopefully smoother. Of course the GUI environment fights with having a command-line; it likes stuff on menus.
User avatar
Forum Moderator
Forum Moderator
Posts: 2946
Joined: Mon Jan 09, 2012 3:16 pm
by Bakul Shah » Mon Feb 04, 2013 10:51 pm
rurwin wrote:It seems to me that you need the ability to edit source code and issue commands. Those are two modes and two windows, unless you go back to line numbers. You can do "windows" in text mode; standard FORTH has the top two thirds of the screen as an editor window and the bottom as a scrolling command window. Something like that should be possible. On a GUI you end up with something not unlike IDLE, but hopefully smoother. Of course the GUI environment fights with having a command-line; it likes stuff on menus.

Check out this tutorial on the acme editor. You can type anywhere in an acme window. Commands are executed simply by selecting their text and clicking the middle mouse button. Acme provides a menu line for convenience but really you can type any command anywhere and execute it.
Posts: 293
Joined: Sun Sep 25, 2011 1:25 am
by DavidS » Tue Feb 05, 2013 12:28 am
jamesh wrote:
DavidS wrote:Perhaps it is time to begin a thread on compiler design? It is part of CS so I feel hat it is a topic that needs to be addressed for the RPi.


Why? There are surely many sites out there dedicated to compiler design that could cover it much better - especially since there is nothing specifically Pi related in compiler design.

I never did compiler design as part of my CS degree btw! Not sure there was even a course on it at UEA when I was there, but then I did concentrate on graphics.

Eben might disagree - his PhD was in compiler stuff!

Yes there are plenty of sites that cover the topic, though they are either incomplete, or scattered, or point to one of the three well known books as a reference (and these are expencive [I have all three]).

As to the idea of a thread:
Traditional compiler design topics focus on the advanced progrmmer. The RPi does not focus on that level, and once a kid is familiar with assemby language they could learn compiler design (if taught correctly). The need is more of ironing out the questions of how to teach this to a 12 to 14 year old kid in a class room settig.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by pygmy_giant » Tue Feb 05, 2013 12:33 am
You should call the thread 'Kiss my Parser'
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by DavidS » Tue Feb 05, 2013 12:38 am
pygmy_giant wrote:You should call the thread 'Kiss my Parser'

:-) Thank you, needed a good laugh. Though that would talk to the point. KISS is the philosophy that would be needed. Start with a simple typed language and a recursive decent parser type compiler, then once this is passed (3 to 4 weeks?), move on to some form of simple tree parser. Spend the rest of he year on some of the simpler optimization techneques. Though as to the detais I am not sure.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by tufty » Wed Feb 06, 2013 8:56 am
DavidS wrote:Start with a simple typed language and a recursive decent parser type compiler

I beg to disagree. You want to leave parsing right out of it, and start by working on the syntax tree direct. Something lisp-like, a language that's already expressed in terms of a syntax tree, would be the best place to start, and make it obvious that compiling is, in fact, merely a sequence of source->source transforms.

Parsing is hard.
Posts: 1375
Joined: Sun Sep 11, 2011 2:32 pm
by -rst- » Wed Feb 06, 2013 10:27 am
gordon@drogon.net wrote:
abishur wrote:
-rst- wrote:Abishur's idea about extending Nano sounds like worth taking a look. Or could we have a CLI version of IDLE (defaults to interactive mode, but easy way to open/save files)?

...


And before you know it, you end up with emacs ;-)

-Gordon


Most likely so! About two minutes after writing my post above, I remembered I am using Emacs myself (for C) and I do know that most of this can be done within Emacs -maybe there is even a way to modify the menus available to suit...
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'
Posts: 904
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland
by tufty » Wed Feb 06, 2013 10:44 am
-rst- wrote:Most likely so! About two minutes after writing my post above, I remembered I am using Emacs myself (for C) and I do know that most of this can be done within Emacs -maybe there is even a way to modify the menus available to suit...

There's a load of BASIC modes out there for emacs, you should be able to hack something together. Eventually you'd probably want to end up with something like SLIME (Common Lisp interaction mode)
Posts: 1375
Joined: Sun Sep 11, 2011 2:32 pm
by Bakul Shah » Wed Feb 06, 2013 4:35 pm
tufty wrote:
DavidS wrote:Start with a simple typed language and a recursive decent parser type compiler

I beg to disagree. You want to leave parsing right out of it, and start by working on the syntax tree direct. Something lisp-like, a language that's already expressed in terms of a syntax tree, would be the best place to start, and make it obvious that compiling is, in fact, merely a sequence of source->source transforms.

Parsing is hard.

Just use yacc (or bison) and let it generate a parser from a high level description. Not too hard to learn and can save you loads of time; especially if the language syntax "evolves". I usually hand code the lexer (or scanner) but you can use lex (or flex) for that. But I agree with you that the real "meat" of compiling, the more interesting bits, comes after the parsing phase. It is just that you have to create this syntax tree somehow to test the latter compiler passes so you may as well write the front end lexer & parser. They come for free only if you are willing to stick to lisp's prefix form syntax.

As to if this a suitable topic for 12-14 year old kids, I am not sure.
Posts: 293
Joined: Sun Sep 25, 2011 1:25 am
by DavidS » Wed Feb 06, 2013 5:05 pm
tufty wrote:
DavidS wrote:Start with a simple typed language and a recursive decent parser type compiler

I beg to disagree. You want to leave parsing right out of it, and start by working on the syntax tree direct. Something lisp-like, a language that's already expressed in terms of a syntax tree, would be the best place to start, and make it obvious that compiling is, in fact, merely a sequence of source->source transforms.

Parsing is hard.


I disagree with both points. Parsing is presented as hard, in fact parsing is extremely simple. And using a language that will hide everything and teach nothing is nonsence.

Your argument sounds alot like those that say "Assembly language programming is dificult and slow".
We all know that AQssembly language is one of the simplest languages to work with, and development time for the same project is generaly shorter in assembly than with other languages.

Just because the dogma is that it is difficult does not make it true.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by Bakul Shah » Wed Feb 06, 2013 5:53 pm
DavidS wrote:Parsing is presented as hard, in fact parsing is extremely simple.

In practice you can get away not knowing a lot of the theory but the parsing theory is not exactly simple. Check out the "Dragon book" on compilers!

And using a language that will hide everything and teach nothing is nonsence.

Have you studied the Structure and Interpretation of Computer Programs) book? It uses Scheme and teaches you a whole lot -- more than virtually any other CS book.

We all know that AQssembly language is one of the simplest languages to work with, and development time for the same project is generaly shorter in assembly than with other languages.

Assembly languages are certainly simpler but the second part is not true in general. It has been decades since a single compiler for any high level language has been written entirely in assembly language (an exception may be Forth). OSes written in assembly languages are either toy ones or become impossible to maintain after a while.

I do think that every programmer should know assembly language but that is to understand the cost of various high level language features + finding occasional compiler bugs + learning how to do low level optimization when nothing else will help. Story time: When the open source BSD was very very young, I speeded up its ip checksumming by a factor of 5 by replacing its inner loop with a 3 line assembly code version -- using gcc's horrible inline syntax. A few years later, processors had gotten more complex and my "optimized" code turned out to be a pessimization compared to an all-C version that was more cache aware! And this is yet another problem with sticking with assembly code -- such projects don't evolve easily. In fact assembly code *hates* to evolve and even wonderful efforts like the Synthesis Kernel then get abandoned.
Posts: 293
Joined: Sun Sep 25, 2011 1:25 am
by jackokring » Wed Feb 06, 2013 7:07 pm
I agree that parsing can be complex, and with my first language design I used a forth style postfix, but included nesting using [ ] to make lists. Infix could be achieved by using a language word 'parse' which would bring in the following code/list and place it on stack. This allows for as much parse as you need.

It turns out that forward parsing was/is only needed to allow literal parameters to functions. This made the base language simple, as literal strings were introduced, and only conditional code and a few other specials needed to remain literal before execution. Compilation is to lists of references to named lists of references, to eventual object overridden "primitives". The "bytecode(sort of)" is hence pointer lists to machine code.

The only current faults are the need for spaces on both sides of [ or ] (not [or]), minor optimization resolving unknowns (not sure if it actually should be fixed), and there is no IO, as everything is a stack based Java module/package. https://github.com/jackokring/jarvar/wiki/WordsOfScriptLanguage and everything needs much testing (hard without IO). The removal of all IO from the language "standard" was intentional, as it's considered application decided.

With some good IO, I would have preferred this language to either basic, forth, logo or lisp. I don't see any of those languages as "harmful", just with their own syntactic imperfections.
Pi=B256R0USB CL4SD8GB Raspbian Stock. https://sites.google.com/site/rubikcompression/strictly-long https://dl.dropboxusercontent.com/u/1615413/Own%20Work/Leptronics.pdf https://groups.google.com/forum/#!topic/comp.compression/t22ct_BKi9w
User avatar
Posts: 784
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
by polas » Wed Feb 06, 2013 7:21 pm
Bakul Shah wrote:Just use yacc (or bison) and let it generate a parser from a high level description. Not too hard to learn and can save you loads of time; especially if the language syntax "evolves". But I agree with you that the real "meat" of compiling, the more interesting bits, comes after the parsing phase.


Having done lots of work on programming language and compiler design I absolutely agree. The lexing & parsing phases are boring and there are plenty of perfectly capable existing tools to automate this stage. What makes or breaks your programming language is the semantics and for the compilers implementing the semantics of a language in a correct, optimized form is the critical part which, as you say, comes after tokenisation and parsing.

I also believe that if people want to study compilers, then they should start by looking at the mathematical foundations upon which we design programming languages (most importantly of which are the different semantic models.) As compilers are simply an implementation of this design, then without that basic foundation the implementor is unlikely to be successful; writing a compiler is not just an exercise in programming.
Posts: 33
Joined: Tue Jan 15, 2013 9:52 am
by DavidS » Wed Feb 06, 2013 7:35 pm
Bakul Shah wrote:In practice you can get away not knowing a lot of the theory but the parsing theory is not exactly simple. Check out the "Dragon book" on compilers!

I am very familuar with the 'Dragon Book": Principles of Compiler Design. Two things about your statement:
    1) The dragon book presents the therory of parsing going to extremes and making it seem more dificult than it is.
    2) The Dragon Book covers a lot more than just parsing.

Once again just because the dogma sais it is dificult does not meen it is.

Have you studied the Structure and Interpretation of Computer Programs) book? It uses Scheme and teaches you a whole lot -- more than virtually any other CS book.

No I can not say as I have. Though its title does not do it justice if it is as complete as you are implying.

Assembly languages are certainly simpler but the second part is not true in general. It has been decades since a single compiler for any high level language has been written entirely in assembly language (an exception may be Forth).

I would hope that most compilers are self compiling, written in the high level language that they work with.

OSes written in assembly languages are either toy ones or become impossible to maintain after a while.

This is a matter of debate. Assembly code can be as maintainable as any other language if not more so. I know many programmers that still work almost exclusively in assembly language (myself included), and maintain and update large projects that are written in assembly regularly. It gives us the opertunity to choose what trade offs we wish to make when we update our projects for a new generation of the CPU. RISC OS is still more than half written in Assembly language, and is still maintainable, and maintained 25 years later.

I do think that every programmer should know assembly language but that is to understand the cost of various high level language features + finding occasional compiler bugs + learning how to do low level optimization when nothing else will help.

What about writing good easily updatable complete projects?

Story time: When the open source BSD was very very young, I speeded up its ip checksumming by a factor of 5 by replacing its inner loop with a 3 line assembly code version -- using gcc's horrible inline syntax. A few years later, processors had gotten more complex and my "optimized" code turned out to be a pessimization compared to an all-C version that was more cache aware!

And you prefer to rely on the compiler being updated? Assembly language programmers do not relly on such things. We update our code and make the trade offs that we feel are apropriate (do we optimize for the next generation CPU at the cost of speed loss on the older generation, etc...).

And BSD is a poor example as it is designed to be completely independant of the underlying CPU and as such is written almost entirely in C.

And this is yet another problem with sticking with assembly code -- such projects don't evolve easily. In fact assembly code *hates* to evolve and even wonderful efforts like the Synthesis Kernel then get abandoned.
Most projects that assembly language programmers create evolve fast and continue to evolve. This is because well documented, correctly formatted Assembly is a lot easier to fallow than a HLL (or even mid level like C), easier to update, and unlimitted in what can be done.
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by pygmy_giant » Wed Feb 06, 2013 8:13 pm
I would hope that most compilers are self compiling, written in the high level language that they work with.


Umm.....
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by jackokring » Wed Feb 06, 2013 8:48 pm
pygmy_giant wrote:
I would hope that most compilers are self compiling, written in the high level language that they work with.


Umm.....


This has been part of the bootstrap process for many compilers, but not all. The argument being that a better compiler can be written in the HLL, than the simple bootstrap compiler that worked first. It's also a good test of the language feature set, and it's completeness. It is not always the case though, especially with soft type languages/script languages. In this case the compiler produced would be less effective, even though it would be possibly much easier to write. The compiler produced when then compiling itself may be more effective though. Cfinal = Chll(Chll(Cbootstrap)).
Last edited by jackokring on Wed Feb 06, 2013 9:03 pm, edited 1 time in total.
Pi=B256R0USB CL4SD8GB Raspbian Stock. https://sites.google.com/site/rubikcompression/strictly-long https://dl.dropboxusercontent.com/u/1615413/Own%20Work/Leptronics.pdf https://groups.google.com/forum/#!topic/comp.compression/t22ct_BKi9w
User avatar
Posts: 784
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
by pygmy_giant » Wed Feb 06, 2013 8:52 pm
Ah!
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by joan » Wed Feb 06, 2013 9:02 pm
Angels and pinheads.

I first wrote an interpreter for BASIC more years ago than I care to remember.

It was limited to 26 variables, rather imaginitively called A to Z. I programmed it into a 2708 EPROM (I also had to create the hardware to program the EPROM). Less than 2000 bytes for the interperter!
User avatar
Posts: 6552
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK
by pygmy_giant » Wed Feb 06, 2013 9:31 pm
Oh - think I'll leave it to the experts :)
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by joan » Wed Feb 06, 2013 9:39 pm
I didn't have a point. If I had a point it would be children enthuse themselves. PCs did not exist when I was a child.
User avatar
Posts: 6552
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK
by Bakul Shah » Wed Feb 06, 2013 9:42 pm
joan wrote:Angels and pinheads.

I first wrote an interpreter for BASIC more years ago than I care to remember.

It was limited to 26 variables, rather imaginitively called A to Z. I programmed it into a 2708 EPROM (I also had to create the hardware to program the EPROM). Less than 2000 bytes for the interperter!

How'd you manage to stuff 2000 bytes in a 1Kx8 EPROM? :-)
Posts: 293
Joined: Sun Sep 25, 2011 1:25 am