Yes, that was an interesting comment about the braces. Is that the main thing that people find difficult about C?
No, it's an annoying property of C, Java, Perl, Javascript, Go and many other languages!
What really annoys me is when writes refer to them as "curly braces" .....folks, they are just braces, there aren't curly and non-curly braces, just braces.
No, it's an annoying property of C, Java, Perl, Javascript, Go and many other languages!
What really annoys me is when writes refer to them as "curly braces" .....folks, they are just braces, there aren't curly and non-curly braces, just braces.
Maybe "curly braces" is to distinguish them from Moe and Larry braces?
Hambuger buns might be annoying but they are far less annoying than:
BEGIN...END and such as used in Pascal and the verbose languages.
(...) as used in Lisp, Scheme etc. They have no idea of different brackets for parameter lists, array indices etc, very confusing.
Nothing, delimiting blocks with white space is damn annoying when the spaces get mashed around (as when posting too the forum) and the code code is so hard to follow with the eye people constantly beg for those block markers, like the Prop Tool has, in Simple IDE etc. Also you can't pretty print it.
Umm. Larry Wall used Moe, Larry, Curley, Shep, Curley Joe, and all the regulars. He also included all the Little Rascals and some of the Looney Toons. Not a Perl dig BTW, it's just that there is a ton of syntax required for regular expressions and other things.
I fully understand why Parallax has an effort to get 'C' for propeller working -- that just makes good business sense for trying to get a toe-hold in other markets. Spin is an interesting language, and is an effective language for the propeller, but I think that a large part of the embedded community is not eager to adopt it. With regard to BASIC -- it seems to me that Parallax ought to figure out a way to officially adopt that into the Propeller tool chain because, well, you should dance with the one that brung ya.
With regard to BASIC -- it seems to me that Parallax ought to figure out a way to officially adopt that into the Propeller tool chain because, well, you should dance with the one that brung ya. .
The BASIC Stamp gave birth to the Propeller, both in terms of experience and financial power. For a long time these two customer bases have been somewhat isolated and we should find a way to bring them together. Those who've made the leap to the Propeller are here; others have been intrigued by other platforms and may need a reason to come home.
Have I made it clear that you've got our attention?
There's much I don't know about PropBASIC. There are some considerations to the whole thing, and even though I might be posing questions they're really just thinking points:
PropBASIC would need to find a way to justify some financial support from Parallax, furthering the evolution of the BatangIDE and BeanCompiler (or translator?). Either through side-by-side KickStart examples in PBASIC, an open source BS3, Propeller Activity Board dependency, a retro book (I could be interested) plus parts kit it would need to have some pull that relates to sales. This way the developers have more firepower than provided by their free evening time. Some financial renumeration is important. But this shouldn't be a focus at this early stage - such financial considerations to perform can wreck a good effort.
Multi-platform, multi-OS. Yeah, everything must be done this way. Again, developers must have some reason to give everything away (first point, above). Recognition is important, but it's not everything.
Stability in syntax. To product-ize (just pretend it's a word) a language the syntax must be developed and stable. Everybody knows this, but even PBASIC 2.5 was released years later with significant improvements. Long-term thought must be given to the syntax, so that it's stable in the beginning.
What constitutes "official support". Hosting tools, providing progression paths, documentation, examples. It's almost like we need to be able to host an "unofficial Parallax" set of resources on our own site. Not a mixed set of messages, but one conveying that "we're experimenting and developing PropBASIC - and want to share it with you" so that expectations are in line. The problem is that everybody tells us we're famous for the best documentation and support, so this could fly against our reputation if it's anything short of the best documentation and support.
Parallax resources. They're quite limited, as you can see from the outside. We're developing a C program, putting Propeller 2 [back] into fab, developing a new robot, and supporting FAE customers. Though we just added another editorial content person to Stephanie's quiver, everything is planned out for months or sometimes years in advance. Everything we're doing is for long-term growth, not just next month. To incorporate PropBASIC into our documentation I'd need another person. That's entirely feasible with some revenue driven by the product.
Bean,
If people want to use PropBasic to see what PASM is needed for a statement, they can write statements with only one operator. Please do have generalized expressions.
Regarding Ken's 3rd point ("Stability in syntax") ... There's a huge difference between PropBasic and PBasic in terms of syntax and features. How much of what makes up PBasic should be transferred to the Prop? What's the purpose of having PropBasic? To provide a (mostly) familiar programming language for high speed (PASM) programming on the Propeller or to migrate existing PBasic programs to the Propeller? These are very different projects. Both have merit.
At one point, I thought of extending and modifying FemtoBasic to include most of PBasic, at least the BS2 features. I quickly realized that it wouldn't fit into 32K and would have to be redone as a compiler / interpreter in multiple phases and it would be a large project that I couldn't commit to. I thought about a PBasic interpreter for the Propeller, but the PBasic code format is not open and I wasn't going to try to crack it and do an interpreter as well. Bean came out with PropBasic and that reduced my sense of need for a compatible Propeller Basic.
So here we are again with some of the same questions yet unanswered. It's a lot of work to adapt PropBasic as it exists for the Prop 2. It would be even more work to significantly change the language although this would be a good time to do it if it's to be done at all. Bean needs to chime in about how much interest he has and for what features. He doesn't need to get burned out about committing to a project that doesn't catch his interest.
The BASIC Stamp gave birth to the Propeller, both in terms of experience and financial power. For a long time these two customer bases have been somewhat isolated and we should find a way to bring them together. Those who've made the leap to the Propeller are here; others have been intrigued by other platforms and may need a reason to come home.
Have I made it clear that you've got our attention?
Indeed you have. This is smart thinking, too. Very smart. If nothing else it would draw (some) people back to Parallax who've drifted on to other places: PICAXE, Maximite, PICBASIC ... et al. and perhaps even some Arduino folks as well, depending on how PropBASIC and related tools and products evolve. Also, it goes without saying that this is another way people can get into the Propeller easily, which can only help Propeller sales in the long run.
That said, I understand the balancing act involved when you have finite resources and many other priorities. Still, I think it's worth doing -- if it can at all be done.
I wonder whether an approach like Eric Smith took with Spin (spin2cpp) would work well with PropBasic as well. Rather than having it generate PASM directly why not have it generate C or C++ so you can make use of the GCC optimizer to get fast code? Since Basic syntax is simpler than Spin I imagine it might not be that hard to do.
That said, I understand the balancing act involved when you have finite resources and many other priorities. Still, I think it's worth doing -- if it can at all be done.
Yep, I want it too.
Ya know, KC_Rob, there's a very important overriding consideration to projects like this one. And that's whether or not we want to work with the "PropBASIC people" and that they want to work with us. In this case, we have great people with whom to work. Bean is a man of integrity, honesty and reasonableness. Batang has made numerous technical contributions on the forums and also has a very good character. These traits are truly a prerequisite for a successful working relationship. And this isn't just because I'm more of a social being than an engineer, but because reasonable people are, well, reasonable! Work with people you like. And you better like your customers, too!
I would ditto David's suggestion, particularly if we want a Prop Basic closer to PBasic. It would be an easier project and it would make use of the power of GCC for code generation and optimization. There might be some pathological PBasic programs with a huge number of labels that might be difficult to translate into C. Fortunately, PBasic programs always were constrained to fit in 2K, thus were limited in size.
<snip>
* Stability in syntax. To product-ize (just pretend it's a word) a language the syntax must be developed and stable. Everybody knows this, but even PBASIC 2.5 was released years later with significant improvements. Long-term thought must be given to the syntax, so that it's stable in the beginning.
<snip>
For now, I'd need to learn more about PropBASIC.
There are a couple of steps to support :
Adding 3rd party tools to any IDE is not a large task - the ones in there now are command line driven, and then the output is parsed, to point to any compile time errors.
Finally, a Success! binary is sent to the target.
Syntax highlighting is also not complex, many editors have this as a user-file set.
Doing that makes it clear to everyone it is '3rd party tools', so keeps the support channels clear ( well, less blurred )
It also opens support for ANY language - Forth's, Basics, Alternate C's and so on...
Once that 'support 3rd party pass' is done, then bringing a better BASIC 'more into the stable' is also a good idea.
An important aspect of that is to include ease of testing and code-block checking.
That means doing a (careful) subset of a PC program. ( That is one of the driving appeals of C - module testing )
Stability in syntax. To product-ize (just pretend it's a word) a language the syntax must be developed and stable. Everybody knows this, but even PBASIC 2.5 was released years later with significant improvements. Long-term thought must be given to the syntax, so that it's stable in the beginning.
Where can I find a description of PBASIC 2.5? I'm assuming that is the latest version?
I wonder whether an approach like Eric Smith took with Spin (spin2cpp) would work well with PropBasic as well. Rather than having it generate PASM directly why not have it generate C or C++ so you can make use of the GCC optimizer to get fast code? Since Basic syntax is simpler than Spin I imagine it might not be that hard to do.
I just spent a couple of days trying to translate a PropBasic program into the current C environment and could not make it fit into an LMM/CMM environment no matter what I did. Also, this program needs to generate fairly precisely timed pulses from a couple of cogs and I found it, well, nowhere near as precise as the PropBasic version when I ran just a subset of code that would fit to check precision. The generated assembler was much more difficult to get a handle on and the code was 3 times the size as the PropBasic version. I am absolutely certain that one of the GCC pros could make it work in C - but - please DO NOT make this the only avenue going forward. Please do not misunderstand me - the C product is absolutely awesome and I use it as well. Some tasks require different tools and trying to make a one-size-fits-all product can result in something which does lots of things but none of them superbly.
I just spent a couple of days trying to translate a PropBasic program into the current C environment and could not make it fit into an LMM/CMM environment no matter what I did. Also, this program needs to generate fairly precisely timed pulses from a couple of cogs and I found it, well, nowhere near as precise as the PropBasic version when I ran just a subset of code that would fit to check precision. The generated assembler was much more difficult to get a handle on and the code was 3 times the size as the PropBasic version. I am absolutely certain that one of the GCC pros could make it work in C - but - please DO NOT make this the only avenue going forward. Please do not misunderstand me - the C product is absolutely awesome and I use it as well. Some tasks require different tools and trying to make a one-size-fits-all product can result in something which does lots of things but none of them superbly.
Could you post the original PropBasic code and your translation?
I am really happy to see all this buzz about PropBASIC. PropBASIC is one of the avenues that I was looking towards when developing the "PropBSC" (Propeller BASIC Stamp Compatible) module. PropBASIC would be a really nice touch to allow BOEBOT owners to take advantage of what the module can offer in a "BASIC Stamp drop-in replacement" package.
Wow, this thread has grown, I being in a different time zone and all so a lot to read.
@Ken Gracey: Initial deployment will be for Windows and then after that Mac.
Heater
BEGIN...END and such as used in Pascal and the verbose languages.
I am implementing code completion for various constructs i.e. IF..THEN, FOR..NEXT etc.
So if you type IF something= something THEN and hit enter the ENDIF is automatically inserted and so on.
Preempting again here: I am implementing an as you type syntax parser which underline the typed code in red if there is an error.
jazzed
Sweet. What about drag-n-drop peripherals? The idea is to define device drivers and pin connections for the given language. The community provided some ICONs here.
Here is a more recent thread discussing a stand-alone editor. Such an editor could produce a source file for a given language and methodology regardless of the
development environment.
Best regards.
--Steve
You know Steve, I had an idea like that for several years and saw something like it materialize in the Psoc Creator program from Cypress.
Unlike Psoc Creator which defines peripherals in hardware I had an idea to have libraries of peripherals that could be drag/dropped into the graphic of the chip and then have a properties box which would allow the settings to be changed i.e. baud rate etc if it were a UART and which pins are used and updated in the graphic.
This is still some I am looking at and with that in mind I have requested from Bean (and received today) some examples of library files, also this may require changes to the PropBasic compiler which I would have to discuss with Bean.
I do not think that I will have time for the initial beta release of the IDE for this but who knows, this would require community support to provide the libraries when the structure of the library is worked.
To everyone else thanks for the support and enthusiasm and to Bean for providing the core for what I hope will be a great tool.
I had an idea to have libraries of peripherals that could be drag/dropped into the graphic of the chip and then have a properties box which would allow the settings to be changed i.e. baud rate etc if it were a UART and which pins are used and updated in the graphic.
I'd like to see that! That is the main thing I like about the PSOC Creator software. Dropping in the modules and then configuring them for your application makes easy work of setting up all of the fundamentals (I have a couple projects with PSOC devices utilizing CapSense for capacitive touch). Having a similar setup in a BASIC environment would reduce the migration from PBASIC to PropBASIC and even to SPIN.
This is still some I am looking at and with that in mind I have requested from Bean (and received today) some examples of library files, also this may require changes to the PropBasic compiler which I would have to discuss with Bean.
I do not think that I will have time for the initial beta release of the IDE for this but who knows, this would require community support to provide the libraries when the structure of the library is worked.
It would not need to be a binary library file - these days, PC's are plenty fast enough to compile all sources.
- but it does need to be able to pull together multiple source files (ideally mixed) and remove unused code.
Conditional switches can also help control code size.
I am implementing code completion for various constructs i.e. IF..THEN, FOR..NEXT etc.
This is good.
My comment about things like BEGIN...END being annoying was not about writing the code but reading it. They are just ugly and get in the way. As there tends to be rather a lot of them it eases the situation by reducing them to "hamburger buns".
It's for the same reason we don't write sentences with things like "PERIOD" at the end. We just delimit them with an upper case first letter and a dot at the end.
My comment about things like BEGIN...END being annoying was not about writing the code but reading it. They are just ugly and get in the way. As there tends to be rather a lot of them it eases the situation by reducing them to "hamburger buns".
It's for the same reason we don't write sentences with things like "PERIOD" at the end. We just delimit them with an upper case first letter and a dot at the end.
Good observation.
Interestingly though, once upon a time telegrams used STOP and not the dot.
Please keep it away from C, there's a reason people prefer BASIC, you are just adding another level of complexity if you do that.
In any case, PropBASIC is one of the fastest compilers around....
I wonder whether an approach like Eric Smith took with Spin (spin2cpp) would work well with PropBasic as well. Rather than having it generate PASM directly why not have it generate C or C++ so you can make use of the GCC optimizer to get fast code? Since Basic syntax is simpler than Spin I imagine it might not be that hard to do.
Converting BASIC to C so as to be able to make use of the optimizations offered by GCC, as suggested by Davis, may or may not be a good idea. On the face of it it makes sense.
However if it is to be used in production by people who want to program in BASIC it may have one fatal flaw.
Those people are never going to want to see any C code or any error messages that may come out of the C compiler. Or be involved in any of the mechanics of the thing using C. It would all have to be buried, out of sight, internal to the BASIC compilation system.
That implies that the code generated by the BASIC to C translator will have to be 100 percent sure never to generate C that won't compile.
Further along there may be issues in debugging. How do you match up the generated code back to the original BASIC source code?
Is it possible to make a BASIC compiler system using intermediate C under these constraints?
Converting BASIC to C so as to be able to make use of the optimizations offered by GCC, as suggested by Davis, may or may not be a good idea. On the face of it it makes sense.
However if it is to be used in production by people who want to program in BASIC it may have one fatal flaw.
Those people are never going to want to see any C code or any error messages that may come out of the C compiler. Or be involved in any of the mechanics of the thing using C. It would all have to be buried, out of sight, internal to the BASIC compilation system.
That implies that the code generated by the BASIC to C translator will have to be 100 percent sure never to generate C that won't compile.
Further along there may be issues in debugging. How do you match up the generated code back to the original BASIC source code?
Is it possible to make a BASIC compiler system using intermediate C under these constraints?
I agree that the basic2cpp translator would have to produce 100% correct C code to eliminate syntax errors from the C compiler. However, doing this at all might not make sense if PropBasic already produces better code than PropGCC. I'm still waiting for an example to be posted. I'd love to see how the code generation compares. Maybe we can learn something that will help us improve PropGCC!
Comments
No, it's an annoying property of C, Java, Perl, Javascript, Go and many other languages!
What really annoys me is when writes refer to them as "curly braces" .....folks, they are just braces, there aren't curly and non-curly braces, just braces.
( } ]
Yep, you're right!!
BEGIN...END and such as used in Pascal and the verbose languages.
(...) as used in Lisp, Scheme etc. They have no idea of different brackets for parameter lists, array indices etc, very confusing.
Nothing, delimiting blocks with white space is damn annoying when the spaces get mashed around (as when posting too the forum) and the code code is so hard to follow with the eye people constantly beg for those block markers, like the Prop Tool has, in Simple IDE etc. Also you can't pretty print it.
Must be since Larry (Wall) brackets are in Perl!
Umm. Larry Wall used Moe, Larry, Curley, Shep, Curley Joe, and all the regulars. He also included all the Little Rascals and some of the Looney Toons. Not a Perl dig BTW, it's just that there is a ton of syntax required for regular expressions and other things.
[FONT=Verdana][SIZE=2][COLOR=#000000] [/COLOR][/SIZE][/FONT] #:: ::-| ::-| .-. :||-:: 0-| .-| ::||-| .:|-. :|| open(Q,$0);while(<Q>){if(/^#(.*)$/){for(split('-',$1)){$q=0;for(split){s/\| /:.:/xg;s/:/../g;$Q=$_?length:$_;$q+=$q?$Q:$Q*20;}print chr($q);}}}print"\n"; #.: ::||-| .||-| :|||-| ::||-| ||-:: :|||-| .:|cheers!
...off to tinker now...
The BASIC Stamp gave birth to the Propeller, both in terms of experience and financial power. For a long time these two customer bases have been somewhat isolated and we should find a way to bring them together. Those who've made the leap to the Propeller are here; others have been intrigued by other platforms and may need a reason to come home.
Have I made it clear that you've got our attention?
There's much I don't know about PropBASIC. There are some considerations to the whole thing, and even though I might be posing questions they're really just thinking points:
- PropBASIC would need to find a way to justify some financial support from Parallax, furthering the evolution of the BatangIDE and BeanCompiler (or translator?). Either through side-by-side KickStart examples in PBASIC, an open source BS3, Propeller Activity Board dependency, a retro book (I could be interested) plus parts kit it would need to have some pull that relates to sales. This way the developers have more firepower than provided by their free evening time. Some financial renumeration is important. But this shouldn't be a focus at this early stage - such financial considerations to perform can wreck a good effort.
- Multi-platform, multi-OS. Yeah, everything must be done this way. Again, developers must have some reason to give everything away (first point, above). Recognition is important, but it's not everything.
- Stability in syntax. To product-ize (just pretend it's a word) a language the syntax must be developed and stable. Everybody knows this, but even PBASIC 2.5 was released years later with significant improvements. Long-term thought must be given to the syntax, so that it's stable in the beginning.
- What constitutes "official support". Hosting tools, providing progression paths, documentation, examples. It's almost like we need to be able to host an "unofficial Parallax" set of resources on our own site. Not a mixed set of messages, but one conveying that "we're experimenting and developing PropBASIC - and want to share it with you" so that expectations are in line. The problem is that everybody tells us we're famous for the best documentation and support, so this could fly against our reputation if it's anything short of the best documentation and support.
- Parallax resources. They're quite limited, as you can see from the outside. We're developing a C program, putting Propeller 2 [back] into fab, developing a new robot, and supporting FAE customers. Though we just added another editorial content person to Stephanie's quiver, everything is planned out for months or sometimes years in advance. Everything we're doing is for long-term growth, not just next month. To incorporate PropBASIC into our documentation I'd need another person. That's entirely feasible with some revenue driven by the product.
For now, I'd need to learn more about PropBASIC.If people want to use PropBasic to see what PASM is needed for a statement, they can write statements with only one operator. Please do have generalized expressions.
Regarding Ken's 3rd point ("Stability in syntax") ... There's a huge difference between PropBasic and PBasic in terms of syntax and features. How much of what makes up PBasic should be transferred to the Prop? What's the purpose of having PropBasic? To provide a (mostly) familiar programming language for high speed (PASM) programming on the Propeller or to migrate existing PBasic programs to the Propeller? These are very different projects. Both have merit.
At one point, I thought of extending and modifying FemtoBasic to include most of PBasic, at least the BS2 features. I quickly realized that it wouldn't fit into 32K and would have to be redone as a compiler / interpreter in multiple phases and it would be a large project that I couldn't commit to. I thought about a PBasic interpreter for the Propeller, but the PBasic code format is not open and I wasn't going to try to crack it and do an interpreter as well. Bean came out with PropBasic and that reduced my sense of need for a compatible Propeller Basic.
So here we are again with some of the same questions yet unanswered. It's a lot of work to adapt PropBasic as it exists for the Prop 2. It would be even more work to significantly change the language although this would be a good time to do it if it's to be done at all. Bean needs to chime in about how much interest he has and for what features. He doesn't need to get burned out about committing to a project that doesn't catch his interest.
That said, I understand the balancing act involved when you have finite resources and many other priorities. Still, I think it's worth doing -- if it can at all be done.
Yep, I want it too.
Ya know, KC_Rob, there's a very important overriding consideration to projects like this one. And that's whether or not we want to work with the "PropBASIC people" and that they want to work with us. In this case, we have great people with whom to work. Bean is a man of integrity, honesty and reasonableness. Batang has made numerous technical contributions on the forums and also has a very good character. These traits are truly a prerequisite for a successful working relationship. And this isn't just because I'm more of a social being than an engineer, but because reasonable people are, well, reasonable! Work with people you like. And you better like your customers, too!
There are a couple of steps to support :
Adding 3rd party tools to any IDE is not a large task - the ones in there now are command line driven, and then the output is parsed, to point to any compile time errors.
Finally, a Success! binary is sent to the target.
Syntax highlighting is also not complex, many editors have this as a user-file set.
Doing that makes it clear to everyone it is '3rd party tools', so keeps the support channels clear ( well, less blurred )
It also opens support for ANY language - Forth's, Basics, Alternate C's and so on...
Once that 'support 3rd party pass' is done, then bringing a better BASIC 'more into the stable' is also a good idea.
An important aspect of that is to include ease of testing and code-block checking.
That means doing a (careful) subset of a PC program. ( That is one of the driving appeals of C - module testing )
For a top-down starting point, I'd suggest a look at FreeBasic.
http://www.freebasic.net/
This has a couple of nice Editors already, and a good debugger... (& Compiler is command linen driven, from the editors)
http://www.freebasic.net/forum/viewforum.php?f=8
and the Help is also quite high quality
http://www.freebasic.net/wiki/wikka.php?wakka=DocToc
and in more than one place
http://virtualink.wikidot.com/fbtut:fbasic
@Ken Gracey: Initial deployment will be for Windows and then after that Mac.
Heater
I am implementing code completion for various constructs i.e. IF..THEN, FOR..NEXT etc.
So if you type IF something= something THEN and hit enter the ENDIF is automatically inserted and so on.
Preempting again here: I am implementing an as you type syntax parser which underline the typed code in red if there is an error.
jazzed
You know Steve, I had an idea like that for several years and saw something like it materialize in the Psoc Creator program from Cypress.
Unlike Psoc Creator which defines peripherals in hardware I had an idea to have libraries of peripherals that could be drag/dropped into the graphic of the chip and then have a properties box which would allow the settings to be changed i.e. baud rate etc if it were a UART and which pins are used and updated in the graphic.
This is still some I am looking at and with that in mind I have requested from Bean (and received today) some examples of library files, also this may require changes to the PropBasic compiler which I would have to discuss with Bean.
I do not think that I will have time for the initial beta release of the IDE for this but who knows, this would require community support to provide the libraries when the structure of the library is worked.
To everyone else thanks for the support and enthusiasm and to Bean for providing the core for what I hope will be a great tool.
Regards
David
I'd like to see that! That is the main thing I like about the PSOC Creator software. Dropping in the modules and then configuring them for your application makes easy work of setting up all of the fundamentals (I have a couple projects with PSOC devices utilizing CapSense for capacitive touch). Having a similar setup in a BASIC environment would reduce the migration from PBASIC to PropBASIC and even to SPIN.
It would not need to be a binary library file - these days, PC's are plenty fast enough to compile all sources.
- but it does need to be able to pull together multiple source files (ideally mixed) and remove unused code.
Conditional switches can also help control code size.
My comment about things like BEGIN...END being annoying was not about writing the code but reading it. They are just ugly and get in the way. As there tends to be rather a lot of them it eases the situation by reducing them to "hamburger buns".
It's for the same reason we don't write sentences with things like "PERIOD" at the end. We just delimit them with an upper case first letter and a dot at the end.
Good observation.
Interestingly though, once upon a time telegrams used STOP and not the dot.
Cheers
In any case, PropBASIC is one of the fastest compilers around....
If you want a BASIC to C Converter try BCX http://bcx-basic.sourceforge.net/
However if it is to be used in production by people who want to program in BASIC it may have one fatal flaw.
Those people are never going to want to see any C code or any error messages that may come out of the C compiler. Or be involved in any of the mechanics of the thing using C. It would all have to be buried, out of sight, internal to the BASIC compilation system.
That implies that the code generated by the BASIC to C translator will have to be 100 percent sure never to generate C that won't compile.
Further along there may be issues in debugging. How do you match up the generated code back to the original BASIC source code?
Is it possible to make a BASIC compiler system using intermediate C under these constraints?