On Sunday, March 13, 2022 at 8:32:24 PM UTC-5, dxforth wrote:
Where's the gain for breaking convention? Were I to implement ' foo FORGET >> it would necessitate a second vocab search using xt to find the nfa. It
I don't have that cost; my xt (pfa) to nfa doesn't require a search so tick is the
only search and is factored out.
On 15/03/2022 04:37, S Jack wrote:
On Sunday, March 13, 2022 at 8:32:24 PM UTC-5, dxforth wrote:
Where's the gain for breaking convention? Were I to implement ' foo FORGET >> it would necessitate a second vocab search using xt to find the nfa. It
I don't have that cost; my xt (pfa) to nfa doesn't require a search so tick is theYou've factored out the search for the target address. Perhaps it's all you need. For most of us FORGET still needs to search every vocab and thread
only search and is factored out.
in the dictionary and trim those at the appropriate point. And that's not counting the things that may need to be undone such as DEFERs pointing to words that no longer exist.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
so you can tell if it started as a 2VALUE etc.2VALUEs and FVALUEs are fundamentally incompatible with VALUEs,
CVALUEs, WVALUEs, LVALUEs: the latter produce a cell (and TO consumes
a cell for them), while 2VALUEs produce two cells, and FVALUEs produce
a float.
Yes, that is the idea of having a companion to ADDR that makes the type
and (maybe implicitly) size info available. So you can implement
something like TO in terms of ADDR and its companion.
On Friday, March 11, 2022 at 12:35:40 AM UTC-6, Marcel Hendrix wrote:
On Friday, March 11, 2022 at 2:25:06 AM UTC+1, S Jack wrote:
[..]
Actually, I would fully endorse such a move. But not for TO etc.,
where the prefix construct has clear advantages.
That the parsing word could do some optimization (if that's what you are >referring to as the clear advantage) did play somewhat in decision to not >change TO and IS . But that advantage didn't appear to be too significant
( I could easily be wrong there.)
On 3/10/22 8:58 AM, Anton Ertl wrote:
Doug Hoffman <dhoffman888@gmail.com> writes:
On 3/8/22 5:05 PM, Anton Ertl wrote:
But ... (... value-flavoured fields) have nothing to do with OOP;
they miss an essential feature of OOP: dynamic binding.
So they would be a simpler subset of an oop extension.
No.
The syntax is the same.
No.
My apologies, these statements apply to VALUEs and FVALUEs and LOCALs. I
had been reading N.Nelson's 2020 EuroForth paper "Extending the Value >Concept" where he talks first about VALUEs and then STRUCTs. So yes,
with value flavored STRUCTs we need an extra stack input item so the
syntax is not exactly the same (though very similar IMO).
Many Forths already do the following:
0 value v
1 to v
1 +to v
v . \ => 2
0e fvalue fv
1e to fv
1e +to fv
fv f. \ => 2.0000000
: test 0 locals| lv |
1 to lv 1 +to lv lv . ;
test \ => 2
So the above shows 3 different "types" of Forth "objects" that all
respond to the same (overloaded) messages, I mean operators.
The
underlying code may be a case statement or whatever. My point was that
this *syntax* is identical to <parameter> <message> <object>. I
understand fully that it is not exactly the same as oop. But the syntax
above is no different.
The oop discussions are dead.
We implement TO through a method for word headers. For
value-flavoured fields, this method knows how to compute the address
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
We implement TO through a method for word headers. For
value-flavoured fields, this method knows how to compute the address
Right, but what about wanting to use ADDR to pass the address to
something? It is theoretically desirable to have the result of ADDR
also be able to report the size and access methods.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
We implement TO through a method for word headers. For
value-flavoured fields, this method knows how to compute the address
Right, but what about wanting to use ADDR to pass the address to
something? It is theoretically desirable to have the result of ADDR
also be able to report the size and access methods. Maybe not in Forth though.
An advantage of not having the address is that the system could
de-fragment and perform other memory storage operations transparently
in the background.
But of course one might pursue this idea further, and design a "Forth"
system which does not give out general addresses, only typed addresses
which allow the system to determin exactly which cells are addresses
and which are other things; and this can then be used for precise
garbage collection.
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
But of course one might pursue this idea further, and design a "Forth" >system which does not give out general addresses, only typed addresses >which allow the system to determin exactly which cells are addressesOf course the question is if precise garbage collection is a goal
and which are other things; and this can then be used for precise
garbage collection.
worth the costs. And if so, what the right approach is. E.g., OCaml
is a language with a type system that makes it possible to track all addresses with compiler smarts and without general tagging of all
data; yet when I looked at the Ocaml implementation, it used a bit in
every cell to say whether that cell contained an address or not; this
saved complexity in the compiler.
In any case, I have thought some more about how a Forth system without general addresses (a Managed Forth) could look like: I am thinking
about a system with somewhat Java-like objects (rather than a system
like Lisp or Postscript with only a few built-in types). The Forth
system would have a separate objects stack that contains references to
these objects, as well as the usual data stack that contains integers (including characters), and of course the FP stack.
The objects are the usual ones with fields (aka object variables or
instance variables), but also arrays. You access a field with a value-flavoured access word, say LIST-NEXT (list -- obj). You access
an array with the value-flavoured [] (array u -- v). There is no
address arithmetic or somesuch. An array access is bounds-checked
(and somewhat type-checked), a field access checks that it accesses
the right kind of object. There is no address arithmetics. Whether
field names are private, public, or configurable is beyond the present discussion.
Discussion: We get from the low-level nature of Forth into what is
known as "managed languages", with all advantages (better security as
long as we don't call C libraries for performance reasons:-) and disadvantages (some performance techniques can no longer be used).
Related work: Oforth seems to have similar goals, but it does not use
a separate object stack, which means that it needs some compiler
smarts or more run-time provisions for differentiating between
addresses and non-addresses. Postscript also has only one typed
stack. By contrast, separating the object stack from the data stack
allows full performance for integer operations without compiler
smarts.
I doubt that I will find the time to pursue this idea further in the foreseeable future.
CATCH/THROW should include the object stack, and rewind it
including
freeing memory of discarded objects. While this would be no rocket science >for pure data objects, freeing classes or objects with pointers to other ob= >jects
could become rather complex.=20
Doug Hoffman <dhoffman888@gmail.com> writes:
The oop discussions are dead.
Well, I thought that we had reached consensus at least on passing
objects on the stack (aka "object method" syntax), but you seem to
want to ressurect this part of these discussions.
On 3/16/22 9:50 AM, Anton Ertl wrote:
Doug Hoffman <dhoff...@gmail.com> writes:
The oop discussions are dead.
Well, I thought that we had reached consensus at least on passingNo. I am too heavily invested now in object-method to want to change.
objects on the stack (aka "object method" syntax), but you seem to
want to ressurect this part of these discussions.
I was just commenting that method-object works fine also. The sudden resurrection of method-object via method-flavored fields (structs) is
pretty strong proof though I know you don't agree with that observation.
I am done with this.
-Doug
I have never felt the need for full OOP implementation.
On 3/18/22 7:47 AM, Jali Heinonen wrote:
I have never felt the need for full OOP implementation.You are not alone. Many find it sufficient to use just parts of oop behavior, which seems very reasonable to me. I don't think it is
possible to define, regardless of programming language, exactly what is
a "full" oop implementation. At least one won't get much agreement about this. I don't see that as a problem.
-Doug
"UDT"?
"object method" syntax?
"method-flavored fields (structs)"?
Yeah, what is "full" oop implementation definition is a bit complex. Let's = >stick to the classic defintion: if system provides the ability of encapsula= >tion, inheritance and polymorphism - it is full oop.
Could someone explain the terminology used in this thread:
"UDT"?
"object method" syntax?
"method-flavored fields (structs)"?
Gforth does have defining words that define defer-flavoured words,=20
though. Can you guess how they behave?
Do you mean defining word 'forward'? I took a look at the implementation bu= >t it is too complex, I just get the general idea how I would implement this= >.
On Sunday, March 20, 2022 at 5:33:53 PM UTC+1, Anton Ertl wrote:
But what I meant is, e.g., defer-flavoured locals:
: foo {: xt: x :}
x \ this EXECUTE's the xt stored in x
;
1 2 ' + foo . \ 3
You can also use ACTION-OF and IS on defer-flavoured words, but if you
do a lot of that, it's probably better to use a value-flavoured or
variable-flavoured word in combination with EXECUTE.
Sorry, but what is the difference with a standard
: foo ( ? xt -- arity1 ) ( F: ? -- arity2 )
>R ( something ) R> EXECUTE ( something else ) ;
?
So what is the purpose of ACTION-OF
or IS then?
Ice Black <blacki...@gmail.com> writes:
Gforth does have defining words that define defer-flavoured words,
though. Can you guess how they behave?
Do you mean defining word 'forward'? I took a look at the implementation
but it is too complex, I just get the general idea how I would implement
this.
No, I did not mean FORWARD. FORWARD is an interesting demonstration
of how various recent Gforth features can be used for good effect, but understanding it is fairly involved. You can find an explanation in <2018Dec3...@mips.complang.tuwien.ac.at> (<http://al.howardknight.net/?ID=164779351600>, unfortunately
truncated, but the main explanation is there).
But what I meant is, e.g., defer-flavoured locals:
: foo {: xt: x :}
x \ this EXECUTE's the xt stored in x
;
1 2 ' + foo . \ 3
You can also use ACTION-OF and IS on defer-flavoured words, but if you
do a lot of that, it's probably better to use a value-flavoured or variable-flavoured word in combination with EXECUTE.
: A {: w^ k x1 x2 x3 xt: x4 xt: x5 | w^ B :} recursive
k @ 0<= IF x4 x5 + ELSE
B k x1 x2 x3 action-of x4 [{: B k x1 x2 x3 x4 :}L
-1 k +!
k @ B @ x1 x2 x3 x4 A ;] dup B !
execute THEN ;
: man-or-boy? ( n -- n' ) [: 1 ;] [: -1 ;] 2dup swap [: 0 ;] A ;
This is Gforth's variant of Knuth's man-or-boy test. As is usual for
Knuth's examples, there is no intrinsic point, so don't try to
understand it; but you can see how defer-flavoured locals are used
here directly and with ACTION-OF.
Jan Coombs <jan4comp....@murray-microft.co.uk> writes:
An advantage of not having the address is that the system couldCertainly for value-flavoured fields we are out of luck, because we
de-fragment and perform other memory storage operations transparently
in the background.
would need to have complete compile-time knowledge about where struct addresses reside.
But of course one might pursue this idea further, and design a "Forth"
system which does not give out general addresses, only typed addresses
which allow the system to determin exactly which cells are addresses
and which are other things; and this can then be used for precise
garbage collection. The resulting language would probably have a much
more Java-like feeling, but maybe it would be closer to traditional
Forth than I expect. Certainly oForth has some features that I
associated with "not Forth", but it turned out to be much Forthier
than I had expected.
- anton
On Thursday, March 17, 2022 at 4:55:25 AM UTC-5, Anton Ertl wrote:
Jan Coombs <jan4comp....@murray-microft.co.uk> writes:
An advantage of not having the address is that the system could >de-fragment and perform other memory storage operations transparentlyCertainly for value-flavoured fields we are out of luck, because we
in the background.
would need to have complete compile-time knowledge about where struct addresses reside.
But of course one might pursue this idea further, and design a "Forth" system which does not give out general addresses, only typed addresses which allow the system to determin exactly which cells are addressesAFAIUI that's almost exactly how Java was borne. Gosling's previous projects had been a popular implementation of emacs, and Sun NeWS , a windowing system built using object-oriented PostScript.
and which are other things; and this can then be used for precise
garbage collection. The resulting language would probably have a much
more Java-like feeling, but maybe it would be closer to traditional
Forth than I expect. Certainly oForth has some features that I
associated with "not Forth", but it turned out to be much Forthier
than I had expected.
- anton
https://www.academia.edu/27027623/A_User_Interface_Toolkit_in_Object_Oriented_PostScript_Owen_M_Densmore
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 71:22:17 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,275,626 |