Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #919 > unrolled thread

Renaissance of Forth

Back to article view | Back to comp.lang.forth

Contents

  Renaissance of Forth visualforth@rocketmail.com - 2011-03-31 16:06 -0700
    Re: Renaissance of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-01 02:29 -0500
    Re: Renaissance of Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-01 12:46 +0000
      Re: Renaissance of Forth Dennis <daruffer@gmail.com> - 2011-04-01 07:36 -0700
        Re: Renaissance of Forth Brad <hwfwguy@gmail.com> - 2011-04-01 07:47 -0700
        Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-01 16:40 -0700
          Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-01 18:20 -0700
      Re: Renaissance of Forth Paul Rubin <no.email@nospam.invalid> - 2011-04-01 12:34 -0700
        Re: Renaissance of Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-02 00:23 +0000
          Re: Renaissance of Forth Paul Rubin <no.email@nospam.invalid> - 2011-04-01 16:24 -0700
    Re: Renaissance of Forth Gary Bergstrom <g.bergstrom@ieee.org> - 2011-04-01 08:36 -0700
    Re: Renaissance of Forth "The Beez'" <hansoft@bigfoot.com> - 2011-04-01 16:04 -0700
      Re: Renaissance of Forth mhx@iae.nl (Marcel Hendrix) - 2011-04-02 10:40 +0200
        Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-02 14:50 -0700
          Re: Renaissance of Forth "Massimo A. Dentico" <massimo_dentico@hotmail.com> - 2011-04-03 00:34 +0200
            Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-02 21:08 -0700
              Re: Renaissance of Forth mhx@iae.nl (Marcel Hendrix) - 2011-04-03 09:24 +0200
                Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-03 15:45 -0700
                  Re: Renaissance of Forth Paul Rubin <no.email@nospam.invalid> - 2011-04-03 16:45 -0700
                    Re: Renaissance of Forth Elizabeth D Rather <erather@forth.com> - 2011-04-03 14:01 -1000
                      Re: Renaissance of Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-06 22:43 +0000
                    Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-03 17:34 -0700
                      Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-04 10:55 -0700
                        Re: Renaissance of Forth pliz <s.m.plis@gmail.com> - 2011-04-04 13:11 -0700
                          Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-05 09:10 -0700
                        Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-04 16:33 -0700
                          Re: Renaissance of Forth Elizabeth D Rather <erather@forth.com> - 2011-04-04 16:31 -1000
                            Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-04 19:52 -0700
                              Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-05 09:58 -0700
                                Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-05 18:36 -0700
                                  Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-06 13:53 -0700
                                    Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-06 15:29 -0700
                                      Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-07 08:35 -0700
                                        Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-07 16:20 -0700
                          Re: Renaissance of Forth Alex McDonald <blog@rivadpm.com> - 2011-04-05 08:56 -0700
                          Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-05 09:35 -0700
                        Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-06 17:48 -0700
                        Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-12 15:47 -0700
                          Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-13 09:27 -0700
                            Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-13 09:55 -0700
                              Re: Renaissance of Forth Richard Owlett <rowlett@pcnetinc.com> - 2011-04-13 13:02 -0500
                              Re: Renaissance of Forth Elizabeth D Rather <erather@forth.com> - 2011-04-13 09:01 -1000
                              Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-13 13:23 -0700
                                Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-13 20:32 -0700
                                  Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-13 20:52 -0700
                                    Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-13 22:26 -0700
                                      Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-13 23:42 -0700
                                        Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-14 10:42 -0700
                                          Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-14 13:06 -0700
                                            Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-14 14:26 -0700
                                              Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-14 21:31 -0700
                                                Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-14 23:42 -0700
                                                  Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-15 00:56 -0700
                                            Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-15 08:03 -0700
                                              Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-15 09:28 -0700
                                                Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-15 10:28 -0700
                              Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-13 20:40 -0700
                                Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-13 22:57 -0700
                    Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-04 08:39 -0700
                      Re: Renaissance of Forth Paul Rubin <no.email@nospam.invalid> - 2011-04-04 09:41 -0700
                  Re: Renaissance of Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-06 22:39 +0000
    Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-02 20:32 -0700
      Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-02 22:06 -0700
        Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-03 07:17 -0700
    Re: Renaissance of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-04 17:09 +0000
      Re: Renaissance of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-05 15:55 +0200
        Re: Renaissance of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-07 16:25 +0000
          Re: Renaissance of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-08 21:07 +0200
            Re: Renaissance of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-09 17:29 +0000
              Re: Renaissance of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-10 18:39 +0200
        redirecting TYPE to a string (was: Renaissance of Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-09 16:54 +0000
          Re: redirecting TYPE to a string (was: Renaissance of Forth) BruceMcF <agila61@netscape.net> - 2011-04-09 13:07 -0700
          Re: redirecting TYPE to a string (was: Renaissance of Forth) Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-10 18:07 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#1027

In article <27udnR6IY-7GlwTQnZ2dnUVZ_jCdnZ2d@supernews.com>,
Elizabeth D Rather  <erather@forth.com> wrote:
>On 4/3/11 1:45 PM, Paul Rubin wrote:
>> John Passaniti<john.passaniti@gmail.com>  writes:
>>> you had a way to invoke C statements, but the
>>> code executed lived in it's own little world-- the C code had no
>>> visibility of Forth's stack and the grammar didn't appear to have any
>>> way to call Forth code.
>>
>> How is this usually handled if you replace the word "C" with "assembler"?
>
>Many Forths (all that I've ever worked with) included an assembler
>written in Forth for the processor it's running on.  You can write CODE
>definitions whose bodies are expressed in that assembler, which generate
>actual machine code.  And you can drop into assembler for things like
>interrupt handlers.  The entire Forth VM (as well as the underlying
>processor) is available to such code, and there's nothing external to
>the Forth that has to be involved.
>
>Nowadays, the approach is to minimize the requirement to write CODE
>words by using an optimizing compiler that generates good-quality
>machine code.

Bottom line: the assembly code *lives* in the Forth world.
This is very different from *interfacing* with a C-world.

>
>Cheers,
>Elizabeth

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#993

On Apr 3, 7:45 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> John Passaniti <john.passan...@gmail.com> writes:
> > ou had a way to invoke C statements, but the
> > code executed lived in it's own little world-- the C code had no
> > visibility of Forth's stack and the grammar didn't appear to have any
> > way to call Forth code.

> How is this usually handled if you replace the word "C" with "assembler"?

That's what I was referring to as CCODE: ... ;CCODE ~ a way to embed
operations written in C (perhaps calling external functions originally
designed to be called from C, perhaps entirely embedded), in a way
that creates a Forth word that handles the interface, in precisely the
same way that an external C-library function interface creates a Forth
word that calls the external function.

So possibly integrated, but not seamless. One use would be borrowing
available open source device driver code in C.

[toc] | [prev] | [next] | [standalone]

#1000

On Apr 3, 8:34 pm, BruceMcF <agil...@netscape.net> wrote:
> That's what I was referring to as CCODE: ... ;CCODE ~ a way to
> embed operations written in C (perhaps calling external
> functions originally designed to be called from C, perhaps
> entirely embedded), in a way that creates a Forth word that
> handles the interface, in precisely the same way that an
> external C-library function interface creates a Forth word
> that calls the external function.

Maybe the problem here is that I'm looking at this too generally.  The
OP wants to replace assembly with C.  That to me means that *anything*
assembly can do, C should be able to do the same.  If it can't, then
it's not a replacement.  Further, the OP suggested the value of this
would be that C programmers could get some of the benefits of Forth
and vice-versa.  That to me says that there should be no limits in
Forth code calling C (easy) or C code calling Forth (harder).

For trivial cases, this isn't a problem:

    CCODE:
        int square(int x) { return x*x; }
    ;CCODE

    3 square . 9 ok

Or even the reverse:

    : square dup * ;

    CCODE:
        printf("%d", square(3));
    ;CCODE

    9 ok

I can easily imagine the system mapping the top of the stack to the
variable x, and replacing it after the function ends with the return
value.  I don't have a problem with obvious mappings like this,
because, well, they're obvious.  The cross-language semantics here
aren't a problem because there isn't any pushing of the boundaries of
either language; you're dealing with the lowest common denominator of
the two languages.

That's valid, but it wasn't what the OP described.  And maybe that's
my problem.  If the problem is redefined not as being able to replace
assembly code with C, but being able to have some non-seamless,
reasonable (but incomplete) interoperability between the languages,
then things are easier.  Then instead of thinking about how to return
multiple arguments to the stack from C, we punt and say, "you can't."
Instead of worrying about mapping c-addr/u strings our counted strings
to C, we do something like require the C programmer to use a type
(other than a raw char*) that is specific to the kind of string being
passed.  If C wants to return a structure, we either say, "you can't"
or come up with some idiom to allow it.

And so on.  Again, not what the OP wanted, but what the OP wants is
too complicated.

[toc] | [prev] | [next] | [standalone]

#1001

On Apr 4, 11:55 am, John Passaniti <john.passan...@gmail.com> wrote:
Do you have the trivial implementation of the "reverse" part available
for gforth?:
"Or even the reverse:

    : square dup * ;

    CCODE:
        printf("%d", square(3));
    ;CCODE
"
I am missing callbacks in libcc.fs

[toc] | [prev] | [next] | [standalone]

#1012

On Apr 4, 4:11 pm, pliz <s.m.p...@gmail.com> wrote:
> On Apr 4, 11:55 am, John Passaniti <john.passan...@gmail.com> wrote:
> Do you have the trivial implementation of the "reverse" part available
> for gforth?:
> "Or even the reverse:
>
>     : square dup * ;
>
>     CCODE:
>         printf("%d", square(3));
>     ;CCODE
> "
> I am missing callbacks in libcc.fs

I am saying that it is conceptually trivial.  Most of this discussion
is about what a hybrid Forth/C language would look like, not ready-to-
run code for people to try.

I say it is trivial because an embedded C compiler should be able to
inspect the Forth dictionary in addition to its own symbol table when
generating code.  If the C symbol table didn't find "square" then the
Forth dictionary could be scanned.  Words found in the Forth
dictionary could be called by C by looking at context:

     int x = square(3);

We can tell by context that square is expected to leave an item on the
stack.  Where here:

     foo(42);

We can tell by context that foo doesn't leave anything on the stack.

If the Forth had additional information that overrode these
assumptions (such as stack effect diagrams encoded in some useful
way), the embedded C compiler could use that.

[toc] | [prev] | [next] | [standalone]

#1002

On Apr 4, 1:55 pm, John Passaniti <john.passan...@gmail.com> wrote:
> On Apr 3, 8:34 pm, BruceMcF <agil...@netscape.net> wrote:
>
> > That's what I was referring to as CCODE: ... ;CCODE ~ a way to
> > embed operations written in C (perhaps calling external
> > functions originally designed to be called from C, perhaps
> > entirely embedded), in a way that creates a Forth word that
> > handles the interface, in precisely the same way that an
> > external C-library function interface creates a Forth word
> > that calls the external function.
>
> Maybe the problem here is that I'm looking at this too generally.  The
> OP wants to replace assembly with C.  That to me means that *anything*
> assembly can do, C should be able to do the same.

Except that might be imputed. It might be that what the OP *does* with
assembly, he'd like to be able to do with the same facility with C.
Whether that requires being able to do *everything* that assembly can
do is not automatic.

> If it can't, then it's not a replacement.

If it can do the same kinds of things that the OP uses assembly for in
a mixed assembly/Forth context, then its a replacement.

> Further, the OP suggested the value of this
> would be that C programmers could get some of the benefits of Forth
> and vice-versa.  That to me says that there should be no limits in
> Forth code calling C (easy) or C code calling Forth (harder).

Again, not a necessary implication. To get rapid application
development for an existing code base in C, adding a set of
judiciously selected Forth calls to call the relevant bits of the
existing code base might allow for an interactive development
environment with a different feel ... and of course, and exposure of
results back to C could well be limited to a class of known depth of
call stack and a single returned value. If systems of IRQ handlers can
be built around top level (--) words, then an extension to a C code
base written in Forth could well be built around top level (x*i--x)
words.

And less from speculation and more from personal experience, the most
appealing reason to embed C code is that dozens or hundreds or even
thousands of eyeballs have looked over the code, and it does something
I want to do, and its a hell of a lot easier to copy and paste than to
reimplement.

> For trivial cases, this isn't a problem:
>
>     CCODE:
>         int square(int x) { return x*x; }
>     ;CCODE
>
>     3 square . 9 ok

I want *that* direction to be able to call any given C function and
put the results on the stack any which way, and I do not want to be
constrained to the name choice of the C code, so rather:

CCODE: square  square{ x -- return }
   /* C code */
      int square(int x) { return x*x; }
;CCODE

>
> Or even the reverse:
>
>     : square dup * ;
>
>     CCODE:
>         printf("%d", square(3));
>     ;CCODE
>
>     9 ok

   : square dup * ;

CEXPORT: int square(int val) square{ val -- return } ;CEXPORT

Going in the CEXPORT: ... ;CEXPORT direction, its going to be called
from C, so the spec dictates it first from a C perspective, and then
from a Forth perspective. This is in a Forth source, so in Forth
style, its exported once its known, and no need for anything but spec.

> That's valid, but it wasn't what the OP described.  And maybe that's
> my problem.  If the problem is redefined not as being able to replace
> assembly code with C, but being able to have some non-seamless,
> reasonable (but incomplete) interoperability between the languages,
> then things are easier.

As I've used assembler together with Forth, its been a non-seamless,
reasonable (but incomplete) interoperability between the languages.

[toc] | [prev] | [next] | [standalone]

#1003

On 4/4/11 1:33 PM, BruceMcF wrote:
> On Apr 4, 1:55 pm, John Passaniti<john.passan...@gmail.com>  wrote:
...
> If it can do the same kinds of things that the OP uses assembly for in
> a mixed assembly/Forth context, then its a replacement.
>
>>   Further, the OP suggested the value of this
>> would be that C programmers could get some of the benefits of Forth
>> and vice-versa.  That to me says that there should be no limits in
>> Forth code calling C (easy) or C code calling Forth (harder).
>
> Again, not a necessary implication. To get rapid application
> development for an existing code base in C, adding a set of
> judiciously selected Forth calls to call the relevant bits of the
> existing code base might allow for an interactive development
> environment with a different feel ... and of course, and exposure of
> results back to C could well be limited to a class of known depth of
> call stack and a single returned value. If systems of IRQ handlers can
> be built around top level (--) words, then an extension to a C code
> base written in Forth could well be built around top level (x*i--x)
> words.
>
> And less from speculation and more from personal experience, the most
> appealing reason to embed C code is that dozens or hundreds or even
> thousands of eyeballs have looked over the code, and it does something
> I want to do, and its a hell of a lot easier to copy and paste than to
> reimplement.

But for being able to use pre-existing, tested C code, it's sufficient 
to compile it separately and call it from Forth, which many Forths allow.

I know that MPE, FORTH, Inc., and probably a number of folks here have 
worked on applications written in multiple languages, and have been able 
to establish very convenient cross-language interoperability, which is 
much easier than full embedding.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#1004

On Apr 4, 10:31 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> But for being able to use pre-existing, tested C code, it's sufficient
> to compile it separately and call it from Forth, which many Forths allow.

Yes, I agree, the OP was not referring to sufficiency alone, but to
something more ambitious, since one of the more interesting things to
do with that code is to break it into pieces and then put it together
again in new and hopefully surprising ways.

> I know that MPE, FORTH, Inc., and probably a number of folks here have
> worked on applications written in multiple languages, and have been able
> to establish very convenient cross-language interoperability, which is
> much easier than full embedding.

The kind of embedding that John is talking about would be much easier
with AWK than with C, though as a language originally designed as a
unix shell tool, its straightforward enough in a Forth with a shell
command line feature to write an AWK script embedding word that saves
the embedded script as a file and then runs it on the desired data
file.

Obviously you need a harness to bridge each implementations approach
to handling directories, other than that it could be close to standard
code.

[toc] | [prev] | [next] | [standalone]

#1014

On Apr 4, 10:52 pm, BruceMcF <agil...@netscape.net> wrote:
> The kind of embedding that John is talking about would be
> much easier with AWK than with C, though as a language
> originally designed as a unix shell tool, its
> straightforward enough in a Forth with a shell command
> line feature to write an AWK script embedding word that
> saves the embedded script as a file and then runs it
> on the desired data file.

I don't see awk or any other high-level language as being easier than
C to embed.  Both Forth and C are relatively low-level languages with
similar views about the underlying machine.  The impedance mismatches
have more to do with things like C functions not being able to return
multiple values, Forth words not being aware of typed pointers (and
thus having to do pointer math explicitly), differences in strings, C
allowing an implicit drop of return values from functions used as
statements, etc.  None of this is insurmountable, but it's things that
get in the way.

On the other hand, interfacing to high-level languages is going to
impose a much larger impedance mismatch, just as it does for C.  In
most such languages, variables don't have types, but values do, and
these values are often coerced as needed to the proper type of a
particular operation.  For example, in awk:

BEGIN {
    a = 2
    b = "3"
    c = a*b
    d = "I have " c " things"
    print(d)
}

This would print "I have 6 things" which means that the assignment to
c silently coerced b into a number, and the assignment to d silently
coerced from a number to a string for the concatenation.
Interoperability between awk and Forth would be easier in the Forth-
>awk direction but would require all such calls into awk to decorate
values with their types.  In the awk->Forth direction, you would
either have to canonicalize to a specific type or have Forth be aware
of types and have the programmer coerce them as necessary.  Either
way, barring any cleverness (which will invariably fail in some
cases), interoperability is going to be much more painful than between
C.

[toc] | [prev] | [next] | [standalone]

#1017

On Apr 5, 12:58 pm, John Passaniti <john.passan...@gmail.com> wrote:
> I don't see awk or any other high-level language as being easier than
> C to embed.  Both Forth and C are relatively low-level languages with
> similar views about the underlying machine.  The impedance mismatches
> have more to do with things like C functions not being able to return
> multiple values, Forth words not being aware of typed pointers (and
> thus having to do pointer math explicitly), differences in strings, C
> allowing an implicit drop of return values from functions used as
> statements, etc.  None of this is insurmountable, but it's things that
> get in the way.

Only if you embed at a lower level than would be of any use in any
event. Embedding an awk expression in a Forth word is silly, but
embedding an awk procedure processing a file could be quite handy.

[toc] | [prev] | [next] | [standalone]

#1024

On Apr 5, 9:36 pm, BruceMcF <agil...@netscape.net> wrote:
> Only if you embed at a lower level than would be of any use
> in any event. Embedding an awk expression in a Forth word
> is silly, but embedding an awk procedure processing a file
> could be quite handy.

Conceptually, sure.  And we can abstractly talk about all sorts of
interesting blended languages and think how they would be useful.  But
as I've pointed out before, the challenge here is to come up with
concrete syntax and semantics.  And that doesn't take a working
system.  That only requires imagination and thinking about how the
resulting hybrid language would work.

Can you provide a sample of what Forth/awk code doing something useful
would look like?

[toc] | [prev] | [next] | [standalone]

#1028

On Apr 6, 4:53 pm, John Passaniti <john.passan...@gmail.com> wrote:
> Can you provide a sample of what Forth/awk code doing something useful
> would look like?

At the moment, the task that inspired that is a tottering pile of
nested BAT and grep scripts driving wget, so my thinking on that front
is in terms of process flow rather than what it looks like. Each
embedded awk scriptlet builds the data file(s) connected to each step
in the process ~ stripping the list of series indexed at the bootleg
streaming site into a series index file, testing the series index file
against the rights owner series files to get the pages for each
episode, getting the page for each episode and filtering down to the
embedded stream link, filtering the embedded stream links into
canonical forms for host sites with various functioning link formats,
building the spider script for wget, and filtering the log for live
links, takedowns and undetermined status results.

I don't really have any grand Renaissance of Forth in mind, I just
know which of those programming tasks I'd rather do in Forth, which
I'd rather do in awk, and the fact that I'd prefer it all be one file
rather than a collection.

AWKLET: takedown ( ca u -- )
# functioning awk code here
;AWKLET
\ functioning forth code here

--spider$ >t
infile$ +t
outfile$ +t
\ ...

t@ takedown
\ ...

However, there's no particular concern with portable Forth code. Since
the support tools have to be freely distributable, it'll be gforth and
wget and an open source awk, one Windows set and one Linux set.
Whether the scriptlet is fed over stdio or a temp file or a file
spawned out of the source when it it first compiled would be whichever
seems to work better after some experimentation.

[toc] | [prev] | [next] | [standalone]

#1041

On Apr 6, 6:29 pm, BruceMcF <agil...@netscape.net> wrote:
> At the moment, the task that inspired that is a tottering
> pile of nested BAT and grep scripts driving wget, so my
> thinking on that front is in terms of process flow rather
> than what it looks like.

The reason I'm focusing on what it looks like is that when one
actually sits down and types out code in these hybrid languages, it
forces one to think about the various issues behind language
integration.  From simple issues like how one "wraps" the other
language in some kind of marker to indicate it isn't Forth code to
more significant issues like how to get the code in both languages to
communicate with each other, the exercise of writing code forces one
to confront the various issues very quickly.  And that's where I see
the most interesting questions and (potentially) the most creative
solutions are.

[toc] | [prev] | [next] | [standalone]

#1053

On Apr 7, 11:35 am, John Passaniti <john.passan...@gmail.com> wrote:
> The reason I'm focusing on what it looks like is that when one
> actually sits down and types out code in these hybrid languages, it
> forces one to think about the various issues behind language
> integration.

The various issues behind language integration in this case are how to
pass the input filename and output filename and how to get and return
the error return. Since the AWK script for a given action is a black
box to Forth, and the language of the caller is of no relevance to the
AWK script, I'll pass the filenames as counted strings and just assume
that I can massage the AWK return into an ior:

AWKLET: name ( ca1 ca2 -- ior }
#Awk scrip here
;AWKLET

AWKLET: foo ( ca1 ca2 -- ior )
{ print $1 }
;AWKLET

Given the name foo, AWKLET: creates an empty macro %AWKfoo% which can
be defined before calling foo to pass special options, eg, specify a
separator regular expression. Therefore, "%" is not a valid character
in an AWKLET word name.

[toc] | [prev] | [next] | [standalone]

#1011

On Apr 4, 4:33 pm, BruceMcF <agil...@netscape.net> wrote:
> On Apr 4, 1:55 pm, John Passaniti <john.passan...@gmail.com> wrote:
>
> > On Apr 3, 8:34 pm, BruceMcF <agil...@netscape.net> wrote:
>
> > > That's what I was referring to as CCODE: ... ;CCODE ~ a way to
> > > embed operations written in C (perhaps calling external
> > > functions originally designed to be called from C, perhaps
> > > entirely embedded), in a way that creates a Forth word that
> > > handles the interface, in precisely the same way that an
> > > external C-library function interface creates a Forth word
> > > that calls the external function.
>
> > Maybe the problem here is that I'm looking at this too generally.  The
> > OP wants to replace assembly with C.  That to me means that *anything*
> > assembly can do, C should be able to do the same.
>
> Except that might be imputed. It might be that what the OP *does* with
> assembly, he'd like to be able to do with the same facility with C.
> Whether that requires being able to do *everything* that assembly can
> do is not automatic.
>
> > If it can't, then it's not a replacement.
>
> If it can do the same kinds of things that the OP uses assembly for in
> a mixed assembly/Forth context, then its a replacement.
>
> > Further, the OP suggested the value of this
> > would be that C programmers could get some of the benefits of Forth
> > and vice-versa.  That to me says that there should be no limits in
> > Forth code calling C (easy) or C code calling Forth (harder).
>
> Again, not a necessary implication. To get rapid application
> development for an existing code base in C, adding a set of
> judiciously selected Forth calls to call the relevant bits of the
> existing code base might allow for an interactive development
> environment with a different feel ... and of course, and exposure of
> results back to C could well be limited to a class of known depth of
> call stack and a single returned value. If systems of IRQ handlers can
> be built around top level (--) words, then an extension to a C code
> base written in Forth could well be built around top level (x*i--x)
> words.
>
> And less from speculation and more from personal experience, the most
> appealing reason to embed C code is that dozens or hundreds or even
> thousands of eyeballs have looked over the code, and it does something
> I want to do, and its a hell of a lot easier to copy and paste than to
> reimplement.
>
> > For trivial cases, this isn't a problem:
>
> >     CCODE:
> >         int square(int x) { return x*x; }
> >     ;CCODE
>
> >     3 square . 9 ok
>
> I want *that* direction to be able to call any given C function and
> put the results on the stack any which way, and I do not want to be
> constrained to the name choice of the C code, so rather:
>
> CCODE: square  square{ x -- return }
>    /* C code */
>       int square(int x) { return x*x; }
> ;CCODE
>
>
>
> > Or even the reverse:
>
> >     : square dup * ;
>
> >     CCODE:
> >         printf("%d", square(3));
> >     ;CCODE
>
> >     9 ok
>
>    : square dup * ;
>
> CEXPORT: int square(int val) square{ val -- return } ;CEXPORT
>
> Going in the CEXPORT: ... ;CEXPORT direction, its going to be called
> from C, so the spec dictates it first from a C perspective, and then
> from a Forth perspective. This is in a Forth source, so in Forth
> style, its exported once its known, and no need for anything but spec.

Here's an equivalent (my own copy of a heavily modified Win32Forth);

  fload exports.f

  1 export: square ( a -- a*a ) dup * ;
  ( export: places the word in an exports wordlist, and makes )
  ( it available to external code                             )

  ( test it, invoke is an external linkage call               )
  also exports
  3 ' square invoke .

The external entry points (square in this example) are built at run
time and callable from C or any other language that supports late
bound calls. I've successfully used this method to generate code that
supports GTK (snippet here).

library libgtk-win32-2.0-0.dll ( gtk libs )
library libgobject-2.0-0.dll

...

( dynamically generate exports for GTK calls )
2 __cdecl export: on_checkbutton1_toggled { button  u -- true }
... ;

2 __cdecl export: on_button3_clicked { button  u -- true }
... ;

( much supporting GTK stuff ... )

>
> > That's valid, but it wasn't what the OP described.  And maybe that's
> > my problem.  If the problem is redefined not as being able to replace
> > assembly code with C, but being able to have some non-seamless,
> > reasonable (but incomplete) interoperability between the languages,
> > then things are easier.
>
> As I've used assembler together with Forth, its been a non-seamless,
> reasonable (but incomplete) interoperability between the languages.

[toc] | [prev] | [next] | [standalone]

#1013

On Apr 4, 7:33 pm, BruceMcF <agil...@netscape.net> wrote:
> Except that might be imputed. It might be that what the OP
> *does* with assembly, he'd like to be able to do with the
> same facility with C.

Well, yeah, that's true.  And it's true in the other direction as
well.  I'm a CS guy who works with EE guys who for the most part
really do treat C as a high-level assembly language.  Their C code
tends to be very primitive and often misses out on effective use of
the language.  So yeah, lacking a specific needs or lacking
sophistication with either Forth or C, one could probably get by with
a subset and be happy.  Wouldn't make me happy, but I'm not the OP or
someone who finds the overall idea terribly compelling.

> As I've used assembler together with Forth, its been a
> non-seamless, reasonable (but incomplete) interoperability
> between the languages.

But the difference with assembler is that you have access to
everything.  Yes, you have to do everything yourself at a very low
level, but you aren't fundamentally stopped from doing anything you
want.  If you want to (for example) push a value on the return stack,
you can.  You don't have that ability in C, because C is abstracting
the underlying machine.  But as you wrote, if you don't need to do any
of the things this hybrid language doesn't let you do, you're fine.

[toc] | [prev] | [next] | [standalone]

#1030

On Apr 4, 1:55 pm, John Passaniti <john.passan...@gmail.com> wrote:
> On Apr 3, 8:34 pm, BruceMcF <agil...@netscape.net> wrote:
>
> > That's what I was referring to as CCODE: ... ;CCODE ~ a way to
> > embed operations written in C
>
> Maybe the problem here is that I'm looking at this too generally.  The
> OP wants to replace assembly with C.  
>
> For trivial cases, this isn't a problem:
>
>     CCODE:
>         int square(int x) { return x*x; }
>     ;CCODE
>
>     3 square . 9 ok
>
> Then instead of thinking about how to return
> multiple arguments to the stack from C, we punt and say, "you can't."
>

That's just what I wanted. When I used RSC-Forth first time long ago I
was glad to be able to use all my machine language programs, like LCD
and keypad drivers, barcode readers, CRC etc.
There was a totally easy interface. It only connected the starting
address of my old program inside a code: definition, like that:

CODE DISOUT  ( Char --- )  \ nowadays this would be: CODE: DISOUT
XSAVE STX,         \ save current Stackpointer
TOP LDA,           \ read current TOS (8 bit)
 ' #DISOUT @ JSR,  \ execute machine code
XSAVE LDX,         \ restore Stackpointer
INX, INX,          \ drop TOS value
NEXT JMP,          \ go to Next
END-CODE           \ nowadays this is CODE;

That's what I had in mind could be done in C, too. The whole procedure
I took from the RSC-Forth manual, and the only thing I had to take
care of, was not to get into a conflict with registers used by RSC-
Forth.
To save the X register was important because this was needed in my
machine code program, and it was used as the stack pointer inside RSC-
Forth.

My idea was to use C programs only in case I really need it because of
speed. Elizabeth Rather said that this is not needed any more, but
with microprocessors I doubt it. For me it would help to deal better
with new microprocessors when assembly programs are really hard to
learn how to write.

I appreciate so much that Forth made my programming life easy. I could
deal with microprocessors and projects which I never could have done
without Forth.

[toc] | [prev] | [next] | [standalone]

#1185

On 4 Apr., 13:55, John Passaniti <john.passan...@gmail.com> wrote:
> On Apr 3, 8:34 pm, BruceMcF <agil...@netscape.net> wrote:
>
> > That's what I was referring to as CCODE: ... ;CCODE ~ a way to
> > embed operations written in C ...
>
> For trivial cases, this isn't a problem:
>
>     CCODE:
>         int square(int x) { return x*x; }
>     ;CCODE
>
>     3 square . 9 ok
>
> I can easily imagine the system mapping the top of the stack to the
> variable x, and replacing it after the function ends with the return
> value.  I don't have a problem with obvious mappings like this,
> because, well, they're obvious.
>

That's just what I wanted!
A while ago I got a recommendation to look for Loeliger's "Threaded
Interpretive Languages" and I have it on my desk today. He writes more
clearly what I am asking for:

"A TIL assembler is very different from the usual concept of an
assembler. The TIL assembler is specifically designed to allow the
addition of keywords to the TIL rather than to produce stand-alone
program or subroutines." (Page 182)

If you read "Forth" instead of "TIL" and "C-compiler" instead of
"assembler", then this is just what my recommendation is. To make
programming of primitives possible for people used to program in C
without knowledge of the target assembly language. And reading your
comments this looks feasible.

The other part is mentioned, too, by Loeliger: "... it is not unusual
to incorporate library routines by stealing the source code ... and
merging it with the program source code. A library of such source code
routines is very helpful in generating programs." (Page 237/238)

This looks like Loeliger has seen this the same way I have. When I
started using Forth, I had a bunch of software written in assembler
(barcode-reader, magstripe-reader, LCD-control, Keypad-scan), and the
only thing I did was to create a header and a data connection for each
of these software modules. This seems to be the main problem when
using C-libraries, IIRC. But I am sure there is a method to get these
things connected. But okay, a first start would be the possibility to
write primitives in C according to Loeliger on Page 182.

[toc] | [prev] | [next] | [standalone]

#1192

On Apr 12, 6:47 pm, Bluebee <visualfo...@rocketmail.com> wrote:
> If you read "Forth" instead of "TIL" and "C-compiler" instead
> of "assembler", then this is just what my recommendation is. To
> make programming of primitives possible for people used to
> program in C without knowledge of the target assembly language.
> And reading your comments this looks feasible.

Sure, but just because something is possible, doesn't necessarily mean
it is a good idea.  If you've read my other comments, I've pointed out
that there are *many* problems with the overall idea.  Here is yet
another one:

Most non-trivial C code will invariably use pointers.  Pointers in C
are more than just a memory address.  They have type information and
therefore, they have size information.  C uses this information as
part of the array/pointer duality to great effect, and it allows for
some very succinct and intuitive pointer arithmetic.  Forth has
nothing like it, although it can certainly be added.  The point being
that data that crosses the Forth/C barrier has a loss of information,
and that loss will result in more verbose C *and* Forth code.

And that added verbosity (along with the maintenance needed to ensure
that both Forth and C are happy) will directly cut at the heart of
what you're trying to do.  So yeah, you can do it.  But the result is
likely to be unappealing.

Again, I urge you and anyone who thinks this embedding of C in Forth
to be a good idea to stop thinking abstractly about goals and instead
sit down and write some actual code in this proposed hybrid.  Do that,
and I think you'll quickly come up against the problems with the
idea.  Maybe those problems have interesting and useful solutions, but
until you do some design work and experience the impedance mismatch
between the languages, you won't see them.

> The other part is mentioned, too, by Loeliger: "... it is not
> unusual to incorporate library routines by stealing the source
> code ... and merging it with the program source code. A library
> of such source code routines is very helpful in generating
> programs." (Page 237/238)

Yes, I'm sure all of us at one time or another has "stolen" our own
code from other projects, or adapted code we found from someone else.
But far more often than not, when crossing language boundaries, that
code isn't used verbatim; it's translated into the target language.
Aside from avoiding the complexity of trying to merge two languages
together, the benefit is that you can fully use the capabilities of
the target language.

> This looks like Loeliger has seen this the same way I have.

I haven't read his book, but it's more likely he was talking about
taking assembly language code and "merging" it in Forth.  The process
of "merging" isn't literal copying, but is fixing up the assembly
language code to meet the requirements of the Forth-- calling
conventions, register usage, etc.

But again, please sit down and write some code.  See how it looks.
Think about the cross-language mechanisms.  I think you'll see that
while it can be done, the effect on the code isn't going to be pretty,
and there is a fairly large cost in complexity.  Far simpler is to use
wetware to convert code between the languages.

[toc] | [prev] | [next] | [standalone]

#1193

On 13 Apr., 12:27, John Passaniti <john.passan...@gmail.com> wrote:
> On Apr 12, 6:47 pm, Bluebee <visualfo...@rocketmail.com> wrote:
>
> > If you read "Forth" instead of "TIL" and "C-compiler" instead
> > of "assembler", then this is just what my recommendation is. To
> > make programming of primitives possible for people used to
> > program in C without knowledge of the target assembly language.
> > And reading your comments this looks feasible.
>
> Sure, but just because something is possible, doesn't necessarily mean
> it is a good idea.  
>
> But again, please sit down and write some code.  See how it looks.

That's my problem. I am not a C-programmer, and I never wrote my own
Forth, I am a Forth user. I am not able to do these tests, that's why
I was asking for your opinion and your help.

But thanks for letting me know that Forth and C are programming
languages, but assembler is not.

I assumed a compiled C-code is as usable as an assembled peace of
code. Seems to be it is not.
It's a pity, because there are so many useful microprocessor C-
packages out there, especially for I/O (USB etc). So if I decide to
stay with Forth - and I will - I have to "reinvent the wheel" or to
analyze the C-code and rebuild it by Forth. I did this once for my ARM
project. I never had learned C, but for a few lines of code it worked.

I am hooked with Forth, because it does everything for me with ease
(and I don't like C). But I recognize that young people who are
starting with low cost microprocessor kits will not see any advantage
of Forth because there are all these C examples and libraries for
their kits.

How will there be a new generation of Forth programmers?

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web