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

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

Which input to use?

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

Contents

  Which input to use? Lauri Alanko <la@iki.fi> - 2014-04-06 14:13 +0000
    Re: Which input to use? mhx@iae.nl - 2014-04-06 07:59 -0700
      Re: Which input to use? "Elizabeth D. Rather" <erather@forth.com> - 2014-04-06 08:26 -1000
        Re: Which input to use? hughaguilar96@yahoo.com - 2014-04-19 19:48 -0700
          Re: Which input to use? "Alex McDonald" <blog@rivadpm.com> - 2014-04-21 02:09 +0100
            Re: Which input to use? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-21 04:01 -0400
    Re: Which input to use? hughaguilar96@yahoo.com - 2014-04-06 23:16 -0700
    Re: Which input to use? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-07 10:44 +0000
    Re: Which input to use? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-07 17:45 +0000
      Re: Which input to use? mhx@iae.nl - 2014-04-07 12:09 -0700
        Re: Which input to use? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-08 16:11 +0000
          Re: Which input to use? mhx@iae.nl - 2014-04-08 13:05 -0700
      Re: Which input to use? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-08 03:18 -0500
        Re: Which input to use? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-08 10:49 +0000
          Re: Which input to use? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-09 16:07 +0000
            Re: Which input to use? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-04-10 01:36 +0000
              Re: Which input to use? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-11 17:59 +0000
        Re: Which input to use? "Alex McDonald" <blog@rivadpm.com> - 2014-04-08 12:28 +0100
        Re: Which input to use? hughaguilar96@yahoo.com - 2014-04-08 21:03 -0700
          Re: Which input to use? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-04-09 03:14 -0500
        EXECUTE-PARSING (was: Which input to use?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-04-09 15:13 +0000
          Re: EXECUTE-PARSING (was: Which input to use?) Bernd Paysan <bernd.paysan@gmx.de> - 2014-04-09 18:54 +0200
            Re: EXECUTE-PARSING (was: Which input to use?) Alexander Skobelev <al.skobelev@gmail.com> - 2014-04-09 22:44 -0700

Page 1 of 2  [1] 2  Next page →

#29321 — Which input to use?

Hello.

I'm a bit confused by the design of Forth's input system. If I read
the Forth 2012 draft correctly, we have the following:

* The user input device. This is just some system-dependent input
source that is read with KEY and ACCEPT.

* Files. These are read with READ-FILE and READ-LINE.

* The input source. This is used by parsing words during
interpretation. The input source is accessed through the input buffer
with SOURCE, >IN and REFILL.

This all seems terribly complicated from the programmer's point of
view. What if I just want to write general-purpose text processing
code that can be used with arbitrary inputs? Now it seems I have to
write a separate abstraction layer to deal with the above cases.

I would have expected there to be either a way to make a file into the
user input device, or to treat the user input device as a file, so one
could use a single interface uniformly.

Funnily enough, there is one abstraction layer already in place: the
input source, which can be set to read either from the user input
device (with QUIT) or from a file (with INCLUDE-FILE). It even has a
number of useful parsing primitives available already.

But unfortunately it seems that there is no way to change the input
source without starting to interpret it immediately. So it seems that
the input source cannot be used as an input abstraction layer if we
are reading data that isn't structured as Forth words.

Have I understood the situation correctly? Is there some reason for
these limitations?


Lauri

[toc] | [next] | [standalone]

#29324

> I'm a bit confused by the design of Forth's input system. 
> If I read the Forth 2012 draft correctly, we have the following

The Standard is the worst possible document to learn Forth from.
Work your way through the Wikipedia article and start on the references.

-marcel

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

#29328

On 4/6/14 4:59 AM, mhx@iae.nl wrote:
>> I'm a bit confused by the design of Forth's input system.
>> If I read the Forth 2012 draft correctly, we have the following
>
> The Standard is the worst possible document to learn Forth from.
> Work your way through the Wikipedia article and start on the references.
>
> -marcel

I agree with Marcel, you need to be using materials intended for 
teaching folks how to use Forth, not a Standard that prescribes rules 
from which a newbie has to generalize.

Most Forths come with some sort of user documentation. SwiftForth, for 
example, which is the one I am most familiar with, includes the book 
Forth Programmer's Handbook in pdf, along with its specific produce 
manual. A free evaluation version (with full capabilities, it just 
doesn't support making distributable turnkey programs) is available from 
forth.com. Also, my tutorial Forth Application Techniques, is available 
from Amazon. It covers these issues in detail, with examples and exercises.

In brief: the input abstraction works pretty much as you wish for 
interpretable text. Input of other kinds (e.g., binary data) is even easier.

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]

#29727

On Sunday, April 6, 2014 11:26:53 AM UTC-7, Elizabeth D. Rather wrote:
> On 4/6/14 4:59 AM, mhx@iae.nl wrote:
> >> I'm a bit confused by the design of Forth's input system.
> >> If I read the Forth 2012 draft correctly, we have the following
 
> > The Standard is the worst possible document to learn Forth from.
> > Work your way through the Wikipedia article and start on the references.

> I agree with Marcel, you need to be using materials intended for 
> teaching folks how to use Forth, not a Standard that prescribes rules 
> from which a newbie has to generalize.

It is unlikely that we will ever hear from her again --- it is incredibly insulting to tell anybody to read Wikipedia --- actually, the term "newbie" is pretty insulting too.

> In brief: the input abstraction works pretty much as you wish for 
> interpretable text. Input of other kinds (e.g., binary data) is even easier.

No it doesn't. You don't know what the term "abstraction layer" means. The question went over your head.

Also, all that talk about EXECUTE-PARSING was completely off-topic. This is pretty typical on C.L.F. --- when people don't understand a question, or don't want to answer it because doing so involves admitting to a problem in ANS-Forth, you divert the discussion into something irrelevant. Well, at least we didn't trot out the issue with IF(N>N+1) in C again --- if everybody reading C.L.F. dies of boredom (and I'm pretty close), then C.L.F. will finally fizzle out.

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

#29744

on 20/04/2014 03:48:23, His Hughness Prince Aguilar of the Principality
of Taxi wrote: > ...if everybody reading C.L.F. dies of
> boredom (and I'm pretty close), ...

If you desire to expire, just go for it. Don't keep breathing on our
account.

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

#29746

On Sun, 20 Apr 2014 21:09:43 -0400, Alex McDonald <blog@rivadpm.com> wrote:
> on 20/04/2014 03:48:23, His Hughness Prince Aguilar of the Principality
> of Taxi wrote:

>> ...if everybody reading C.L.F. dies of boredom (and I'm
>> pretty close), ...
>
> If you desire to expire, just go for it. Don't keep breathing
> on our account.

After playing "air guitar" for three minutes, my hand hurts...

Uh, did someone say something? important? topical?

Oh, it's *YOU* again...  Apparently, the reports you were run
over by a reckless, maniacal city bus driver were fraudulent.
It could happen.  I'm sure that if Hugh can drive a taxi,
he could drive a bus.

Well, no one said an escaped, coked up mental patient like you
can't become a great musician someday, but that cocaine-laced
Thames water pushes the usage over the edge just a bit, doesn't
it?  Apparently, driving anti-clockwise for life around London
in never ending unwindable circles just seals the insanity deal
for you...

(For those DUMB enough to believe that any of that above
about Alex is true and not just an abusive insult, GO AWAY.)

Hmm, since there is nothing of value or insight or topicality
to read here by either Hugh or Alex, just what should my next
song for air guitar be?:

Snowblind Friend - "... he bought a one way ticket on an airline made of  
snow ..."
Cocaine - "... you got bad news, you wanna kick them blues ... "
Twist of Cain - "... twist of Cain ... drives my brain ... from a God  
below ..."
Snowblind - "... lying snowblind in the sun, will my ice age ever come?"
Master of Puppets - "... come crawling faster ... obey your master ...  
your life burns faster ..."


Rod Pemberton

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

#29357

On Sunday, April 6, 2014 7:13:01 AM UTC-7, Lauri Alanko wrote:
> Hello.
> 
> I'm a bit confused by the design of Forth's input system. If I read
> the Forth 2012 draft correctly, we have the following:
> 
> * The user input device. This is just some system-dependent input
> source that is read with KEY and ACCEPT.
> 
> * Files. These are read with READ-FILE and READ-LINE.
> 
> * The input source. This is used by parsing words during
> interpretation. The input source is accessed through the input buffer
> with SOURCE, >IN and REFILL.
> 
> This all seems terribly complicated from the programmer's point of
> view. What if I just want to write general-purpose text processing
> code that can be used with arbitrary inputs? Now it seems I have to
> write a separate abstraction layer to deal with the above cases.

You are quite correct --- in ANS-Forth you do have to write a separate abstraction layer yourself. 

The way that I would do this, is to write a vectored function that obtains a line of input from some input source. The vector can be patched at run-time to point to a function specific to whatever input source you need at that time. In my novice package (http://www.forth.org/novice.html) I have DEFER and the more efficient VECTOR that can be used for this.

As I recall, UR/Forth had a way to make OPEN-FILE open up the console as an input source as if it were a file, or open up the serial line as an input source as if it were a file, and maybe some other devices as well. This is an example of embedding the feature in the language. I don't really like this idea though, because it limits the feature to input devices that the language designer knows about (console and serial port). It is actually better to make the user (you) write the abstraction layer yourself, because this allows you to support any kind of device that your computer may have now or in the future --- doing so is not particularly onerous, and it gives you flexibility for the future.

P.S. Don't pay any attention to anybody encourages you to read Wikipedia articles --- Wikipedia is just pseudo-intellectual nonsense, primarily used by high-school students writing reports on subjects that they know nothing about to be graded by teachers who also know nothing about the subject. Also, don't pay any attention to anybody who encourages you to buy a $50 book --- that is just a scam to get your money.

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

#29371

In article <lhrndd$2pa$1@speranza.aioe.org>, Lauri Alanko  <la@iki.fi> wrote:
>Hello.
>
>I'm a bit confused by the design of Forth's input system. If I read
>the Forth 2012 draft correctly, we have the following:
>
>* The user input device. This is just some system-dependent input
>source that is read with KEY and ACCEPT.
>
>* Files. These are read with READ-FILE and READ-LINE.
>
>* The input source. This is used by parsing words during
>interpretation. The input source is accessed through the input buffer
>with SOURCE, >IN and REFILL.
>
>This all seems terribly complicated from the programmer's point of
>view. What if I just want to write general-purpose text processing
>code that can be used with arbitrary inputs? Now it seems I have to
>write a separate abstraction layer to deal with the above cases.
>
>I would have expected there to be either a way to make a file into the
>user input device, or to treat the user input device as a file, so one
>could use a single interface uniformly.
>
>Funnily enough, there is one abstraction layer already in place: the
>input source, which can be set to read either from the user input
>device (with QUIT) or from a file (with INCLUDE-FILE). It even has a
>number of useful parsing primitives available already.
>
>But unfortunately it seems that there is no way to change the input
>source without starting to interpret it immediately. So it seems that
>the input source cannot be used as an input abstraction layer if we
>are reading data that isn't structured as Forth words.
>
>Have I understood the situation correctly? Is there some reason for
>these limitations?

You express some concerns about the internal design of Forth.
IMO it probably boils down to some implementation issue where starting
from the ISO language spec puts you on the wrong foot.

I designed my Forth (ciforth) more along your idea, e.g. evaluate reads
like this. (I'm leaving out exceptions.)
: EVALUATE SAVE   SET-SRC   INTERPRET   RESTORE ;

and INCLUDED is basically

: INCLUDED GET-FILE EVALUATE ;

after SET-SRC you can parse the input file, using PARSE-NAME
and PARSE.

So internally it is more elegant, but then there is more effort
to get it ISO compliant. (Then one can't totally succeed because
ISO let some of the internals shine through that can't be hidden.)

I've made SET-SRC easy by requiring that text to scanned must be
in memory. (This sounds weird, how could it not be?)

>
>
>Lauri

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]

#29389

Lauri Alanko <la@iki.fi> writes:
>Hello.
>
>I'm a bit confused by the design of Forth's input system. If I read
>the Forth 2012 draft correctly, we have the following:
>
>* The user input device. This is just some system-dependent input
>source that is read with KEY and ACCEPT.
>
>* Files. These are read with READ-FILE and READ-LINE.
>
>* The input source. This is used by parsing words during
>interpretation. The input source is accessed through the input buffer
>with SOURCE, >IN and REFILL.
>
>This all seems terribly complicated from the programmer's point of
>view. What if I just want to write general-purpose text processing
>code that can be used with arbitrary inputs? Now it seems I have to
>write a separate abstraction layer to deal with the above cases.
...
>Funnily enough, there is one abstraction layer already in place: the
>input source, which can be set to read either from the user input
>device (with QUIT) or from a file (with INCLUDE-FILE). It even has a
>number of useful parsing primitives available already.
>
>But unfortunately it seems that there is no way to change the input
>source without starting to interpret it immediately. So it seems that
>the input source cannot be used as an input abstraction layer if we
>are reading data that isn't structured as Forth words.
>
>Have I understood the situation correctly? Is there some reason for
>these limitations?

You have understood it correctly, as far as the standard is concerned.
As for the reason: I think there are too few people on the standards
committee who are interested in text processing.  Admittedly I have
not tried much in that direction, but even EXECUTE-PARSING, which
would be useful beyond text processing, has been met with resistance.

So I recommend Gforth for this kind of application; it was written
with that stuff in mind, and has been used for that stuff, and it
contains the features you are missing:

* You can use KEY on any file with INFILE-EXECUTE
  <http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Redirection.html>.

* You can use file words like READ-FILE or READ-LINE on standard input
  with STDIN
  <http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/General-files.html>.

* And you can use any file as input source with EXECUTE-PARSING-FILE
  <https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/The-Input-Stream.html>

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#29394

On Monday, April 7, 2014 7:45:01 PM UTC+2, Anton Ertl wrote:
[..]
> So I recommend Gforth for this kind of application; it was written
> with that stuff in mind, and has been used for that stuff, and it
> contains the features you are missing:
> 
> * You can use KEY on any file with INFILE-EXECUTE
>   <http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Redirection.html>.
> 
> * You can use file words like READ-FILE or READ-LINE on standard input
>   with STDIN
>   <http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/General-files.html>.
> * And you can use any file as input source with EXECUTE-PARSING-FILE
>   <https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/The-Input-Stream.html>

This shows the power of documentation (or a relaxed exposition of 
general issues). Without your posting I would not have noticed the 
improved consistency of the language.

-marcel 

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

#29450

mhx@iae.nl writes:
>On Monday, April 7, 2014 7:45:01 PM UTC+2, Anton Ertl wrote:
>[..]
>> So I recommend Gforth for this kind of application; it was written
>> with that stuff in mind, and has been used for that stuff, and it
>> contains the features you are missing:
>> 
>> * You can use KEY on any file with INFILE-EXECUTE
>>   <http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Redirection.html>.
>> 
>> * You can use file words like READ-FILE or READ-LINE on standard input
>>   with STDIN
>>   <http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/General-files.html>.
>> * And you can use any file as input source with EXECUTE-PARSING-FILE
>>   <https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/The-Input-Stream.html>
>
>This shows the power of documentation (or a relaxed exposition of 
>general issues). Without your posting I would not have noticed the 
>improved consistency of the language.

Can you elaborate on that?  It sounds interesting, but I don't know
what exactly you mean.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#29460

anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote Re: Which input to use?

> mhx@iae.nl writes:
>>On Monday, April 7, 2014 7:45:01 PM UTC+2, Anton Ertl wrote:
[..]
>>> So I recommend Gforth for this kind of application; it was written
>>> with that stuff in mind, and has been used for that stuff, and it
>>> contains the features you are missing:
>>> 
>>> * You can use KEY on any file with INFILE-EXECUTE
[..]
>>> * You can use file words like READ-FILE or READ-LINE on standard input with STDIN
[..]
>>> * And you can use any file as input source with EXECUTE-PARSING-FILE
[..]
>>This shows the power of documentation (or a relaxed exposition of 
>>general issues). Without your posting I would not have noticed the 
>>improved consistency of the language.

> Can you elaborate on that?  It sounds interesting, but I don't know
> what exactly you mean.

It means that I knew about these words from scattered postings,
but I hadn't caught on to the underlying ideas and the increased
consistency they offer.

I started to like Forth because the way it "just fits together."
Unfortunately, with increasing years less occurrences of flashing 
insight happen, but for me this was one of them, YMMV.

It would be nice to describe the full Forth I/O system including
these new ideas/concepts somewhere, maybe at a Forth Wiki designed
to take FORML's place.

-marcel

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

#29426

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 
> You have understood it correctly, as far as the standard is
> concerned.  As for the reason: I think there are too few people on
> the standards committee who are interested in text processing.
> Admittedly I have not tried much in that direction, but even
> EXECUTE-PARSING, which would be useful beyond text processing, has
> been met with resistance.

I'm sure there is some truth in what you say.  EXECUTE-PARSING has an
unbefsckinglievably awful name for such a simple concept, which is
perhaps a significant psychological reason for that resistance.  I'm
afraid that I haven't been able to come up with a decent name for it
either.

Andrew.

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

#29436

In article <PbGdnRjos59ALd7OnZ2dnUVZ_rmdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>
>> You have understood it correctly, as far as the standard is
>> concerned.  As for the reason: I think there are too few people on
>> the standards committee who are interested in text processing.
>> Admittedly I have not tried much in that direction, but even
>> EXECUTE-PARSING, which would be useful beyond text processing, has
>> been met with resistance.
>
>I'm sure there is some truth in what you say.  EXECUTE-PARSING has an
>unbefsckinglievably awful name for such a simple concept, which is
>perhaps a significant psychological reason for that resistance.  I'm
>afraid that I haven't been able to come up with a decent name for it
>either.

Let's see

\ Interpret the file with name (addr,len)
: INCLUDED 'INTERPRET EXECUTE-PARSING ;

This makes EXECUTE-PARSING an underlying concept.
There under is the concept of transparently saving and restoring
the current input stream and setting a buffer to be an input stream.

: EXECUTE-PARSING  SAVE GET-FILE SET-SRC EXECUTE RESTORE ;

So in a primitive form these concepts underly ciforth.

( SAVE RESTORE SET-SRC are actual ciforth words ).

There is of course not much use for EXECUTE-PARSING. It is like
an array word when you have CREATE DOES>.

I did a uudecode program recently. Instead of using SET-SRC it
turned out to be more convenient to us the fdcopy system call,
which is much the same concept.

Thinking of it, ACCEPT is related READ-LINE of the standard
input in disguise. I never realized that.

I have (ACCEPT) which is a floating `` ^J PARSE '', like PARSE-NAME
returns a floating string.

>
>Andrew.

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]

#29492

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>\ Interpret the file with name (addr,len)
>: INCLUDED 'INTERPRET EXECUTE-PARSING ;

Not sure what your 'INTERPRET does, but in Gforth the following
definitions of INCLUDED should work:

: included
  ['] include execute-parsing ;

: included ( ... c-addr u -- ... )
  open-fpath-file throw ['] read-loop execute-parsing-file ;

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#29500

In article <2014Apr9.180703@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>\ Interpret the file with name (addr,len)
>>: INCLUDED 'INTERPRET EXECUTE-PARSING ;
>
>Not sure what your 'INTERPRET does, but in Gforth the following
>definitions of INCLUDED should work:
>
>: included
>  ['] include execute-parsing ;
>
>: included ( ... c-addr u -- ... )
>  open-fpath-file throw ['] read-loop execute-parsing-file ;

This suggests that I'm confused about what execute-parsing does.
Could it be that the second included is a typo (include)?

>
>- anton

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]

#29532

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2014Apr9.180703@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>\ Interpret the file with name (addr,len)
>>>: INCLUDED 'INTERPRET EXECUTE-PARSING ;
>>
>>Not sure what your 'INTERPRET does, but in Gforth the following
>>definitions of INCLUDED should work:
>>
>>: included
>>  ['] include execute-parsing ;
>>
>>: included ( ... c-addr u -- ... )
>>  open-fpath-file throw ['] read-loop execute-parsing-file ;
>
>This suggests that I'm confused about what execute-parsing does.
>Could it be that the second included is a typo (include)?

These are two alternative implementations of INCLUDED.

If there is anything particular you are confused about, please ask.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#29438

on 08/04/2014 09:18:34, Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>
>> You have understood it correctly, as far as the standard is
>> concerned.  As for the reason: I think there are too few people on
>> the standards committee who are interested in text processing.
>> Admittedly I have not tried much in that direction, but even
>> EXECUTE-PARSING, which would be useful beyond text processing, has
>> been met with resistance.
> 
> I'm sure there is some truth in what you say.  EXECUTE-PARSING has an
> unbefsckinglievably awful name for such a simple concept, which is

 ^^^^^^^^^^^^^^^^^^^

I'm stealing that word. 

> perhaps a significant psychological reason for that resistance.  I'm
> afraid that I haven't been able to come up with a decent name for it
> either.
> 
> Andrew.
> 

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

#29478

On Tuesday, April 8, 2014 1:18:37 AM UTC-7, Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 
> > You have understood it correctly, as far as the standard is
> > concerned.  As for the reason: I think there are too few people on
> > the standards committee who are interested in text processing.
> > Admittedly I have not tried much in that direction, but even
> > EXECUTE-PARSING, which would be useful beyond text processing, has
> > been met with resistance.

> I'm sure there is some truth in what you say.  EXECUTE-PARSING has an
> unbefsckinglievably awful name for such a simple concept, which is
> perhaps a significant psychological reason for that resistance.  I'm
> afraid that I haven't been able to come up with a decent name for it
> either.

See :NAME in the novice package.

Everything in the Forth-200x standard seems over-wrought to me. Most of this stuff can be simplified significantly.

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

#29485

hughaguilar96@yahoo.com wrote:
> On Tuesday, April 8, 2014 1:18:37 AM UTC-7, Andrew Haley wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 
>> > You have understood it correctly, as far as the standard is
>> > concerned.  As for the reason: I think there are too few people on
>> > the standards committee who are interested in text processing.
>> > Admittedly I have not tried much in that direction, but even
>> > EXECUTE-PARSING, which would be useful beyond text processing, has
>> > been met with resistance.
> 
>> I'm sure there is some truth in what you say.  EXECUTE-PARSING has an
>> unbefsckinglievably awful name for such a simple concept, which is
>> perhaps a significant psychological reason for that resistance.  I'm
>> afraid that I haven't been able to come up with a decent name for it
>> either.
> 
> See :NAME in the novice package.

I have, and it is not as useful or as well-factored as EXECUTE-PARSING.

Andrew.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web