'C' Expression Parsing in Forth?
- From: "bobjaffray@xxxxxxxx" <bobjaffray@xxxxxxxx>
- Date: 7 Aug 2005 22:41:10 -0700
>TOPIC: 'C' Expression Parsing in Forth?
>http://groups.google.com/group/comp.lang.forth/browse_thread/thread/ea1e29e3abddf3f6
>
>
>Date: Sat 6 Aug 2005 03:31
>From: PagCal
>
>John Passaniti wrote:
>> PagCal wrote:
>>
>>> One of the problems I've been trying to solve with forth was it's
>>> arcaine language with a steep learning curve. I felt that a 'c'
>>> syntax, optionally provided within forth, would provide a stepping
>>> stone. New users would stick to the familiar 'c' but then branch out
>>> into forth as they became more comfortable with it.
>>
>>
>> A fundamental question to ask here is what value do you think Forth has
>> as a language? With your (optional) facility, you've removed two of
>> it's defining attributes (a programmer-visible stack with nameless items
>> on it). So what's left? What value is there in programming in Forth
>> for you?
>
>It provides a useful structure to investigate what a programming
>language should be.
You are kidding.
But my question to you is, what is it about Forth that
attracts you?
>>> Example:
>>>
>>> : times ( a b -- resultant-product )
>>>
>>> c-expression ( a*b ) \ results of any 'c' expression pushed
>>> \ onto data stack
>>>
>>> nip nip
>>> ;
>>>
>>> I've also added 'c' statements, so you could rewrite the above as:
>>>
>>> : times ( a b -- resultant-product )
>>>
>>> c-statement ( a a*b; )
>>>
>>> drop
>>> ;
>>
>>
>> I think you've just wonderfully illustrated the "impedance mismatch"
>> between Forth and C with these examples. In 'times' you presumably push
>> the result of the a*b on the stack, which now doesn't have a name-- just
>> a position on the stack. And because it doesn't have a name, if I want
>> to use this value in a subsequent calculation, how do I reference it
>> from a c-expression? Even better, is the 'nip nip' that occurs in
>> 'times'. The programmer is freed from having to deal with the stack
>> with c-expression, and then in the next couple statements is forced
>> to... deal with the stack. And this helps the programmer how?
>
>Well, I left out a bit. Along with c-statements, I support
>class/union/struct, subroutines, and am generally extending the 'c'
>syntax over time to where it'll do the entire c file.
Your goal is to take C syntax and produce what you
think is Forth code. But it is not handling data in
the ordinary Forth way because you are using a stack
frame. I asked you before, and now ask you again,
where do you implement the stack frame that you referred
to?
>The 'times' example above could have been re-written:
>
> c-subroutine (
> int times ( int a, int b)
> {
> return a*b;
> }
> )
>
>>> A second plus for such an approach, is that a great deal of
>>> open-source 'c' code is available to be included into your project and
>>> this could be just compiled into forth along with whatever else you
>>> wanted. You thus shrink the project time down considerably.
>>
>>
>> This is perhaps your worst argument. In order to use that open source
>> 'C' code, your solution requires me to edit the original 'C' code (which
>> is typically going to be a set of functions and data structures, not
>> just a simple c-expression and c-statement) and wrap it with Forth. Why
>> would I want to do that?
PagCal, you do not answer this. But it seems clear to me that
you want to be able to compile just about any C source.
>> If I want to integrate C and Forth code, a much better and cleaner
>> solution is to come up with a call interface between the two languages.
>> Allow C code to call words from Forth, and Forth code to call functions
>> from C. Both languages stay as they are, both fully retaining all their
>> benefits.
>>
>
>I've done that as well in two ways. dlopen/close will map constructs out
>of libraries, and I wrote a tool to declare 'c' subroutines to my forth
>engine. The tool builds all of the hooks necessary to just plop the 'c'
>code into the executable.
(cut)
>>> Compare the above with what you can groak in with CREATE DOES> and you
>>> can see the above is a lot cleaner.
>>
>>
>> It's horrific. You have the programmer having to shift mindsets between
>> Forth and C with no benefit visible other than you don't have to juggle
>> items on the stack inside a c-expression or c-statement. But as soon as
>> that c-expression or c-statement ends, the programmer is tossed back
>> into the world of dealing with the stack-- presumably what you were
>> trying to avoid.
>
>Shift Mindsets? That's an interesting way to look at programming languages.
>
>I rather view all these modern languages trying to do the same things,
>but using different syntax to achieve these goals.
>
>For example, you've got to interate over something. In 'c', you'd do
>
> for ( i 0 ; i < 10 ; i++ ) {
>
> }
>
>but in forth, you'd do:
>
> 10 0 do
>
> loop
>
My question is about the implementation in Forth. What kind of
code do you generate from your c-expressions and c-statements?
They don't seem to be Forth-like, or are they. What about factoring?
Your example doesn't really illustrate what kind of code
you generally produce.
(cut)
Bob Jaffray
.
- Prev by Date: Order of stack items
- Next by Date: 'C' Expression Parsing in Forth?
- Previous by thread: Re: 'C' Expression Parsing in Forth?
- Next by thread: 'C' Expression Parsing in Forth?
- Index(es):
Relevant Pages
|
Loading
