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

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

FEED

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

Contents

  FEED albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-21 16:22 +0200
    Re: FEED Mark Wills <markwills1970@gmail.com> - 2016-09-21 10:09 -0700
      Re: FEED Andreas Wagner <andreas.wagner@lowfatcomputing.org> - 2016-09-21 12:13 -0700
        Re: FEED foxaudioresearch@gmail.com - 2016-09-21 12:43 -0700
          Re: FEED "HAA" <someone@microsoft.com> - 2016-09-22 12:20 +1000
          Re: FEED Mark Wills <markwills1970@gmail.com> - 2016-09-21 21:31 -0700
            Re: FEED Michael Barry <barrym95838@yahoo.com> - 2016-09-21 22:09 -0700
    Re: FEED anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-22 08:24 +0000
      Re: FEED Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-22 15:53 +0100
    Re: FEED Julian Fondren <julian.fondren@gmail.com> - 2016-09-22 08:19 -0700
      Re: FEED albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-22 20:08 +0200
      Re: FEED "HAA" <someone@microsoft.com> - 2016-09-23 11:32 +1000
        Re: FEED julian.fondren@endurance.com - 2016-09-22 20:57 -0700
        Re: FEED Julian Fondren <julian.fondren@gmail.com> - 2016-09-22 21:46 -0700
          Re: FEED "HAA" <someone@microsoft.com> - 2016-09-24 14:07 +1000
            Re: FEED hughaguilar96@gmail.com - 2016-10-03 20:56 -0700
        Re: FEED Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-23 10:30 +0100

#51150 — FEED

FEED
(sc xt -- n*x)
Feed the string `sc' as an input stream to `xt'.

Can we drop the clunky name EXECUTE-PARSING already?

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] | [next] | [standalone]

#51155

On Wednesday, 21 September 2016 15:14:34 UTC+1, Albert van der Horst  wrote:
> FEED
> (sc xt -- n*x)
> Feed the string `sc' as an input stream to `xt'.
> 
> Can we drop the clunky name EXECUTE-PARSING already?
> 
> 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

It's clunky, but FEED doesn't address what EXECUTE-PARSING actually
does. Yes, it takes a string, but it *parses it* and *executes* it.
FEED does not describe that behavior adequately IMO. Though I applaud
your effort to get rid the rather long EXECUTE-PARSING name. 

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

#51157

On Wednesday, September 21, 2016 at 1:09:41 PM UTC-4, Mark Wills wrote:
> On Wednesday, 21 September 2016 15:14:34 UTC+1, Albert van der Horst  wrote:
> > FEED
> > (sc xt -- n*x)
> > Feed the string `sc' as an input stream to `xt'.
> > 
> > Can we drop the clunky name EXECUTE-PARSING already?
> > 
> > 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
> 
> It's clunky, but FEED doesn't address what EXECUTE-PARSING actually
> does. Yes, it takes a string, but it *parses it* and *executes* it.
> FEED does not describe that behavior adequately IMO. Though I applaud
> your effort to get rid the rather long EXECUTE-PARSING name.

I think it's an apt name. "FEED" implies that you input something in order such as a meal or a text string and do something with the input such as go for a run up a mountain or execute code.

Lengthy descriptions belong in the documentation not in the names of functions or words. Names are indirection and therefore a little context is always necessary.

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

#51158

On Wednesday, September 21, 2016 at 3:13:54 PM UTC-4, Andreas Wagner wrote:
> On Wednesday, September 21, 2016 at 1:09:41 PM UTC-4, Mark Wills wrote:
> > On Wednesday, 21 September 2016 15:14:34 UTC+1, Albert van der Horst  wrote:
> > > FEED
> > > (sc xt -- n*x)
> > > Feed the string `sc' as an input stream to `xt'.
> > > 
> > > Can we drop the clunky name EXECUTE-PARSING already?
> > > 
> > > 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
> > 
> > It's clunky, but FEED doesn't address what EXECUTE-PARSING actually
> > does. Yes, it takes a string, but it *parses it* and *executes* it.
> > FEED does not describe that behavior adequately IMO. Though I applaud
> > your effort to get rid the rather long EXECUTE-PARSING name.
> 
> I think it's an apt name. "FEED" implies that you input something in order such as a meal or a text string and do something with the input such as go for a run up a mountain or execute code.
> 
> Lengthy descriptions belong in the documentation not in the names of functions or words. Names are indirection and therefore a little context is 
always necessary.

This might be a contest between native English speakers vs the rest because I 
tend to agree with Mark.  "FEED" like "SLURP" are not words that sound 
consistent with a programming language somehow. 

However I am also happy to see hyphenated words go away.  Forth has a tradition 
of finding succinct names.  As the language gets bigger however the choices for
good one-word names become less.

Other languages have resorted to "computery" terms to accomplish this.

sprintf, printf,  putch,  getch etc.


English has a large dictionary (due to borrowings and invasions)
Some possible alternatives for discussion:

 ASSESS, PERFORM, CLARIFY, DECODE, DECIPHER, ELUCIDATE, UNDERSTAND
ENACT, 

food for thought...

BF 

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

#51163

foxaudioresearch@gmail.com wrote:
> ...
> This might be a contest between native English speakers vs the rest because I
> tend to agree with Mark.  "FEED" like "SLURP" are not words that sound
> consistent with a programming language somehow.

By way of explanation, the name FEED was inspired by the LMI function of the
same name (similar context, different syntax).  LMI is long gone but those who
remember the name, may find its new use both appealing and befitting.

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

#51165

On Wednesday, 21 September 2016 20:44:00 UTC+1, foxaudio...@gmail.com  wrote:
> On Wednesday, September 21, 2016 at 3:13:54 PM UTC-4, Andreas Wagner wrote:
> > On Wednesday, September 21, 2016 at 1:09:41 PM UTC-4, Mark Wills wrote:
> > > On Wednesday, 21 September 2016 15:14:34 UTC+1, Albert van der Horst  wrote:
> > > > FEED
> > > > (sc xt -- n*x)
> > > > Feed the string `sc' as an input stream to `xt'.
> > > > 
> > > > Can we drop the clunky name EXECUTE-PARSING already?
> > > > 
> > > > 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
> > > 
> > > It's clunky, but FEED doesn't address what EXECUTE-PARSING actually
> > > does. Yes, it takes a string, but it *parses it* and *executes* it.
> > > FEED does not describe that behavior adequately IMO. Though I applaud
> > > your effort to get rid the rather long EXECUTE-PARSING name.
> > 
> > I think it's an apt name. "FEED" implies that you input something in order such as a meal or a text string and do something with the input such as go for a run up a mountain or execute code.
> > 
> > Lengthy descriptions belong in the documentation not in the names of functions or words. Names are indirection and therefore a little context is 
> always necessary.
> 
> This might be a contest between native English speakers vs the rest because I 
> tend to agree with Mark.  "FEED" like "SLURP" are not words that sound 
> consistent with a programming language somehow. 
> 
> However I am also happy to see hyphenated words go away.  Forth has a tradition 
> of finding succinct names.  As the language gets bigger however the choices for
> good one-word names become less.
> 
> Other languages have resorted to "computery" terms to accomplish this.
> 
> sprintf, printf,  putch,  getch etc.
> 
> 
> English has a large dictionary (due to borrowings and invasions)
> Some possible alternatives for discussion:
> 
>  ASSESS, PERFORM, CLARIFY, DECODE, DECIPHER, ELUCIDATE, UNDERSTAND
> ENACT, 
> 
> food for thought...
> 
> BF

PERFORM sounds good. 

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

#51166

On Wednesday, September 21, 2016 at 9:31:07 PM UTC-7, Mark Wills wrote:
>
> PERFORM sounds good.
>

I have seen PERFORM several times elsewhere as
: perform @ execute ;

Mike B.

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

#51168

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>FEED
>(sc xt -- n*x)
>Feed the string `sc' as an input stream to `xt'.
>
>Can we drop the clunky name EXECUTE-PARSING already?

Right, a bike-shed colour discussion.

If you convince the SwiftForth and VFX maintainers to provide
EXECUTE-PARSING under the name FEED, I will be happy to add

synonym feed execute-parsing

to Gforth.

- 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 2016: http://www.euroforth.org/ef16/

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

#51172

On 22/09/2016 09:24, Anton Ertl wrote:
> albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>> FEED
>> (sc xt -- n*x)
>> Feed the string `sc' as an input stream to `xt'.
>>
>> Can we drop the clunky name EXECUTE-PARSING already?
>
> Right, a bike-shed colour discussion.
>
> If you convince the SwiftForth and VFX maintainers to provide
> EXECUTE-PARSING under the name FEED, I will be happy to add
>
> synonym feed execute-parsing
>

I think FEED is too general, it doesn't give any hint of 
EXECUTE-PARSING's actions. We don't have to go for a short name, there's 
nothing wrong with a hyphenated name for a more complex action. Why not 
PARSED-WITH as the action is to parse (caddr u) with the supplied xt.
Alternatively more generally EXECUTED-WITH. I prefer to use the past 
tense as it allows a parsing variant to be defined as with INCLUDED  and 
INCLUDE.

-- 
Gerry

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

#51173

On Wednesday, September 21, 2016 at 9:14:34 AM UTC-5, Albert van der Horst wrote:
> FEED
> (sc xt -- n*x)
> Feed the string `sc' as an input stream to `xt'.
> 
> Can we drop the clunky name EXECUTE-PARSING already?
> 

It's certainly clunky.  It's also very rarely used.  When it might be
used more than a few times it's more likely to just get used as a
factor of a short word like (:) or (VAR) , reducing the usage count
back down to one or so per program.  Because its usage is so rare,
it's nice that it has this clunky, descriptive name.  One can get the
meaning from the name rather than have the word always at the top of
the mind.

This is the same attitude one has with variable scope.  If you'll be
occasionally referring to a variable all over your program, you want a
long, descriptive, easily searched-for name.  If you'll be frequently
referring to a variable within a very small part of your program, and
nowhere else, a single letter of a name is preferable.  Doing
otherwise is punishing: going long in the latter case makes the code
hard to read and annoying to write; going short in the former case
makes the variable's usage harder to track and makes it more
mysterious when read.


-- Julian

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

#51175

In article <3eb39af6-4e11-4239-96a9-002910eee5b0@googlegroups.com>,
Julian Fondren  <julian.fondren@gmail.com> wrote:
>On Wednesday, September 21, 2016 at 9:14:34 AM UTC-5, Albert van der Horst wrote:
>> FEED
>> (sc xt -- n*x)
>> Feed the string `sc' as an input stream to `xt'.
>>
>> Can we drop the clunky name EXECUTE-PARSING already?
>>
>
>It's certainly clunky.  It's also very rarely used.  When it might be
>used more than a few times it's more likely to just get used as a
>factor of a short word like (:) or (VAR) , reducing the usage count
>back down to one or so per program.  Because its usage is so rare,
>it's nice that it has this clunky, descriptive name.  One can get the
>meaning from the name rather than have the word always at the top of
>the mind.

You got me there. A clunky word deserves a clunky name.
So FEED be gone.

<SNIP>

>-- Julian
-- 
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]

#51179

Julian Fondren wrote:
> On Wednesday, September 21, 2016 at 9:14:34 AM UTC-5, Albert van der Horst wrote:
> > FEED
> > (sc xt -- n*x)
> > Feed the string `sc' as an input stream to `xt'.
> >
> > Can we drop the clunky name EXECUTE-PARSING already?
> >
>
> It's certainly clunky.  It's also very rarely used.  When it might be
> used more than a few times it's more likely to just get used as a
> factor of a short word like (:) or (VAR) , reducing the usage count
> back down to one or so per program. Because its usage is so rare,
> it's nice that it has this clunky, descriptive name.  One can get the
> meaning from the name rather than have the word always at the top of
> the mind.

So in the space of a few c.l.f. days this has gone from essential Forth
functionality that required a complicated idiot-proof ANS-compatible
definition four years in the making, back to a rarely used function that
hardly deserves a name.

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

#51180

On Thursday, September 22, 2016 at 8:31:35 PM UTC-5, HAA wrote:
> So in the space of a few c.l.f. days

adventures_of_the_man_that_just_started_paying_attention.png

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

#51181

On Thursday, September 22, 2016 at 8:31:35 PM UTC-5, HAA wrote:
> So in the space of a few c.l.f. days

adventures-of-the-man-that-just-started-paying-attention.png

> required a complicated idiot-proof ANS-compatible definition four
> years in the making

It doesn't have a trivial ANS definition.

It does have trivial system-specific definitions.

Point #1 is emphasized by nobody having presented a correct definition
until four years after variously defective definitions were presented.

With these points in mind, it's suggested that Forth systems implement
it a convenient system-specific way.

This then permits the standardization of a single generally useful
word, instead of lots of narrowly useful words.

> idiot-proof

"Actually does what it's supposed to do."

> rarely used function

Standards aren't a popularity contest for words.

> hardly deserves a name

Suppose that Forth had only ever dealt with decimal numbers, but now
people are wanting BINARY OCTAL HEX words, and DECIMAL to set things
back to normal.  In response to this, general functionality is
proposed, in NUMBER-BASE 

Would you sneer that this word "hardly deserves a name" after it's
argued that it doesn't need a short word like BASE ?

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

#51219

Julian Fondren wrote:
> On Thursday, September 22, 2016 at 8:31:35 PM UTC-5, HAA wrote:
> > So in the space of a few c.l.f. days
>
> adventures-of-the-man-that-just-started-paying-attention.png
>
> > required a complicated idiot-proof ANS-compatible definition four
> > years in the making
>
> It doesn't have a trivial ANS definition.
>
> It does have trivial system-specific definitions.
>
> Point #1 is emphasized by nobody having presented a correct definition
> until four years after variously defective definitions were presented.
>
> With these points in mind, it's suggested that Forth systems implement
> it a convenient system-specific way.
>
> This then permits the standardization of a single generally useful
> word, instead of lots of narrowly useful words.

If it were me, I'd first be asking what good is this function, what uses have
been made of it, what critical need does it fulfill.  I'd do that before I'd consider
implementing it, let alone standardizing it.  Given the enthusiasm expressed
for this function on c.l.f., I looked at the uses gforth has made of it and it left
me underwhelmed.

> > idiot-proof
>
> "Actually does what it's supposed to do."
>
> > rarely used function
>
> Standards aren't a popularity contest for words.
>
> > hardly deserves a name
>
> Suppose that Forth had only ever dealt with decimal numbers, but now
> people are wanting BINARY OCTAL HEX words, and DECIMAL to set things
> back to normal.  In response to this, general functionality is
> proposed, in NUMBER-BASE
>
> Would you sneer that this word "hardly deserves a name" after it's
> argued that it doesn't need a short word like BASE ?

Not arguing over names, just commenting on the rapidly changing
weather on comp.lang.forth - 'clunky' one day and fine the next.

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

#51593

On Friday, September 23, 2016 at 9:06:36 PM UTC-7, HAA wrote:
> Julian Fondren wrote:
> > On Thursday, September 22, 2016 at 8:31:35 PM UTC-5, HAA wrote:
> > > required a complicated idiot-proof ANS-compatible definition four
> > > years in the making
> >
> > It doesn't have a trivial ANS definition.
> >
> > It does have trivial system-specific definitions.

Implementing :NAME was the work of one day --- it was trivial.

Julien Fondren just doesn't know how to program in Forth very well --- he is trying to project his own imcompetance on to the entire Forth community --- stuff like this is actually trivial (UR/Forth had it built-in 25 years ago).

> If it were me, I'd first be asking what good is this function, what uses have
> been made of it, what critical need does it fulfill.  I'd do that before I'd consider
> implementing it, let alone standardizing it.  Given the enthusiasm expressed
> for this function on c.l.f., I looked at the uses gforth has made of it and it left
> me underwhelmed.

In my novice-package I almost never use CREATE DOES> for anything (the only example is DEFER which I provided because it is traditional, but I have VECTOR that is more efficient because it doesn't use CREATE DOES>) --- CREATE DOES> words are always grossly inefficient (especially on SwiftForth) --- :NAME always generates more efficient code, which is why I use it for all my defining words in the novice-package.

I had something similar to :NAME in UR/Forth (it was HEADER that was built-in) --- this is a crucial component of a cross-compiler --- if you don't know what :NAME is for, this implies that you don't know how to write a cross-compiler.

As for EXECUTE-PARSING --- I have never used it --- it is ugly over-complicated code typical of gForth.

I have no intention of ever becoming a gForth programmer --- it is an ugly over-complicated language that generates grossly inefficient code --- gForth has never been used for writing commercial software, and it never will be used for anything except toy programs.

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

#51183

On 23/09/2016 02:32, HAA wrote:
> Julian Fondren wrote:
>> On Wednesday, September 21, 2016 at 9:14:34 AM UTC-5, Albert van der Horst wrote:
>>> FEED
>>> (sc xt -- n*x)
>>> Feed the string `sc' as an input stream to `xt'.
>>>
>>> Can we drop the clunky name EXECUTE-PARSING already?
>>>
>>
>> It's certainly clunky.  It's also very rarely used.  When it might be
>> used more than a few times it's more likely to just get used as a
>> factor of a short word like (:) or (VAR) , reducing the usage count
>> back down to one or so per program. Because its usage is so rare,
>> it's nice that it has this clunky, descriptive name.  One can get the
>> meaning from the name rather than have the word always at the top of
>> the mind.
>
> So in the space of a few c.l.f. days this has gone from essential Forth
> functionality that required a complicated idiot-proof ANS-compatible
> definition four years in the making, back to a rarely used function that
> hardly deserves a name.
>

Well I doubt that anybody was actively working on for four years as you 
imply. Anyway rarely used or not, the facts that NEXTNAME, POSTFIX and 
EXECUTE-PARSING exist and periodically someone calls for the capability, 
demonstrates that some users need it. The question is how and what it 
should be called. Proper implementation in a system would not need to be 
as complicated as the pure-ANS Forth definition.

-- 
Gerry

[toc] | [prev] | [standalone]

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

csiph-web