Went open source with my GA144 simulator written in Factor

[Leon (leon@koningssoftware.com)]

I am happy to say, I went public with the GA144 Simulator, I wrote in Factor.

As you all know the GA144 is a chip containing 144 small computers.
Invented by Chuck Moore and produced by Greenarrays, Inc. See:
http://www.greenarraychips.com/

It is a rather big project with the name arrayFactor. The repository
is at Bitbucket. You can reach it via http://arrayfactor.org

Best regards,

Leon Konings

[Luca Saiu]

On 2013-04-24 at 13:50, Leon (le...@koningssoftware.com) wrote:

> I am happy to say, I went public with the GA144 Simulator, I wrote in Factor.

This looks very nice. Thanks.

--
Luca Saiu
Home page: http://ageinghacker.net
GNU epsilon: http://www.gnu.org/software/epsilon
Marionnet: http://marionnet.org

[m.a.m....@tue.nl]

On Wednesday, April 24, 2013 1:50:50 PM UTC+2, Leon (le...@koningssoftware.com) wrote:
> I am happy to say, I went public with the GA144 Simulator, I wrote in Factor.

Why did you write it in Factor?

-marcel

[Mark Wills]

On Apr 24, 4:03 pm, m.a.m.hend...@tue.nl wrote:

> On Wednesday, April 24, 2013 1:50:50 PM UTC+2, Leon (l...@koningssoftware.com) wrote:
> > I am happy to say, I went public with the GA144 Simulator, I wrote in Factor.
>
> Why did you write it in Factor?
>
> -marcel
>
>

Object oriented? Each processor is an instance of an object?

Just guessing...

[Mark Wills]

On Apr 24, 4:03 pm, m.a.m.hend...@tue.nl wrote:

> On Wednesday, April 24, 2013 1:50:50 PM UTC+2, Leon (l...@koningssoftware.com) wrote:
> > I am happy to say, I went public with the GA144 Simulator, I wrote in Factor.
>
> Why did you write it in Factor?
>
> -marcel
>
>

Also, Factor supports a GUI.

[rickman]

I have looked at the GA simulator. One of the limitations is that it
doesn't handling timing in a very useful way. They make some *very*
gross estimations of instruction timing and let it go. I found that I
couldn't expect it to be very useful for a multiprocessor device dealing
with real time issues.

How does your simulator deal with timing information?

--

Rick

[rickman]

Really? You need factor to get "object" orientation? I think any Forth
could handle that quite easily without being "object oriented". I
believe any number of Forths also provide a GUI.

Not that there is anything wrong with using Factor. I'm just sayin'...

--

Rick

[Mark Wills]

No, there's a number of OOP implementations on the FLAG, so it's easy
to graft it into most ANS Forths. However, in Factor, it's there right
out the box.

Ditto a GUI. It's all in there, ready to go.

However, I'm speculating, I should stress that.

Another more persuasive reason might be that there's only one Factor,
so no compatibility issues; whereas there are 50 million ANS Forths,
and none of them run all but the most trivial programs the same, or at
all.

Just sayin' ;-)

[lkoni...@gmail.com]

At the time I started this project I was looking for something I could do with Factor. Mark mentioned the other reasons already. He is obviously very good at guessing. I am very happy I choose Factor. You get a very nice programming environment with it for free, with many good libraries. Supported by a younger generation of programmers.

The simulator does know, that certain instructions take twice as long as others, and without checking the code I believe it might even be a bit smarter than that. GreenArrays has offered me to use their testing tools to validate the simulator, and I am planning to make use of these tools. I am sure their simulator is much better at timing at the moment.

I believe the biggest advantage of the arrayFactor is in the different ways you can look at the programming problems you are solving. You can work with big screens, many windows with relevant data etcetera. I personally like that.

Leon Konings

[Paul Rubin]

"Leon (le...@koningssoftware.com)" <lkoni...@gmail.com> writes:
> I am happy to say, I went public with the GA144 Simulator, I wrote in
> Factor.

Wow, this sounds neat. I had been toying with the idea of writing
something like that in Erlang, which supports lightweight parallelism.
Factor is of course closer to Forth. I see there is a new version of
Factor and it looks like it is growing pretty rapidly.

[Anton Ertl]

Mark Wills <markrob...@yahoo.co.uk> writes:
>Another more persuasive reason might be that there's only one Factor,
>so no compatibility issues; whereas there are 50 million ANS Forths,
>and none of them run all but the most trivial programs the same, or at
>all.

So what? If being dependent on one system is fine with you, there is
no need to write standard code; just write your simulator specific
for, say, bigForth (with OOP and GUI). If, OTOH, you want a second
source for the language implementation, you can have that in Forth
(but with fewer features), in contrast to Factor.

- 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/

[rickman]

On 4/24/2013 12:02 PM, Mark Wills wrote:
> On Apr 24, 4:52 pm, rickman<gnu...@gmail.com> wrote:
>> On 4/24/2013 11:34 AM, Mark Wills wrote:
>>
>>> On Apr 24, 4:03 pm, m.a.m.hend...@tue.nl wrote:
>>>> On Wednesday, April 24, 2013 1:50:50 PM UTC+2, Leon (l...@koningssoftware.com) wrote:
>>>>> I am happy to say, I went public with the GA144 Simulator, I wrote in Factor.
>>
>>>> Why did you write it in Factor?
>>
>>>> -marcel
>>
>>> Also, Factor supports a GUI.
>>
>> Really? You need factor to get "object" orientation? I think any Forth
>> could handle that quite easily without being "object oriented". I
>> believe any number of Forths also provide a GUI.
>>
>> Not that there is anything wrong with using Factor. I'm just sayin'...
>>
>> --
>>
>> Rick
>>
>>
>
> No, there's a number of OOP implementations on the FLAG, so it's easy
> to graft it into most ANS Forths. However, in Factor, it's there right
> out the box.

My point is, why is OOP needed? Forth can do the same sort of stuff
without having the name OOP.

> Ditto a GUI. It's all in there, ready to go.

Uh, there are GUIs in Forths, all ready to go.

> However, I'm speculating, I should stress that.

Not sure what that means. What are you speculating about?

> Another more persuasive reason might be that there's only one Factor,
> so no compatibility issues; whereas there are 50 million ANS Forths,
> and none of them run all but the most trivial programs the same, or at
> all.

I think that is grossly overstated. I believe there are any number of
programs that run on many Forths without issues.


> Just sayin' ;-)

I'm just listening... lol

--

Rick

[rickman]

The kind of work I do would use the GA part like an FPGA with each cell
handling a piece of the problem and interacting with the neighbors in a
real time manner. GA has never provided enough info to analyze the
timing statically as done in FPGAs. The simulator is only a crude
approximation to timing analysis. I believe they told me they map the
timing into multipliers (3x, 5x, etc) of some basic time value. For
much work that is plenty good enough, but for hard core real time better
info is needed.

BTW, "twice as long" is a very rough approximation. There is data on
much of the instruction timing and it is complicated by memory ops
interacting with the instruction prefetch.

I was just wondering if this was being addressed in your simulator. But
if GA won't release the info, there is no way to incorporate it into
your design. If you have an interest in making the timing aspect of
your simulation more realistic, I'd be happy to help you learn about the
timing data published. It took me a while to dig down and find all the
nitty gritty details. The part they wouldn't share with me is timing on
the interactions via comms channels, both interprocessor and the I/O
ports. Some of their timing info is a bit cryptic.

--

Rick

[Albert van der Horst]

You bet that if you want to add it, it will be easier than in colorforth.
More important, should you add it to arrayforth, your efforts are gone
with the next release of the arrayforth environment.

Apparently there is extensive timing in OKAD, so GA has little
incentive to add it into the similator.

>
>--
>
>Rick

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

[rickman]

On 4/24/2013 2:28 PM, Albert van der Horst wrote:
> In article<kl8uq5$opq$1...@dont-email.me>, rickman<gnu...@gmail.com> wrote:
>> On 4/24/2013 7:50 AM, Leon (le...@koningssoftware.com) wrote:
>>> I am happy to say, I went public with the GA144 Simulator, I wrote in Factor.
>>>
>>> As you all know the GA144 is a chip containing 144 small computers.
>>> Invented by Chuck Moore and produced by Greenarrays, Inc. See:
>>> http://www.greenarraychips.com/
>>>
>>> It is a rather big project with the name arrayFactor. The repository
>>> is at Bitbucket. You can reach it via http://arrayfactor.org
>>
>> I have looked at the GA simulator. One of the limitations is that it
>> doesn't handling timing in a very useful way. They make some *very*
>> gross estimations of instruction timing and let it go. I found that I
>> couldn't expect it to be very useful for a multiprocessor device dealing
>> with real time issues.
>>
>> How does your simulator deal with timing information?
>
> You bet that if you want to add it, it will be easier than in colorforth.
> More important, should you add it to arrayforth, your efforts are gone
> with the next release of the arrayforth environment.

Timing is something that has to be built in from scratch. It would be
hard to add later. The way FPGA simulators handle it would be useful.
They create a queue of events. Every event results in other events
being scheduled and placed in the queue according to the associated
delay. A simulator based on fixed delays or unit delays likely would
need to be started over depending on the structure.

> Apparently there is extensive timing in OKAD, so GA has little
> incentive to add it into the similator.

OKAD is for designing chips. The simulator is for testing software.
The timing info from OKAD, or better, the actual chip characterization,
would be used to set up the simulation timing, but the two are not
functionally interchangable.

GA doesn't worry about the simulator doing accurate timing because they
feel you should do your work on a chip and just measure things. I find
that humorous really. On one hand they say it is too much work to fully
characterize some of the timing I asked for, but on the other hand they
expect users to do the same thing for every timing critical program they
write.

The interactive testing philosophy of Forth is great for finding logical
bugs and such. I think evaluating timing this way is absurd and
actually impossible to do for internal nodes that you can't observe.

I've had to design FPGAs with tools that were broken and would fail to
flag timing problems. Testing timing on real chips by varying
temperature, process and voltage is a *HUGE* pita. BTW, you *can't*
really vary process yourself, can you? The best you can do is to find a
handful of chips that seem to represent a cross section of what is
likely to be produced, then pray. With only two fab lots out so far, I
expect they don't know the range of process yet.

When I had this conversation with GA was when I stopped looking at the
chips for timing critical real time apps.

--

Rick

[Marcel Hendrix]

lkoni...@gmail.com writes Re: Went open source with my GA144 simulator written in Factor

> At the time I started this project I was looking for something I could do
> with Factor. Mark mentioned the other reasons already. He is obviously very
> good at guessing. I am very happy I choose Factor. You get a very nice
> programming environment with it for free, with many good libraries. Supported
> by a younger generation of programmers.

So you, chairman of the Dutch FIG, selected some yuppy's miserable excuse of
a programming language to write a down-to-the-metal environment for the
flagship of modern Forth, the GA144, giving off unmistakable signals that
Forth is unportable, can not cope with the 'obviously' necessary
object-oriented programming style such a project needs, and that the equally
'necessary' GUI interface is alien to current Forth systems.

In doing so you mention the 50 million Forth systems you have examined and
rejected before you selected some arbitrary language experiment and
immediately solved all the problems of a life-long struggle.

> The simulator does know, that certain instructions take twice as long as
> others, and without checking the code I believe it might even be a bit smarter
> than that.

Ah yes, without checking the code, you know. We had people like that in here
before :-)

> GreenArrays has offered me to use their testing tools to validate
> the simulator, and I am planning to make use of these tools. I am sure
> their simulator is much better at timing at the moment.

But you aren't sure, because you had no idea what to do with arrayFactor
once it was finished and have only written a few trivialities in it?

> I believe the biggest advantage of the arrayFactor is in the different ways
> you can look at the programming problems you are solving. You can work with
> big screens, many windows with relevant data etcetera. I personally like
> that.

Much better than that single 64x16 screen that those 50 million
Forths offered? Did you write any Forth programs in the past 20 years?

Indeed -- at long last a CLF post that succeeds to badly ruffle my
feathers.

-marcel

[Mark Wills]

On Apr 24, 9:56 pm, m...@iae.nl (Marcel Hendrix) wrote:
> lkoning...@gmail.com writes Re: Went open source with my GA144 simulator written in Factor

Wow! Attacking somebody just because of the particular language they
used to write a program in. That's got to be a new low, even for this
newsgroup.

[Andrew Haley]

Marcel Hendrix <m...@iae.nl> wrote:
> lkoni...@gmail.com writes Re: Went open source with my GA144 simulator written in Factor
>
>> At the time I started this project I was looking for something I
>> could do with Factor. Mark mentioned the other reasons already. He
>> is obviously very good at guessing. I am very happy I choose
>> Factor. You get a very nice programming environment with it for
>> free, with many good libraries. Supported by a younger generation
>> of programmers.
>
> So you, chairman of the Dutch FIG, selected some yuppy's miserable
> excuse of a programming language to write a down-to-the-metal
> environment for the flagship of modern Forth, the GA144, giving off
> unmistakable signals that Forth is unportable, can not cope with the
> 'obviously' necessary object-oriented programming style such a
> project needs, and that the equally 'necessary' GUI interface is
> alien to current Forth systems.
>
> In doing so you mention the 50 million Forth systems you have
> examined and rejected before you selected some arbitrary language
> experiment and immediately solved all the problems of a life-long
> struggle.

Yo, Marcel! Please don't be so restrained. Tell it like you feel it.

> Indeed -- at long last a CLF post that succeeds to badly ruffle my
> feathers.

And I hope that I never get to be in front of you when you have a
flame thrower...

Andrew.

[Mark Wills]

*Any* language could do it without recourse to objects, obviously. One
chooses ones weapons according to the fight, right? This problem feels
like a perfect fit for objects to me. Given the OPs connection to
Forth, he would have been drawn to Factor by its Forthy-ness and the
fact that it offers a lot of functionality out of the box.

Personally I'd have reached for Java, but that's just me. I'd have
classes for an address bus, a data bus, a circular stack, with
methods to manipulate them. I'd use them to create a processor class.
That processor class would have (among other things) a north, east,
south and west interface which each took an instance of the class
processor. I'd then use this to create a GA144 class which
instantiated 144 instances of processor and hooked them up to each
other.

Each class is completely self-contained, no repeated code, highly
factored, built from the bottom up and tested as you go. There you go;
the Forth paradigm successfully used to leverage Java ;-)

I would imagine that the OP simply fancied giving Factor a test-drive.
Seems reasonable given his connection to Forth. Such heresy is
unforgivable around here, as evidenced by Marcel's post.

[rickman]

On 4/24/2013 4:56 PM, Marcel Hendrix wrote:
...snip...

> So you, chairman of the Dutch FIG, selected some yuppy's miserable excuse of
> a programming language to write a down-to-the-metal environment for the
> flagship of modern Forth, the GA144, giving off unmistakable signals that
> Forth is unportable, can not cope with the 'obviously' necessary
> object-oriented programming style such a project needs, and that the equally
> 'necessary' GUI interface is alien to current Forth systems.
>
> In doing so you mention the 50 million Forth systems you have examined and
> rejected before you selected some arbitrary language experiment and
> immediately solved all the problems of a life-long struggle.

...snip...

> Ah yes, without checking the code, you know. We had people like that in here
> before :-)

...snip...

> But you aren't sure, because you had no idea what to do with arrayFactor
> once it was finished and have only written a few trivialities in it?

...snip...

> Much better than that single 64x16 screen that those 50 million
> Forths offered? Did you write any Forth programs in the past 20 years?
>
> Indeed -- at long last a CLF post that succeeds to badly ruffle my
> feathers.

Quite the little tirade. Not trying to offend, I just found this last
line to be pretty funny... lol!

--

Rick

[rickman]

On 4/24/2013 5:56 PM, Mark Wills wrote:
>
> *Any* language could do it without recourse to objects, obviously. One
> chooses ones weapons according to the fight, right? This problem feels
> like a perfect fit for objects to me. Given the OPs connection to
> Forth, he would have been drawn to Factor by its Forthy-ness and the
> fact that it offers a lot of functionality out of the box.
>
> Personally I'd have reached for Java, but that's just me. I'd have
> classes for an address bus, a data bus, a circular stack, with
> methods to manipulate them. I'd use them to create a processor class.
> That processor class would have (among other things) a north, east,
> south and west interface which each took an instance of the class
> processor. I'd then use this to create a GA144 class which
> instantiated 144 instances of processor and hooked them up to each
> other.

I have to admit that I am largely clueless about OOP, so maybe I
shouldn't criticize... nah! Well, maybe...

I'm just used to doing things in VHDL where I would love to have the
modularity of Forth while describing things like address and data
busses, stacks, etc without a hint of OOP. Maybe I am talking out of
ignorance, but I have no feel for what a class does for you or why
methods are better than... well functions (with side effects of course)
I suppose, is that what they are?

I have always had the impression that OOP is just a way to formalize
what has been done for ages by programmers. It was very early on that I
was taught that programming was all about data structures and the ways
you want to manipulate them. No one told me that I needed a language
with whatever it is that OOP gives you to create "classes" and
"methods". I have done the same thing for many, many years without the
advantage of OOP.

So in all honesty, I'm happy to hear what OOP has to offer if someone
can explain it in a way that would make sense to me. Talking about
classes and methods doesn't relay anything to me until I know what the
advantage of them are over just doing the same thing manually. Do they
automate something that needs to be automated? Do they restrict
something that needs restriction?

> Each class is completely self-contained, no repeated code, highly
> factored, built from the bottom up and tested as you go. There you go;
> the Forth paradigm successfully used to leverage Java ;-)

Why would I want to leverage Java? Is it missing a lever? If each
class is self contained, wouldn't you need to repeat code that could be
used in other classes?

> I would imagine that the OP simply fancied giving Factor a test-drive.
> Seems reasonable given his connection to Forth. Such heresy is
> unforgivable around here, as evidenced by Marcel's post.

Yeah, I don't see a problem with using Factor for this. I just didn't
get the explanation for it.

Hey, Marcel is entitled to a rant every now and then. Everyone else
does, why not him?

--

Rick

[Mark Wills]

On Apr 24, 11:12 pm, rickman <gnu...@gmail.com> wrote:
> On 4/24/2013 5:56 PM, Mark Wills wrote:
>
>
>
> > *Any* language could do it without recourse to objects, obviously. One
> > chooses ones weapons according to the fight, right? This problem feels

> > like a perdon't discuss it herefect fit for objects to me. Given the OPs connection to

Well that's certainly true, we all like a rant sometimes, i thought
it was a bit personal though. I mean the guy just wrote some (cool)
software. It's not like he ran over Marcel's puppy!

As to the oop stuff I'll post tomorrow - bed beckons. Though it will
of course be outrageously off topic, so perhaps email might be better.
And we can discuss VHDL. I'm working on a Forth CPU at the moment with
a friend. 16 bit, multiple instructions per 16 bit word. I don't
discuss it here because apparently only forth programming is allowed
to be discussed, according to the Forth police!

forthfreak at gmail dot com

Mark

[rickman]

It *is* a Forth CPU, right? How about cross posting to ...vhdl or
...verilog as appropriate or *what the hell*, both? Or I'll shoot you
an email and we can laugh at everyone else offline... snicker....
guffaw... chortle.

I just realized that it must be my newsreader that doesn't break the
lines when posting. It breaks the lines for me in the editor though.
Odd... or was the complain that it didn't break the lines at *exactly*
right length maybe?

--

Rick

[rickman]

On 4/24/2013 7:50 AM, Leon (le...@koningssoftware.com) wrote:

BTW, Leon, no matter what I say about some of the issues, I think it is
great that you are working on this. Keep up the good work, no matter
what language.

--

Rick

[AKE]

On Wednesday, April 24, 2013 11:43:19 PM UTC+1, Mark Wills wrote:
>
> I'm working on a Forth CPU at the moment with
> a friend. 16 bit, multiple instructions per 16 bit word. I don't
> discuss it here because apparently only forth programming is allowed
> to be discussed, according to the Forth police!
>

I can't speak for an entire Usenet group, but from the histrionics I've seen over the past few weeks around Rick's hardware postings, I'm inclined to think that these 'Forth police' you mention are in fact just a minority on CLF.

So I'll echo a comment in Rick's thread -- just ignore them.

These matters are interesting, and it looks like to more than just myself judging by the number of posts on the threads discussing Forth chips and Forth hardware, and the apparent background of most Forth people.

So unless there's an up-or-down vote by the entire newsgroup, I don't think anyone can speak for everyone on CLF.

[Hugh Aguilar]

I agree --- anybody who writes a program that works, deserves praise
--- there are many who never write a program that works in any
language, and yet make a career out of being "God's Gift to
Programming," which mostly involves criticizing other programmers'
design decisions.

Here is Marcel Hendrix posting my program on CLF with my name removed
from the copyright notice, and no mention made that I wrote the
program --- and he later says: "I don't know what [your algorithm] is
designed to do." --- I would consider that to be even lower behavior
than what he is up to now, which is just attacking people for writing
programs, but not actually stealing those programs. The OP's program
is open-source though, so Marcel could port it over to iForth and then
pretend that it is his own program.
https://groups.google.com/group/comp.lang.forth/browse_thread/thread/c0fe67c350a5cec3

I programmed in Factor for a while, and it wasn't really for me. I
don't like dynamic-OOP. To each his own, though. Whatever gets the job
done.

It is not uncommon to have multiple languages used together. I have
always said that Forth is primarily for micro-controllers, and that it
is a mistake for ANS-Forth to be for both micro-controllers and
desktop-computers --- it becomes a "jack of all trades and a master of
none." It makes sense to me to use Forth for micro-controllers, but
use a different language for the related desktop-computer programs.

My simulator for the MiniForth was written in Forth, and it was pretty
slow. Of course, it was also table-driven. I did this because, at the
time, the MiniForth didn't exist as a physical chip. The definition of
the MiniForth processor was changing on an almost daily basis, so I
had to have a way to easily add new instructions and/or change what
the instructions did --- so I had a table, which I referred to as the
"MiniForth du jour," which defined what the MiniForth was. This kind
of flexibility isn't needed with the GA144 because its definition is
written in stone (well, silicon).

For most simulators, I would write in assembly-language. Speed is
really an issue with simulation! For a processor such as the GA144
that is massively parallel, I would likely try Go or Erlang or some
such thing that supports concurrency.

I didn't really like Scheme too much, as it was too similar to Factor,
what with dynamic-OOP. Now I'm delving into Go --- has anybody else
tried Go?

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> So in all honesty, I'm happy to hear what OOP has to offer if someone
> can explain it in a way that would make sense to me.

OOP was badly overblown in the 1990's and the functional-programming
community takes a dim view of it these days, but it's a reasonable
approach for something like a GA144 emulator. The idea is you've got a
bunch of data structures (representing F18A nodes) that support similar
operations, but whose specific implementations come in several flavors.
For example, each node has one or more i/o ports, but while the interior
nodes have four such ports, the ones at the edges may have less than
four. And ports facing other nodes are implemented as communications
channels between the nodes, but exterior ports can go to i/o pins, d/a
converters, etc. You'd implement that as a class supporting all the
operations, with some of them delegated to subclasses that implement the
different variants while inheriting the shared operations.

Regarding your issues with GA144 instruction timing: I think GA never
expected people to press the chip timing to its limits. They figured it
was fast enough to cover a wide range of uses. There are of course lots
of other uses for which there is no such thing as "fast enough". The
range you're concerned about, close to the boundary between "not quite
fast enough" and "just barely fast enough", is very narrow and it's
surprising that any particular application (such as yours) falls in it.

[Paul Rubin]

m...@iae.nl (Marcel Hendrix) writes:
> So you, chairman of the Dutch FIG, selected some yuppy's miserable
> excuse of a programming language to write a down-to-the-metal
> environment for the flagship of modern Forth, the GA144, giving off

> unmistakable signals that Forth is unportable, ...

> In doing so you mention the 50 million Forth systems you have examined

Actually it was Mark Wills who mentioned 50 million ANS Forth.s Leon
Konings just was interested in trying out Factor, which doesn't seem
like a sinful thing for a Forther ;-). Really Marcel, I think you got a
little bit too upset by that.

[Andrew Haley]

rickman <gnu...@gmail.com> wrote:
> On 4/24/2013 5:56 PM, Mark Wills wrote:

> I have to admit that I am largely clueless about OOP, so maybe I
> shouldn't criticize... nah! Well, maybe...
>
> I'm just used to doing things in VHDL where I would love to have the
> modularity of Forth while describing things like address and data
> busses, stacks, etc without a hint of OOP. Maybe I am talking out
> of ignorance, but I have no feel for what a class does for you or
> why methods are better than... well functions (with side effects of
> course) I suppose, is that what they are?

OOP is, essentially, about encapsulation and late binding. (Forget
classes, inheritance, etc, for a moment: they're not essential.)
Encapsulation means that when you access data in an object you do it
via the set of routines (aka methods) that object provides. I'm sure
that you know what late binding means already.

The advantage of encapsulation is that you can change the
representation of data in an object without having to change any of
its users. Also, it keeps all that access logic in one place. The
advantage of late binding is that you can have different versions of
an object accessed identically: the user of an object calls its
methods and the right thing happens.

Alan Kay has talked about the first instance of this, which was around
1960. NASA had some data on a tape, but that tape was in a special
binary format. So, there was the problem of how to decode the data,
and how to document the format. There was also the problem that when
the data format changed, you'd have to document that, and change the
programs that read it, and maybe have some sort of version number on
that tape. A program reading the tape would have first to read the
version number, then call right one of a bunch of routines for that
data. Somebody had a truly brilliant idea, one of the best in the
history of computer science: put the routines for decoding the data at
the start of the tape. So, when a program needed to analyze the data,
it first loaded the routines at the start of the tape, and then called
those routines to read the data.

Andrew.

[Andrew Haley]

m.a.m....@tue.nl wrote:
> On Wednesday, April 24, 2013 11:43:36 PM UTC+2, Andrew Haley wrote:
>> Marcel Hendrix <m...@iae.nl> wrote:
> [..]

>> And I hope that I never get to be in front of you when you have a
>> flame thrower...
>

> I am sure that is just an unfortunate formulation; do I come across as
> somebody who would solve a technical argument with such an appropriate
> tool? A strategically placed constipated elephant fully suffices in
> the case under consideration.

Hah, yes! Good plan. :-)

Andrew.

[lkoni...@gmail.com]

Hi Marcel,

Nice rant. Some people like that, but I like to keep it short, and not too personal. I expected an attack like this,. Interesting that it comes from you.

In the talk I held in Germany last Saturday, I mentioned that I like Factor, but I love Forth.

The main reason I choose Factor was that I wanted to do something with this new interesting language. I wanted to learn Lisp also. So a mix of Forth and Lisp seemed very attractive. Factor is a very powerful language, and I am still very happy with this choice.

I could have choosen gForth also, if portability was the main issue.

You are not the first person, who is laughing about the fact, that I as chairman of the Dutch FIG am working with Factor. It is kind of funny. I believe ii has enough Forth like features to get away with it.

The purpose for writing the arrayFactor was to learn some Factor, and understand more about how to program the GA144. For the last year my progress has been slow. This is the main reason I made it public. People like you can push me to become more productive.

Thanks for the little push!

Leon

[Stephen Pelc]

For Intellasys, MPE wrote a GUI for the Intellasys simulator for the
24 core chip. This was before we had the cross-platform GUI that we
now have.

>lkoni...@gmail.com writes Re: Went open source with my GA144 simulator written in Factor
>
>> At the time I started this project I was looking for something I could do
>> with Factor. Mark mentioned the other reasons already. He is obviously very
>> good at guessing. I am very happy I choose Factor. You get a very nice
>> programming environment with it for free, with many good libraries. Supported
>> by a younger generation of programmers.

However, it seems to me that the key phrase in the paragraph above
is "for free".

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Alex McDonald]

On Apr 25, 9:23 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:

[snip]

>
> Alan Kay has talked about the first instance of this, which was around
> 1960.  NASA had some data on a tape, but that tape was in a special
> binary format.  So, there was the problem of how to decode the data,
> and how to document the format.  There was also the problem that when
> the data format changed, you'd have to document that, and change the
> programs that read it, and maybe have some sort of version number on
> that tape.  A program reading the tape would have first to read the
> version number, then call right one of a bunch of routines for that
> data.  Somebody had a truly brilliant idea, one of the best in the
> history of computer science: put the routines for decoding the data at
> the start of the tape.  So, when a program needed to analyze the data,
> it first loaded the routines at the start of the tape, and then called
> those routines to read the data.
>
> Andrew.

What goes around, comes around. Digital preservation & archiving is a
growing field. Many recommend storing entire VMs along with the data;
now you have an entire encapsulated application and OS and the data as
a single object. The only requirement is a "machine" (also described
in the object's meta-data) to run it on. Future generations are
expected to be able to build simulators to rerun the VM and reprocess
the data.

I wish my grandchildren all the best in interpreting the Intel specs.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>>lkoni...@gmail.com writes Re: Went open source with my GA144 simulator written in Factor

>>> I am very happy I choose Factor. You get a very nice
>>> programming environment with it for free, with many good libraries.

[...]

>However, it seems to me that the key phrase in the paragraph above
>is "for free".

I think the discerning part in that sentence is "programming
environment" (as in "IDE"). Apart from Wolf Wejgaards work on Holon,
I am not aware that people have been doing such things for Forth
(probably because most Forth programmers, including me, don't see that
an IDE provides an advantage).

[m.a.m....@tue.nl]

On Wednesday, April 24, 2013 11:43:36 PM UTC+2, Andrew Haley wrote:
> Marcel Hendrix <m...@iae.nl> wrote:
[..]

> And I hope that I never get to be in front of you when you have a
> flame thrower...

I am sure that is just an unfortunate formulation; do I come across as

somebody who would solve a technical argument with such an inappropriate

tool? A strategically placed constipated elephant fully suffices in
the case under consideration.

-marcel

[Doug Hoffman]

On 4/25/13 4:23 AM, Andrew Haley wrote:
> rickman <gnu...@gmail.com> wrote:
>> On 4/24/2013 5:56 PM, Mark Wills wrote:
>
>> I have to admit that I am largely clueless about OOP, so maybe I
>> shouldn't criticize... nah! Well, maybe...
>>
>> I'm just used to doing things in VHDL where I would love to have the
>> modularity of Forth while describing things like address and data
>> busses, stacks, etc without a hint of OOP. Maybe I am talking out
>> of ignorance, but I have no feel for what a class does for you or
>> why methods are better than... well functions (with side effects of
>> course) I suppose, is that what they are?
>
> OOP is, essentially, about encapsulation and late binding. (Forget
> classes, inheritance, etc, for a moment: they're not essential.)
> Encapsulation means that when you access data in an object you do it
> via the set of routines (aka methods) that object provides. I'm sure
> that you know what late binding means already.
>
> The advantage of encapsulation is that you can change the
> representation of data in an object without having to change any of
> its users. Also, it keeps all that access logic in one place. The
> advantage of late binding is that you can have different versions of
> an object accessed identically: the user of an object calls its
> methods and the right thing happens.

I agree with what Andrew says. Of course there can be a lot more to it.

To expound a bit more on encapsulation. Once you bypass using only
methods (aka sending messages) to access an object's data and routines,
which some programmers seem want to do, then you have destroyed the
ability to do what Andrew describes. In other words if you bypass
messaging and then change the internal data structure/naming then you
just broke all the code that uses those objects. Don't do that, IMHO.


Late binding. A powerful technique for code reuse. Consider when you
define a new type of object based on an already defined object, call it
a subclass type of object. Say you have defined a cell-width array
class. The print method may look like this:

method .elem ( n -- ) . method-end
method print self size 0 ?do i self at self .elem loop method-end

A floating-point array, a subclass of the above array, need only define
the ".elem" method and print will work as needed. A new print method
need not be defined:

method .elem ( R: r -- ) f. method-end


OOP can be controversial. There isn't even wide agreement on what
minimum features are needed for object programming. Google "advantages
of oop over procedural programming" or whatever, read the various
descriptions and opinions and draw your own conclusions.

Standard disclaimer: I do *not* believe that an OOP approach is always
best. OOP only lends itself well to certain categories of problems.

I don't like languages where everything is an object. Rather, using an
objects extension that integrates well with conventional Forth
programming is my preference.

-Doug

[Albert van der Horst]

In article <2013Apr2...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>steph...@mpeforth.com (Stephen Pelc) writes:
>>>lkoni...@gmail.com writes Re: Went open source with my GA144
>simulator written in Factor
>>>> I am very happy I choose Factor. You get a very nice
>>>> programming environment with it for free, with many good libraries.
>[...]
>>However, it seems to me that the key phrase in the paragraph above
>>is "for free".
>
>I think the discerning part in that sentence is "programming
>environment" (as in "IDE"). Apart from Wolf Wejgaards work on Holon,
>I am not aware that people have been doing such things for Forth
>(probably because most Forth programmers, including me, don't see that
>an IDE provides an advantage).

Surely Leon feels more comfortable with an IDE.

For free counts for something too. At this point in time only hobbyists
are attracted to Greenarrays. Investing hundreds of euro's makes it
unlikely many would get on board. Now it costs nothing to try out the
arrayfactor environment, even before you purchase any chips.

Recent discussion trigger me to stress that this is not a toy and
is sufficiently mature to run my parpi (parallel prime counting program)
which exercises the larger part of the GA144.

>
>- anton

[m.a.m....@tue.nl]

On Thursday, April 25, 2013 11:14:23 AM UTC+2, lkoni...@gmail.com wrote:
> Hi Marcel, Nice rant. Some people like that, but I like to keep it
> short, and not too personal. I expected an attack like this,.
> Interesting that it comes from you.

There would not have a been a reaction were you not the Dutch FIG's present chairman.

-marcel

[Albert van der Horst]

In article <fe1be464-94dd-468d...@googlegroups.com>,

Why don't you become a member of the Dutch Forth Chapter (official name
hcc!forth ) and be candidate for chairman?
(Last april Leon was re-elected for 3 more years.)
hcc!forth has always been taken Forth broadly, incorporating things as
Novix, colorforth, GA144 chips, our own chip (FIETS), BYTEforth (8 bits Forth,
non-standard), and now a stack oriented Forth-inspired language: Factor.

>
>-marcel

[Alex McDonald]

On Apr 25, 10:56 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> stephen...@mpeforth.com (Stephen Pelc) writes:
> >>lkoning...@gmail.com writes Re: Went open source with my GA144 simulator written in Factor

Win32Forth provides a sort-of IDE; at least, the GUI based editor
(written in Forth) is integrated into the Forth environment.

I'm not sure about IDEs in general. I have tried Eclipse, and to be
frank it is an overwhelming and huge environment that seems to require
more work than the actual coding effort. But I do find a console and
separate editor quite limiting; getting edited text back and forth
from the console to the editor is clumsy and error prone.

[Bernd Paysan]

Andrew Haley wrote:
> OOP is, essentially, about encapsulation and late binding. (Forget
> classes, inheritance, etc, for a moment: they're not essential.)
> Encapsulation means that when you access data in an object you do it
> via the set of routines (aka methods) that object provides. I'm sure
> that you know what late binding means already.

The typical approach in Forth IMHO is to use the features as isolated tools.
IMHO, OOP is late binding methods, structures referenced by an "implicit
pointer", wordlists to separate different classes or class hierarchies.
Best used creatively, and use what you need. I've heard you saying at
EuroForth "I don't need a current object pointer" - fine with me, *I* do
need that.

I've added a current object pointer to Mini-OOF, and suddenly, it does all
what I need. Well, the second thing I added to it was a template method and
ivar, so you can actually choose whatever you want: with or without current
object, or with a user variable as entry pointer for your class (very
suitable if you want to use that for IO vectoring).

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Paul Rubin]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
> For free counts for something too. At this point in time only hobbyists
> are attracted to Greenarrays. Investing hundreds of euro's makes it
> unlikely many would get on board. Now it costs nothing to try out the
> arrayfactor environment, even before you purchase any chips.

Well, Greenarrays has its own simulator too (Arrayforth). I'm not sure
what Leon's simulator does differently. It's of course fine to have
more than one regardless. Factor was an interesting choice. I do know
there are some OOP systems for ANS Forth that might have been a good fit
for the simulation side of the problem. I don't know about the GUI
side.

[Anton Ertl]

Alex McDonald <bl...@rivadpm.com> writes:
>I'm not sure about IDEs in general. I have tried Eclipse, and to be
>frank it is an overwhelming and huge environment that seems to require
>more work than the actual coding effort. But I do find a console and
>separate editor quite limiting; getting edited text back and forth
>from the console to the editor is clumsy and error prone.

The way I work, I don't do that. Most of the time I edit code in the
editor, save the file, and then load and run it from the shell command
line. Sometimes I do things on the Forth command line, but that's
just quickly running a few commands that I don't intend (and don't)
copy back to the editor.

The Emacs Forth mode forth.el (from which gforth.el is derived)
contains more IDE-like stuff, like running Forth in an emacs shell
buffer, and copying a region to the Forth buffer (as input to the
Forth system), but I never really used it, nor did any other Gforth
developer, so we did not maintain that code.

For getting code back, you could copy it from the history file (which
contains the command-line history of Gforth), but I never do that,
either.

I do copy and paste from the editor to the Forth system (at least
Forth systems where that works, like Gforth) when I write postings
here, and want to test or benchmark the code I write. I only find it
clumsy on the one system where it doesn't work.

[lkoni...@gmail.com]

I am sometimes saying I would like arrayFactor to be an IDE. I like Eclipse. Mostly I like two things about it. The way windows are neatly organized, and the tree of documents.

Factor starts with just the listener, which is a terminal with some extras. The help and documentation use the browser window. An inspector window shows you info about an object. There is also a debugger window when needed. Then there is the window for the very nice testing facility.

arrayFactor makes it worse if you don't like windows. You have the nodes window with 144 nodes. For every node you can open a number of windows too. The stacks, ram, rom, registers, instructions, ports and source editor.

So you have to be really selective about which window to open. It can get messy. If you don't like windows, just use the simulator from GreenArrays!

You can get a lot of information, but at a price. So arrayFactor is for free, but it could drive you crazy.

Best regards,
Leon

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Andrew Haley wrote:
>> OOP is, essentially, about encapsulation and late binding. (Forget
>> classes, inheritance, etc, for a moment: they're not essential.)
>> Encapsulation means that when you access data in an object you do it
>> via the set of routines (aka methods) that object provides. I'm sure
>> that you know what late binding means already.
>
> The typical approach in Forth IMHO is to use the features as isolated tools.
> IMHO, OOP is late binding methods, structures referenced by an "implicit
> pointer", wordlists to separate different classes or class hierarchies.

Right, but classes and class hierarchies aren't essential to OOP: not
all OOP systems have them.

> Best used creatively, and use what you need. I've heard you saying at
> EuroForth "I don't need a current object pointer" - fine with me, *I* do
> need that.

Sure, you need a current object pointer, of course, else how would you
find your data? The only question is where that pointer goes.

Andrew.

[rickman]

On 4/24/2013 11:23 PM, Paul Rubin wrote:
> rickman<gnu...@gmail.com> writes:
>> So in all honesty, I'm happy to hear what OOP has to offer if someone
>> can explain it in a way that would make sense to me.
>
> OOP was badly overblown in the 1990's and the functional-programming
> community takes a dim view of it these days, but it's a reasonable
> approach for something like a GA144 emulator. The idea is you've got a
> bunch of data structures (representing F18A nodes) that support similar
> operations, but whose specific implementations come in several flavors.
> For example, each node has one or more i/o ports, but while the interior
> nodes have four such ports, the ones at the edges may have less than
> four. And ports facing other nodes are implemented as communications
> channels between the nodes, but exterior ports can go to i/o pins, d/a
> converters, etc. You'd implement that as a class supporting all the
> operations, with some of them delegated to subclasses that implement the
> different variants while inheriting the shared operations.

Thanks for the attempt to explain OOP, but I can't say I get the point
of OOP as a language. Everything you describe can be done in any
language. Obviously there is something about OOP that facilitates this
particular method of decomposition. But I can honestly say this is
exactly how I would develop a GA144 simulator regardless of the
language. I just wouldn't use the word "class", etc.

> Regarding your issues with GA144 instruction timing: I think GA never
> expected people to press the chip timing to its limits. They figured it
> was fast enough to cover a wide range of uses. There are of course lots
> of other uses for which there is no such thing as "fast enough". The
> range you're concerned about, close to the boundary between "not quite
> fast enough" and "just barely fast enough", is very narrow and it's
> surprising that any particular application (such as yours) falls in it.

Yeah, I was looking at using the GA144 for a single chip oscilloscope.
It has some potential even though there are lots of others out there,
they are far from single chip, using an FPGA, ADC, RAM, MCU and the misc
power, interface, etc chips. The GA144 has potential for replacing the
FPGA, ADC and MCU. I was looking at making an interface to an SDRAM to
get more speed than the static RAM with the eval board. But to run a
fast clock required interactions between nodes with high precision, very
much like is done all the time with FPGAs.

When I asked for the timing of interactions between nodes and other
nodes or the external I/O I was told this was proprietary. I realized
that without better support the effort was hopeless, so I gave up.

I still like the idea. I got a lot of inspiration from Chuck's work
with video although I really want a device that attaches to the PC. I
think I could get an input bandwidth of up to 10 MHz or so. That's
pretty good for a device that might only cost $30 to build. But without
a practical way to understand the timing of the comms there is no way I
can design like I design with FPGAs.

BTW, the real timing of the GA144 nodes are not as obvious as they might
appear. There are some subtleties that require reading of the
information a number of times to perceive. But then is that surprising
given this is a chip by Chuck? "The Map is not the Territory". Or as
Chuck puts it, "the chip is not the chip".

--

Rick

[rickman]

On 4/25/2013 4:23 AM, Andrew Haley wrote:
> rickman<gnu...@gmail.com> wrote:
>> On 4/24/2013 5:56 PM, Mark Wills wrote:
>
>> I have to admit that I am largely clueless about OOP, so maybe I
>> shouldn't criticize... nah! Well, maybe...
>>
>> I'm just used to doing things in VHDL where I would love to have the
>> modularity of Forth while describing things like address and data
>> busses, stacks, etc without a hint of OOP. Maybe I am talking out
>> of ignorance, but I have no feel for what a class does for you or
>> why methods are better than... well functions (with side effects of
>> course) I suppose, is that what they are?
>
> OOP is, essentially, about encapsulation and late binding. (Forget
> classes, inheritance, etc, for a moment: they're not essential.)
> Encapsulation means that when you access data in an object you do it
> via the set of routines (aka methods) that object provides. I'm sure
> that you know what late binding means already.

Uh, you have that exactly backwards. Encapsulation is a concept I
learned in college, or one very like it called "decision hiding". Over
the years I learned to encapsulate my code so that each data structure
was operated on by a set of routines and *only* those routines so as to
hide the decisions made in how the data structure was implemented.

I have no idea what "late binding" is.

> The advantage of encapsulation is that you can change the
> representation of data in an object without having to change any of
> its users. Also, it keeps all that access logic in one place. The
> advantage of late binding is that you can have different versions of
> an object accessed identically: the user of an object calls its
> methods and the right thing happens.

Yes, it was called "decision hiding" back in my day in school. It
applies to other aspects of system design as well, interfaces, UI
issues, etc.

Oops, you just used the 'm' word. What is that exactly or do I really
need to know? The real question is "what is better about OOP that I
can't do in a language without OOP"? I can implement all these concepts
without OOP as far as I can tell.

> Alan Kay has talked about the first instance of this, which was around
> 1960. NASA had some data on a tape, but that tape was in a special
> binary format. So, there was the problem of how to decode the data,
> and how to document the format. There was also the problem that when
> the data format changed, you'd have to document that, and change the
> programs that read it, and maybe have some sort of version number on
> that tape. A program reading the tape would have first to read the
> version number, then call right one of a bunch of routines for that
> data. Somebody had a truly brilliant idea, one of the best in the
> history of computer science: put the routines for decoding the data at
> the start of the tape. So, when a program needed to analyze the data,
> it first loaded the routines at the start of the tape, and then called
> those routines to read the data.

That is great until you change the machine you want to run it on, lol...
unless it was in open firmware and was compiled in real time.

--

Rick

[Gerry Jackson]

On 25/04/2013 15:04, Alex McDonald wrote:
> On Apr 25, 10:56 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>> stephen...@mpeforth.com (Stephen Pelc) writes:
>>>> lkoning...@gmail.com writes Re: Went open source with my GA144 simulator written in Factor
>>>>> I am very happy I choose Factor. You get a very nice
>>>>> programming environment with it for free, with many good libraries.
>> [...]
>>> However, it seems to me that the key phrase in the paragraph above
>>> is "for free".
>>
>> I think the discerning part in that sentence is "programming
>> environment" (as in "IDE"). Apart from Wolf Wejgaards work on Holon,
>> I am not aware that people have been doing such things for Forth
>> (probably because most Forth programmers, including me, don't see that
>> an IDE provides an advantage).
>>

>

> Win32Forth provides a sort-of IDE; at least, the GUI based editor
> (written in Forth) is integrated into the Forth environment.
>
> I'm not sure about IDEs in general. I have tried Eclipse, and to be
> frank it is an overwhelming and huge environment that seems to require
> more work than the actual coding effort.

I've used Eclipse for some 3 or 4 years now and use it all the time,
even for small things. I've got it set up so that my test cycle is to
edit a forth source file, run a batch file by double clicking on it.
This sets up things and starts my Forth system to run whatever it is I'm
testing. Literally a double click to run & test 'just like that'. I use
it with a Mercurial plug-in for version control. I use it to run several
Forth systems in the same way when doing portability testing. Any file
type can be stored in the directory tree & viewed/run by double clicking
on it.

Eclipse is admittedly big and I probably only use a small part of it and
it took a bit of effort to get started with it. But for me it was worth
it and I wouldn't go back to a non-IDE approach.

But I do find a console and
> separate editor quite limiting; getting edited text back and forth
> from the console to the editor is clumsy and error prone.
>

--
Gerry

[AKE]

On Thursday, April 25, 2013 8:47:42 PM UTC+1, rickman wrote:
>
> <snip> The real question is "what is better about OOP that I

> can't do in a language without OOP"? I can implement all these concepts
> without OOP as far as I can tell.
>

IMHO the answer to your question is: nothing. There is nothing about OOP that cannot be done in a non-OOP language. It's just you have to establish all of the conventions yourself, and then stick to them. But I would imagine that caveat is not probably neither new nor worrying to Forth programmers.

OOP is essentially a paradigm, a way of organising information and designing software -- again IMHO it is an intuitive model for building blocks in software.

Is it necessary? No. As you've mentioned, experienced programmers employ data hiding naturally, even if the language does not provide for it. And bad programmers don't hide their data properly even if the language does provide OOP facilities.

There's an online book written in the mid nineties by Jerry Jongerius in which he argues that bug-free C programs should be written in a manner that employs OO principles -- however, notice that he does not recommend C++.

http://www.duckware.com/bugfreec/index.html

[AKE]

On Thursday, April 25, 2013 8:47:42 PM UTC+1, rickman wrote:

> On 4/25/2013 4:23 AM, Andrew Haley wrote:
>
> > OOP is, essentially, about encapsulation and late binding. (Forget
> > classes, inheritance, etc, for a moment: they're not essential.)
>

Agree about encapsulation.

I would, however, replace late binding with polymorphism.

Why OOP? For a novice programmer, a well-designed OOP language can provide a friendlier model for writing applications. (I don't consider C++ to be a user friendly OOP language.)

[Andrew Haley]

rickman <gnu...@gmail.com> wrote:
> On 4/25/2013 4:23 AM, Andrew Haley wrote:
>> rickman<gnu...@gmail.com> wrote:
>>> On 4/24/2013 5:56 PM, Mark Wills wrote:
>>
>>> I have to admit that I am largely clueless about OOP, so maybe I
>>> shouldn't criticize... nah! Well, maybe...
>>>
>>> I'm just used to doing things in VHDL where I would love to have the
>>> modularity of Forth while describing things like address and data
>>> busses, stacks, etc without a hint of OOP. Maybe I am talking out
>>> of ignorance, but I have no feel for what a class does for you or
>>> why methods are better than... well functions (with side effects of
>>> course) I suppose, is that what they are?
>>
>> OOP is, essentially, about encapsulation and late binding. (Forget
>> classes, inheritance, etc, for a moment: they're not essential.)
>> Encapsulation means that when you access data in an object you do it
>> via the set of routines (aka methods) that object provides. I'm sure
>> that you know what late binding means already.
>
> Uh, you have that exactly backwards. Encapsulation is a concept I
> learned in college, or one very like it called "decision hiding". Over
> the years I learned to encapsulate my code so that each data structure
> was operated on by a set of routines and *only* those routines so as to
> hide the decisions made in how the data structure was implemented.

"decision hiding" is certainly not standard terminology.

> I have no idea what "late binding" is.

I suspect you're familiar with the concept, though. It can be as
simple as a few pointers at the start of the data; all a caller needs
to know is that you EXECUTE them to access the data. It's called
"late binding" because the call isn't bound to any particular target
until execution time. This is distinct from "early binding" where you
know at compile time exactly where a call is going to go.

> Oops, you just used the 'm' word. What is that exactly or do I
> really need to know?

"method", you mean? They're the routines that access the data, that's
all.

> The real question is "what is better about OOP that I can't do in a
> language without OOP"? I can implement all these concepts without
> OOP as far as I can tell.

No, you can't do that without OOP, because those concepts *are* OOP.
Do that consistently. and you're object-oriented programming. You
don't need an object-oriented language: that's purely a matter of
notation. But notation is important. Turing famously was quite happy
to read a display backwards in binary, but everyone else found it
inconvenient.

>> Alan Kay has talked about the first instance of this, which was
>> around 1960. NASA had some data on a tape, but that tape was in a
>> special binary format. So, there was the problem of how to decode
>> the data, and how to document the format. There was also the
>> problem that when the data format changed, you'd have to document
>> that, and change the programs that read it, and maybe have some
>> sort of version number on that tape. A program reading the tape
>> would have first to read the version number, then call right one of
>> a bunch of routines for that data. Somebody had a truly brilliant
>> idea, one of the best in the history of computer science: put the
>> routines for decoding the data at the start of the tape. So, when
>> a program needed to analyze the data, it first loaded the routines
>> at the start of the tape, and then called those routines to read
>> the data.
>
> That is great until you change the machine you want to run it on,
> lol... unless it was in open firmware and was compiled in real
> time.

Not in 1960. These days people use Java bytecode.

Andrew.

[lkoni...@gmail.com]

Hi Gerry,

What you are doing with Eclipse sounds great to me. It never occured to me to use it with Forth. I used it with some other languages like Java and lately Code Composer Studio. These environments work "out of the box". I will have to look into this!

Best regards,
Leon

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> The Emacs Forth mode forth.el (from which gforth.el is derived)
> contains more IDE-like stuff, like running Forth in an emacs shell

I use Forth mode and find it's convenient. Somehow I had thought that
the fancy commercial Forths had IDE's, but I've never used one so don't
know. I even thought it was like that in the olden days of blocks and
screens. I've been wanting someday to see Polyforth in action, or get
F83 running just to see what it was like.

[Doug Hoffman]

On 4/25/13 12:16 PM, Anton Ertl wrote:
> Alex McDonald <bl...@rivadpm.com> writes:
>> I'm not sure about IDEs in general. I have tried Eclipse, and to be
>> frank it is an overwhelming and huge environment that seems to require
>> more work than the actual coding effort. But I do find a console and
>> separate editor quite limiting; getting edited text back and forth
>>from the console to the editor is clumsy and error prone.
>
> The way I work, I don't do that. Most of the time I edit code in the
> editor, save the file, and then load and run it from the shell command
> line. Sometimes I do things on the Forth command line, but that's
> just quickly running a few commands that I don't intend (and don't)
> copy back to the editor.

...

> I do copy and paste from the editor to the Forth system (at least
> Forth systems where that works, like Gforth) when I write postings
> here, and want to test or benchmark the code I write.

MacForth has each editor window do double duty as a console. So you can
do something like the following in the same window with no
copy/switch-window/paste/switch-window-back tedium:

: go ( n -- )<return>
0 do i . cr loop ;<return>
3 go
<hilite above 3 lines and press enter>
0
1
2
ok

If you like the results of the session then you can simply save the
window and it becomes a source file. Probably would want to comment out
the output (or just delete it if you don't want to document behavior)
which is done by hiliting the last 5 lines and invoking a command from
the MacForth GUI menu (although ok is a noop):

: go ( n -- )
0 do i . cr loop ;
((
ok
3 go
0
1
2
ok
))

Again, no copy/paste. No switching windows.

As many editor windows as desired can be open at the same time. I often
use 10+.

Command-K simultaneously saves the current editor window and then loads
it in one swell foop. The window remains open for further editing/running.

If I don't care about saving input/output from the session then I'll
just use an Untitled editor window and not save it when done.

Keywords are optionally hilited (on a window-by-window basis) with
color/bold/italic/underline all of which is user configurable. Standard
for a good programmer's editor these days I believe.

There's a lot more.

-Doug

[Bernd Paysan]

Andrew Haley wrote:

> Bernd Paysan <bernd....@gmx.de> wrote:
>> The typical approach in Forth IMHO is to use the features as isolated
>> tools. IMHO, OOP is late binding methods, structures referenced by an
>> "implicit pointer", wordlists to separate different classes or class
>> hierarchies.
>
> Right, but classes and class hierarchies aren't essential to OOP: not
> all OOP systems have them.

Yes; though you could say that a prototype based system has classes, but
each class has at least one instance.

>> Best used creatively, and use what you need. I've heard you saying at
>> EuroForth "I don't need a current object pointer" - fine with me, *I* do
>> need that.
>
> Sure, you need a current object pointer, of course, else how would you
> find your data? The only question is where that pointer goes.

If it's on the stack, as it was with the first Mini-OOF, it is in the way.

[Roelf Toxopeus]

In article <517a787b$0$32117$1472...@news.sunsite.dk>,

Like, it's written in Forth.
The source code is there.
Adjust, extend to your heart's content...

Sorely missed.

-roelf

[rickman]

On 4/25/2013 5:43 PM, Andrew Haley wrote:
> rickman<gnu...@gmail.com> wrote:
>> On 4/25/2013 4:23 AM, Andrew Haley wrote:
>>> OOP is, essentially, about encapsulation and late binding. (Forget
>>> classes, inheritance, etc, for a moment: they're not essential.)
>>> Encapsulation means that when you access data in an object you do it
>>> via the set of routines (aka methods) that object provides. I'm sure
>>> that you know what late binding means already.
>>
>> Uh, you have that exactly backwards. Encapsulation is a concept I
>> learned in college, or one very like it called "decision hiding". Over
>> the years I learned to encapsulate my code so that each data structure
>> was operated on by a set of routines and *only* those routines so as to
>> hide the decisions made in how the data structure was implemented.
>
> "decision hiding" is certainly not standard terminology.

Maybe not now, but in the Software Engineering course I took it was a
significant topic. This was actually one of the more significant
courses I took in school. It was taught in EE by a professor who
actually wanted to be involved with the students. He was one of those
rare teachers who make a difference. The course covered a lot that make
us think and is the foundation of how I approach work in many ways.

>> I have no idea what "late binding" is.
>
> I suspect you're familiar with the concept, though. It can be as
> simple as a few pointers at the start of the data; all a caller needs
> to know is that you EXECUTE them to access the data. It's called
> "late binding" because the call isn't bound to any particular target
> until execution time. This is distinct from "early binding" where you
> know at compile time exactly where a call is going to go.

Hmmm, so what would happen between compile time and execution time that
might alter these pointers? I think that is what is significant about it.

>> Oops, you just used the 'm' word. What is that exactly or do I
>> really need to know?
>
> "method", you mean? They're the routines that access the data, that's
> all.

I have *always* use the concept behind "methods". I think it was a low
level course where the instructor explained that programming was all
about defining data structures and then the operations on those data
structures. I guess all the examples we were given had separations
between the methods for different data structures, so it never occurred
to me to do it a different way.

>> The real question is "what is better about OOP that I can't do in a
>> language without OOP"? I can implement all these concepts without
>> OOP as far as I can tell.
>
> No, you can't do that without OOP, because those concepts *are* OOP.
> Do that consistently. and you're object-oriented programming. You
> don't need an object-oriented language: that's purely a matter of
> notation. But notation is important. Turing famously was quite happy
> to read a display backwards in binary, but everyone else found it
> inconvenient.

Ok, then what is different about an OOP language? It seems I have
mostly done OOP, but without using an OOP language.

--

Rick

[Andrew Haley]

So put it in a local: that's what locals are for, and you can put that
pointer in one, just the same as you'd do with anything else that's in
the way. There's no difference between the current object in OOP and
a pointer to a struct. But we're getting beside the point, which is
about question is about what OOP *is*, not how-many-angels-can-dance-
on-the-head-of-a-pin implementation details.

Andrew.

[Andrew Haley]

rickman <gnu...@gmail.com> wrote:
> On 4/25/2013 5:43 PM, Andrew Haley wrote:
>> rickman<gnu...@gmail.com> wrote:

>
>>> I have no idea what "late binding" is.
>>
>> I suspect you're familiar with the concept, though. It can be as
>> simple as a few pointers at the start of the data; all a caller needs
>> to know is that you EXECUTE them to access the data. It's called
>> "late binding" because the call isn't bound to any particular target
>> until execution time. This is distinct from "early binding" where you
>> know at compile time exactly where a call is going to go.
>
> Hmmm, so what would happen between compile time and execution time
> that might alter these pointers? I think that is what is
> significant about it.

All sorts of things. There might be any number of different kinds of
object, each with its own behaviour for each call. Which kind of
object gets generated might depend on the program's run-time
environment, for example. When you execute a window's display method
you don't know what kind of window it is. It might be a mail window
or it might be a chat window, but the caller doesn't need to know.

>>> The real question is "what is better about OOP that I can't do in a
>>> language without OOP"? I can implement all these concepts without
>>> OOP as far as I can tell.
>>
>> No, you can't do that without OOP, because those concepts *are* OOP.
>> Do that consistently. and you're object-oriented programming. You
>> don't need an object-oriented language: that's purely a matter of
>> notation. But notation is important. Turing famously was quite happy
>> to read a display backwards in binary, but everyone else found it
>> inconvenient.
>
> Ok, then what is different about an OOP language? It seems I have
> mostly done OOP, but without using an OOP language.

It's just about notational convenience. It's not hard to do in Forth,
where you can define methods so that

FOO PRINT

executes the PRINT method on the object FOO. It might be as simple as
fetching a pointer to a table from FOO, then jumping to the Nth entry
in that table. It's Forth, so it's pretty easy. But OO Forth
extensions can be a lot more sophisticated than that, providing all
manner of useful features to make life easy so that you don't have to
construct all that scaffolding by hand.

Andrew.

[Bernd Paysan]

Andrew Haley wrote:
> So put it in a local: that's what locals are for, and you can put that
> pointer in one, just the same as you'd do with anything else that's in
> the way. There's no difference between the current object in OOP and
> a pointer to a struct. But we're getting beside the point, which is
> about question is about what OOP *is*, not how-many-angels-can-dance-
> on-the-head-of-a-pin implementation details.

Andrew, you don't get it, and you really should try it. The current-object
stays current when you call a word that's using it, you don't need to pass
it around all the time. It's just there, it's a global thing (can be a
register), and with >o and o> it has it's (conceptual) stack associated.

It doesn't work if you just have it within one word.

When you tell me "I don't need it", I rather think it's "I've never used it,
so I don't understand why it's good."

Of course it's not *essential* to OOP.

[m...@iae.nl]

On Friday, April 26, 2013 5:16:26 PM UTC+2, Roelf Toxopeus wrote:
> In article <517a787b$0$32117$1472...@news.sunsite.dk>,
[..]

> Like, it's written in Forth.
> The source code is there.
> Adjust, extend to your heart's content...
>
> Sorely missed.

Can the source be ported to other Forths?
Does it need kernel support? What kind of?

-marcel

[Doug Hoffman]

Perhaps you could explain to Andrew, and the rest of us, why it's good.

Consuming a register seems a very large price to pay, if that is
required, and not likely to exist for very many Forths. But I gather
it's not required. So maybe we should ignore that aspect for now.

The >o and o> manipulations for the object stack is obviously more
effort for the programmer, so an explanation of the usage (when and why
use >o and o>) and the payback for the programmer would seem beneficial.

-Doug

[Bernd Paysan]

Doug Hoffman wrote:
> Perhaps you could explain to Andrew, and the rest of us, why it's good.

When you do OOP programming, you usually refer to instance variables. If
you use something like Mini-OOF, it's going to be

:noname ( params ... this -- return ) { this }
this x @ this y @ ... this bla ;

your code is cluttered with "this". Many OOP packages therefore "hide" the
local this, to make instance variable access use a local variable, but you
still need this to call other methods.

As we are programming Forth, our methods are factored into small one- or
two-liners, which means we mostly call other methods or helper words dealing
with the same object. With an explicit this, it means your code is full of
"this" even when you hide it for instance variables.

> Consuming a register seems a very large price to pay, if that is
> required, and not likely to exist for very many Forths.

You can use a user variable if your architecture is register starved (i.e.
x86). Many OOP systems have some sort of current object pointer, and if you
have enough registers, putting that into a register improves performance
significantly (depends on the code generator, of course).

> But I gather
> it's not required. So maybe we should ignore that aspect for now.
>
> The >o and o> manipulations for the object stack is obviously more
> effort for the programmer, so an explanation of the usage (when and why
> use >o and o>) and the payback for the programmer would seem beneficial.

When: When you switch the object used. Compared to actually *use* the
object (as base pointer for instance variables or to call methods with it),
this is the rare case. You should tune your tools for the common case, not
for the rare case.

Why: To tell the system that you switched the object used.

When I talk about OOP programming, I often see that the Sapir-Worph
hypothesis isn't that wrong. People use their own idiom, and it forms their
code ("thinking"). When you suggest other idioms, you receive blank stares.
People can't imagine the benefit of something they don't know, so any
attempt at explaining it results in more blank stares. Something we
Forthers are confronted with quite often ;-).

So please try it, and check if it benefits your code, or if your coding
style changes. I've tried both (as Mini-OOF was without current object),
and my personal result was that OOP without current object is too cumbersome
to use. Many OOP systems have a compromise, as I said, using the current
object pointer for instance variables, but not for method invocation. This
results in inconsistent code, which needs more explanation than consistent
code.

BerndOOF makes the >o o> manipulations implicit in many cases, but all this
implicit magic might be overkill.

[Roelf Toxopeus]

In article <14b8bf52-d9bc-4501...@googlegroups.com>,

m...@iae.nl wrote:

> On Friday, April 26, 2013 5:16:26 PM UTC+2, Roelf Toxopeus wrote:
> > In article <517a787b$0$32117$1472...@news.sunsite.dk>,
> [..]
> > Like, it's written in Forth.
> > The source code is there.
> > Adjust, extend to your heart's content...
> >
> > Sorely missed.
>
> Can the source be ported to other Forths?

It's not open source. It's what you get when you have MacForth or
MFonVFX. The idea is portable of course and remembering how it's done
helps ;-) But I think that would be quite a task

> Does it need kernel support? What kind of?

It's using OSX Carbon for GUI items and event handling. So you'll need
the equivalents, if available, on other OS's.
(IMHO a Cocoa version on OSX should be investigated ...)

Ward wrote a version for VFX in which the turnkeyed editor is a
front-end for plain VFX. Pipes used for communication.
Worth a try with SF and iForth.
One Forth as an IDE front-end for another Forth, why not?

There is a stand-alone version of coco-sf which has it's own editable
I/O window (no Terminal shell window needed). It primitively does what
Doug described. It's like the Mops front-end. You can save and reload
your sessions as in a worksheet. This can be ported to coco-i4 and
coco-vfx easily. But it really needs much more to come even close to the
Sibley Editor as the MF editor is also known.

-roelf

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:

> Doug Hoffman wrote:
>> The >o and o> manipulations for the object stack is obviously more
>> effort for the programmer, so an explanation of the usage (when and why
>> use >o and o>) and the payback for the programmer would seem beneficial.
>
> When: When you switch the object used. Compared to actually *use*
> the object (as base pointer for instance variables or to call
> methods with it), this is the rare case. You should tune your tools
> for the common case, not for the rare case.
>
> Why: To tell the system that you switched the object used.

I don't quite get this. When you call a PRINT method on an object
called THING, you presumably say something like THING PRINT . You
don't have to say THING >O PRINT . So is this just for instance
variables? But that can't be right either, because you'd have to
treat instance variables differently from calling methods on SELF .
If so, replacing an instance variable with a method or vice versa
would require the callers to be changed. Or is SELF also elided if
you happen to call methods on SELF , as well as instance variables?
But that can't be right either because methods would have different
stack effects depending on where they were called from.

Andrew.

[Mark Wills]

It will likely make the source code a lot easier to read. In java
source code can get very wordy with doors all over the place. ..80
character long object paths etc. The current object pointer removes
all that and all the typing.

VB and C# has the WITH operator which does the same thing:

With human.female.sally
Eyecolor=eyes.Green
Haircolor=colors.brown
Race=races.caucasian
End with

Much clearer and saves a lot of typing.

[Albert van der Horst]

In article <156dc9c4-ae6d-4c2e...@16g2000vbx.googlegroups.com>,

Mark Wills <markrob...@yahoo.co.uk> wrote:
>On Apr 26, 8:56�pm, Doug Hoffman <glide...@gmail.com> wrote:
>> On 4/26/13 3:34 PM, Bernd Paysan wrote:

<SNIP>

>>
>> The >o and o> manipulations for the object stack is obviously more
>> effort for the programmer, so an explanation of the usage (when and why
>> use >o and o>) and the payback for the programmer would seem beneficial.
>>
>> -Doug
>
>It will likely make the source code a lot easier to read. In java
>source code can get very wordy with doors all over the place. ..80
>character long object paths etc. The current object pointer removes
>all that and all the typing.
>
>VB and C# has the WITH operator which does the same thing:

As if Microsoft invented that. It is just Pascal.

>
>With human.female.sally
> Eyecolor=eyes.Green
> Haircolor=colors.brown
> Race=races.caucasian
>End with
>
>Much clearer and saves a lot of typing.

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

[Mark Wills]

On Apr 27, 10:09 am, alb...@spenarnc.xs4all.nl (Albert van der Horst)
wrote:
> In article <156dc9c4-ae6d-4c2e-ba07-8df24a48c...@16g2000vbx.googlegroups.com>,

Thanks for pointing that out.

[Andrew Haley]

Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> In article <156dc9c4-ae6d-4c2e...@16g2000vbx.googlegroups.com>,
> Mark Wills <markrob...@yahoo.co.uk> wrote:
>>
>>VB and C# has the WITH operator which does the same thing:
>
> As if Microsoft invented that. It is just Pascal.

Or perhaps originally Tony Hoare: it's described in "Notes On Data
Structuring". The WITH statement insn't in Algol W or in Simula. I
don't know if it was Wirth's or Hoare's idea.

Andrew.

[Doug Hoffman]

On 4/27/13 3:42 AM, Mark Wills wrote:
> On Apr 26, 8:56 pm, Doug Hoffman <glide...@gmail.com> wrote:

...

>> The >o and o> manipulations for the object stack is obviously more
>> effort for the programmer, so an explanation of the usage (when and why
>> use >o and o>) and the payback for the programmer would seem beneficial.

...

> VB and C# has the WITH operator which does the same thing:

I don't know either VB or C# and don't want to take the time to learn.
An example using BerndOOF and >o o> would be preferred.

Is "With" the same as >o ?
Is "End with" the same as o> ?

> With human.female.sally
> Eyecolor=eyes.Green
> Haircolor=colors.brown
> Race=races.caucasian
> End with

What is this, part of a class definition or just code outside of a class
definition?

What are human female and sally? classes? objects? instance-variables?
other?

What are Eyecolor Haircolor and Race? instance-variables? messages? other?

Same questions for eyes Green etc.

-Doug

[Andrew Haley]

Doug Hoffman <glid...@gmail.com> wrote:
>> With human.female.sally
>> Eyecolor=eyes.Green
>> Haircolor=colors.brown
>> Race=races.caucasian
>> End with
>
> What is this, part of a class definition or just code outside of a class
> definition?

It's just code. Could be either.

> What are human female and sally? classes? objects? instance-variables?
> other?
>
> What are Eyecolor Haircolor and Race? instance-variables? messages? other?
>
> Same questions for eyes Green etc.

This is all Pascal-style data structuring. human is a variable of
RECORD type, i.e. a struct. female is a field of the variable human .
It is also of record type. sally is a field of the field human.female .

Eyecolor is a field of the field human.female.sally . Etc...

Andrew.

[Bernd Paysan]

Andrew Haley wrote:
> I don't quite get this. When you call a PRINT method on an object
> called THING, you presumably say something like THING PRINT . You
> don't have to say THING >O PRINT . So is this just for instance
> variables? But that can't be right either, because you'd have to
> treat instance variables differently from calling methods on SELF .

Why? Treating two closely related things differently for no good reason is
a bad design decision.

> If so, replacing an instance variable with a method or vice versa
> would require the callers to be changed. Or is SELF also elided if
> you happen to call methods on SELF , as well as instance variables?
> But that can't be right either because methods would have different
> stack effects depending on where they were called from.

Ok, just look at what the common case is: The common case is SELF something,
either instance variable or method, because you factor a lot in Forth. The
uncommon case is THING PRINT (yes, it's the uncommon case, though in typical
badly factored languages like Java, it might be more common). In BerndOOF,
the THING PRINT is solved by having THING do the >O and O> before and after
PRINT (parsing word). The downside for this is that THING is no longer a
simple address, but a complex, state-smart parsing word. Mini-OOF (the
first one) has the current object on the top of stack, so THING PRINT works
straight-forward, but since you have to juggle the current object for
everything you do, it was way too cumbersome to use. The common case
*isn't* THING PRINT. If it was, Mini-OOF would be perfect.

A real-world example: Last week, I've written a Matroska parser. Matroska
is a "binary XML" format, so the Forth way of doing this is to make each tag
a word which, when executed, does the parsing of that particular field (or
calls the recursive parser if the field contains other fields). A generic
Matroska parser certainly shouldn't have hardcoded parsers for each fields;
that's what an OOP system is for. So I created a Mini-OOF2 class (with
current object) that contains a method for each tag, and there's a Gforth
TABLE (a wordlist where the words don't have to be printable) which maps
tags to methods. The parser then just goes through each tag, fetches the
length, calls the method, and continues with the next field.

Since Mini-OOF2 has a current object, this is all simple straight-forward
Forth code without juggling an object through all these nested recursive
parsers of the Matroska structure. The object is set on the top-level of
the parsing, that's it. There are a few derived classes, one is generating
MPEG Transport Stream out of Matroska, another one is displaying a human
readable dump of the Matroska file.

[Bernd Paysan]

Whoever had this idea, it was brilliant. If you don't like >o and o>,
rename it to with .. endwith.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Andrew Haley wrote:
>> I don't quite get this. When you call a PRINT method on an object
>> called THING, you presumably say something like THING PRINT . You
>> don't have to say THING >O PRINT . So is this just for instance
>> variables? But that can't be right either, because you'd have to
>> treat instance variables differently from calling methods on SELF .
>
> Why?

I'm asking a question. Is this just for instance variables, or not?

> Treating two closely related things differently for no good reason
> is a bad design decision.
>
>> If so, replacing an instance variable with a method or vice versa
>> would require the callers to be changed. Or is SELF also elided if
>> you happen to call methods on SELF , as well as instance variables?
>> But that can't be right either because methods would have different
>> stack effects depending on where they were called from.
>
> Ok, just look at what the common case is: The common case is SELF
> something, either instance variable or method, because you factor a
> lot in Forth.

SELF something is very common, that's true.

> The uncommon case is THING PRINT (yes, it's the uncommon case,
> though in typical badly factored languages like Java, it might be
> more common). In BerndOOF, the THING PRINT is solved by having
> THING do the >O and O> before and after PRINT (parsing word).

Oh dear, no.

> The downside for this is that THING is no longer a simple address,
> but a complex, state-smart parsing word.

Eh? I might as well have said @ PRINT or DUP PRINT . If you can't do
this:

: z dup . print ;
thing z

them you really do have a problem.

> Mini-OOF (the first one) has the current object on the top of stack,
> so THING PRINT works straight-forward, but since you have to juggle
> the current object for everything you do, it was way too cumbersome
> to use.

Why do you have to juggle it? Surely SELF is just the first local.
Same as almost every other OO language in existence.

> The common case *isn't* THING PRINT. If it was, Mini-OOF
> would be perfect.
>
> A real-world example: Last week, I've written a Matroska parser.
> Matroska is a "binary XML" format, so the Forth way of doing this is
> to make each tag a word which, when executed, does the parsing of
> that particular field (or calls the recursive parser if the field
> contains other fields). A generic Matroska parser certainly
> shouldn't have hardcoded parsers for each fields; that's what an OOP
> system is for. So I created a Mini-OOF2 class (with current object)
> that contains a method for each tag, and there's a Gforth TABLE (a
> wordlist where the words don't have to be printable) which maps tags
> to methods. The parser then just goes through each tag, fetches the
> length, calls the method, and continues with the next field.
>
> Since Mini-OOF2 has a current object, this is all simple
> straight-forward Forth code without juggling an object through all
> these nested recursive parsers of the Matroska structure. The
> object is set on the top-level of the parsing, that's it. There are
> a few derived classes, one is generating MPEG Transport Stream out
> of Matroska, another one is displaying a human readable dump of the
> Matroska file.

Sure, having a current object is a reasonable enough technique for
such things, and it's used a lot in OO.

Andrew.

[Doug Hoffman]

On 4/26/13 6:48 PM, Bernd Paysan wrote:

> When you do OOP programming, you usually refer to instance variables.

> :noname ( params ... this -- return ) { this }
> this x @ this y @ ... this bla ;
>
> your code is cluttered with "this". Many OOP packages therefore "hide" the
> local this, to make instance variable access use a local variable, but you
> still need this to call other methods.

Since instance variable names are only used inside class definitions
having to prefix each instance variable name with this or anything else
looks unnecessary and cumbersome. I would never want to have to do
that. I prefer to only use instance variable names inside class
definitions for the encapsulation reasons that Andrew already discussed
which makes prefixing unnecessary.

> BerndOOF makes the >o o> manipulations implicit in many cases, but all this
> implicit magic might be overkill.

If you are wanting to eliminate the evil of too many uses of this are we
not replacing it with another evil of having to use >o and o> ( and o@
?) and remembering when to use them?

I am struggling to grasp the advantage of manually switching the current
object via >o o> or any other means. I've stared at (and run) your
oofsampl.fs file but nothing there looks like an advantage for me. Maybe
I'm overlooking something.

When sending messages the receivers of the messages can change often and
can come from many different places in the same definition: the code
itself, the stack, a local, a global, the "super" or "this" pseudo
instance variables, etc. "Least surprise" in knowing where a message is
being sent has value for me, even if more explicit "this"s are used.

-Doug

[Doug Hoffman]

On 4/28/13 4:31 AM, Andrew Haley wrote:

> If you can't do this:
>
> : z dup . print ;
> thing z
>
> them you really do have a problem.

Agreed. Object use and message use must integrate seamlessly with
normal colon definitions, outside of class definitions, as Andrew
illustrates above.

-Doug

[Doug Hoffman]

On 4/27/13 3:42 AM, Mark Wills wrote:

> VB and C# has the WITH operator which does the same thing:
>
> With human.female.sally
> Eyecolor=eyes.Green
> Haircolor=colors.brown
> Race=races.caucasian
> End with

In the context of OOP the above breaks encapsulation. Andrew has
already discussed the importance of encapsulation to object programming,
in particular regarding instance variable names and structure.

So if sally is an object, we should instead do something like the following:

: set-traits { obj -- }
Green obj :eyecolor
brown obj :haircolor
caucasian obj :race ;

sally set-traits

Where :race :haircolor and :eyecolor are messages. The fact that sally
is an object of type female which in turn is a subclass of type human is
all handled implicitly by the object system. If we later change the
internal data structure of humans, for example change 'eyes' to
'vision-system', then we don't break code like set-traits.

-Doug

[Albert van der Horst]

In article <517d0183$0$32109$1472...@news.sunsite.dk>,

Doug Hoffman <glid...@gmail.com> wrote:
>On 4/27/13 3:42 AM, Mark Wills wrote:
>
>> VB and C# has the WITH operator which does the same thing:
>>
>> With human.female.sally
>> Eyecolor=eyes.Green
>> Haircolor=colors.brown
>> Race=races.caucasian
>> End with
>
>In the context of OOP the above breaks encapsulation. Andrew has
>already discussed the importance of encapsulation to object programming,
>in particular regarding instance variable names and structure.

I was confused, until I realized that it may be random comment on the
above code, nothing specific about "with". Is that right?

>
>So if sally is an object, we should instead do something like the following:
>
>: set-traits { obj -- }
> Green obj :eyecolor
> brown obj :haircolor
> caucasian obj :race ;
>
>sally set-traits
>
>Where :race :haircolor and :eyecolor are messages. The fact that sally
>is an object of type female which in turn is a subclass of type human is
>all handled implicitly by the object system. If we later change the
>internal data structure of humans, for example change 'eyes' to
>'vision-system', then we don't break code like set-traits.

In view of Forth if you use my simple oo it becomes abundantly clear.

Eyecolor is merely a message that returns a reference to a color.

This makes your point moot. If you can call Eyecolor that means the object
exports a reference to a color. If it does it means that it grants
you the right to change it. If you don't want to grant the right and
you do grant it, your program is wrong. This is not a language issue.


>
>-Doug

[Doug Hoffman]

On 4/28/13 9:09 AM, Albert van der Horst wrote:
> In article <517d0183$0$32109$1472...@news.sunsite.dk>,
> Doug Hoffman <glid...@gmail.com> wrote:
>> On 4/27/13 3:42 AM, Mark Wills wrote:
>>
>>> VB and C# has the WITH operator which does the same thing:
>>>
>>> With human.female.sally
>>> Eyecolor=eyes.Green
>>> Haircolor=colors.brown
>>> Race=races.caucasian
>>> End with
>>
>> In the context of OOP the above breaks encapsulation. Andrew has
>> already discussed the importance of encapsulation to object programming,
>> in particular regarding instance variable names and structure.
>
> I was confused, until I realized that it may be random comment on the
> above code, nothing specific about "with". Is that right?

Not exactly. My comment includes the fact that "with" and "End with" (
or >o and o> ) are not needed.

>> So if sally is an object, we should instead do something like the following:
>>
>> : set-traits { obj -- }
>> Green obj :eyecolor
>> brown obj :haircolor
>> caucasian obj :race ;
>>
>> sally set-traits
>>
>> Where :race :haircolor and :eyecolor are messages. The fact that sally
>> is an object of type female which in turn is a subclass of type human is
>> all handled implicitly by the object system. If we later change the
>> internal data structure of humans, for example change 'eyes' to
>> 'vision-system', then we don't break code like set-traits.
>
> In view of Forth if you use my simple oo it becomes abundantly clear.
>
> Eyecolor is merely a message that returns a reference to a color.
>
> This makes your point moot.

I don't see how.

>>> With human.female.sally
>>> Eyecolor=eyes.Green
>>> Haircolor=colors.brown
>>> Race=races.caucasian
>>> End with

The above requires With human female eyes End with. If Eyecolor were a
message that does what you say, and it certainly could be, then all we
need is:

sally Eyecolor

and the color reference is left on the stack. We can change eyes to
vision-system and your message still works and my point is still not moot.

-Doug

[Bernd Paysan]

Doug Hoffman wrote:

> On 4/26/13 6:48 PM, Bernd Paysan wrote:
>
>> When you do OOP programming, you usually refer to instance variables.
>
>> :noname ( params ... this -- return ) { this }
>> this x @ this y @ ... this bla ;
>>
>> your code is cluttered with "this". Many OOP packages therefore "hide"
>> the local this, to make instance variable access use a local variable,
>> but you still need this to call other methods.
>
> Since instance variable names are only used inside class definitions
> having to prefix each instance variable name with this or anything else
> looks unnecessary and cumbersome. I would never want to have to do
> that. I prefer to only use instance variable names inside class
> definitions for the encapsulation reasons that Andrew already discussed
> which makes prefixing unnecessary.

Yes, because you use some sort of "current object".

>> BerndOOF makes the >o o> manipulations implicit in many cases, but all
>> this implicit magic might be overkill.
>
> If you are wanting to eliminate the evil of too many uses of this are we
> not replacing it with another evil of having to use >o and o> ( and o@
> ?) and remembering when to use them?

When you want to do something with an object, use >o and o>. This doesn't
sound too difficult to remember...

> I am struggling to grasp the advantage of manually switching the current
> object via >o o> or any other means. I've stared at (and run) your
> oofsampl.fs file but nothing there looks like an advantage for me. Maybe
> I'm overlooking something.

The only way to see advantages and disadvantages is to try solve your own
problems. I've never seen much advantages from just reading small examples.
Simple examples like oofsampl.fs are usually simple in all kinds of OOP
systems.

> When sending messages the receivers of the messages can change often and
> can come from many different places in the same definition: the code
> itself, the stack, a local, a global, the "super" or "this" pseudo
> instance variables, etc. "Least surprise" in knowing where a message is
> being sent has value for me, even if more explicit "this"s are used.

Not quite sure what you mean. In Forth, we are used to many "implicit"
things, as we have unnamed parameters on the stack and things like that.
The question is: do you factor your OOP code so that methods from a class
frequently call other methods of the same class? I do. This is the Forth
way of programming, and therefore the THIS is the most likely target of an
object. As there already is an implicit THIS pointer for instance variables
(which should only be accessed from within the class, i.e. encapsulation),
there is no point *not* using this for method invocations, either.

If you talk to another object, you change context, and >o o> (or with ..
endwith if you like that names better) make it visible.

For me, an object is a sort of "context". You have instance variables and
methods that work in the context of the object. It is also very common that
when you interact with a particular object, you'll be sending more than one
message to it. You don't say "thing print", you more likely say "thing
initialize thing populate thing manipulate thing print". Or

thing >o initialize populated manipulate print o>

Maybe with some parameters on the stack for the stuff you do.

The term is multi-messaging, and it is fairly convenient if a language has
that thing.

[Roelf Toxopeus]

In article <klj8v4$4vq$1...@online.de>, Bernd Paysan <bernd....@gmx.de>
wrote:

> For me, an object is a sort of "context". You have instance variables and
> methods that work in the context of the object. It is also very common that
> when you interact with a particular object, you'll be sending more than one
> message to it. You don't say "thing print", you more likely say "thing
> initialize thing populate thing manipulate thing print". Or
>
> thing >o initialize populated manipulate print o>

Bernd, I recall a syntax doing what you suggest in a FD article begin
1990's., only one step further. The author used a single word to set the
OO context:

thing initialize populated manipulate print

Like we use vocabularies and wordlist in Forth. The author was
critisized for this syntax, couldn't grasp why.
I thought it was very neat and Forth like, using things in context.
Never saw the like again until your >o o>.
(for my Obj-C interface I keep the object on the stack as long as it's
needed, like with variables.)

-r

[Alex McDonald]

Better;

: set-traits
Green :eyecolor
brown :haircolor
caucasian :race ;

sally set-traits

[Alex McDonald]

Ignore that. I hit send instead of discard.

[Bernd Paysan]

Roelf Toxopeus wrote:
> Bernd, I recall a syntax doing what you suggest in a FD article begin
> 1990's., only one step further. The author used a single word to set the
> OO context:
>
> thing initialize populated manipulate print

I suppose the problem here was "where does it end" and "how do you get back
to the previous context". For vocabularies we have also/previous. Maybe
the critics wasn't on the syntax, but on the implementation.

> Like we use vocabularies and wordlist in Forth. The author was
> critisized for this syntax, couldn't grasp why.
> I thought it was very neat and Forth like, using things in context.
> Never saw the like again until your >o o>.

This >o o> thing is now nearly 23 years old, most of BerndOOF was written on
september 6+7 in 1991 (there were two previous throw-away versions written
on the two days before, but they were thrown away ;-).

> (for my Obj-C interface I keep the object on the stack as long as it's
> needed, like with variables.)

For my Java Native Interface, I just use the current object pointer. As if
it was a Forth object. Works perfect.

[Roelf Toxopeus]

In article <klkfbi$v9n$1...@online.de>, Bernd Paysan <bernd....@gmx.de>
wrote:

> Roelf Toxopeus wrote:
> > Bernd, I recall a syntax doing what you suggest in a FD article begin
> > 1990's., only one step further. The author used a single word to set the
> > OO context:
> >
> > thing initialize populated manipulate print
>
> I suppose the problem here was "where does it end" and "how do you get back
> to the previous context". For vocabularies we have also/previous. Maybe
> the critics wasn't on the syntax, but on the implementation.

Sure, but perhaps there was no end: 'You better make sure you set the
right context". Not unreasonable IMHO. At least you know why you
crashed, which is an end in itself ;-)
(allow for my memory playing tricks regarding the syntax.)

>
> > Like we use vocabularies and wordlist in Forth. The author was
> > critisized for this syntax, couldn't grasp why.
> > I thought it was very neat and Forth like, using things in context.
> > Never saw the like again until your >o o>.
>
> This >o o> thing is now nearly 23 years old, most of BerndOOF was written on
> september 6+7 in 1991 (there were two previous throw-away versions written
> on the two days before, but they were thrown away ;-).

I plead ignorance.
Many OOF's were written in those days, overwhelmed lost count and track
:-)
(and no internet or bbs for me)

>
> > (for my Obj-C interface I keep the object on the stack as long as it's
> > needed, like with variables.)
>
> For my Java Native Interface, I just use the current object pointer. As if
> it was a Forth object. Works perfect.

Talking about interface:
did you ever wrote and interface to openCL?

-roelf

[Doug Hoffman]

On 4/28/13 9:41 AM, Bernd Paysan wrote:

> It is also very common that
> when you interact with a particular object, you'll be sending more than one
> message to it. You don't say "thing print", you more likely say "thing
> initialize thing populate thing manipulate thing print". Or
>
> thing >o initialize populated manipulate print o>

You replaced 8 tokens with 7. Doesn't seem like a big deal.

OK, I believe I better understand why you use >o and o>. It's
apparently a syntax preference thing. Thanks for the explanation.

-Doug

[Bernd Paysan]

Doug Hoffman wrote:

> On 4/28/13 9:41 AM, Bernd Paysan wrote:
>
>> It is also very common that
>> when you interact with a particular object, you'll be sending more than
>> one
>> message to it. You don't say "thing print", you more likely say "thing
>> initialize thing populate thing manipulate thing print". Or
>>
>> thing >o initialize populated manipulate print o>
>
> You replaced 8 tokens with 7. Doesn't seem like a big deal.

Some tokens have a "lighter" brain representation. Like groupers. >o o>
are groupers. They help you to understand the structure of the things you
do.

And you can cut&paste factor, e.g.

: input initialize populate manipulate ;

thing >o input print o>

Without any stack juggling to get this done (there is quite likely enough
stack juggling for populate and manipulate).

> OK, I believe I better understand why you use >o and o>. It's
> apparently a syntax preference thing. Thanks for the explanation.

This is still a trivial example where there are no other stack effects apart
from the object itself. That's not the normal case.

In any case, this is semantics. The syntax of all these things is just
space-separated words.

[Bernd Paysan]

Roelf Toxopeus wrote:
> Talking about interface:
> did you ever wrote and interface to openCL?

No, not yet.

[Bernd Paysan]

Bernd Paysan wrote:

> Doug Hoffman wrote:
>>> thing >o initialize populated manipulate print o>
>>
>> You replaced 8 tokens with 7. Doesn't seem like a big deal.
>
> Some tokens have a "lighter" brain representation. Like groupers. >o o>
> are groupers. They help you to understand the structure of the things you
> do.

Maybe a real world example helps more. Consider an object that represents
an array of two-dimensional things ("size"). I'm currently having Java
return such things to me for the camera preview size. So I do

: .sizes ( list<size> -- )
>o l-size 0 ?DO i l-get >o width . height . cr o> LOOP o> ;

This is a one-liner with a loop, dealing with two object contexts - one is
the list, the other is the size element inside the list.

[Doug Hoffman]

On 4/29/13 4:01 PM, Bernd Paysan wrote:
> Bernd Paysan wrote:
>
>> Doug Hoffman wrote:
>>>> thing >o initialize populated manipulate print o>
>>>
>>> You replaced 8 tokens with 7. Doesn't seem like a big deal.
>>
>> Some tokens have a "lighter" brain representation. Like groupers. >o o>
>> are groupers. They help you to understand the structure of the things you
>> do.
>
> Maybe a real world example helps more. Consider an object that represents
> an array of two-dimensional things ("size"). I'm currently having Java
> return such things to me for the camera preview size. So I do
>
> : .sizes ( list<size> -- )
> >o l-size 0 ?DO i l-get >o width . height . cr o> LOOP o> ;
>
> This is a one-liner with a loop, dealing with two object contexts - one is
> the list, the other is the size element inside the list.

: .sizes { list -- }
list :size 0 ?DO i list :get dup :width . :height . cr LOOP ;


Be sure to match all of your >os and o>s. I had trouble following them
in oofsampl.fs, especially combined with a couple of selfs:

method of class linked

: . self >o [char] (
BEGIN emit ? next atom? next self o> >o
IF ." . " data . o> ." )" EXIT THEN bl
empty? UNTIL o> drop ." )" ;

Glad that it all works for you. I'll stick with explicit objects.

-Doug

[Bernd Paysan]

Doug Hoffman wrote:
> Be sure to match all of your >os and o>s.

Yes, like >r and r>. And they fail the same way (hard). Crash-early is not
really a problem in Forth.

> I had trouble following them
> in oofsampl.fs, especially combined with a couple of selfs:

[...]

> Glad that it all works for you. I'll stick with explicit objects.

Your example shows that you need locals for that. Let's do it without
locals:

: .sizes ( list -- )
dup :size 0 ?DO i over :get dup :width . :height . cr LOOP drop ;

This is exactly the sort of stack-noisy code that is difficult to read and
maintain. However, I now understand why you need the : marker for methods:
It helps you to remember that they take an object as parameter. I don't
need that, because my methods don't take an object as parameter. They just
take whatever normal Forth word would take. Which means the mental model is
smaller.

And for advanced hacking, the thing I need this for is to find the preview
with the maximum area:

: max-area ( w h o:size -- w' h' )
2dup m* width height m* d< IF 2drop width height THEN ;

: max-preview ( o:list -- w h )
0 0 list-size 0 ?DO I list-get >o max-area o> LOOP ;

For your approach, you need at least one local per object used.

I really prefer current objects. Explicit feels so Java-like, it makes
concatenative factoring difficult. If I would like Java more than Forth, I
wouldn't program in Forth. Refactoring in Java is supported by something
like 10 million lines of Eclipse code ;-).

Well, the code above *is* calling Java... I'm quite happy that it is
possible to seamlessly integrate Java and Forth OOP, except that you can't
inherit from Java classes.

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Doug Hoffman wrote:
>> Be sure to match all of your >os and o>s.
>
> Yes, like >r and r>. And they fail the same way (hard). Crash-early is not
> really a problem in Forth.
>
>> I had trouble following them
>> in oofsampl.fs, especially combined with a couple of selfs:
> [...]
>> Glad that it all works for you. I'll stick with explicit objects.
>
> Your example shows that you need locals for that. Let's do it without
> locals:

Whatever for? Ideological purity?

> : .sizes ( list -- )
> dup :size 0 ?DO i over :get dup :width . :height . cr LOOP drop ;
>
> This is exactly the sort of stack-noisy code that is difficult to
> read and maintain. However, I now understand why you need the :
> marker for methods: It helps you to remember that they take an
> object as parameter. I don't need that, because my methods don't
> take an object as parameter. They just take whatever normal Forth
> word would take.

This makes no sense at all. Of course methods take an object as a
parameter, otherwise they wouldn't know what the current object was.
The only question is *how* the object is to be passed, whether on the
data stack or on an auxiliary stack.

> And for advanced hacking, the thing I need this for is to find the preview
> with the maximum area:
>
> : max-area ( w h o:size -- w' h' )
> 2dup m* width height m* d< IF 2drop width height THEN ;
>
> : max-preview ( o:list -- w h )
> 0 0 list-size 0 ?DO I list-get >o max-area o> LOOP ;

As opposed to...

: area { self -- n } self width self height m* ;

: max-area ( w h o -- w' h' ) { self }
2dup m* self area d< IF 2drop self width self height THEN ;

: max-preview ( o:list -- w h )

0 0 list-size 0 ?DO I list-get max-area LOOP ;

> For your approach, you need at least one local per object used.
>
> I really prefer current objects. Explicit feels so Java-like

How so? Java has the current object concept for both instance
variables and methods. Explicit is more Python.

Andrew.

[Doug Hoffman]

On 4/29/13 5:57 PM, Bernd Paysan wrote:
> Doug Hoffman wrote:
>> Be sure to match all of your >os and o>s.
>
> Yes, like >r and r>. And they fail the same way (hard). Crash-early is not
> really a problem in Forth.

If I'm crashing a lot I worry about my coding style.

>> I had trouble following them
>> in oofsampl.fs, especially combined with a couple of selfs:
> [...]
>> Glad that it all works for you. I'll stick with explicit objects.
>
> Your example shows that you need locals for that. Let's do it without
> locals:
>
> : .sizes ( list -- )
> dup :size 0 ?DO i over :get dup :width . :height . cr LOOP drop ;

Using the normal Forth stack is being explicit, for me.
You coded that exactly as I did and almost posted for locals-haters
(which I am not). You may consider it stack noisy, I don't. Anyone
competent in Forth should have no problem using it. 15 tokens, same as:

: .sizes ( list<size> -- )

>o l-size 0 ?DO i l-get >o width . height . cr o> LOOP o> ;


One should use the technique that works best for them.

-Doug

[Doug Hoffman]

On 4/29/13 5:57 PM, Bernd Paysan wrote:

Not to get too far off topic, but in reality I write lists that use an
each message for iterating through the list and would write the code
something like this:

:each ( list-obj -- list-elem flag )

: .sizes { list -- }
begin
list :each
while

dup :width .
:height .

repeat ;

> However, I now understand why you need the : marker for methods:
> It helps you to remember that they take an object as parameter. I don't
> need that, because my methods don't take an object as parameter. They just
> take whatever normal Forth word would take.

You defined . as a message in oofsampl.fs. How would I know if . is the
normal Forth . or the message . ? I don't need the : convention but I
sure like it.

-Doug

[Bernd Paysan]

Andrew Haley wrote:
>> For your approach, you need at least one local per object used.
>> I really prefer current objects. Explicit feels so Java-like
>
> How so? Java has the current object concept for both instance
> variables and methods. Explicit is more Python.

Hm, not sure. Java does not have a with statement, but inside a class, you
don't need self to call methods. The .net languages have a with statement,
probably a result of .net being led by a famous Pascal programmer.

Python's with statement is a bit confusing; I'm not sure if it can be used
as implicit current object. It usually only is used as try..catch block
structure.

[Bernd Paysan]

Doug Hoffman wrote:

> On 4/29/13 5:57 PM, Bernd Paysan wrote:
>
> Not to get too far off topic, but in reality I write lists that use an
> each message for iterating through the list and would write the code
> something like this:

This list is a Java list. For sure it has an iterator... but also a size
method.

> :each ( list-obj -- list-elem flag )
>
> : .sizes { list -- }
> begin
> list :each
> while
> dup :width .
> :height .
> repeat ;
>
>> However, I now understand why you need the : marker for methods:
>> It helps you to remember that they take an object as parameter. I don't
>> need that, because my methods don't take an object as parameter. They
>> just take whatever normal Forth word would take.
>
> You defined . as a message in oofsampl.fs. How would I know if . is the
> normal Forth . or the message . ?

Inside the class hierarchy where you defined . as message, it is the
message, outside it is the Forth word. This part is to illustrate how the
scoping works.

> I don't need the : convention but I
> sure like it.

It's a bit of hungarian notation. An Eclipse-like IDE could highlight this
for you in different colors.

[Steve]

Hi guys,

Just like to ask, are you guys seeing my threads, being using groups
but threads and posts are not showing up, like the group was dead?
The latest is "Misc expansion". Rick, Paul and Hugh are, but I just
switched form summary view to list and can see heaps more topics.

This is the sort of topic that is an interesting read.

[Ron Aaron]

On 04/29/2013 11:01 PM, Bernd Paysan wrote:

> Maybe a real world example helps more. Consider an object that represents
> an array of two-dimensional things ("size"). I'm currently having Java
> return such things to me for the camera preview size. So I do
>
> : .sizes ( list<size> -- )
> >o l-size 0 ?DO i l-get >o width . height . cr o> LOOP o> ;
>
> This is a one-liner with a loop, dealing with two object contexts - one is
> the list, the other is the size element inside the list.

That is a very interesting example; I'm looking at doing something
similar by embedding a Forth within a WebKit wrapper (to get
cross-platform UI w/ webby-stuff for "free").

[Andrew Haley]

Bernd Paysan <bernd....@gmx.de> wrote:
> Andrew Haley wrote:
>>> For your approach, you need at least one local per object used.
>>> I really prefer current objects. Explicit feels so Java-like
>>
>> How so? Java has the current object concept for both instance
>> variables and methods. Explicit is more Python.
>
> Hm, not sure. Java does not have a with statement, but inside a class, you
> don't need self to call methods.

Yes, that's what I mean. That is exactly the same as having a
"current object".

Andrew.