Another OOP thread; everything on the stack is an object

[Alex McDonald]

The "current object" thread and my investigations on a prototype based
object model for Forth has led me to think that it should be possible
to construct a stack based "everything is an object" language. Assume
a stack where each entry is an object (possibly implemented as some
form of closure pointer), and where every word (including numbers and
strings) are objects that respond to messages/methods. These are also
first class objects ala Javascript; the only distinction between an
object and a message is the stack effect.

For instance 1 DUP can be considered as sending the message DUP to
the object 1, leaving two objects 1 1 on the stack. 1 2 + sends the
message + to the object 2, which consumes the object 1 and leaves the
object 3 on the stack. Or "abcd" "1" + where the message + is sent
to the string object "1", producing the object "abcd1".

var x \ the object x
10 x ! \ send the store message to X
string y
"abcd" y !
y length x !
x . \ types 4

A sizable chunk of the resulting language is very Forth-like.
Thoughts?

[Bernd Paysan]

Sure this is possible, reminds me of Alex Burger's Teatime, a reverse polish
Lisp-like system, which instead of building on some few types as Lisp, did
build on an object oriented foundation (actually parts were written in
Java).

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

[hughag...@yahoo.com]

Alex McDonald has just invented Factor! And PostScript, Joy, and Cat as well!

None of this has anything to do with Forth.

[Ron Aaron]

On 05/16/2013 11:37 PM, Alex McDonald wrote:

> A sizable chunk of the resulting language is very Forth-like.
> Thoughts?
>

Yes: that is the direction I'm going with my next-generation Reva
(called "sheminit", or "8th").

It makes sense to me to "do the right thing" where possible, e.g "+"
should concatenate strings if the objects on the stack are strings, and
do addition if they are numbers. It becomes a bit less clear what to do
if the objects are mixed, and that is where excellent documentation (and
example code) will be most useful.

I'm also eliminating the distinction between normal integers, doubles
and floating point. One set of words for them all, and the 'number'
object will use the most precise but smallest representation it can.
The progression (for integer numbers) would be "32bit" -> "64bit" ->
"128bit" -> "bigint". So while the math would get slower, one wouldn't
have to be concerned with overflow and such things. If, for example,
attempting to calculate the US debt...

I'm not certain what representation to use for "real" numbers. Since I
expect to run on Intel and ARM as well (my target platforms are
Windows/Mac/Linux and Android/iOS, at first) and perhaps other, unknown
CPUs, I don't know if using the IEEE fp formats is supported across the
board, though it probably doesn't make a difference except when
transferring data from one to another (and that would potentially affect
integer data as well, so ...)

[Paul Rubin]

Ron Aaron <ramb...@gmail.com> writes:
> It makes sense to me to "do the right thing" where possible, e.g "+"
> should concatenate strings if the objects on the stack are strings,
> and do addition if they are numbers. It becomes a bit less clear what
> to do if the objects are mixed, and that is where excellent
> documentation (and example code) will be most useful.

You are re-inventing Lisp. You may as well look at the Lisp or Scheme
specifications for approaches to these issues.

[Ron Aaron]

On 05/17/2013 08:19 AM, Paul Rubin wrote:

> You are re-inventing Lisp. You may as well look at the Lisp or Scheme
> specifications for approaches to these issues.

Not especially. It's a Forth derivative, not a Lisp machine. For the
purpose I have in mind, having three different vocabularies to handle
math operations does not make sense. You might as well say JavaScript
is like Lisp...

[Paul Rubin]

Ron Aaron <ramb...@gmail.com> writes:
> having three different vocabularies to handle math operations does not
> make sense.

Yes, the Scheme and Lisp designers considered this pretty carefully and
gave a detailed spec of how they handle it. Of course you don't have to
do what they did, but in cases where you don't see a particular reason
to do otherwise, following an existing working example seems like an ok
strategy.

> You might as well say JavaScript is like Lisp...

But it is ;-).

[Ron Aaron]

On 05/17/2013 08:43 AM, Paul Rubin wrote:

> Of course you don't have to
> do what they did, but in cases where you don't see a particular reason
> to do otherwise, following an existing working example seems like an ok
> strategy.

Certainly. No need to reinvent something that works...

>> You might as well say JavaScript is like Lisp...
>
> But it is ;-).

Heh.

[Mark Wills]

It reminded me of Smalltalk.

[Mark Wills]

Sounds great. I'd be interested in using something like that.

[Alex McDonald]

Are there no mirrors where you live?

[Alex McDonald]

Do you have a reference? I'm not getting anything through google on
"teatime".

[Alex McDonald]

I am only at the thought experiment stage. I'm interested in how far
you might get without destroying the Forthiness of the resulting
language.

[Anton Ertl]

Ron Aaron <ramb...@gmail.com> writes:
>It makes sense to me to "do the right thing" where possible, e.g "+"
>should concatenate strings if the objects on the stack are strings

Really bad example, because this is the wrong thing. + is for adding
numbers. Addition has a number of algebraic properties that string
concatenation does not have; in particular, it forms a commutative
group. I.e., addition is commutative (which string concatenation
obviously is not), and every number has an inverse element
wrt. addition (the negated number). That's not the case for string
concatenation.

>I'm not certain what representation to use for "real" numbers. Since I
>expect to run on Intel and ARM as well (my target platforms are
>Windows/Mac/Linux and Android/iOS, at first) and perhaps other, unknown
>CPUs, I don't know if using the IEEE fp formats is supported across the
>board

It is. Other formats are going the way of 1s-complement. However, I
have come across at least one FPU-less ARM which had broken FP
support.

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

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Addition has a number of algebraic properties that string
> concatenation does not have; in particular, it forms a commutative
> group. I.e., addition is commutative (which string concatenation
> obviously is not), and every number has an inverse element
> wrt. addition (the negated number).

I tend to agree that + isn't the right operator for string
concatenation, but in arithmetic it doesn't especially connote the
existence of an inverse. I.e. it's used for unsigned arithmetic as well
as signed arithmetic, or (in math) on the natural numbers as well as on
the integers. In fact it doesn't even have to be a monoid, since the
naturals are sometimes taken as {1,2,3...} without any zero. I guess
commutativity is implied though.

[Ron Aaron]

On 05/17/2013 03:40 PM, Alex McDonald wrote:

> I am only at the thought experiment stage. I'm interested in how far
> you might get without destroying the Forthiness of the resulting
> language.

Depends of course on what you mean by 'Forthiness'. As long as the
usual stuff, e.g.

1 2 + .

does what one would expect, I'm not sure how un-Forthly the internal
mechanisms would make things appear.

In my case, I will be hooking my "8th" into a webkit browser as a
cross-platform UI, in lieu of (and in addition to) JavaScript. It's
important for the kinds of apps I want to write that a user be unable to
crash the system using the Forth interpreter. So for example, I will
bounds-check the stack. Is that un-Forthly? Well, it's un-fast-Forthly
anyway.

But for example, I will make "." print whatever object is on the top of
the stack. So

"hi there" .

will print the string "hi there". You'll have guessed I want to handle
string parsing a bit differently than standard Forths as well ...
actually, I was going to do that in Reva as well at some point but
didn't get around to it.

I think that choosing words carefully will make the learning curve for
new users much less steep, but the price is even less conformance with
other Forths. Well, that's not a huge price to pay in my book.

[Ron Aaron]

On 05/17/2013 03:50 PM, Anton Ertl wrote:
> Ron Aaron <ramb...@gmail.com> writes:
>> It makes sense to me to "do the right thing" where possible, e.g "+"
>> should concatenate strings if the objects on the stack are strings
>
> Really bad example, because this is the wrong thing. + is for adding
> numbers.

Yes it is. But it is *also* widely used as an idiom for concatenation
of strings, in many languages. I disagree it's a "wrong thing", unless
the problem domain is exclusively mathematical.

The real question is one of implementation. A smart "+" word would be
an abomination since when new types are added which one might wish to
"+" one would have to expand the definition of "+". I guess that can be
done, but it seems much cleaner to let a string know what "+" means for
it. So there would be a number.+, a string.+, etc.

>> I don't know if using the IEEE fp formats is supported across the
>> board
>
> It is. Other formats are going the way of 1s-complement. However, I
> have come across at least one FPU-less ARM which had broken FP
> support.

Ah, thank you; that's a good thing to know.

[Anton Ertl]

And, to reaffirm my point about +:

Welcome to Racket v5.1.3.
> (+ "a" "b")
+: expects type <number> as 1st argument, given: "a"; other arguments were: "b"

I rather thought about Postscript and Factor, but at least Postscript
also does the right thing:

GPL Ghostscript 9.05 (2012-02-08)
Copyright (C) 2010 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>(a) (b) add
Error: /typecheck in --add--

[Alberto]

Have you looked at RPL? It was the language of the HP 48
I think it implemented similar concepts

Alberto

[Bernd Paysan]

Alex McDonald wrote:

> On May 16, 11:09 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> Sure this is possible, reminds me of Alex Burger's Teatime, a reverse
>> polish Lisp-like system, which instead of building on some few types as
>> Lisp, did build on an object oriented foundation (actually parts were
>> written in Java).
>

> Do you have a reference? I'm not getting anything through google on
> "teatime".

Alex Burger presented this on a Forth-Tagung, and in the local Munich Forth
group; IIRC in about late nineties. Alex Burger currently works on
PicoLisp, and doesn't have any links to TeaTime on his own web server:

http://www.software-lab.de/

[Bernd Paysan]

Anton Ertl wrote:
> I rather thought about Postscript and Factor, but at least Postscript
> also does the right thing:

Factor also complains. The right word in Factor to add strings is called
"append".

If you are looking for popular languages overloading + to add strings,
here's the right place:

http://www.codecodex.com/wiki/Concatenate_two_strings

[visua...@rocketmail.com]

On Saturday, May 18, 2013 6:34:49 PM UTC-4, Bernd Paysan wrote:

> Factor also complains. The right word in Factor to add strings is called
> "append".

Win32Forth uses "append", too.
And concatenate looks like this:

\ string concatenation: $1 + $2 -> $1+$2 in pad \ from apps\Chess\TOOLSET.F

: $concat ( $1 n $2 n - pad n1+2 )
temp$ place \ Save old $2. It might be in pad.
pad place \ Put $1 in place.
temp$ count pad +place \ Add old $2.
pad count
;

> If you are looking for popular languages overloading + to add strings,
> here's the right place:
> http://www.codecodex.com/wiki/Concatenate_two_strings

There is a long list of programming languages from Ada, over Go and Smalltalk to Zsh - why isn't there Forth?

[Bernd Paysan]

visua...@rocketmail.com wrote:

> On Saturday, May 18, 2013 6:34:49 PM UTC-4, Bernd Paysan wrote:
>
>> Factor also complains. The right word in Factor to add strings is called
>> "append".
>
> Win32Forth uses "append", too.

place/append are pretty dated versions of Forth string handling, but yes,
that's probably how Factor got "append".

> And concatenate looks like this:
>
> \ string concatenation: $1 + $2 -> $1+$2 in pad \ from
> apps\Chess\TOOLSET.F
>
> : $concat ( $1 n $2 n - pad n1+2 )
> temp$ place \ Save old $2. It might be in pad.
> pad place \ Put $1 in place.
> temp$ count pad +place \ Add old $2.
> pad count
> ;
>
>> If you are looking for popular languages overloading + to add strings,
>> here's the right place:
>> http://www.codecodex.com/wiki/Concatenate_two_strings
>
> There is a long list of programming languages from Ada, over Go and
> Smalltalk to Zsh - why isn't there Forth?

It's a wiki. Don't complain, just add the Forth entry.

[Coos Haak]

Op Sat, 18 May 2013 15:55:37 -0700 (PDT) schreef
visua...@rocketmail.com:

Strings on the stack are pairs of 'c-addr u'
( c-addr1 u1 c-addr2 u2 -- c-addr3 u2 ) CONCAT

"Hello, " "World" CONCAT TYPE
Hello, World OK

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

[hughag...@yahoo.com]

On Friday, May 17, 2013 12:29:08 AM UTC-7, Mark Wills wrote:
> On Friday, May 17, 2013 6:04:34 AM UTC+1, Ron Aaron wrote:
> > Yes: that is the direction I'm going with my next-generation Reva
> > (called "sheminit", or "8th").
>

> Sounds great. I'd be interested in using something like that.

I don't like dynamic-OOP languages. If you are interested in using a dynamic-OOP language however, there are abundant choices available, many of which have large active communities and beaucoup libraries of code available. There is no need to start from scratch inventing yet-another one --- the subject of dynamic-OOP has really been done to death --- I can't imagine any new innovations coming out, especially from the comp.lang.forth crowd.

If you want one that is somewhat Forth-like, then go with Factor. Dynamic-OOP is inherently inefficient because it does the type-checking at run-time. Factor is one of the fastest around however, as it compiles into machine-code and has a sophisticated optimizer. I used Factor for a while, and it was pretty fast --- dynamic-OOP just isn't my cup of tea though, so I dropped Factor.

None of this has anything to do with Forth --- the only thing Forth is good for is programming micro-controllers, and you obviously aren't going to do dynamic-OOP on a micro-controller. For desktop-computer programming, as I said, there are myriad good choices already available, but Forth isn't one of them.

[Steve]

Good on you Alex. In my own solution many years back, I considered a
underlying virtual object machine. A stack value can be a value or
object pointer, depending on how you use it. totally transparent and
interpolated, as the virtual machine handles everything simply. But
then again these embedded objects were not the usual.

Keep rehashing it and see where you get. We really need a stripped
down "ForthToo" version of forth. There are enough rehashes of forth
around to draw upon.


Steve.

[Ian Osgood]

On Saturday, May 18, 2013 3:09:52 PM UTC-7, Bernd Paysan wrote:
>
> Alex Burger presented this on a Forth-Tagung, and in the local Munich Forth
>
> group; IIRC in about late nineties. Alex Burger currently works on
>
> PicoLisp, and doesn't have any links to TeaTime on his own web server:
>
>
>
> http://www.software-lab.de/
>
>
>
> --
>
> Bernd Paysan
>
> "If you want it done right, you have to do it yourself"
>
> http://bernd-paysan.de/

By the way, I would encourage folks here to check out PicoLisp. It is quite capable for such a minimal Lisp. You can tell that the author had a good appreciation of Forth from many of its practical design decisions.

Ian

[Paul Rubin]

Ian Osgood <ia...@quirkster.com> writes:
> By the way, I would encourage folks here to check out PicoLisp. It is
> quite capable for such a minimal Lisp. You can tell that the author
> had a good appreciation of Forth from many of its practical design
> decisions.

Picolisp is interesting. I wouldn't call it minimal, just "small", and
powerful for its size. I hadn't recognized Forth influence in it though
I guess it fits the picture. I would have liked it better if he had
stayed with traditional Lisp syntax in more places.

[Jason Damisch]

On Thursday, May 16, 2013 1:37:12 PM UTC-7, Alex McDonald wrote:

> The "current object" thread and my investigations on a prototype based
> object model for Forth has led me to think that it should be possible
> to construct a stack based "everything is an object" language. Assume

This brings to mind MUF.

http://en.wikipedia.org/wiki/MUF_%28programming_language%29

Which lets you put both numbers and strings on the same stack.

It was used for text based games.

Jason