🚀 go-pugleaf

I have been debugging a simple, line-oriented BASIC interpreter
which I hope to release soon as source code (probably comp.sources.misc
stuff).  The interpreter implements (under ANSI C) all of the (few)
commands and functions of ANSI Minimal C, and has a user interface
roughly similar to older Microsoft-type BASIC interpreters, where
the user can enter a line preceded by a line number and it is
added to the program in memory; the program in memory can be saved
as an ASCII file, etc.  

I have added one feature to this interpreter which might qualify it
as a shell language: whenever a line is entered that a) does not
begin with a recognized BASIC command and b) is not an implied
LET command, the interpreter shells out (using shell()) and tries
to let the default o.s. command shell interpret the line. So
that under Unix the line "ls -l" will simply be executed by sh
or whatever the default shell is, and any executable file can
be executed by entering it at the (BASIC) prompt. 

My questions, then: (a) why couldn't BASIC serve as a command
shell in place of sh, ksh, csh etc.? and implied in this question,
(b) what do you think is necessary for a shell programming language
beyond the bare ability to execute commands that another shell
can execute? Perhaps implicit, further, is (c) the question of
whether there is a better term than "shell" for this, since
after all it does not execute commands directly but calls up the
default shell to do so? Perhaps I should execute them using 
execl() or some such? Perhaps I should call my implementation a
"subshell? Or is there another term in use for this kind of
program? 

Thanks very much. 

Ted A. Campbell
Duke University
tcamp@acpub.duke.edu