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

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

Re: Forth in Python

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Forth in Python "P.M.Lawrence" <pml540114@gmail.com> - 2011-03-29 06:02 -0700
    Re: Forth in Python John Passaniti <john.passaniti@gmail.com> - 2011-03-29 07:20 -0700
      Re: Forth in Python Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-03-29 11:49 -0500
        Re: Forth in Python John Passaniti <john.passaniti@gmail.com> - 2011-03-29 10:35 -0700
      Re: Forth in Python "P.M.Lawrence" <pml540114@gmail.com> - 2011-03-31 18:52 -0700
        Re: Forth in Python John Passaniti <john.passaniti@gmail.com> - 2011-03-31 19:06 -0700
          Re: Forth in Python Paul Rubin <no.email@nospam.invalid> - 2011-03-31 19:36 -0700
    Re: Forth in Python "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-03-29 12:30 -0400
      Re: Forth in Python Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-03-30 15:25 +0100
      Re: Forth in Python "P.M.Lawrence" <pml540114@gmail.com> - 2011-03-31 19:02 -0700
        Re: Forth in Python "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-04-01 05:22 -0400
          Re: Forth in Python Anonymous <nobody@remailer.paranoici.org> - 2011-04-01 15:59 +0200
          Re: Forth in Python Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-01 23:55 +0000
      Re: Forth in Python BruceMcF <agila61@netscape.net> - 2011-03-31 21:32 -0700

#852 — Re: Forth in Python

Rod Pemberton wrote:
> "Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
> news:lisghz.drb@spenarnc.xs4all.nl...
> >
> > I have been thinking along these lines for the implementation
> > of a Forth chip that did not have branching, only calls.
> >
>
> You need to have branching.  If not, you cannot select between executing one
> block of code instead of another.  Calls are insufficient to provide choice.

No. The simplest constructs I have seen involve ordinary calls and
conditional returns (or conditional calls and ordinary returns), with
recursion to emulate loops. You can use an execution stack approach to
manage the recursion without stack overflow without having branching
hidden inside tall call optimisation. P.M.Lawrence.

[toc] | [next] | [standalone]

#857

On Mar 29, 9:02 am, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> No. The simplest constructs I have seen involve ordinary
> calls and conditional returns (or conditional calls and
> ordinary returns), with recursion to emulate loops. You
> can use an execution stack approach to manage the
> recursion without stack overflow without having branching
> hidden inside tall call optimisation.

Languages that use recursion for loops would implement tail-call
optimization, and no more depth on the execution stack would be needed
for each iteration.

The simplest constructs I've seen (aside from PostScript and related
languages) are like those in Smalltalk.  Smalltalk doesn't have any
conditional or looping constructs at the language level.  Instead,
they are methods on objects.  So a Boolean object in Smalltalk has
ifTrue and ifFalse methods (along with others).  Two objects derived
from the Boolean object are True and False.  So the ifTrue method on
True executes the argument, and ifTrue on False doesn't.  Relational
operators then return the True or False object.

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

#871

John Passaniti <john.passaniti@gmail.com> wrote:

> The simplest constructs I've seen (aside from PostScript and related
> languages) are like those in Smalltalk.  Smalltalk doesn't have any
> conditional or looping constructs at the language level.  Instead,
> they are methods on objects.  So a Boolean object in Smalltalk has
> ifTrue and ifFalse methods (along with others).  Two objects derived
> from the Boolean object are True and False.  So the ifTrue method on
> True executes the argument, and ifTrue on False doesn't.  Relational
> operators then return the True or False object.

I've always loved that too, but a little warning might might be
appropriate in case people are misled.  That's how it appears in the
source, so that's how people think about it, but Smalltalk doesn't
always actually do it that way.

Something like

isPositive

        ^ (self >= 0)
        ifTrue:  [ 1 ]
        ifFalse: [ 0 ]

compiles to

13 <70> self
14 <75> pushConstant: 0
15 <B5> send: >=
16 <99> jumpFalse: 19
17 <76> pushConstant: 1
18 <90> jumpTo: 20
19 <75> pushConstant: 0
20 <7C> returnTop

... which is remarkably similar to what a traditional interpreted
Forth would do.

Andrew.

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

#879

On Mar 29, 12:49 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> I've always loved that too, but a little warning might
> might be appropriate in case people are misled.  That's
> how it appears in the source, so that's how people
> think about it, but Smalltalk doesn't always actually
> do it that way.

Well, yeah, but I don't think this is misleading.  This entire sub-
thread is getting increasingly sloppy in being specific about
discussing conditionals.  We have conditionals at the language level
as dedicated control-flow structures or as functions, conditionals at
the code generation and language implementation level, and if I read
Albert's message correctly, conditional opcodes.

What I'm talking about is what the programmers sees and how the
programmer conceptualizes the semantics of the language.
Optimizations here and there don't change that.

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

#920

John Passaniti wrote:
> On Mar 29, 9:02 am, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> > No. The simplest constructs I have seen involve ordinary
> > calls and conditional returns (or conditional calls and
> > ordinary returns), with recursion to emulate loops. You
> > can use an execution stack approach to manage the
> > recursion without stack overflow without having branching
> > hidden inside tall call optimisation.
>
> Languages that use recursion for loops would implement tail-call
> optimization, and no more depth on the execution stack would be needed
> for each iteration.

NO, they DON'T all do it that way. That's why I mentioned the
execution stack approach. With that, each "call" is really a run time
macro expansion, popping the "call" and pushing the entire
"subroutine" onto the execution stack. There's no return instruction
as such, apart from using a return as a syntactic marker in the
source. Instead, the execution stack gets cut back incrementally as
the "subroutine" is executed (so you would need to have conditional
calls to get a non-branch language this way). The thing is, tall call
optimisation does actually have branches, but they are hidden. This
approach shows that you don't even need that.

I have actually seen something that uses an execution stack, the
scripting language on the old Datapoint minicomputer. For that, the
performance penalty didn't matter, and it saved on having an open
ended number of active file handles for each file that provided a
subroutine. Henry Baker has also suggested in one of his papers that
cacheing and Forth's short words could make it viable for Forth, too.
(I think that was a paper on linear logic.) P.M.Lawrence.

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

#922

On Mar 31, 9:52 pm, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> > Languages that use recursion for loops would implement
> > tail-call optimization, and no more depth on the
> > execution stack would be needed for each iteration.
>
> NO, they DON'T all do it that way.

Maybe I'm not following the technique you're describing.  Are you
describing something like a "reduction" in Erlang?

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

#923

John Passaniti <john.passaniti@gmail.com> writes:
> Maybe I'm not following the technique you're describing.  Are you
> describing something like a "reduction" in Erlang?

I don't know what a reduction is but it sounds like he's describing a
bizarre version of continuation-passing style, where you execute code
directly from the stack, popping each instruction off the stack when you
execute it.  If you then want to call function FOO, you push the code of
FOO to the stack.  The mind wobbles.  I think I looked at that Henry
Baker paper some time back, but that aspect of it went past me:

http://home.pipeline.com/~hbaker1/ForthStack.html
http://home.pipeline.com/~hbaker1/ForthStack.ps.gz

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

#867

"P.M.Lawrence" <pml540114@gmail.com> wrote in message
news:c42dfd39-149d-4b0b-9c6e-9998b342a4bb@r4g2000prm.googlegroups.com...
> Rod Pemberton wrote:
> > "Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
> > news:lisghz.drb@spenarnc.xs4all.nl...
> > >
> > > I have been thinking along these lines for the implementation
> > > of a Forth chip that did not have branching, only calls.
> > >
> >
> > You need to have branching.  If not, you cannot select between executing
> > one block of code instead of another.  Calls are insufficient to provide
> > choice.
>
> No. The simplest constructs I have seen involve ordinary calls and
> conditional returns
>

Conditional returns include branching, or they wouldn't be labeled
"conditional"...

> ... (or conditional calls and ordinary returns),

Conditional calls include branching.  Ditto...

You cannot change the control flow without a branch in one form or another.
It's impossible.  Calls normally do not include a conditional, i.e., cannot
provide choice.


Rod Pemberton

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

#896

On 29/03/11 17:30, Rod Pemberton wrote:
    . . .
> You cannot change the control flow without a branch in one form or another.
> It's impossible.  Calls normally do not include a conditional, i.e., cannot
> provide choice.

The ARM processors execute every instruction conditionally, so 
control flow can change although the processor will still have 
fetched every instruction; those for the IF clause, and those for 
the ELSE.

This avoids delays caused by trashing the code cache.  It might be 
interesting to consider a similar technique for stack processors.

Jan Coombs.

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

#921

Rod Pemberton wrote:
> "P.M.Lawrence" <pml540114@gmail.com> wrote in message
> news:c42dfd39-149d-4b0b-9c6e-9998b342a4bb@r4g2000prm.googlegroups.com...
> > Rod Pemberton wrote:
> > > "Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
> > > news:lisghz.drb@spenarnc.xs4all.nl...
> > > >
> > > > I have been thinking along these lines for the implementation
> > > > of a Forth chip that did not have branching, only calls.
> > > >
> > >
> > > You need to have branching.  If not, you cannot select between executing
> > > one block of code instead of another.  Calls are insufficient to provide
> > > choice.
> >
> > No. The simplest constructs I have seen involve ordinary calls and
> > conditional returns
> >
>
> Conditional returns include branching, or they wouldn't be labeled
> "conditional"...

Only if you use that as the definition of "branching". I was reading
it as the distinguishing feature of a jump as opposed to a call, not
the distinguishing feature of a choice of two or more control flow
paths as opposed to a single control flow path.

>
> > ... (or conditional calls and ordinary returns),
>
> Conditional calls include branching.  Ditto...
>
> You cannot change the control flow without a branch in one form or another.
> It's impossible.  Calls normally do not include a conditional, i.e., cannot
> provide choice.

Ditto...

But you still can, if you use dynamically computed code to "call" by
pushing onto an execution stack. More precisely, you don't change the
control flow as such - it's always what's on the execution stack - you
just change what gets there. And THAT means you don't need branching,
because you don't need to alter control flow (narrowly defined).
P.M.Lawrence.

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

#926

"P.M.Lawrence" <pml540114@gmail.com> wrote in message
news:a349301a-153e-4089-b90e-321b813d589b@q12g2000prb.googlegroups.com...
> Rod Pemberton wrote:
> > "P.M.Lawrence" <pml540114@gmail.com> wrote in message
> > news:c42dfd39-149d-4b0b-9c6e-9998b342a4bb@r4g2000prm.googlegroups.com...
> > > Rod Pemberton wrote:
> > > > "Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
> > > > news:lisghz.drb@spenarnc.xs4all.nl...
> > > > >
> > > > > I have been thinking along these lines for the implementation
> > > > > of a Forth chip that did not have branching, only calls.
> > > > >
> > > >
> > > > You need to have branching.  If not, you cannot select between
> > > > executing one block of code instead of another.  Calls are
> > > > insufficient to provide choice.
> > >
> > > No. The simplest constructs I have seen involve ordinary calls and
> > > conditional returns
> > >
> >
> > Conditional returns include branching, or they wouldn't be labeled
> > "conditional"...
>
> Only if you use that as the definition of "branching". I was reading
> it as the distinguishing feature of a jump as opposed to a call,
>

That's true, as long as the call is not conditional and one does not modify
the call's return address, which is what you implied when you just used
"call" here.  You just used "call" in that generic sense.

> not
> the distinguishing feature of a choice of two or more control flow
> paths as opposed to a single control flow path.
>

That's what branching is.  That's why I mentioned choice.

> But you still can, if you use dynamically computed code to "call" by
> pushing onto an execution stack. More precisely, you don't change the
> control flow as such - it's always what's on the execution stack - you
> just change what gets there. And THAT means you don't need branching,
> because you don't need to alter control flow (narrowly defined).
>

How do you "change what gets there"?  That requires branching.  It requires
a conditional to select a value, to change an offset, to perform an addition
or not.  All your example does, as well as that of the other examples
presented in Forth, is shift the location where the branching is occuring or
change the type of branching.  None of them eliminate branching.


Rod Pemberton

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

#931

> > But you still can, if you use dynamically computed code to "call" by
> > pushing onto an execution stack. More precisely, you don't change the
> > control flow as such - it's always what's on the execution stack - you
> > just change what gets there. And THAT means you don't need branching,
> > because you don't need to alter control flow (narrowly defined).
> >
> 
> How do you "change what gets there"?  That requires branching.  It
> > requires a conditional to select a value, to change an offset, to
> > perform an addition or not.  All your example does, as well as that of
> > the other examples presented in Forth, is shift the location where the
> > branching is occuring or change the type of branching.  None of them
> > eliminate branching. 

Maybe he was thinking in Intercal "COMES FROM" mode.

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

#941

In article <in458f$uq4$1@speranza.aioe.org>,
Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
>"P.M.Lawrence" <pml540114@gmail.com> wrote in message
>
>> But you still can, if you use dynamically computed code to "call" by
>> pushing onto an execution stack. More precisely, you don't change the
>> control flow as such - it's always what's on the execution stack - you
>> just change what gets there. And THAT means you don't need branching,
>> because you don't need to alter control flow (narrowly defined).
>>
>
>How do you "change what gets there"?  That requires branching.  It requires
>a conditional to select a value, to change an offset, to perform an addition
>or not.  All your example does, as well as that of the other examples
>presented in Forth, is shift the location where the branching is occuring or
>change the type of branching.  None of them eliminate branching.

No it doesn't.  Look for instance at Chuck Moore's F18 structure.
It can execute instructions from a port. The data that is put there
by some other processor gets executed.

>
>
>Rod Pemberton


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

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

#924

On Mar 29, 12:30 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> Conditional calls include branching.  Ditto...

This seems to be mostly semantic argument, an argument in which the
same words are used to point to different semantics and the same
semantics are named with different words.

But there also seems to be a bit of a substantive argument as well.


> You cannot change the control flow without a branch in one form or another.
> It's impossible.  Calls normally do not include a conditional, i.e., cannot
> provide choice.

"Calls do not normally" is not evidence for "calls cannot". A
conditional call implemented on a system without one would be
implemented using a conditional jump, but equally a conditional jump
on a system with only unconditional jumps could be implemented using a
conditional call.

If a "branch" is a conditional fork in the program flow, both
conditional jumps and conditions calls are "branches", if "branch" is
a synonym for "jump", obviously only the conditional and unconditional
jumps are branches.

And of course if you have only unconditional calls, jumps and returns,
you need either self-modifying code or at least one level of
indirection available in the calls or the jumps.

[toc] | [prev] | [standalone]

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

csiph-web