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

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

Starting Forth 6.

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

Contents

  Starting Forth 6. "WJ" <w_a_x_man@yahoo.com> - 2013-09-24 23:09 +0000
    Re: Starting Forth 6. "WJ" <w_a_x_man@yahoo.com> - 2013-09-24 23:36 +0000
      Re: Starting Forth 6. "WJ" <w_a_x_man@yahoo.com> - 2013-09-24 23:47 +0000
    Re: Starting Forth 6. "Ed" <invalid@invalid.com> - 2013-09-25 18:22 +1000
      Re: Starting Forth 6. "Elizabeth D. Rather" <erather@forth.com> - 2013-09-25 08:44 -1000
        Re: Starting Forth 6. hughaguilar96@yahoo.com - 2013-09-25 20:09 -0700
          Re: Starting Forth 6. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-09-26 12:27 +0000
            Re: Starting Forth 6. "Elizabeth D. Rather" <erather@forth.com> - 2013-09-26 09:09 -1000
              Re: Starting Forth 6. hughaguilar96@yahoo.com - 2013-09-27 23:16 -0700
                Re: Starting Forth 6. the_gavino_himself <visphatesjava@gmail.com> - 2013-11-16 17:07 -0800
              Re: Starting Forth 6. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-10-11 22:37 -0700
                Re: Starting Forth 6. the_gavino_himself <visphatesjava@gmail.com> - 2013-11-16 17:11 -0800
                  Re: Starting Forth 6. "Stanley Daniel de Liver" <notagoodone@invalid.org.invalid> - 2013-12-11 16:49 +0000
            Re: Starting Forth 6. "Ed" <invalid@invalid.com> - 2013-09-27 11:39 +1000
              Re: Starting Forth 6. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-10-11 22:39 -0700
            Re: Starting Forth 6. hughaguilar96@yahoo.com - 2013-09-30 16:47 -0700
            Re: Starting Forth 6. David Thompson <dave.thompson2@verizon.net> - 2013-10-12 18:22 -0400
              Re: Starting Forth 6. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-10-13 12:17 +0000
          Re: Starting Forth 6. Whammo <sidciavic@gmail.com> - 2013-09-26 11:37 -0700
            Re: Starting Forth 6. hughaguilar96@yahoo.com - 2013-09-27 22:28 -0700
            Re: Starting Forth 6. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-10-11 22:34 -0700
      Re: Starting Forth 6. hughaguilar96@yahoo.com - 2013-09-25 19:58 -0700
    Re: Starting Forth 6. "WJ" <w_a_x_man@yahoo.com> - 2013-10-01 15:21 +0000
    Re: Starting Forth 6. "WJ" <w_a_x_man@yahoo.com> - 2013-10-12 09:17 +0000
    Re: Starting Forth 6. "WJ" <w_a_x_man@yahoo.com> - 2013-10-12 19:01 +0000

Page 1 of 2  [1] 2  Next page →

#26005 — Starting Forth 6.

Brodie creates a defining word ARRAY, which creates a
two-dimensional array.  However, the words created by
ARRAY don't fetch values from the array or store values
in the array; they only return the addresses of array
elements.

Racket:

The following function returns a closure:

(define (array rows cols)
  (let ((the-vec (make-vector (* rows cols) 0)))
    (define (calc-index row col) (+ (* row cols) col))
    (case-lambda
      [(row col) (vector-ref the-vec (calc-index row col))]
      [(row col new-val)
       (vector-set! the-vec (calc-index row col) new-val)])))

(define board (array 4 4))

When called with 3 arguments, the third is placed in the array;
when called with 2 arguments, the value in the cell is returned.

  > (board 0 0 999)
  > (board 0 0)
  999

(for* ([row 4] [col 4])
  (board row col (+ col (* row 10))))
(for ([row 4])
  (for ([col 4])
    (display (~a (board row col) #:width 3 #:align 'right)))
  (newline))

  0  1  2  3
 10 11 12 13
 20 21 22 23
 30 31 32 33

[toc] | [next] | [standalone]

#26006

WJ wrote:

> Brodie creates a defining word ARRAY, which creates a
> two-dimensional array.  However, the words created by
> ARRAY don't fetch values from the array or store values
> in the array; they only return the addresses of array
> elements.
> 
> Racket:
> 
> The following function returns a closure:
> 
> (define (array rows cols)
>   (let ((the-vec (make-vector (* rows cols) 0)))
>     (define (calc-index row col) (+ (* row cols) col))
>     (case-lambda
>       [(row col) (vector-ref the-vec (calc-index row col))]
>       [(row col new-val)
>        (vector-set! the-vec (calc-index row col) new-val)])))
> 
> (define board (array 4 4))
> 
> When called with 3 arguments, the third is placed in the array;
> when called with 2 arguments, the value in the cell is returned.
> 
>   > (board 0 0 999)
>   > (board 0 0)
>   999
> 
> (for* ([row 4] [col 4])
>   (board row col (+ col (* row 10))))
> (for ([row 4])
>   (for ([col 4])
>     (display (~a (board row col) #:width 3 #:align 'right)))
>   (newline))
> 
>   0  1  2  3
>  10 11 12 13
>  20 21 22 23
>  30 31 32 33

Modified so that when the closure is called with no arguments,
the entire vector is returned.

(define (array rows cols)
  (let ((the-vec (make-vector (* rows cols) 0)))
    (define (calc-index row col) (+ (* row cols) col))
    (case-lambda
      [(row col) (vector-ref the-vec (calc-index row col)) ]
      [(row col new-val)
       (vector-set! the-vec (calc-index row col) new-val) ]
      [() the-vec])))


  > (define board (array 4 4))
  > (for* ([row 4] [col 4])
    (board row col (+ col (* row 10))))
  > (board)
  '#(0 1 2 3 10 11 12 13 20 21 22 23 30 31 32 33)

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

#26007

WJ wrote:

> WJ wrote:
> 
> > Brodie creates a defining word ARRAY, which creates a
> > two-dimensional array.  However, the words created by
> > ARRAY don't fetch values from the array or store values
> > in the array; they only return the addresses of array
> > elements.
> > 
> > Racket:
> > 
> > The following function returns a closure:
> > 
> > (define (array rows cols)
> >   (let ((the-vec (make-vector (* rows cols) 0)))
> >     (define (calc-index row col) (+ (* row cols) col))
> >     (case-lambda
> >       [(row col) (vector-ref the-vec (calc-index row col))]
> >       [(row col new-val)
> >        (vector-set! the-vec (calc-index row col) new-val)])))
> > 
> > (define board (array 4 4))
> > 
> > When called with 3 arguments, the third is placed in the array;
> > when called with 2 arguments, the value in the cell is returned.
> > 
> >   > (board 0 0 999)
> >   > (board 0 0)
> >   999
> > 
> > (for* ([row 4] [col 4])
> >   (board row col (+ col (* row 10))))
> > (for ([row 4])
> >   (for ([col 4])
> >     (display (~a (board row col) #:width 3 #:align 'right)))
> >   (newline))
> > 
> >   0  1  2  3
> >  10 11 12 13
> >  20 21 22 23
> >  30 31 32 33
> 
> Modified so that when the closure is called with no arguments,
> the entire vector is returned.
> 
> (define (array rows cols)
>   (let ((the-vec (make-vector (* rows cols) 0)))
>     (define (calc-index row col) (+ (* row cols) col))
>     (case-lambda
>       [(row col) (vector-ref the-vec (calc-index row col)) ]
>       [(row col new-val)
>        (vector-set! the-vec (calc-index row col) new-val) ]
>       [() the-vec])))
> 
> 
>   > (define board (array 4 4))
>   > (for* ([row 4] [col 4])
>     (board row col (+ col (* row 10))))
>   > (board)
>   '#(0 1 2 3 10 11 12 13 20 21 22 23 30 31 32 33)

Modified so that when the closure is called with one argument,
a row of the vector is returned.

(define (array rows cols)
  (let ((the-vec (make-vector (* rows cols) 0)))
    (define (calc-index row col) (+ (* row cols) col))
    (case-lambda
      [(row col) (vector-ref the-vec (calc-index row col)) ]
      [(row col new-val)
       (vector-set! the-vec (calc-index row col) new-val) ]
      [() the-vec]
      [(row)
       (vector-copy the-vec
         (calc-index row 0) (calc-index (add1 row) 0))])))

  > (define board (array 4 4))
  > (for* ([row 4] [col 4])
    (board row col (+ col (* row 10))))
  > (board 3)
  '#(30 31 32 33)

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

#26017

WJ wrote:
> Brodie creates a defining word ARRAY, which creates a
> two-dimensional array.  However, the words created by
> ARRAY don't fetch values from the array or store values
> in the array; they only return the addresses of array
> elements.

Nothing wrong there.  This is Forth and what Brodie did was
entirely appropriate.

> Racket:

Can do as it pleases.

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

#26028

On 9/24/13 10:22 PM, Ed wrote:
> WJ wrote:
>> Brodie creates a defining word ARRAY, which creates a
>> two-dimensional array.  However, the words created by
>> ARRAY don't fetch values from the array or store values
>> in the array; they only return the addresses of array
>> elements.
>
> Nothing wrong there.  This is Forth and what Brodie did was
> entirely appropriate.
>
>> Racket:
>
> Can do as it pleases.

Moreover, if you want an array to return a value instead of an address, 
it's trivial to make that mod: at the point at which the address was 
developed, just add @ (or the appropriate fetch operator). Of course, 
then you'll have to figure out how to store into an element of the 
array, and it starts to get more complicated, which is why Brodie's 
ARRAY returns an address instead of a value.

But my point is that you can define data objects to behave *exactly* the 
way you want them to, to solve the problem at hand.

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]

#26037

On Wednesday, September 25, 2013 11:44:35 AM UTC-7, Elizabeth D. Rather wrote:
> But my point is that you can define data objects to behave *exactly* the 
> way you want them to, to solve the problem at hand.

I totally disagree with this. It is foolish to custom-implement basic data structures such as arrays for every application. It is easy to write a general-purpose array or linked-list or whatever, that works exactly the way that you want it to for *every* application.

Forthers have to stop dinking around with reinventing the wheel over and over again --- no professional company allots time for their employees to do this --- the employees are expected to spend their time writing application code and making progress. 

An employee can't tell his boss: "Well, I spent all day implementing a linked list, and the remainder of the week will be spent on implementing an LLRB tree --- maybe I will start on the application program next week --- unless I think of some more fun ways to avoid getting started in the meantime!" --- that is a good way to get fired.

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

#26040

In article <043a32ac-c009-4aff-beda-aa4041daadcb@googlegroups.com>,
 <hughaguilar96@yahoo.com> wrote:
>On Wednesday, September 25, 2013 11:44:35 AM UTC-7, Elizabeth D. Rather wrote:
>> But my point is that you can define data objects to behave *exactly* the
>> way you want them to, to solve the problem at hand.
>
>I totally disagree with this. It is foolish to custom-implement basic
>data structures such as arrays for every application. It is easy to
>write a general-purpose array or linked-list or whatever, that works
>exactly the way that you want it to for *every* application.
>
>Forthers have to stop dinking around with reinventing the wheel over and
>over again --- no professional company allots time for their employees
>to do this --- the employees are expected to spend their time writing
>application code and making progress.
>
>An employee can't tell his boss: "Well, I spent all day implementing a
>linked list, and the remainder of the week will be spent on implementing
>an LLRB tree --- maybe I will start on the application program next week
>--- unless I think of some more fun ways to avoid getting started in the
>meantime!" --- that is a good way to get fired.

I agree, to an extent. Trying to find out how a predefined LLRB works
in an Eclipse Java environment could easily take more than a week,
but there is the hidden benefit of using tested software.

Having to adapt an array to the kind of things stored in the array
every time, is a chore and it looks like Elizabeth doesn't appreciate
that. Again this chore may be less than what java does: requiring you
to "box" simple integers into an object, before you can arrange them
into an array. Even the mindset needed prior to this is a considerable
investment.

There are trade offs here. I'm thinking about this huge project of a
book recognition project (OCR doesn't quite cover it). The investment
of tailor made data structure is negligable in such a large project.
I'm sure similar trade offs apply to the luggage handling system in
the middle East.

Groetjes Albert

P.S.
Well Hugh, I must say you're talking much sense lately.
Keep to the technical issues and you may become a valued contributor!
-- 
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]

#26047

On 9/26/13 2:27 AM, Albert van der Horst wrote:
> In article <043a32ac-c009-4aff-beda-aa4041daadcb@googlegroups.com>,
>   <hughaguilar96@yahoo.com> wrote:
>> On Wednesday, September 25, 2013 11:44:35 AM UTC-7, Elizabeth D. Rather wrote:
>>> But my point is that you can define data objects to behave *exactly* the
>>> way you want them to, to solve the problem at hand.
>>
>> I totally disagree with this. It is foolish to custom-implement basic
>> data structures such as arrays for every application. It is easy to
>> write a general-purpose array or linked-list or whatever, that works
>> exactly the way that you want it to for *every* application.

Does "*every* application" you write use exactly the same kind of data 
arranged in the same way? If so, having written it once you can reuse it 
often. If not, you either have to rearrange your data to make it work or 
modify your "general-purpose" structure.

>> Forthers have to stop dinking around with reinventing the wheel over and
>> over again --- no professional company allots time for their employees
>> to do this --- the employees are expected to spend their time writing
>> application code and making progress.
>>
>> An employee can't tell his boss: "Well, I spent all day implementing a
>> linked list, and the remainder of the week will be spent on implementing
>> an LLRB tree --- maybe I will start on the application program next week
>> --- unless I think of some more fun ways to avoid getting started in the
>> meantime!" --- that is a good way to get fired.
>
> I agree, to an extent. Trying to find out how a predefined LLRB works
> in an Eclipse Java environment could easily take more than a week,
> but there is the hidden benefit of using tested software.

It really is a cost-benefit tradeoff. Linked lists are a good example. I 
have worked with several, each of which followed a somewhat different 
algorithm according to the needs of the application, and each of which 
took 30 mins to an hour to implement, and involved only a few lines of 
code. Something that simple and easy to implement can also be easily 
tested. In Forth, these things don't take days and weeks.

> Having to adapt an array to the kind of things stored in the array
> every time, is a chore and it looks like Elizabeth doesn't appreciate
> that. Again this chore may be less than what java does: requiring you
> to "box" simple integers into an object, before you can arrange them
> into an array. Even the mindset needed prior to this is a considerable
> investment.

I guess I have to question where the "chore" lies: finding an 
appropriate "general purpose" widget and figuring out how to use it for 
your particular situation can easily be more work than just writing it, 
given the kind of flexibility Forth offers.

> There are trade offs here. I'm thinking about this huge project of a
> book recognition project (OCR doesn't quite cover it). The investment
> of tailor made data structure is negligible in such a large project.
> I'm sure similar trade offs apply to the luggage handling system in
> the middle East.

It was a whole airport in the middle East :-) And we designed and 
implemented a whole database for it in the first month of an 18-month, 
15 man-year project.

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]

#26061

On Thursday, September 26, 2013 12:09:59 PM UTC-7, Elizabeth D. Rather wrote:
> On 9/26/13 2:27 AM, Albert van der Horst wrote:
> > In article <043a32ac-c009-4aff-beda-aa4041daadcb@googlegroups.com>,
> >   <hughaguilar96@yahoo.com> wrote:
> >> On Wednesday, September 25, 2013 11:44:35 AM UTC-7, Elizabeth D. Rather wrote:
> >>> But my point is that you can define data objects to behave *exactly* the
> >>> way you want them to, to solve the problem at hand.
> 
> >> I totally disagree with this. It is foolish to custom-implement basic
> >> data structures such as arrays for every application. It is easy to
> >> write a general-purpose array or linked-list or whatever, that works
> >> exactly the way that you want it to for *every* application.
> 
> Does "*every* application" you write use exactly the same kind of data 
> arranged in the same way? If so, having written it once you can reuse it 
> often. If not, you either have to rearrange your data to make it work or 
> modify your "general-purpose" structure.

This is utter nonsense! You are totally not understanding the concept of general-purpose code. You have said before that you didn't know what closures were, and you apparently don't know what vectored execution is either, although that is described in "Starting Forth" which you teach from.

Consider my SORT function for arrays. No, I do not need to have the same fields arranged in the same way for every application. The SORT function takes as a parameter the xt of a compare-function that compares two structs --- this compare-function has to be customized for every application (depending upon what fields there are, how they are arranged, and which field is the key), but the SORT function is general-purpose --- the SORT function can work with any struct or with pointers to structs of any kind, and the user doesn't have to know anything about how SORT works or even have the source-code to SORT. General-purpose means that it works in *every* possible case. Only the part that is different from application to application (the comparer function) needs to be customized for the application --- but the majority of the code, which is the same for every application, doesn't need to be messed with.

That novice package has been available since 2009. You really could look at it and figure out how it works, rather than endlessly make these nonsensical criticisms that plainly show that you don't know what you are talking about. You don't know what general-purpose software is supposed to do, so how would you know if the novice-package is good or bad at being general purpose?

> It really is a cost-benefit tradeoff. Linked lists are a good example. I 
> have worked with several, each of which followed a somewhat different 
> algorithm according to the needs of the application, and each of which 
> took 30 mins to an hour to implement, and involved only a few lines of 
> code. Something that simple and easy to implement can also be easily 
> tested. In Forth, these things don't take days and weeks.

Lists can be singly or doubly linked, and they can be circular or linear, and they can have a handle or just a pointer to the head node.

Pick one of these configurations and write a general-purpose linked-list implementation for it --- if it is well-written, I will include it in the novice package. I have already done singly-linked, linear and with a pointer into the list (the simplest case) --- so, unless you think that it was not well-written, pick another (make yours compatible with mine as much as possible, so users can smoothly upgrade from the simple to the more complicated, without having to change much if any of their own code). Since it only takes 30 minutes to an hour for you to write code like this, I will look forward to seeing your implementation before the weekend is passed. 

If I were writing an application and discovered that my basic list implementation provided in the novice package wasn't what I wanted, then I would write a new implementation that did what I wanted it to do --- but, I would make it general-purpose and include it in the novice package for future use --- I certainly wouldn't bury this low-level code inside of an application, because it is not application code but it is support code, so it belongs in the novice package.

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

#26859

hugh have you got anything like firefox working ona pc with just forth under it?

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

#26408

On Thursday, September 26, 2013 2:09:59 PM UTC-5, Elizabeth D. Rather wrote:
> On 9/26/13 2:27 AM, Albert van der Horst wrote:
> 
> > In article <043a32ac-c009-4aff-beda-aa4041daadcb@googlegroups.com>,
> 
> >   <hughaguilar96@yahoo.com> wrote:
> 
> >> On Wednesday, September 25, 2013 11:44:35 AM UTC-7, Elizabeth D. Rather wrote:
> 
> >>> But my point is that you can define data objects to behave *exactly* the
> 
> >>> way you want them to, to solve the problem at hand.
> 
> >>
> 
> >> I totally disagree with this. It is foolish to custom-implement basic
> 
> >> data structures such as arrays for every application. It is easy to
> 
> >> write a general-purpose array or linked-list or whatever, that works
> 
> >> exactly the way that you want it to for *every* application.
> 
> 
> 
> Does "*every* application" you write use exactly the same kind of data 
> 
> arranged in the same way? If so, having written it once you can reuse it 
> 
> often. If not, you either have to rearrange your data to make it work or 
> 
> modify your "general-purpose" structure.
> 
> 
> 
> >> Forthers have to stop dinking around with reinventing the wheel over and
> 
> >> over again --- no professional company allots time for their employees
> 
> >> to do this --- the employees are expected to spend their time writing
> 
> >> application code and making progress.
> 
> >>
> 
> >> An employee can't tell his boss: "Well, I spent all day implementing a
> 
> >> linked list, and the remainder of the week will be spent on implementing
> 
> >> an LLRB tree --- maybe I will start on the application program next week
> 
> >> --- unless I think of some more fun ways to avoid getting started in the
> 
> >> meantime!" --- that is a good way to get fired.
> 
> >
> 
> > I agree, to an extent. Trying to find out how a predefined LLRB works
> 
> > in an Eclipse Java environment could easily take more than a week,
> 
> > but there is the hidden benefit of using tested software.
> 
> 
> 
> It really is a cost-benefit tradeoff. Linked lists are a good example. I 
> 
> have worked with several, each of which followed a somewhat different 
> 
> algorithm according to the needs of the application, and each of which 
> 
> took 30 mins to an hour to implement, and involved only a few lines of 
> 
> code. Something that simple and easy to implement can also be easily 
> 
> tested. In Forth, these things don't take days and weeks.
> 
> 
> 
> > Having to adapt an array to the kind of things stored in the array
> 
> > every time, is a chore and it looks like Elizabeth doesn't appreciate
> 
> > that. Again this chore may be less than what java does: requiring you
> 
> > to "box" simple integers into an object, before you can arrange them
> 
> > into an array. Even the mindset needed prior to this is a considerable
> 
> > investment.
> 
> 
> 
> I guess I have to question where the "chore" lies: finding an 
> 
> appropriate "general purpose" widget and figuring out how to use it for 
> 
> your particular situation can easily be more work than just writing it, 
> 
> given the kind of flexibility Forth offers.
> 
> 
> 
> > There are trade offs here. I'm thinking about this huge project of a
> 
> > book recognition project (OCR doesn't quite cover it). The investment
> 
> > of tailor made data structure is negligible in such a large project.
> 
> > I'm sure similar trade offs apply to the luggage handling system in
> 
> > the middle East.
> 
> 
> 
> It was a whole airport in the middle East :-) And we designed and 
> 
> implemented a whole database for it in the first month of an 18-month, 
> 
> 15 man-year project.
> 
> 
> 
> 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."
> 
> ==================================================

I feel there is faint understanding of forth's beauty and benefits in this forum.

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

#26860

I agree.

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

#27217

On Sun, 17 Nov 2013 01:11:42 -0000, the_gavino_himself  
<visphatesjava@gmail.com> wrote:

> I agree.
>

Well that's excellent.
-- 
It's a money /life balance.

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

#26049

Albert van der Horst wrote:
> ...
> Having to adapt an array to the kind of things stored in the array
> every time, is a chore and it looks like Elizabeth doesn't appreciate
> that.

Here's how I interpreted it.

In Forth, arrays returning an address is most useful because fetch and store
operators typically require for their argument an address on the stack.
That said, situations can be exploited.  An example would be array objects
which are read-only and it's both feasable and convenient to return them
directly rather than as an address ...

: error-msgs
  create ( adr ) ,
  does> ( n )  @ swap 0 ?do count + loop count space type ;

here ( adr)
0 c,
," File not found"
," Filename expected"
," Attempted to compare Forth with dissimilar languages"

( *) error-msgs SYSERR

1 syserr  File not found ok
0 syserr   ok
2 syserr  Filename expected ok

: WJ  3 syserr abort ;

WJ  Attempted to compare Forth with dissimilar languages

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

#26409

On Thursday, September 26, 2013 8:39:35 PM UTC-5, Ed wrote:
> Albert van der Horst wrote:
> 
> > ...
> 
> > Having to adapt an array to the kind of things stored in the array
> 
> > every time, is a chore and it looks like Elizabeth doesn't appreciate
> 
> > that.
> 
> 
> 
> Here's how I interpreted it.
> 
> 
> 
> In Forth, arrays returning an address is most useful because fetch and store
> 
> operators typically require for their argument an address on the stack.
> 
> That said, situations can be exploited.  An example would be array objects
> 
> which are read-only and it's both feasable and convenient to return them
> 
> directly rather than as an address ...
> 
> 
> 
> : error-msgs
> 
>   create ( adr ) ,
> 
>   does> ( n )  @ swap 0 ?do count + loop count space type ;
> 
> 
> 
> here ( adr)
> 
> 0 c,
> 
> ," File not found"
> 
> ," Filename expected"
> 
> ," Attempted to compare Forth with dissimilar languages"
> 
> 
> 
> ( *) error-msgs SYSERR
> 
> 
> 
> 1 syserr  File not found ok
> 
> 0 syserr   ok
> 
> 2 syserr  Filename expected ok
> 
> 
> 
> : WJ  3 syserr abort ;
> 
> 
> 
> WJ  Attempted to compare Forth with dissimilar languages

yup

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

#26081

On Thursday, September 26, 2013 5:27:18 AM UTC-7, Albert van der Horst wrote:
> P.S.
> Well Hugh, I must say you're talking much sense lately.
> Keep to the technical issues and you may become a valued contributor!

I'll never become a valued contributor to comp.lang.forth until Elizabeth Rather says that I'm a valued contributor, and that will never happen. 

I wrote that novice package in 2009. Writing code like that doesn't count as "keeping to the technical issues" --- if it did, then somebody else (such as yourself) would have written a package of general-purpose code --- but nobody has. Nobody ever will, because writing general-purpose code incurs the wrath of Elizabeth Rather --- there is nothing in the world that she hates and fears more than Forth code that works.

I think that Elizabeth Rather attacks general-purpose code on comp.lang.forth because she wants programming in Forth to be as difficult as possible, so that everybody who attempts Forth will fail --- leaving Forth Inc. the king of the hill (a very small hill composed entirely of steer manure, but that doesn't bother her). 

Most experienced Forthers on comp.lang.forth will try to help the brave novice Forthers to learn (assuming that they want to learn, which leaves out WJ) --- but Elizabeth Rather purposely sabotages the novices' efforts by giving them staggeringly bad advice (write everything from scratch every time) --- because she is afraid that the novices will eventually become competitors to Forth Inc.. She hates me because I am a competitor to Forth Inc. --- I stole the Testra job from Forth Inc. after she made her sales pitch and assumed that Forth Inc. had the job for sure.

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

#26433

On 26 Sep 2013 12:27:18 GMT, albert@spenarnc.xs4all.nl (Albert van der
Horst) wrote:

> In article <043a32ac-c009-4aff-beda-aa4041daadcb@googlegroups.com>,
>  <hughaguilar96@yahoo.com> wrote:
<snip: general-purpose data structures>

> I agree, to an extent. Trying to find out how a predefined LLRB works
> in an Eclipse Java environment could easily take more than a week,
> but there is the hidden benefit of using tested software.
> 
> Having to adapt an array to the kind of things stored in the array
> every time, is a chore and it looks like Elizabeth doesn't appreciate
> that. Again this chore may be less than what java does: requiring you
> to "box" simple integers into an object, before you can arrange them
> into an array. Even the mindset needed prior to this is a considerable
> investment.
> 
Not quite. Java *arrays* are available for both primitive types and
object types. Other things may or may not; as an important case the
standard Java library *containers* (java.util.Vector, HashMap, etc.)
do only objects. And if you want both 'primitive' and object values in
one array, you have to use array of object and box the primitives.

Where un/boxing *is* needed you don't have to actually write it, the
compiler does it automatically; it's considered a conversion just like
short to int and double to float. Whether this is good or bad is de
gustibus; I'll predict most Forthers wouldn't prefer it.

<snip>

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

#26466

In article <9sij59lm13kttp9248fugvnnk4oi9660m8@4ax.com>,
David Thompson  <dave.thompson2@verizon.net> wrote:
>On 26 Sep 2013 12:27:18 GMT, albert@spenarnc.xs4all.nl (Albert van der
>Horst) wrote:
>
>> In article <043a32ac-c009-4aff-beda-aa4041daadcb@googlegroups.com>,
>>  <hughaguilar96@yahoo.com> wrote:
><snip: general-purpose data structures>
>
>> I agree, to an extent. Trying to find out how a predefined LLRB works
>> in an Eclipse Java environment could easily take more than a week,
>> but there is the hidden benefit of using tested software.
>>
>> Having to adapt an array to the kind of things stored in the array
>> every time, is a chore and it looks like Elizabeth doesn't appreciate
>> that. Again this chore may be less than what java does: requiring you
>> to "box" simple integers into an object, before you can arrange them
>> into an array. Even the mindset needed prior to this is a considerable
>> investment.
>>
>Not quite. Java *arrays* are available for both primitive types and
>object types. Other things may or may not; as an important case the
>standard Java library *containers* (java.util.Vector, HashMap, etc.)
>do only objects. And if you want both 'primitive' and object values in
>one array, you have to use array of object and box the primitives.
>
>Where un/boxing *is* needed you don't have to actually write it, the
>compiler does it automatically; it's considered a conversion just like
>short to int and double to float. Whether this is good or bad is de
>gustibus; I'll predict most Forthers wouldn't prefer it.

Thanks for clearing this up.

What you say is, once you understand it, it is fairly transparent.
The problem is in understanding. Some java programmers will be content
with the fact that it works, without understanding. A person with a
Forth mindset would not be content in using Java that way.
He would try to define his own container type and discover that there
is a thing like "boxing" and that it matters.

>
><snip>

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]

#26045

On Wednesday, September 25, 2013 8:09:02 PM UTC-7, hughag...@yahoo.com wrote:
> On Wednesday, September 25, 2013 11:44:35 AM UTC-7, Elizabeth D. Rather wrote:
> 
> > But my point is that you can define data objects to behave *exactly* the 
> 
> > way you want them to, to solve the problem at hand.
> 
> 
> 
> I totally disagree with this. It is foolish to custom-implement basic data structures such as arrays for every application. It is easy to write a general-purpose array or linked-list or whatever, that works exactly the way that you want it to for *every* application.
> 

 It is not foolish to custom-implement basic data structures with Forth, it is a trivial and elementary exercise.
 There are billions of lines of compiled code that check for conditions which are not, and are never going to be found.
 Forth is a paradigm shift in that there are NO general-purposes.
 Speed and efficiency is not an arbitrary standard. It is a real and concrete metric that transcends opinion and argument. 
 "We've always done it this way and this is the way it will be done" is of the realm of petty tyrants and sycophants.
> 
> Forthers have to stop dinking around with reinventing the wheel over and over again --- no professional company allots time for their employees to do this --- the employees are expected to spend their time writing application code and making progress. 
> 

 Wheels? Heh! We're talking trans-galactic instantaneous matter transmission for everyone! Nobody requires time allotments. Professionalism is mere pretense, and expectations are tyranny. 

> 
> An employee can't tell his boss: "Well, I spent all day implementing a linked >list, and the remainder of the week will be spent on implementing an LLRB >tree --- maybe I will start on the application program next week --- unless I >think of some more fun ways to avoid getting started in the meantime!" --- >that is a good way to get fired.

 Coding is trivial. The current paradigm merely feeds egos and budgets.
Until hardware and minds follow suit, the waste will go on while the cognitive dissonance spreads. 

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

#26060

On Thursday, September 26, 2013 11:37:57 AM UTC-7, Whammo wrote:
>  It is not foolish to custom-implement basic data structures with Forth, it is a trivial and elementary exercise.
>  There are billions of lines of compiled code that check for conditions which are not, and are never going to be found.
>  Forth is a paradigm shift in that there are NO general-purposes.

There are ALWAYS general-purposes, unless you are autistic --- it is called "abstraction" guys, try it!

Also, my arrays' bad-parameter checking can be turned off with a compile-time switch if it is not needed anymore.

>  Coding is trivial. The current paradigm merely feeds egos and budgets.
> Until hardware and minds follow suit, the waste will go on while the cognitive dissonance spreads. 

Actually, until the suits follow the hardware and the minds...

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web