Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #51686 > unrolled thread
| Started by | tabcomputing@gmail.com |
|---|---|
| First post | 2016-10-07 17:56 -0700 |
| Last post | 2016-10-15 12:23 -0700 |
| Articles | 7 on this page of 87 — 25 participants |
Back to article view | Back to comp.lang.forth
A New Forth tabcomputing@gmail.com - 2016-10-07 17:56 -0700
Re: A New Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-07 23:05 -0400
Re: A New Forth Walter Banks <walter@bytecraft.com> - 2016-10-08 10:07 -0400
Re: A New Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-08 13:08 +0000
Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 10:54 -0700
Re: A New Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-08 18:03 +0000
Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 11:13 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 11:17 -0700
Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:44 -0700
Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:53 -0700
Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 15:04 -0700
Re: A New Forth rickman <gnuarm@gmail.com> - 2016-10-13 22:55 -0400
Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 12:11 -0700
Re: A New Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-08 21:31 +0200
Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 17:07 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 12:33 -0700
Re: A New Forth missycurl@gmail.com - 2016-10-08 12:54 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 13:29 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 17:28 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 18:00 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-09 09:00 -0700
Re: A New Forth luser droog <mijoryx@yahoo.com> - 2016-10-09 11:19 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 01:09 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 08:24 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 13:28 -0700
Re: A New Forth "Elizabeth D. Rather" <erather@forth.com> - 2016-10-10 11:14 -1000
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 15:11 -0700
Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-11 21:46 -0400
Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 16:26 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 18:58 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 20:15 -0700
Re: A New Forth Ron Aaron <rambamist@gmail.com> - 2016-10-11 07:26 +0300
Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 03:09 -0700
Re: A New Forth Ron Aaron <rambamist@gmail.com> - 2016-10-11 13:27 +0300
Re: A New Forth lawrencedo99@gmail.com - 2016-10-13 18:41 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 19:08 -0700
Re: A New Forth Ron Aaron <rambamist@gmail.com> - 2016-10-14 07:58 +0300
Re: A New Forth franck.bensusan@gmail.com - 2016-10-09 11:09 -0700
Re: A New Forth lawrencedo99@gmail.com - 2016-10-13 18:45 -0700
Re: A New Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-09 10:54 +0200
Re: A New Forth missycurl@gmail.com - 2016-10-09 07:35 -0700
Re: A New Forth Melzzzzz <mel@zzzzz.com> - 2016-10-11 06:23 +0200
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 21:31 -0700
Re: A New Forth franck.bensusan@gmail.com - 2016-10-15 00:26 -0700
Re: A New Forth Melzzzzz <mel@zzzzz.com> - 2016-10-13 19:16 +0200
Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 11:46 -0700
Re: A New Forth Melzzzzz <Melzzzzz@zzzzz.com> - 2016-10-13 19:04 +0000
Re: A New Forth "WJ" <w_a_x_man@yahoo.com> - 2016-10-15 20:07 +0000
Re: A New Forth luser droog <mijoryx@yahoo.com> - 2016-10-08 13:56 -0700
Re: A New Forth polymorph self <jackvanc3@gmail.com> - 2016-10-08 19:58 -0700
Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-10 19:22 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 20:18 -0700
Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-11 11:14 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 14:22 -0700
Re: A New Forth jim.brakefield@ieee.org - 2016-10-11 15:11 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 18:03 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-11 15:13 -0700
Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-11 17:52 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 19:55 -0700
Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:21 -0700
Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:36 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 18:08 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-11 18:21 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 20:01 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 20:33 -0700
Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-12 01:15 -0400
Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 05:44 -0700
Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-12 11:51 -0400
Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 09:47 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-12 10:08 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 11:48 -0700
Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-12 11:56 -0700
Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-12 13:41 -0400
Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 11:57 -0700
Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 12:02 -0700
Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-13 09:24 -0400
Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-13 10:33 -0400
Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 10:05 -0700
Re: A New Forth jim <anon@example.com> - 2016-10-12 19:01 +0100
Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 09:53 -0700
Re: A New Forth fred <anon@example.com> - 2016-10-14 12:37 +0100
Re: A New Forth jim <anon@example.com> - 2016-10-14 14:49 +0100
Re: A New Forth trans <transfire@gmail.com> - 2016-10-14 07:20 -0700
Re: A New Forth jim <anon@example.com> - 2016-10-15 11:58 +0100
Re: A New Forth tabcomputing@gmail.com - 2016-10-15 10:21 -0700
Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-12 04:33 -0700
Re: A New Forth Whammo <sidciavic@gmail.com> - 2016-10-15 12:23 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | fred <anon@example.com> |
|---|---|
| Date | 2016-10-14 12:37 +0100 |
| Message-ID | <MPG.326ad3c79f66f249989694@news.virginmedia.com> |
| In reply to | #51835 |
In article <f91e68a8-a943-4c40-b382-40856287f6ca@googlegroups.com>, transfire@gmail.com says... > > > Jim could you explain this more. What is this intended to accomplish? Also, you seem to be thinking in OOP terms, so maybe it doesn't apply b/c I shooting for multiple dispatch. But maybe there still something to your idea that would apply if I understood it better. Hi trans you are right there are object concepts involved. In fact I stole the concept from Dick Pountains object forth book some years ago. (I just dug out the book so can perhaps explain why this might help better) as I understand mutiple dispatch you want multiple words with the same name to operate on different data types based on the datatype not the operation name. this means the data itself needs to carry a means of telling forth which word to call. What I was thinking was to use pountains concept of hidden dictionaries which are created by breaking the chain of link fields in the search order to "patch out" the different data type processes based on the key used to lock and unlock what is effectively a hidden vocabulary. Forth searching proceeds left to right down the search path a - b - c - d - BREAK e - f - g - 0 BREAK - e - f - g - h The link field in the first 'd' points to the second 'e' normally When your datatype arrives that needs its special type of handling the link field in the first d is changed by an 'unlock' word to point into the first 'e' dictionary revealing that class of operations for that datatype. The last word contains the zero in its link field to stop forth searching past it. When done processing that type the first 'd' gets its original LFA back and the private dictionary is hidden once more. there are some overheads in processing and your abstract data type needs to carry its dictionary address for unlocking but you do gain in information hiding and encapsulation at quite low cost. You also get an effective private vocabulary for all the functions you need to perform on all your different datatypes. Any other method I can think of short of unusable syntax falls appart when you realise you need a way to flag the different method call. You could do it with a single byte and flags (already you are in object territory - but then you need a lookup table The private dictionary gives you that - and the other benefits at the cost of the lock/unlock cycles. I think that's about it as a concept. Feel free to ask if you need more and I'll read up in the book.
[toc] | [prev] | [next] | [standalone]
| From | jim <anon@example.com> |
|---|---|
| Date | 2016-10-14 14:49 +0100 |
| Message-ID | <MPG.326af2dd19827b23989695@news.virginmedia.com> |
| In reply to | #51859 |
In article <MPG.326ad3c79f66f249989694@news.virginmedia.com>, anon@example.com says... > trans - sorry about the name change to fred - I've been fiddling with this newsreader to try and get it to work better in wine.
[toc] | [prev] | [next] | [standalone]
| From | trans <transfire@gmail.com> |
|---|---|
| Date | 2016-10-14 07:20 -0700 |
| Message-ID | <f9e63104-b121-4118-bfa5-a476af7164cf@googlegroups.com> |
| In reply to | #51859 |
On Friday, October 14, 2016 at 7:39:08 AM UTC-4, fred wrote: > you are right there are object concepts involved. In fact I stole the concept from > Dick Pountains object forth book some years ago. (I just dug out the book > so can perhaps explain why this might help better) > > as I understand mutiple dispatch you want multiple words with the same name > to operate on different data types based on the datatype not the operation name. > > this means the data itself needs to carry a means of telling forth which word > to call. > > What I was thinking was to use pountains concept of hidden dictionaries > which are created by breaking the chain of link fields in the search order > to "patch out" the different data type processes based on the key used > to lock and unlock what is effectively a hidden vocabulary. > > Forth searching proceeds left to right down the search path > > a - b - c - d - BREAK e - f - g - 0 BREAK - e - f - g - h > > The link field in the first 'd' points to the second 'e' normally > When your datatype arrives that needs its special type of handling > the link field in the first d is changed by an 'unlock' word to point > into the first 'e' dictionary revealing that class of operations for that datatype. > The last word contains the zero in its link field to stop forth searching past it. > When done processing that type the first 'd' gets its original LFA back and the > private dictionary is hidden once more. > > there are some overheads in processing and your abstract data type > needs to carry its dictionary address for unlocking but you > do gain in information hiding and encapsulation at quite low cost. > > You also get an effective private vocabulary for all the functions > you need to perform on all your different datatypes. > > Any other method I can think of short of unusable syntax falls > appart when you realise you need a way to flag the different > method call. You could do it with a single byte and flags (already > you are in object territory - but then you need a lookup table > The private dictionary gives you that - and the other benefits > at the cost of the lock/unlock cycles. > > I think that's about it as a concept. > Feel free to ask if you need more and I'll read up in the book. So it's a way to limit word lookup to a particular object class by linking in a classes "mini-dictionary" into the main dictionary dynamically. Is that about right?
[toc] | [prev] | [next] | [standalone]
| From | jim <anon@example.com> |
|---|---|
| Date | 2016-10-15 11:58 +0100 |
| Message-ID | <MPG.326c1c3815d51fc989696@news.virginmedia.com> |
| In reply to | #51861 |
In article <f9e63104-b121-4118-bfa5-a476af7164cf@googlegroups.com>, transfire@gmail.com says... > So it's a way to limit word lookup to a particular object class by linking in a classes "mini-dictionary" into the main dictionary dynamically. Is that about right? Yes that's a fair description - and of course prevent other data classes from seeing it or wasting time searching through it. There are other things pountain built on to implement a pretty good object based system that's remarkable efficient but I doubt you'd need that for your current job as I understand it. You retain the context throughout of course - something not obvious initially. If you had a very big system with many words it could also be used to simply speed up forths general word searching I'd guess.
[toc] | [prev] | [next] | [standalone]
| From | tabcomputing@gmail.com |
|---|---|
| Date | 2016-10-15 10:21 -0700 |
| Message-ID | <93154fdb-4309-4dc9-ac87-7a886d7a7bd5@googlegroups.com> |
| In reply to | #51877 |
On Saturday, October 15, 2016 at 7:00:15 AM UTC-4, jim wrote: > In article <f9e63104-b121-4118-bfa5-a476af7164cf@googlegroups.com>, > transfire@gmail.com says... > > So it's a way to limit word lookup to a particular object class by linking in a classes "mini-dictionary" into the main dictionary dynamically. Is that about right? > > > Yes that's a fair description - and of course prevent other data classes from > seeing it or wasting time searching through it. > There are other things pountain built on to implement a pretty good object based > system that's remarkable efficient but I doubt you'd need that for your current > job as I understand it. You retain the context throughout of course - something > not obvious initially. > > If you had a very big system with many words it could also be used > to simply speed up forths general word searching I'd guess. Actually I am definitely going to need some kind of encapsulation -- a module system where the words can only see the other words imported into it. So this may be useful after all. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-10-12 04:33 -0700 |
| Message-ID | <fe3c03c1-08d0-46c3-9c7d-70a3c5dad13a@googlegroups.com> |
| In reply to | #51786 |
On Tuesday, October 11, 2016 at 11:33:26 PM UTC-4, trans wrote: > On Tuesday, October 11, 2016 at 2:14:23 PM UTC-4, Chris Curl wrote: > > > But there is no free lunch. To figure this stuff out at run-time will > > always add overhead. > > I think I figured out a way to minimize the overhead. And it was a lot simpler than I thought. (So kudos to your first statement, "Geez. Do you people always have to make things more complex then they need to be?", because you were right.) > Thanks! > Quite simply, when a word is defined with a *union* type, i.e. with an argument that can be more than one possible type, then any word within the definition that is dependent on that type is simply replaced with if conditions to select which "flavor" to use. So: > > : foo ( int | float ) > 0> > > basically becomes (pseudo-code): > > : foo ( int | float ) > type int = if 0>/int else > type float = if 0>/float else > no-method-error throw > then then ; > > I could probably go a little further and extract the condition out into a hidden definition using quotations and reuse it where ever the same type condition is needed. It would be a tad slower but take up less memory. I'm glad my little rant helped.
[toc] | [prev] | [next] | [standalone]
| From | Whammo <sidciavic@gmail.com> |
|---|---|
| Date | 2016-10-15 12:23 -0700 |
| Message-ID | <3a1d28bb-c635-41a2-afc2-a8c98b24ddee@googlegroups.com> |
| In reply to | #51686 |
On Friday, October 7, 2016 at 5:56:33 PM UTC-7, tabcom...@gmail.com wrote: > I am planning to build a new variant of the Forth language. I plan to do so in Assembly, but I am wondering if I might be better off doing that in LLVM IR. Anyone have any recommendations as to why or why not I should use LLVM? Maybe a stack to keep track of what datatype is currently operating?
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.forth
csiph-web