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

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

A New Forth

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

Contents

  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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#51725

To me, code clarity is 100x more important than how "elegant" it is.

When I come to code that needs to be modified, it is because there is a
either problem with it, or a desire to do some sort of enhancement. In either
case, the code better be "intuitively obvious upon casual inspection". If 
it is not, then there damn well better some great documentation of why it
needs to be the way it is. The last thing I want to do is have to try to 
guess what it is doing.

For some reason, some people make things overly complex when there is no
need for it.

That is the 30+ years of experience as a software developer talking.

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

#51755

On Sun, 9 Oct 2016 10:54:05 +0200 (CEST)
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:

> In article <763508c2-cb4c-476f-96d1-95c603729e73@googlegroups.com>,
> trans  <transfire@gmail.com> wrote:
> >On Saturday, October 8, 2016 at 3:33:58 PM UTC-4, Paul Rubin wrote:  
> <SNIP>
> >  
> >> It sounds like you've been using C++.  If you want exposure to
> >> fancier uses of type systems, you might give Haskell a try.
> >> http://learnyouahaskell.com is a good place to start.  
> >
> >Oh, I have explored Haskell. Lots of interesting ideas. A bit too
> >"interest= ing" I think. On the surface Haskell seems great, but as
> >I explored it more=
> > the extreme focus on types, pure functionality and heavy academics,
> > starts= to wear on code clarity, at least it seemed that way to me.
> > Just look up h=
> >ow to generate a random number for instance.
> >  
> 
> I've seen a lot of solutions to Euler problems where the Haskell code
> was very short and not understandable to me.
> The only thing that suggests to me that there is an interesting
> language to study, not that it is lacking in code clarity, and
> certainly that it is more than just interestign idea's.
> 
> Groetjes Albert

Problem with Haskell is that it is lazy evaluation language. That
implies lot's of memory leaks in more subtle ways than in C.
They called it space leak, because it will be eventually freed but I
seen people have lot of problems because of that.
Most naive example is updating variable without using it on every
iteration. That would result in compiler generating thunk in each
iteration and evaluating said thunks only on first use, which means you
can get out of memory by naive code.

-- 
press any key to continue or any other to quit

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

#51757

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> I've seen a lot of solutions to Euler problems where the Haskell code
> was very short and not understandable to me.

I have reasonable familiarity with the language and as such, I find
the solutions at

   https://wiki.haskell.org/Euler_problems/1_to_10

to be pretty readable, but I can understand how they might not be if the
syntax and vocabularity is new.

I think I mentioned http://learnyouahaskell.com as a good place
to start.  The Haskell Wikibook is also good:

  https://en.wikibooks.org/wiki/Haskell

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

#51875

Le dimanche 9 octobre 2016 10:45:19 UTC+2, Albert van der Horst a écrit :
> In article <763508c2-cb4c-476f-96d1-95c603729e73@googlegroups.com>,
> trans  <transfire@gmail.com> wrote:
> >On Saturday, October 8, 2016 at 3:33:58 PM UTC-4, Paul Rubin wrote:
> <SNIP>
> >
> >> It sounds like you've been using C++.  If you want exposure to fancier
> >> uses of type systems, you might give Haskell a try.
> >> http://learnyouahaskell.com is a good place to start.
> >
> >Oh, I have explored Haskell. Lots of interesting ideas. A bit too "interest=
> >ing" I think. On the surface Haskell seems great, but as I explored it more=
> > the extreme focus on types, pure functionality and heavy academics, starts=
> > to wear on code clarity, at least it seemed that way to me. Just look up h=
> >ow to generate a random number for instance.
> >
> 
> I've seen a lot of solutions to Euler problems where the Haskell code
> was very short and not understandable to me.
> The only thing that suggests to me that there is an interesting language
> to study, not that it is lacking in code clarity, and certainly that it
> is more than just interestign idea's.
> 
> 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

Hi,

Here are a version of Euler problems 1 to 10 in Oforth : 

-------------------------------------------------------
Problem 1 : 
0 #[ dup 3 mod swap 5 mod * not ] #+ 999 seq applyIf 

-------------------------------------------------------
: problem2( n -- m )
   0 1 1 while ( dup n <= ) [
      dup isEven ifTrue: [ rot over + -rot ]
      tuck +
      ] 2drop
;

-------------------------------------------------------
: factors( n -- [n] ) \ Not needed here, but to show how calculate factors
| l p |
    ArrayBuffer new ->l
    n nsqrt ->p
    2 while( dup p <= ) [
        n over /mod swap 
        ifZero: [ dup ->n nsqrt ->p dup l add continue ]
        drop 1+
        ]
     drop l n 1 > ifTrue: [ n over add ] dup freeze 
;

600851475143 factors last

-------------------------------------------------------
: problem4    \ -- n
| i j |
    0 100 999 for: i [
        100 i for: j [
            i j * dup asString dup reverse == ifTrue: [ max ] else: [ drop ]
            ]
         ]
;
-------------------------------------------------------
import: math
1 #lcm 20 seqEach

-------------------------------------------------------
100 seq sum sq  #[ sq - ] 100 seqEach

-------------------------------------------------------
Integer method: isPrime    \ n -- b
| i |
    self 3 <= ifTrue: [ self 1 <> return ]
    self isEven ifTrue: [ false return ]
    3 self nsqrt for: i [ self i mod ifZero: [ false return ] i 1+ ->i ]
    true 
;

: problem7
| i |
   -1 10000 loop: i [ 2 + dup isPrime ifFalse: [ i 1- ->i ] ] ;

-------------------------------------------------------

"73167176531330624919225119674426574742355349194934"
"96983520312774506326239578318016984801869478851843" +
"85861560789112949495459501737958331952853208805511" +
"12540698747158523863050715693290963295227443043557" +
"66896648950445244523161731856403098711121722383113" +
"62229893423380308135336276614282806444486645238749" +
"30358907296290491560440772390713810515859307960866" +
"70172427121883998797908792274921901699720888093776" +
"65727333001053367881220235421809751254540594752243" +
"52584907711670556013604839586446706324415722155397" +
"53697817977846174064955149290862569321978468622482" +
"83972241375657056057490261407972968652414535100474" +
"82166370484403199890008895243450658541227588666881" +
"16427171479924442928230863465674813919123162824586" +
"17866458359124566529476545682848912883142607690042" +
"24219022671055626321111109370544217506941658960408" +
"07198403850962455444362981230987879927244284909188" +
"84580156166097919133875499200524063689912560717606" +
"05886116467109405077541002256983155200055935729725" +
"71636269561882670428252483600823257530420752963450" + 
const: NUMBER

: problem8   \ -- n 
| i j |
     0  NUMBER size 13 - 
     loop: i [ 1 13 loop: j [ i j + 1- NUMBER at asDigit * ] max ]
;
-------------------------------------------------------
: problem9( n -- m )
| a b c |
   n loop: a [
       a 1+ n for: b [
           a sq b sq + sqrt dup asInteger dup ->c == ifFalse: [ continue ]
           a b + c + n == ifTrue: [ a b * c * return ]
           ]
       ]
;
-------------------------------------------------------
: problem10    \ Uses problem 7 #isPrime
| i |
    10 2000000 loop: i [ i isPrime ifTrue: [ i + ] ] 
;
-------------------------------------------------------

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

#51837

On Sat, 8 Oct 2016 17:28:51 -0700 (PDT)
trans <transfire@gmail.com> wrote:

> 
> > It sounds like you've been using C++.  If you want exposure to
> > fancier uses of type systems, you might give Haskell a try.
> > http://learnyouahaskell.com is a good place to start.  
> 
> Oh, I have explored Haskell. Lots of interesting ideas. A bit too
> "interesting" I think. On the surface Haskell seems great, but as I
> explored it more the extreme focus on types, pure functionality and
> heavy academics, starts to wear on code clarity, at least it seemed
> that way to me. Just look up how to generate a random number for
> instance.
> 

I missed this. Haskell is most beautiful language I've seen so far:
What's wrong with random numbers?
    number <- randomIO :: IO Float

or 

    g <- getStdGen
    putStrLn $ show $ take 10 $ randomRs (0::Int,10) g


-- 
press any key to continue or any other to quit

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

#51838

On Thursday, October 13, 2016 at 1:16:07 PM UTC-4, Melzzzzz wrote:
> 
> I missed this. Haskell is most beautiful language I've seen so far:
> What's wrong with random numbers?
>     number <- randomIO :: IO Float
> 
> or 
> 
>     g <- getStdGen
>     putStrLn $ show $ take 10 $ randomRs (0::Int,10) g

Oh yeahhhhh. `IO` and `getStdGen`, so obvious. But wait what about lazy evaluation, I think we need them monads. Yep, you forgot your `do`.

They say beauty is in the eye of the beholder, but really? Look at it in Ruby (or Crystal).

    10.times.collect{ rand(10) }

I'll grant you that the theory behind Haskell does have a certain beauty to it, but to me it doesn't seem to translate that well to practice. I don't think I've had a harder time learning a language than I have had with Haskell.

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

#51839

On 2016-10-13, trans <transfire@gmail.com> wrote:
> On Thursday, October 13, 2016 at 1:16:07 PM UTC-4, Melzzzzz wrote:
>> 
>> I missed this. Haskell is most beautiful language I've seen so far:
>> What's wrong with random numbers?
>>     number <- randomIO :: IO Float
>> 
>> or 
>> 
>>     g <- getStdGen
>>     putStrLn $ show $ take 10 $ randomRs (0::Int,10) g
>
> Oh yeahhhhh.  `IO` and `getStdGen`, so obvious.  But wait what about lazy
> evaluation, I think we need them monads.  Yep, you forgot your `do`.

Well, you don't need monads if g is passed around. Yes, you need monads
because this is how Haskell handles side effects.

>
> They say beauty is in the eye of the beholder, but really?  Look at it in
> Ruby (or Crystal).
>
>     10.times.collect{ rand(10) }
>
> I'll grant you that the theory behind Haskell does have a certain beauty
> to it, but to me it doesn't seem to translate that well to practice.  I
> don't think I've had a harder time learning a language than I have had
> with Haskell.

Haskell is most difficult language I have ever seen, as well. But once you
learn it, you enjoy it.
Try Rust if Haskell is difficult ;)
>


-- 
press any key to continue or any other to quit

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

#51883

trans wrote:

> On the surface
> Haskell seems great,
> but as I explored it more
> the extreme focus on types,
> pure functionality and heavy academics, starts to wear on code clarity,

Look at OCaml.

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

#51716

On Saturday, October 8, 2016 at 2:11:14 PM UTC-5, trans wrote:
> On Friday, October 7, 2016 at 8:56:33 PM UTC-4, 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?
> 
> Okay since I am already talking about it, and the feedback has been really helpful so far, I'll go into it a bit further and see what you guys think.
> 
> Of course the first thing I have to decide is what assembler to use. It will probably be GAS, but I am open to other suggestions. (Note I looked at GNU Lightening but it has limitations too so I am just going to go all the way down and do it in Assembly.) From there I plan to build a core base that will abstract away some of the underlying architecture. I don't think I want to abstract it all away, in fact I want it to be possible to fallback on the underlying architecture where useful, but it should be able to abstract away enough to at least make the language much easier to port.
> 
> The next major decision I have to make is with regards to word lookup because the Forth I am working on will be typed. I am not doing that for type safety or execution performance reasons, although those are nice bonuses, rather I am doing it primarily for the multi-method dispatching it will allow, which will make this new Forth much more readable -- and that is a top priority for me. A problem that arises though, is ambiguity between type signatures. e.g. pseudo-code:
> 
>     : foo ( int int -- int ) ... ;
>     : foo ( int int int -- int ) ... ;
>  
> When deciding which foo to use based on the type signature if there are three ints on the stack, does it use the first or the second definition? Or should it just use the one that shows up first in the definitions list. Or, I suppose, the compiler could just raise an error about the ambiguity?
> 
> Another feature I plan to have are recognizers, but I am pretty sure it will be character based, not word based. I don't think that will prove to be too difficult, but I still have to figure out how to make it as simple as possible to tap into.
> 
> The hardest thing I have to work out is probably how to handle types that can't be determined at compile time -- say if a word returns a float vs an integer based on some runtime condition. I really don't think I want to restrict return values to a single concrete signature. That would make compilation a lot easier, but I fear it would make programming in this Forth feel far too constrained. Am I right about that? 
> 
> I have so far come up with two possible ways to handle it, that would not slow things down too much. One is to use mini-jump tables. So if a word returns two different signatures, then it would also return a jump index (or put it on a special stack) and that would be used as an offset to find the correct xt. The other option is a large global jump table -- think of all the possible word names and type signatures in a multi-dimensional matrix (the dimensions correspond to arity). The xt could be looked up through a few redirections (one per argument). Of course, the downside is that the table could be pretty big and most of it would be empty. Also, the extra indirection would slow things down (though still far faster then something like a binary search). These are both nascent ideas, and I haven't worked through them completely yet. I've been trying to find out how other static compilers handle this situation but haven't found out yet.

This is starting to sound a lot more like PostScript
than forth. I have some C code that does typed overloading 
like this for PostScript.
https://github.com/luser-dr00g/xpost/blob/master/src/lib/xpost_operator.c

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

#51722

On Friday, October 7, 2016 at 8:56:33 PM UTC-4, 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?

tcc

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

#51751

Geez. Do you people always have to make things more complex then they need 
to be? Everything is just numbers on a stack or two. The code that takes
the number(s) off decides what they mean in that context, does something with
them (or not) and leaves the stacks in some known state. Build more 
functionality on top of the functionality you already have. That is all there
is to it.

Everything else is implementation details. You can make it do whatever you
want to make it do. Want to build an object oriented, typed system? Knock
yourself out. There are as many ways to do that as there are programmers
who write code.

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

#51754

On Monday, October 10, 2016 at 10:22:56 PM UTC-4, Chris Curl wrote:
> Geez. Do you people always have to make things more complex then they need 
> to be? Everything is just numbers on a stack or two. The code that takes
> the number(s) off decides what they mean in that context, does something with
> them (or not) and leaves the stacks in some known state. Build more 
> functionality on top of the functionality you already have. That is all there
> is to it.
> 
> Everything else is implementation details. You can make it do whatever you
> want to make it do. Want to build an object oriented, typed system? Knock
> yourself out. There are as many ways to do that as there are programmers
> who write code.

But not so many that don't incur a heavy performance or memory penalty. I am trying to add multi-methods to Forth without significant overhead. If you know a way I am all ears.

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

#51773

On Monday, October 10, 2016 at 11:18:48 PM UTC-4, trans wrote:
> On Monday, October 10, 2016 at 10:22:56 PM UTC-4, Chris Curl wrote:
> > Geez. Do you people always have to make things more complex then they need 
> > to be? Everything is just numbers on a stack or two. The code that takes
> > the number(s) off decides what they mean in that context, does something with
> > them (or not) and leaves the stacks in some known state. Build more 
> > functionality on top of the functionality you already have. That is all there
> > is to it.
> > 
> > Everything else is implementation details. You can make it do whatever you
> > want to make it do. Want to build an object oriented, typed system? Knock
> > yourself out. There are as many ways to do that as there are programmers
> > who write code.
> 
> But not so many that don't incur a heavy performance or memory penalty. I am trying to add multi-methods to Forth without significant overhead. If you know a way I am all ears.

Something, somewhere has to decide which "flavor" of the function you mean.
With a compiled language such as C++, where there is a very tight coupling 
between the function and the parameters being passed to it, so the compiler can
figure it out based on the parameters you are passing. Forth is a completely
different animal. The parameters are much more fluid, and the coupling is 
much looser.

To do something like what you are talking about, I would group the different
flavors of the words into tables of vectors. I would build a parallel stack 
of types, one for each entry on the data stack.

The first vector in the table would be the "selector" and it would use the 
info from the type stack to decide which vector to jump to. How it does that
will depend on the range of signatures you want to be able to support.

But there is no free lunch. To figure this stuff out at run-time will
always add overhead.

I'm not sure I understand why you would want to re-invent that wheel though.
Even in the compiled world, the programmer knows up front which flavor of 
the function he (she) intends to call, the fact that there are >1 function 
with the same name is merely a convenience.

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

#51775

On Tuesday, October 11, 2016 at 2:14:23 PM UTC-4, Chris Curl wrote:
> On Monday, October 10, 2016 at 11:18:48 PM UTC-4, trans wrote:
> > On Monday, October 10, 2016 at 10:22:56 PM UTC-4, Chris Curl wrote:
> > > Geez. Do you people always have to make things more complex then they need 
> > > to be? Everything is just numbers on a stack or two. The code that takes
> > > the number(s) off decides what they mean in that context, does something with
> > > them (or not) and leaves the stacks in some known state. Build more 
> > > functionality on top of the functionality you already have. That is all there
> > > is to it.
> > > 
> > > Everything else is implementation details. You can make it do whatever you
> > > want to make it do. Want to build an object oriented, typed system? Knock
> > > yourself out. There are as many ways to do that as there are programmers
> > > who write code.
> > 
> > But not so many that don't incur a heavy performance or memory penalty. I am trying to add multi-methods to Forth without significant overhead. If you know a way I am all ears.
> 
> Something, somewhere has to decide which "flavor" of the function you mean.
> With a compiled language such as C++, where there is a very tight coupling 
> between the function and the parameters being passed to it, so the compiler can
> figure it out based on the parameters you are passing. Forth is a completely
> different animal. The parameters are much more fluid, and the coupling is 
> much looser.
> 
> To do something like what you are talking about, I would group the different
> flavors of the words into tables of vectors. I would build a parallel stack 
> of types, one for each entry on the data stack.
> 
> The first vector in the table would be the "selector" and it would use the 
> info from the type stack to decide which vector to jump to. How it does that
> will depend on the range of signatures you want to be able to support.

I haven't been able to find source for it, but that sounds like how I imagine StrongForth works. And it is a tempting way to go. Basically compiling each word to a pointer to a lookup table that is indexed on type signature.

> But there is no free lunch. To figure this stuff out at run-time will
> always add overhead.

That's the problem. As tempting as the above approach is for its simplicity. Runtime dispatching on type signatures is still going to eat up a good bit of time with each call. It would be fast pretty if it was direct array indexing, but that would eat way too much memory. Say there are just 20 types in the system, every 3 arity word would have a table of 8000 cells and most would be null. Just not practical. So it would either have to be a search tree or a hash table, and the later doesn't make sense since most words will have a relatively small set of definitions. So a search tree and O(log n) lookup time. That wouldn't be horribly slow, but I'd guesstimate it would still be about 4x slower than C best case scenario.
 
> I'm not sure I understand why you would want to re-invent that wheel though.
> Even in the compiled world, the programmer knows up front which flavor of 
> the function he (she) intends to call, the fact that there are >1 function 
> with the same name is merely a convenience.

It's a pretty huge convenience though that has a significant impact on *readability*. And I stress that, as I learned from using Ruby, readability had such a huge impact to productively, I think it's hard to overestimate the advantage. You compare word names like `d+`, `f+`, `a:+`, etc. vs. `+` for all of those cases, and the scales just fall away off people's eyes.

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

#51776

On Tuesday, October 11, 2016 at 4:22:45 PM UTC-5, trans wrote:
> On Tuesday, October 11, 2016 at 2:14:23 PM UTC-4, Chris Curl wrote:
> > On Monday, October 10, 2016 at 11:18:48 PM UTC-4, trans wrote:
> > > On Monday, October 10, 2016 at 10:22:56 PM UTC-4, Chris Curl wrote:
> > > > Geez. Do you people always have to make things more complex then they need 
> > > > to be? Everything is just numbers on a stack or two. The code that takes
> > > > the number(s) off decides what they mean in that context, does something with
> > > > them (or not) and leaves the stacks in some known state. Build more 
> > > > functionality on top of the functionality you already have. That is all there
> > > > is to it.
> > > > 
> > > > Everything else is implementation details. You can make it do whatever you
> > > > want to make it do. Want to build an object oriented, typed system? Knock
> > > > yourself out. There are as many ways to do that as there are programmers
> > > > who write code.
> > > 
> > > But not so many that don't incur a heavy performance or memory penalty. I am trying to add multi-methods to Forth without significant overhead. If you know a way I am all ears.
> > 
> > Something, somewhere has to decide which "flavor" of the function you mean.
> > With a compiled language such as C++, where there is a very tight coupling 
> > between the function and the parameters being passed to it, so the compiler can
> > figure it out based on the parameters you are passing. Forth is a completely
> > different animal. The parameters are much more fluid, and the coupling is 
> > much looser.
> > 
> > To do something like what you are talking about, I would group the different
> > flavors of the words into tables of vectors. I would build a parallel stack 
> > of types, one for each entry on the data stack.
> > 
> > The first vector in the table would be the "selector" and it would use the 
> > info from the type stack to decide which vector to jump to. How it does that
> > will depend on the range of signatures you want to be able to support.
> 
> I haven't been able to find source for it, but that sounds like how I imagine StrongForth works. And it is a tempting way to go. Basically compiling each word to a pointer to a lookup table that is indexed on type signature.
> 
> > But there is no free lunch. To figure this stuff out at run-time will
> > always add overhead.
> 
> That's the problem. As tempting as the above approach is for its simplicity. Runtime dispatching on type signatures is still going to eat up a good bit of time with each call. It would be fast pretty if it was direct array indexing, but that would eat way too much memory. Say there are just 20 types in the system, every 3 arity word would have a table of 8000 cells and most would be null. Just not practical. So it would either have to be a search tree or a hash table, and the later doesn't make sense since most words will have a relatively small set of definitions. So a search tree and O(log n) lookup time. That wouldn't be horribly slow, but I'd guesstimate it would still be about 4x slower than C best case scenario.
>  
> > I'm not sure I understand why you would want to re-invent that wheel though.
> > Even in the compiled world, the programmer knows up front which flavor of 
> > the function he (she) intends to call, the fact that there are >1 function 
> > with the same name is merely a convenience.
> 
> It's a pretty huge convenience though that has a significant impact on *readability*. And I stress that, as I learned from using Ruby, readability had such a huge impact to productively, I think it's hard to overestimate the advantage. You compare word names like `d+`, `f+`, `a:+`, etc. vs. `+` for all of those cases, and the scales just fall away off people's eyes.

]>Runtime dispatching on type signatures is still going to eat up a good bit of time with each call.

If one hashes the type signature + operator "index" and if the processor has a builtin hash function, then one would suffer a one+ memory cycle delay getting to the specific operator?

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

#51780

On Tuesday, October 11, 2016 at 6:11:36 PM UTC-4, jim.bra...@ieee.org wrote:

> If one hashes the type signature + operator "index" and if the processor has a builtin hash function, then one would suffer a one+ memory cycle delay getting to the specific operator?

I can't seem to find anything through Google search about this. Can you provide a link to any example? I'm guessing you are talking about AES instructions? Everything I found on that related to cryptographic applications. And everything I found about non-cryptographic hashing made no mention of such.

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

#51777

trans <transfire@gmail.com> writes:
> Say there are just 20 types in the system, every 3 arity word would
> have a table of 8000 cells and most would be null. Just not
> practical. So it would either have to be a search tree or a hash
> table, and the later doesn't make sense since most words will have a
> relatively small set of definitions.

Using a hash table is common enough in systems like CLOS.  Or you could
use a tracing JIT to specialize the most common execution paths into
monomorphism.

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

#51779

On Tuesday, October 11, 2016 at 6:13:16 PM UTC-4, Paul Rubin wrote:
> trans <transfire@gmail.com> writes:
> > Say there are just 20 types in the system, every 3 arity word would
> > have a table of 8000 cells and most would be null. Just not
> > practical. So it would either have to be a search tree or a hash
> > table, and the later doesn't make sense since most words will have a
> > relatively small set of definitions.
> 
> Using a hash table is common enough in systems like CLOS.  Or you could
> use a tracing JIT to specialize the most common execution paths into
> monomorphism.

The elephant in the room is that the system doesn't know at runtime how 
many of the values/types on the stack(s) are there for the word/function 
group to use when trying to decide which vector to resolve to. The whole
paradigm in Forth is much more loosely coupled. You could have 2 flavors
of a word, one of which takes one int and one that takes two ints. If the
stack has 7 items on it for whatever reason, if the top 2 are ints, then
it would almost have to choose the 2nd version, even if that was not your
intention.

I suppose you could put a marker in somewhere, or always put the count of
args to use on the top, and then build a hash that you use as an index into 
the table. That probably wouldn't kill the performance too bad.

But I'm still not understanding the need for such a mechanism.

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

#51784

On Tuesday, October 11, 2016 at 8:52:59 PM UTC-4, Chris Curl wrote:
> On Tuesday, October 11, 2016 at 6:13:16 PM UTC-4, Paul Rubin wrote:
> > trans <transfire@gmail.com> writes:
> > > Say there are just 20 types in the system, every 3 arity word would
> > > have a table of 8000 cells and most would be null. Just not
> > > practical. So it would either have to be a search tree or a hash
> > > table, and the later doesn't make sense since most words will have a
> > > relatively small set of definitions.
> > 
> > Using a hash table is common enough in systems like CLOS.  Or you could
> > use a tracing JIT to specialize the most common execution paths into
> > monomorphism.
> 
> The elephant in the room is that the system doesn't know at runtime how 
> many of the values/types on the stack(s) are there for the word/function 
> group to use when trying to decide which vector to resolve to. The whole
> paradigm in Forth is much more loosely coupled. You could have 2 flavors
> of a word, one of which takes one int and one that takes two ints. If the
> stack has 7 items on it for whatever reason, if the top 2 are ints, then
> it would almost have to choose the 2nd version, even if that was not your
> intention.

You are right, and that was one of my first conundrums. I think I have resolved that the definition used is simply the first one found in the dictionary, probably emitting a warning when a word is overridden with a different arity. Is there any show-stopping problems with that approach?

> I suppose you could put a marker in somewhere, or always put the count of
> args to use on the top, and then build a hash that you use as an index into 
> the table. That probably wouldn't kill the performance too bad.

I have thought about that, say using a `,` in pseudo-code:

   1 2 foo , 1 2 3 foo

Of course, the trouble with that is it can mess up the flow. You have to treat the `,` as a thing and swap it around sometimes.

   : bar 1 2 3 ;
   
   bar , -rot foo

Not sure how messy that might get.

Or another way, kind of what you suggest, is like Erlang

  1 2 foo/2 1 2 3 foo/3

> But I'm still not understanding the need for such a mechanism.

Well, it is partly subjective. If you have been coding Forth for a long time, it won't mean diddle to you, I'm sure. But I think to noobs it will make a big difference. And (assuming I can make it work well) I think it will make code much more readable. Like I mentioned that is one of my top goals.

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

#51842

On Tuesday, October 11, 2016 at 5:52:59 PM UTC-7, Chris Curl wrote:
> On Tuesday, October 11, 2016 at 6:13:16 PM UTC-4, Paul Rubin wrote:
> > trans <transfire@gmail.com> writes:
> > > Say there are just 20 types in the system, every 3 arity word would
> > > have a table of 8000 cells and most would be null. Just not
> > > practical. So it would either have to be a search tree or a hash
> > > table, and the later doesn't make sense since most words will have a
> > > relatively small set of definitions.
> > 
> > Using a hash table is common enough in systems like CLOS.  Or you could
> > use a tracing JIT to specialize the most common execution paths into
> > monomorphism.
> 
> The elephant in the room is that the system doesn't know at runtime how 
> many of the values/types on the stack(s) are there for the word/function 
> group to use when trying to decide which vector to resolve to. The whole
> paradigm in Forth is much more loosely coupled. You could have 2 flavors
> of a word, one of which takes one int and one that takes two ints. If the
> stack has 7 items on it for whatever reason, if the top 2 are ints, then
> it would almost have to choose the 2nd version, even if that was not your
> intention.
> 
> I suppose you could put a marker in somewhere, or always put the count of
> args to use on the top, and then build a hash that you use as an index into 
> the table. That probably wouldn't kill the performance too bad.
> 
> But I'm still not understanding the need for such a mechanism.

I don't see any need for such a mechanism --- I don't have tagged data in Straight Forth --- it is a traditional Forth in that you have to use the appropriate function for the data (if you use + on strings you are not going to get concatenation, you are going to get nonsense, and this is your fault not the language designer's fault).

I agree with Chris that too many people over-complicate problems that are inherently simple --- figuring this stuff out at run-time is not needed --- you almost always know how to write your code correctly at compile-time (if you don't, then maybe it is because you are confused).

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

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

csiph-web