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

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

"Control structure mismatch" with simple if-else-then in SwiftForth

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

Contents

  "Control structure mismatch" with simple if-else-then in SwiftForth christopherdumas@gmail.com - 2017-06-14 07:22 -0700
    Re: "Control structure mismatch" with simple if-else-then in SwiftForth Cecil Bayona <cbayona@cbayona.com> - 2017-06-14 09:47 -0500
      Re: "Control structure mismatch" with simple if-else-then in SwiftForth "Elizabeth D. Rather" <erather@forth.com> - 2017-06-14 08:47 -1000
        Re: "Control structure mismatch" with simple if-else-then in SwiftForth hughaguilar96@gmail.com - 2017-06-16 11:22 -0700
          Re: "Control structure mismatch" with simple if-else-then in SwiftForth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-16 20:31 +0200
            Re: "Control structure mismatch" with simple if-else-then in SwiftForth "Elizabeth D. Rather" <erather@forth.com> - 2017-06-16 16:29 -1000
          Re: "Control structure mismatch" with simple if-else-then in SwiftForth Cecil Bayona <cbayona@cbayona.com> - 2017-06-16 15:38 -0500
            Re: "Control structure mismatch" with simple if-else-then in SwiftForth Julian Fondren <julian.fondren@gmail.com> - 2017-06-16 18:12 -0700
            Re: "Control structure mismatch" with simple if-else-then in SwiftForth peter.m.falth@gmail.com - 2017-06-17 15:10 -0700
              Re: "Control structure mismatch" with simple if-else-then in SwiftForth "Robert L." <No_spamming@noWhere_7073.org> - 2017-06-18 00:50 +0000
    Re: "Control structure mismatch" with simple if-else-then in SwiftForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-14 14:47 +0000
      Re: "Control structure mismatch" with simple if-else-then in SwiftForth "Robert L." <No_spamming@noWhere_7073.org> - 2017-06-14 16:16 +0000
        Re: "Control structure mismatch" with simple if-else-then in SwiftForth julian.fondren@endurance.com - 2017-06-14 09:34 -0700
        Re: "Control structure mismatch" with simple if-else-then in SwiftForth "HAA" <someone@microsoft.com> - 2017-06-16 10:20 +1000
          Re: "Control structure mismatch" with simple if-else-then in SwiftForth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 17:50 +0000
            Re: "Control structure mismatch" with simple if-else-then in SwiftForth Julian Fondren <julian.fondren@gmail.com> - 2017-06-17 12:11 -0700
    Re: "Control structure mismatch" with simple if-else-then in SwiftForth hum9 <obi65537@gmail.com> - 2017-06-14 18:12 +0300
      Re: "Control structure mismatch" with simple if-else-then inSwiftForth "Robert L." <No_spamming@noWhere_7073.org> - 2017-06-14 16:21 +0000
        Re: "Control structure mismatch" with simple if-else-then inSwiftForth Julian Fondren <julian.fondren@gmail.com> - 2017-06-14 09:37 -0700
          Re: "Control structure mismatch" with simple if-else-then inSwiftForth christopherdumas@gmail.com - 2017-06-14 10:48 -0700
    Re: "Control structure mismatch" with simple if-else-then in SwiftForth Julian Fondren <julian.fondren@gmail.com> - 2017-06-14 09:10 -0700
    Re: "Control structure mismatch" with simple if-else-then in SwiftForth The Beez <the.beez.speaks@gmail.com> - 2017-06-16 01:47 -0700
    Re: "Control structure mismatch" with simple if-else-then in SwiftForth "HAA" <someone@microsoft.com> - 2017-06-17 14:55 +1000

Page 1 of 2  [1] 2  Next page →

#60722 — "Control structure mismatch" with simple if-else-then in SwiftForth

I'm new to Forth and I've recently downloaded the Free Trial of SwiftForth, which I am exceedingly happy with, because it integrates with Emacs and is one of the nicest, most dynamic and interactive languages I've used. However, there is just a tiny problem: I can't get a simple if-else-then to work in the REPL. Here is my code so far:

0 2 rnd 1 = if 1+ else 2 * then       Control structure mismatch

It seems simple (and correct) to me. I'm sure its probably something simple that I'm missing, but there's no info on the internet on "Control structure mismatch"es. On a side note, this:

: TEST ( n -- ) dup 0= IF drop ELSE process THEN ;

seems to work, but this:

7 dup 0= IF drop ELSE process THEN

Does not. So I'm thinking that control structures don't work unless they are in definitions? Is this correct at all? I seem to vaguely remember something about this from the GForth manual. Thanks!

[toc] | [next] | [standalone]

#60724

On 6/14/2017 9:22 AM, christopherdumas@gmail.com wrote:
> I'm new to Forth and I've recently downloaded the Free Trial of SwiftForth, which I am exceedingly happy with, because it integrates with Emacs and is one of the nicest, most dynamic and interactive languages I've used. However, there is just a tiny problem: I can't get a simple if-else-then to work in the REPL. Here is my code so far:
> 
> 0 2 rnd 1 = if 1+ else 2 * then       Control structure mismatch
> 
> It seems simple (and correct) to me. I'm sure its probably something simple that I'm missing, but there's no info on the internet on "Control structure mismatch"es. On a side note, this:
> 
> : TEST ( n -- ) dup 0= IF drop ELSE process THEN ;
> 
> seems to work, but this:
> 
> 7 dup 0= IF drop ELSE process THEN
> 
> Does not. So I'm thinking that control structures don't work unless they are in definitions? Is this correct at all? I seem to vaguely remember something about this from the GForth manual. Thanks!
> 

IF THEN ELSE only works inside a definition, the looping words BEGIN END 
also work inside a definition only, it's not a serious limit once you 
get used to it.

-- 
Cecil - k5nwa

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

#60756

On 6/14/17 4:47 AM, Cecil Bayona wrote:
> On 6/14/2017 9:22 AM, christopherdumas@gmail.com wrote:
>> I'm new to Forth and I've recently downloaded the Free Trial of 
>> SwiftForth, which I am exceedingly happy with, because it integrates 
>> with Emacs and is one of the nicest, most dynamic and interactive 
>> languages I've used. However, there is just a tiny problem: I can't 
>> get a simple if-else-then to work in the REPL. Here is my code so far:
>>
>> 0 2 rnd 1 = if 1+ else 2 * then       Control structure mismatch
>>
>> It seems simple (and correct) to me. I'm sure its probably something 
>> simple that I'm missing, but there's no info on the internet on 
>> "Control structure mismatch"es. On a side note, this:
>>
>> : TEST ( n -- ) dup 0= IF drop ELSE process THEN ;
>>
>> seems to work, but this:
>>
>> 7 dup 0= IF drop ELSE process THEN
>>
>> Does not. So I'm thinking that control structures don't work unless 
>> they are in definitions? Is this correct at all? I seem to vaguely 
>> remember something about this from the GForth manual. Thanks!
> 
> IF THEN ELSE only works inside a definition, the looping words BEGIN END 
> also work inside a definition only, it's not a serious limit once you 
> get used to it.
> 

Yes, in general control structure words (loops and conditionals) are 
compile-only. There have been some Forths that make them work on the 
command line, but it never really caught on.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#60844

On Wednesday, June 14, 2017 at 11:47:31 AM UTC-7, Elizabeth D. Rather wrote:
> On 6/14/17 4:47 AM, Cecil Bayona wrote:
> > IF THEN ELSE only works inside a definition, the looping words BEGIN END 
> > also work inside a definition only, it's not a serious limit once you 
> > get used to it.
> 
> Yes, in general control structure words (loops and conditionals) are 
> compile-only. There have been some Forths that make them work on the 
> command line, but it never really caught on.

OpenForth is the only Forth system I've ever heard of that did this. 

OpenForth was one of Forth Inc.'s many failures that gave the entire Forth community a black-eye. Elizabeth Rather is personally to blame for this!

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

#60845

In article <54044c5a-088b-4d22-9cec-7d3d4908ff8e@googlegroups.com>,
 <hughaguilar96@gmail.com> wrote:
>On Wednesday, June 14, 2017 at 11:47:31 AM UTC-7, Elizabeth D. Rather wrote:
>> On 6/14/17 4:47 AM, Cecil Bayona wrote:
>> > IF THEN ELSE only works inside a definition, the looping words BEGIN END
>> > also work inside a definition only, it's not a serious limit once you
>> > get used to it.
>>
>> Yes, in general control structure words (loops and conditionals) are
>> compile-only. There have been some Forths that make them work on the
>> command line, but it never really caught on.
>
>OpenForth is the only Forth system I've ever heard of that did this.

ciforth is also one of those. It is pleasant for the -s option
and occassionaly during testing.

Elizabeth Rather probably has a better overview of what Forths
are around then  you

<SNIP>

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

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

#60879

On 6/16/17 8:31 AM, Albert van der Horst wrote:
> In article <54044c5a-088b-4d22-9cec-7d3d4908ff8e@googlegroups.com>,
>   <hughaguilar96@gmail.com> wrote:
>> On Wednesday, June 14, 2017 at 11:47:31 AM UTC-7, Elizabeth D. Rather wrote:
>>> On 6/14/17 4:47 AM, Cecil Bayona wrote:
>>>> IF THEN ELSE only works inside a definition, the looping words BEGIN END
>>>> also work inside a definition only, it's not a serious limit once you
>>>> get used to it.
>>>
>>> Yes, in general control structure words (loops and conditionals) are
>>> compile-only. There have been some Forths that make them work on the
>>> command line, but it never really caught on.
>>
>> OpenForth is the only Forth system I've ever heard of that did this.
> 
> ciforth is also one of those. It is pleasant for the -s option
> and occassionaly during testing.
> 
> Elizabeth Rather probably has a better overview of what Forths
> are around then  you

The other one I know of is Open Firmware, but there's not much of that 
around any more.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#60853

On 6/16/2017 1:22 PM, hughaguilar96@gmail.com wrote:
> On Wednesday, June 14, 2017 at 11:47:31 AM UTC-7, Elizabeth D. Rather wrote:
>> On 6/14/17 4:47 AM, Cecil Bayona wrote:
>>> IF THEN ELSE only works inside a definition, the looping words BEGIN END
>>> also work inside a definition only, it's not a serious limit once you
>>> get used to it.
>>
>> Yes, in general control structure words (loops and conditionals) are
>> compile-only. There have been some Forths that make them work on the
>> command line, but it never really caught on.
> 
> OpenForth is the only Forth system I've ever heard of that did this.
> 
> OpenForth was one of Forth Inc.'s many failures that gave the entire Forth community a black-eye. Elizabeth Rather is personally to blame for this!
> 

The name escapes me but there are other Forth that allow multi-line 
keyboard definitions and control loops outside a definition and it's a 
nice feature, illegal in ANS Forth since they only have compile behavior 
allowed.

-- 
Cecil - k5nwa

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

#60866

On Friday, June 16, 2017 at 3:38:53 PM UTC-5, Cecil - k5nwa wrote:
> 
> The name escapes me but there are other Forth that allow multi-line 
> keyboard definitions

What do you mean by 'multi-line keyboard definitions'? If it's the
obvious meaning, of a Forth definition entered interactively into a
Forth across multiple lines -- I can't think of a single
implementation that doesn't have that.

For even better support (the ability to edit prior lines after
entering them, without having to interrupt the definition and reenter
them), it'd be simplest to just offer a block editor.

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

#60924

On Friday, 16 June 2017 22:38:53 UTC+2, Cecil - k5nwa  wrote:
> On 6/16/2017 1:22 PM, hughaguilar96@gmail.com wrote:
> > On Wednesday, June 14, 2017 at 11:47:31 AM UTC-7, Elizabeth D. Rather wrote:
> >> On 6/14/17 4:47 AM, Cecil Bayona wrote:
> >>> IF THEN ELSE only works inside a definition, the looping words BEGIN END
> >>> also work inside a definition only, it's not a serious limit once you
> >>> get used to it.
> >>
> >> Yes, in general control structure words (loops and conditionals) are
> >> compile-only. There have been some Forths that make them work on the
> >> command line, but it never really caught on.
> > 
> > OpenForth is the only Forth system I've ever heard of that did this.
> > 
> > OpenForth was one of Forth Inc.'s many failures that gave the entire Forth community a black-eye. Elizabeth Rather is personally to blame for this!
> > 
> 
> The name escapes me but there are other Forth that allow multi-line 
> keyboard definitions and control loops outside a definition and it's a 
> nice feature, illegal in ANS Forth since they only have compile behavior 
> allowed.
> 
> -- 
> Cecil - k5nwa

It is definitely not illegal to make loops and conditionals work on 
the commandline. The interpretation semantic for a compile only word 
is undefined. You can define them as you like and the system will
still be ANS compliant (if it was it before of course).

I once looked at doing this in my systems but came to the conclusion
that it was far easier to just define a new word instead

Peter

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

#60935

On 6/17/2017, peter.m.falth@gmail.com wrote:

> It is definitely not illegal to make loops and conditionals work on 
> the commandline. The interpretation semantic for a compile only word 
> is undefined. You can define them as you like and the system will
> still be ANS compliant (if it was it before of course).
> 
> I once looked at doing this in my systems but came to the conclusion
> that it was far easier to just define a new word instead

See?  Forth is designed to make things easy for the implementor
of the language, not for the user of the language.

The user be damned.  That's the Forth philosophy.

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

#60726

christopherdumas@gmail.com writes:
>On a side note, this:
>
>: TEST ( n -- ) dup 0=3D IF drop ELSE process THEN ;
>
>seems to work, but this:
>
>7 dup 0=3D IF drop ELSE process THEN
>
>Does not. So I'm thinking that control structures don't work unless they ar=
>e in definitions?

Correct.

SwiftForth is not particularly strong on error reporting.

In Gforth 0.7 you get:

7 dup 0= IF drop ELSE process THEN   
:1: Interpreting a compile-only word
7 dup 0= >>>IF<<< drop ELSE process THEN

- 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 2017: http://www.euroforth.org/ef17/

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

#60740

On 6/14/2017, Anton Ertl wrote:

> > Does not. So I'm thinking that control structures don't work
>  unless they ar=
> > e in definitions?
> 
> Correct.

See?  Forth is not very interactive at all.

Control structures don't even work in the REPL.

It's amazing how many people say that they picked
Forth because it's interactive.

Why didn't they pick OCaml, Haskell, ML, Scheme, Lisp,
Ruby, Perl, Python, or Julia?

Abysmal ignorance and mindlessness.

Ruby:

if false then 0  else 88 end
    ==>88

Scheme:

#;1> (if #f 0 88)
88

OCaml:

# if false then 0 else 88 ;;
- : int = 88

Lisp:

* (if nil 0 88)

88

-- 
I wrote until my fingers were blue, over and over: "Political
Correctness is a religion."  I proved it and showed you why it is so
important that Political Correctness is a religion.
 --- Bob Whitaker

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

#60743

On Wednesday, June 14, 2017 at 11:16:14 AM UTC-5, Robert L. wrote:
> See?  Forth is not very interactive at all.

You can't copy and paste arbitrary code and have it work the same interactively
as it does non-interactively, or within a definition as it does outside of one.
This is the same with O'Caml (inferior interactive mode), Lisp (extra-powered
interactive mode), Perl (debugger or awkward interactive mode), Python
(obviously a massive pain interactively, but also has some interactive-only
features).

Erlang's an even better example: functions are awkward to define and the
preprocessor isn't available but you OS-like commands and special control over
variables.

Forth still feels more interactive than any of these, just due to the language.

An extra consideration is: how long can you comfortably stay at the repl? With
Forth the answer is often "forever", similar to a bash prompt. Features like
GILD and EMPTY (MARKER ANEW FORGET etc.) that you would rarely use in a
definition are part of why that's so.

> Abysmal ignorance and mindlessness.

This from "iterate in an ordered manner over the keys of a hash-table? That's
like trying to smell blue! The keys are unordered! DUH!"

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

#60798

Robert L. wrote:
> On 6/14/2017, Anton Ertl wrote:
>
> > > Does not. So I'm thinking that control structures don't work
> >  unless they ar=
> > > e in definitions?
> >
> > Correct.
>
> See?  Forth is not very interactive at all.
>
> Control structures don't even work in the REPL.
>
> It's amazing how many people say that they picked
> Forth because it's interactive.

Forth's interactivity revolves around testing and debugging
definitions.  It isn't, nor was it, meant to be a scripting language.
The world has enough of those.

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

#60918

"HAA" <someone@microsoft.com> writes:
>It isn't, nor was it, meant to be a scripting language.

Forth can be used nicely as a scripting language.  The implementation
needs some properties, though, that most Forth systems don't satisfy,
however.  The one that comes to my mind at the moment is: When used as
a scripting language, you must never fall back to interactive input
unless the program tells you to.  In particular, when there is an
error that is not caught by the program, you have to terminate the
process.

- 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 2017: http://www.euroforth.org/ef17/

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

#60919

On Saturday, June 17, 2017 at 12:55:43 PM UTC-5, Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >It isn't, nor was it, meant to be a scripting language.
>
> Forth can be used nicely as a scripting language.  The implementation
> needs some properties, though, that most Forth systems don't satisfy,
> however.  The one that comes to my mind at the moment is: When used as
> a scripting language, you must never fall back to interactive input
> unless the program tells you to.  In particular, when there is an
> error that is not caught by the program, you have to terminate the
> process.

There are CGI scripts, privileged scripts, and then normal scripts.
Falling back to interactive input is a problem for all three:

- a CGI script that accepts uncontrolled input is a remote back door
  to the system running it: POST request's postdata comes in on
  standard input to the CGI script, so someone could induce send a
  POST request that induces an error and then includes a payload of
  Forth commands to further hack the system.

- a privileged script that exposes Forth to uncontrolled commands is a
  privilege-escalation exploit on the system running it: normal users
  can get access to everything the Forth script had access to, rather
  than use it to perform the narrow tasks the code would've permitted.

- a normal script is frequently called not just by other users but by
  other scripts, and scripts rarely use 'timeout' or take other
  measures to control the commands they invoke. It's generally more
  like:

    mount /backup
    /opt/backup/bin/my-forth-backup-helper
    rsync -av --include /opt/backup/thanks-forth.list /home/ /backup/home/
    umount /backup

  instead of running, doing some quick backups, and then going away,
  this script could get stuck (though it probably shouldn't as input
  probably shouldn't be available, but people do weird stuff, maybe
  it's running in its own screen session so that admins can check up
  on it), then /backup is never unmounted, which can cause problems.

It's nice to have, but you definitely want to be able to control it
ever happening, and for it to never happen is the better default.
And although I really like traditional interactive Forth, where your
input is affirmed or questioned instead of prompted, a non-Forth
person suddenly given an interactive Forth may sit there for a while,
wondering why the program doesn't seem to be doing anything, until
they happen to hit enter.

Error handling's a big deal. Otherwise, I'm just sometimes annoyed
with startup overhead, and there was one time a Forth had some
terminal-UI tricks that didn't work well over ssh in slow terminals.

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

#60733

On 14.06.2017 17:22, christopherdumas@gmail.com wrote:
> I'm new to Forth and I've recently downloaded the Free Trial of SwiftForth, which I am exceedingly happy with, because it integrates with Emacs and is one of the nicest, most dynamic and interactive languages I've used. However, there is just a tiny problem: I can't get a simple if-else-then to work in the REPL. Here is my code so far:
> 
> 0 2 rnd 1 = if 1+ else 2 * then       Control structure mismatch
> 
> It seems simple (and correct) to me. I'm sure its probably something simple that I'm missing, but there's no info on the internet on "Control structure mismatch"es. On a side note, this:
> 
> : TEST ( n -- ) dup 0= IF drop ELSE process THEN ;
> 
> seems to work, but this:
> 
> 7 dup 0= IF drop ELSE process THEN
> 
> Does not. So I'm thinking that control structures don't work unless they are in definitions? Is this correct at all? I seem to vaguely remember something about this from the GForth manual. Thanks!
> 

Hi!

Keep stack balanced:

0 2 rnd ( n )
1 = ( f )
IF ( ) 1+ ELSE ( ) 2 * THEN

so when you do '1+' it have nothing on stack,
when '*' have just number '2' in stack and must have two numbers.

It have a very easy remedy, so let you fix it:)

Have a nice day,
hum9

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

#60741 — Re: "Control structure mismatch" with simple if-else-then inSwiftForth

On 6/14/2017, hum9 wrote:

> On 14.06.2017 17:22, christopherdumas@gmail.com wrote:
> > I'm new to Forth and I've recently downloaded the Free Trial of SwiftForth, which I am exceedingly happy with, because it integrates with Emacs and is one of the nicest, most dynamic and interactive languages I've used. However, there is just a tiny problem: I can't get a simple if-else-then to work in the REPL. Here is my code so far:
> > 
> > 0 2 rnd 1 = if 1+ else 2 * then       Control structure mismatch
> > 
> > It seems simple (and correct) to me. I'm sure its probably something simple that I'm missing, but there's no info on the internet on "Control structure mismatch"es. On a side note, this:
> > 
> > : TEST ( n -- ) dup 0= IF drop ELSE process THEN ;
> > 
> > seems to work, but this:
> > 
> > 7 dup 0= IF drop ELSE process THEN
> > 
> > Does not. So I'm thinking that control structures don't work unless they are in definitions? Is this correct at all? I seem to vaguely remember something about this from the GForth manual. Thanks!
> > 
> 
> Hi!
> 
> Keep stack balanced:
> 
> 0 2 rnd ( n )
> 1 = ( f )
> IF ( ) 1+ ELSE ( ) 2 * THEN
> 
> so when you do '1+' it have nothing on stack,
> when '*' have just number '2' in stack and must have two numbers.
> 
> It have a very easy remedy, so let you fix it:)
> 
> Have a nice day,
> hum9

That doesn't work at all.

IF ( ) 1+ ELSE ( ) 2 * THEN
:4: Interpreting a compile-only word
>>>IF<<< ( ) 1+ ELSE ( ) 2 * THEN

How does giving us code that is totally invalid
help us have a nice day?

You and Gavino are the ideal worshippers of Forth.

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

#60745 — Re: "Control structure mismatch" with simple if-else-then inSwiftForth

On Wednesday, June 14, 2017 at 11:16:14 AM UTC-5, Robert L. wrote:
> See?  Forth is not very interactive at all.

You can't copy and paste arbitrary code and have it work the same interactively
as it does non-interactively, or within a definition as it does outside of one.
This is the same with O'Caml (inferior interactive mode), Lisp (extra-powered
interactive mode), Perl (debugger or awkward interactive mode), Python
(obviously a massive pain interactively, but also has some interactive-only
features).

Erlang's an even better example: functions are awkward to define and the
preprocessor isn't available but you OS-like commands and special control over
variables.

Forth still feels more interactive than any of these, just due to the language.

An extra consideration is: how long can you comfortably stay at the repl? With
Forth the answer is often "forever", similar to a bash prompt. Features like
GILD and EMPTY (MARKER ANEW FORGET etc.) that you would rarely use in a
definition are part of why that's so.

> Abysmal ignorance and mindlessness.

This from "iterate in an ordered manner over the keys of a hash-table? That's
like trying to smell blue! The keys are unordered! DUH!"

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

#60748 — Re: "Control structure mismatch" with simple if-else-then inSwiftForth

Thanks everyone! And the reason I call Forth interactive is exactly as Julian says: I can stay in the repl forever, comfortably, without straining. In addition, the development loop (edit-compile-test-expreement-repeat) is really tight in it.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web