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

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

blocks and screens, tell your war stories

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

Contents

  blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 11:08 -0800
    Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 12:35 -1000
      Re: blocks and screens, tell your war stories empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-08 23:24 +0000
        Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 15:36 -0800
          Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 16:42 -1000
            Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 22:55 -0800
              Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:12 -1000
                Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 23:27 -0800
                  Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:41 -1000
                    Re: blocks and screens, tell your war stories Mark Wills <markwills1970@gmail.com> - 2015-01-09 02:21 -0800
                      Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-09 09:21 -1000
                        Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-09 13:07 -0800
                          Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-09 11:46 -1000
                        Re: blocks and screens, tell your war stories empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-01-11 13:58 +0000
                          Re: blocks and screens, tell your war stories "Alex McDonald" <blog@rivadpm.com> - 2015-01-13 14:37 +0000
        Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 18:30 -1000
          Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 20:47 -0800
            Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 20:49 -1000
              Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-09 13:02 -0800
    Re: blocks and screens, tell your war stories a.daniel.eliason@gmail.com - 2015-01-08 14:45 -0800
      Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 15:50 -0800
    Re: blocks and screens, tell your war stories Doug Hoffman <glidedog@gmail.com> - 2015-01-08 22:34 -0500
      Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 17:48 -1000
      Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-08 21:13 -0800
        Re: blocks and screens, tell your war stories "Elizabeth D. Rather" <erather@forth.com> - 2015-01-08 21:09 -1000
      Re: blocks and screens, tell your war stories Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-01-09 09:34 +0100
        Re: blocks and screens, tell your war stories Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2015-01-09 12:26 +0100
    Re: blocks and screens, tell your war stories Stan Barr <plan.b@bluesomatic.org> - 2015-01-09 08:10 +0000
      Re: blocks and screens, tell your war stories JennyB <jennybrien@googlemail.com> - 2015-01-09 03:36 -0800
    Re: blocks and screens, tell your war stories Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-09 14:14 +0000
      Re: blocks and screens, tell your war stories albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-09 15:25 +0000
        Re: blocks and screens, tell your war stories Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-09 20:20 +0000
          Re: blocks and screens, tell your war stories albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-09 20:47 +0000
          Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-09 13:08 -0800
            Re: blocks and screens, tell your war stories Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-09 21:34 +0000
              Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-10 14:00 -0800
                Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-11 11:45 -0800
      Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-09 13:28 -0800
        Re: blocks and screens, tell your war stories Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-10 22:41 +0000
          Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-10 18:49 -0800
            Re: blocks and screens, tell your war stories Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-11 09:27 +0000
              Re: blocks and screens, tell your war stories stephen@mpeforth.com (Stephen Pelc) - 2015-01-11 11:51 +0000
      Re: blocks and screens, tell your war stories Steve Graham <jsgrahamus@yahoo.com> - 2015-01-12 14:46 -0800
        Re: blocks and screens, tell your war stories Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2015-01-13 00:30 +0000
    Re: blocks and screens, tell your war stories Wolf Wejgaard <wejgaard@gmail.com> - 2015-01-12 06:32 -0800
    Re: blocks and screens, tell your war stories rickman <gnuarm@gmail.com> - 2015-01-12 20:35 -0500
      Re: blocks and screens, tell your war stories Mark Wills <markwills1970@gmail.com> - 2015-01-13 03:06 -0800
        Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-25 18:25 +0000
      Re: blocks and screens, tell your war stories Paul Rubin <no.email@nospam.invalid> - 2015-01-15 23:08 -0800
        Re: blocks and screens, tell your war stories m.a.m.hendrix@tue.nl - 2015-01-16 03:09 -0800
        Re: blocks and screens, tell your war stories albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-16 18:25 +0000
        Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-25 21:05 +0000
          Re: blocks and screens, tell your war stories Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-26 01:08 +0100
            Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-26 00:56 +0000
            Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-26 02:12 +0000
              Re: blocks and screens, tell your war stories albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-01-26 18:09 +0000
                Re: blocks and screens, tell your war stories lynx <rinkasu@kaze.void.null> - 2015-01-27 07:42 +0000
                  Re: blocks and screens, tell your war stories Mark Wills <markwills1970@gmail.com> - 2015-01-27 01:25 -0800
                  Re: blocks and screens, tell your war stories Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-01-29 10:20 +0000
            Re: blocks and screens, tell your war stories anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-01-26 12:10 +0000
              Re: blocks and screens, tell your war stories Bernd Paysan <bernd.paysan@gmx.de> - 2015-01-26 22:18 +0100
          Re: blocks and screens, tell your war stories Doug Hoffman <glidedog@gmail.com> - 2015-01-27 08:44 -0500
    Re: blocks and screens, tell your war stories "HAA" <someone@microsoft.com> - 2015-01-14 10:23 +1100
      Re: blocks and screens, tell your war stories hughaguilar96@gmail.com - 2015-01-13 19:47 -0800

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

#35705

hughaguilar96@gmail.com wrote:

> On Saturday, January 10, 2015 at 3:41:23 PM UTC-7, Paul E Bennett wrote:
>> I planned projects out using a number of triads to hold the essential
>> conceptual lexicon I needed. With n THRU-USING and n LOAD-USING I could
>> bring in components from other blocks (I have only ever used the blocks
>> in files between leaving tape storage until I switched to files proper
>> more recently).
> 
> That wasn't in Forth-83, and I don't think UR/Forth had it, or I would
> have used it --- what Forth was that?

If you had picked up on the historical context in my earlier postings you 
would realise that I was using MPE's products following my introductions 
with JB-Forth and BBC-Forth. All the MPE tools I used had LOAD-USING and 
THRU-USING as well as LOAD and THRU.
 
> There weren't any code-libraries available anyway, and I was hired to
> write MFX not general-purpose code, so it was a non-issue anyway.

Some of the useful utilities I used were in Forthwrite (the UK magazine). 
Might have been a couple in FD as well. Not a directly loadable library but 
it didn't take too long to enter and save them if they were useful.

I recall that FSL has been around a long time. We probably should have had a 
FUL (Forth Utilities Library) as well but it seems no-one thought to host 
that.
 
> I never even heard the term "triad" before this thread --- I never made
> paper print-outs, as MFX was growing too fast for anybody to bother with a
> print-out --- besides that, UR/Forth had good support for working with
> source-files. I never made print-outs in C either --- I haven't actually
> printed out a source-file since C64 days (the C64 screen was only 40 chars
> wide).

It was a useful planning unit (fits nicely on a page) whether you printed it 
out or not. Surprising how good your three times table can get to be in your 
head.
 
[%X]

> UR/Forth had a utility that would display all of the 1st lines of all of
> the screens in a range --- so, we would generally put a comment on the 1st
> line that described what words were in the screen to help find them ---
> there was no LOCATE, although I could have written it if I had had the
> time.

I think INDEX was a fairly standard utility and my first line was always an 
identifier for the lexicon, maybe with the word names, my initials and the 
saved date and time. 
 
> The big problem, was that I was hired to write MFX, not to write utility
> programs, so I really didn't have time to write code that wasn't directly
> related to the program. I think UR/Forth was the best Forth available in
> MS-DOS days, but it was still pretty primitive --- not the glitzy IDE you
> get with C or Turbo Pascal.

Sometimes, writing a small utility can save the drudgery of later code 
production. 

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#35709

On Sun, 11 Jan 2015 09:27:58 +0000, Paul E Bennett
<Paul_E.Bennett@topmail.co.uk> wrote:

>I recall that FSL has been around a long time. We probably should have had a 
>FUL (Forth Utilities Library) as well but it seems no-one thought to host 
>that.

So what is FLAG for?
  http://soton.mpeforth.com/flag/

And the Forth Foundation Library?

And ...

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#35753

Paul E Bennett wrote:
>
> Pheww!!!! you guys were busy yesterday!
>
> I only came to Forth in 1982. Previous to that, while I had dealt with
> languages like BASIC (various types), MUMPS and Fortran IV, I did most of my
> serious controller programming in machine code or, if I was lucky,
> Assembler. The Switches and Lamps entry method was very well known to me and
> I guess it was not too dissimilar to playing a piano.
>

Would never have imagined there was another programmer who had 
programmed in BASIC, MUMPS and Fortran.  What did you use these for?

While I've only fiddled with BASIC, I have spent decades with MUMPS and 
4 years with Fortran, using them mostly for medical information systems.


Steve Graham

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

#35754

Steve Graham wrote:

> Paul E Bennett wrote:
>>
>> Pheww!!!! you guys were busy yesterday!
>>
>> I only came to Forth in 1982. Previous to that, while I had dealt with
>> languages like BASIC (various types), MUMPS and Fortran IV, I did most of
>> my serious controller programming in machine code or, if I was lucky,
>> Assembler. The Switches and Lamps entry method was very well known to me
>> and I guess it was not too dissimilar to playing a piano.
>>
> 
> Would never have imagined there was another programmer who had
> programmed in BASIC, MUMPS and Fortran.  What did you use these for?

Never did much in MUMPS. I think it was a small expenses accounting aid but 
I did a better one in Fortran. In Basic I dealt with some controls for a 
radio transceiver (setting synthesizer frequency and some display 
functions). Other things in Fortran iV related to orbit calculations for 
some AMSAT vehicles (knowing when they were going to be in range).
 
> While I've only fiddled with BASIC, I have spent decades with MUMPS and
> 4 years with Fortran, using them mostly for medical information systems.

We had similar time on Fortran, but I gave up on MUMPS within a month. BASIC 
and Machine Code became my mainstay languages until 1982.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#35750

Am Donnerstag, 8. Januar 2015 20:08:23 UTC+1 schrieb Paul Rubin:
> I wonder if those of you who developed Forth programs in the era of
> blocks and screens could say what it was like, compared to today's Forth
> environments.
> 
> What Forth system did you use?  What code editor?  What hardware?
> 
> Did you use the scheme of having a comment screen for each code screen?
> 
> What kind of planning process did you use, before you started coding?
> E.g. did you write a (maybe informal) code glossary ahead of time?
> 
> Did you feel constrained by the 64 char lines, especially if you used
> stack comments?  Were stack comments expected then the way they are now?
> 
> How did you debug?  Was it common for the whole machine to lock up if
> your program had a bug that clobbered memory?  What did you do when that
> happened?
> 
> How did development time for a Forth program compare to writing
> something similar in BASIC, for the problems BASIC could handle?  I know
> that Forth could do a lot of things that were essentially impossible in
> BASIC, but I'm not asking about those.

I did my first Forth job in FORTH-11 on a PDP-11 with the RT-11 operating system. After a week with the block editor I wrote a file interface and used the RT-11 Editor for the rest of the job. I stayed with files until the projects grew to thousands of words. There was still as much space as I wanted, but keeping track of the many words became a problem. I needed a better structure than files and directories, a structure that was integrated in the development system.

I had a fresh look at blocks and found a solution that made me markedly more productive. A solution that gives you both space and structure: One Word Per Block. Just one word/definition! Try it!

With one-word-per-block I had sufficient space for the definition and a comment as well as for revision notes. I could move the word/block easily to a better place in the program, insert new words/blocks and generally refactor without pain.

Each block had the word's name and meta information like date and revision number in line 0, the traditional comment line of blocks.

I added a block-list editor which interactively displayed the blocks (Index, line 0 of each) and provided commands to restructure the program. It was all easy and simple and very productive. Thanks to Forth.

I suppose other Forth programmers have done this too, I would have loved to learn it earlier.

--
Wolf Wejgaard
http://holonforth.com

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

#35756

I haven't looked at this entire thread to see if the GA development 
system is discussed much.  Has anyone taken a look at that?  I know it 
uses blocks and screens.  When I tried to see how to use it they seemed 
to have a very intricate system with multiple levels/layers that, 
frankly, was beyond me on the first pass.  It was one of the most 
convoluted things I have seen.

-- 

Rick

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

#35773

On Tuesday, 13 January 2015 01:35:52 UTC, rickman  wrote:
> I haven't looked at this entire thread to see if the GA development 
> system is discussed much.  Has anyone taken a look at that?  I know it 
> uses blocks and screens.  When I tried to see how to use it they seemed 
> to have a very intricate system with multiple levels/layers that, 
> frankly, was beyond me on the first pass.  It was one of the most 
> convoluted things I have seen.
> 
> -- 
> 
> Rick

I haven't looked at it. For a long, it wouldn't even run on most PCs.
There is a version for Windows now, but the "cost" of getting to grips
with it seems to be just too high for me. I'd only be a tyre-kicker
anyway.

I think Polyforth can (now) be used as a an alternative means of 
programming the GA devices (to paying customers).

Lastly, James Bowman from excamera developed a system in either Perl
or Python that allowed code to be written in standard text files and
uploaded to the nodes on the GA chips. He did a presentation to SVFIG
about it. It's on the web somewhere.

Mark

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

#36014

In <f0eef517-b4a9-43b0-9872-3f0ccbe73eb8@googlegroups.com> Mark Wills <markwills1970@gmail.com> writes:

>I haven't looked at it. For a long, it wouldn't even run on most PCs.

I think you're talking about the original "native" colorForth.

The GA system (ArrayForth) for Windows seems to run on virtually all
Windows PCs just fine, although the "native" version is probably as
fickle as the original colorForth.

>I think Polyforth can (now) be used as a an alternative means of 
>programming the GA devices (to paying customers).

polyForth is included with the ArrayForth download on the GA website.
As is eForth.  Full source included.  They were not sold
separately by GA.

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

#35840

rickman <gnuarm@gmail.com> writes:
> I haven't looked at this entire thread to see if the GA development
> system is discussed much.  Has anyone taken a look at that?  I know it
> uses blocks and screens.  When I tried to see how to use it they
> seemed to have a very intricate system with multiple levels/layers
> that, frankly, was beyond me on the first pass.  It was one of the
> most convoluted things I have seen.

I've looked at it but not tried it.  It was one of the inspirations for
my posting this thread.  I assume its use of blocks is traditional.  The
separation of edit time from compile time (i.e. with significant
processing done at edit time) seems to come from colorforth.  The whole
thing has an interesting steampunk feel, it seems to me.  Why on earth
does anyone with a modern PC tokenize the input at edit time in order to
save at most a few milliseconds on compilation?  

I do miss Jeff Fox who may have originated that scheme, in his Aha
system.  And I just don't understand how anyone could get anything done
in colorforth, much less write something like OKAD.

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

#35842

On Friday, January 16, 2015 at 8:08:05 AM UTC+1, Paul Rubin wrote:
[..]
> And I just don't understand how anyone could get anything done
> in colorforth, much less write something like OKAD.

That is not so strange at all. Think how you would design your personal tools (because you had to), for a very specific and well-defined purpose, for a very specific customer (you), for very specific hardware (the system you use yourself), and without any need for documentation. You might throw in a weird sense of humor that makes fun of archeologists trying to dissect your work in the future.

I have a colorforth feeling when working with git on the command line and trying to make sense of the documentation, i.e. my leg is being pulled :-)

-marcel

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

#35847

In article <87zj9jmcdo.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
<SNIP>
>
>I do miss Jeff Fox who may have originated that scheme, in his Aha
>system.  And I just don't understand how anyone could get anything done
>in colorforth, much less write something like OKAD.

With perseverance and much tweaking Leon and I got something going in
Seaforth (the parallel sieve).
It never worked on colorforth. So I'm with you.

I guess I would write a decent development system upfront, if I thought
the GA144 was worth it. I don't.

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]

#36020

In <87zj9jmcdo.fsf@jester.gateway.pace.com> Paul Rubin <no.email@nospam.invalid> writes:

>I assume its use of blocks is traditional. The separation of edit time
>from compile time (i.e. with significant processing done at edit time)
>seems to come from colorforth.

Yes, the block use is pretty standard as Forths go.  And yes, it is directly
descended from colorForth.

>The whole thing has an interesting steampunk feel, it seems to me.  Why
>on earth does anyone with a modern PC tokenize the input at edit time
>in order to save at most a few milliseconds on compilation?  

It wasn't really designed for modern PCs.  It was designed for
considerably simpler targets, with the idea that code overlays could be
fully retained in source form and yet still added/removed "on the fly"
to make practical use of target memory.

Personally, I think the whole idea of pre-parsing is brilliant.  By
tokenizing at edit time, the compiler becomes much simpler, as there is
no further need to parse source code at that stage and do input number
conversion and whatnot.  If the programmer said this was a number at
edit time, then the compiler "just does" and will compile it as a
literal--no questions asked!  In a way, it extends the argument made
years ago against "state smart" words, making it the full responsibility
of the programmer to be aware of what he/she is doing rather than
leaving it to a "smart" compiler to figure out his/her intentions
through assumptions and ASCII parsing rules each time code is loaded.

A "few milliseconds" gain may seem silly on a single, powerful PC
loading code at the leisure of one user.  But if we're loading code on
say 10, 100, 1000, 10000+ targets simultaneously (the "massively
distributed" vision that appears to be hinted at by the GA144), that hit
each time--considered in aggregate--starts looking like a terrific
waste.  Waste that could have been resolved entirely at *edit* time at
one user's leisure, rather than multiplied out & repeated those tens,
hundreds, thousands, millions+ of times.

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

#36022

lynx wrote:
> A "few milliseconds" gain may seem silly on a single, powerful PC
> loading code at the leisure of one user.  But if we're loading code on
> say 10, 100, 1000, 10000+ targets simultaneously (the "massively
> distributed" vision that appears to be hinted at by the GA144), that hit
> each time--considered in aggregate--starts looking like a terrific
> waste.  Waste that could have been resolved entirely at *edit* time at
> one user's leisure, rather than multiplied out & repeated those tens,
> hundreds, thousands, millions+ of times.

Jeff Fox' Aha went a bit further, also taking the symbol lookup out of the 
compilation time.  It's pretty obvious that a symbol table in the editor is 
an excellent idea: Not only does it save compile time, it also allows the 
editor to check for typos - essentially, you can't enter words which aren't 
in the editor's symbol table (unless you are just defining them).

The concept of an IDE implies that the editor knows a lot about the actual 
program, perhaps even more than the compiler.  If you have a symbol table in 
the editor, you could just as well have all the stack effects in that symbol 
table, and your editor could calculate the stack effect of the definition 
you are just typing, making it easier to get it right without even compiling 
the definition - it is just tokenized and stack analyzed.  Further aid could 
be a symbolic display of the current stack on the cursor position.  If you 
want the real one on example values, you need the Forth system, but for 
symbolic ones, the editor could do it.

IMHO you should rather view this as integration of the editor and the 
compiler, and the benefits are obvious.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

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

#36023

In <ma40gj$507$1@dont-email.me> Bernd Paysan <bernd.paysan@gmx.de> writes:

>Jeff Fox' Aha went a bit further, also taking the symbol lookup out of the 
>compilation time.  It's pretty obvious that a symbol table in the editor is 
>an excellent idea: Not only does it save compile time, it also allows the 
>editor to check for typos - essentially, you can't enter words which aren't 
>in the editor's symbol table (unless you are just defining them).

Yes, this just makes good sense.  A lot of people don't seem to be aware
of the compile & run time penalties of error-checking.

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

#36024

In <ma40gj$507$1@dont-email.me> Bernd Paysan <bernd.paysan@gmx.de> writes:

>The concept of an IDE implies that the editor knows a lot about the actual 
>program, perhaps even more than the compiler.  If you have a symbol table in 
>the editor, you could just as well have all the stack effects in that symbol 
>table, and your editor could calculate the stack effect of the definition 
>you are just typing, making it easier to get it right without even compiling 
>the definition - it is just tokenized and stack analyzed.  Further aid could 
>be a symbolic display of the current stack on the cursor position.  If you 
>want the real one on example values, you need the Forth system, but for 
>symbolic ones, the editor could do it.
>
>IMHO you should rather view this as integration of the editor and the 
>compiler, and the benefits are obvious.

I think this what I really appreciate about colorForth & ArrayForth--the
tight working relationship between the editor and compiler.  As you
point out, this integration can be taken even further.

(Sorry for offering two follow-ups. I hacked off the bottom of my first
reply.)

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

#36043

In article <ma47pq$dho$1@reader1.panix.com>,
lynx  <rinkasu@kaze.void.null> wrote:
>In <ma40gj$507$1@dont-email.me> Bernd Paysan <bernd.paysan@gmx.de> writes:
>
>>The concept of an IDE implies that the editor knows a lot about the actual
>>program, perhaps even more than the compiler.  If you have a symbol table in
>>the editor, you could just as well have all the stack effects in that symbol
>>table, and your editor could calculate the stack effect of the definition
>>you are just typing, making it easier to get it right without even compiling
>>the definition - it is just tokenized and stack analyzed.  Further aid could
>>be a symbolic display of the current stack on the cursor position.  If you
>>want the real one on example values, you need the Forth system, but for
>>symbolic ones, the editor could do it.
>>
>>IMHO you should rather view this as integration of the editor and the
>>compiler, and the benefits are obvious.
>
>I think this what I really appreciate about colorForth & ArrayForth--the
>tight working relationship between the editor and compiler.  As you
>point out, this integration can be taken even further.

Yeah, it looks just like Eclipse. About equally useful.

>
>(Sorry for offering two follow-ups. I hacked off the bottom of my first
>reply.)

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]

#36069

In <54c682f0$0$6861$e4fe514c@dreader36.news.xs4all.nl> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:

>In article <ma47pq$dho$1@reader1.panix.com>,
>lynx  <rinkasu@kaze.void.null> wrote:
>>I think this what I really appreciate about colorForth & ArrayForth--the
>>tight working relationship between the editor and compiler.  As you
>>point out, this integration can be taken even further.

>Yeah, it looks just like Eclipse. About equally useful.

Appearance aside, cF/AF are extremely well considered interfaces for the
environments they were designed for.  There are ideas here that even
"useful" (by your definition) language environments could safely employ
in their own designs with quite a few benefits.

Eclipse, OTOH, is a lumbering disaster conjured by marketing types and
pitched as Everyone's IDE.  I agree that Eclipse is not useful.

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

#36070

On Tuesday, 27 January 2015 07:42:57 UTC, lynx  wrote:
> In <54c682f0$0$6861$e4fe514c@dreader36.news.xs4all.nl> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> 
> >In article <ma47pq$dho$1@reader1.panix.com>,
> >lynx  <rinkasu@kaze.void.null> wrote:
> >>I think this what I really appreciate about colorForth & ArrayForth--the
> >>tight working relationship between the editor and compiler.  As you
> >>point out, this integration can be taken even further.
> 
> >Yeah, it looks just like Eclipse. About equally useful.
> 
> Appearance aside, cF/AF are extremely well considered interfaces for the
> environments they were designed for.  There are ideas here that even
> "useful" (by your definition) language environments could safely employ
> in their own designs with quite a few benefits.
> 
> Eclipse, OTOH, is a lumbering disaster conjured by marketing types and
> pitched as Everyone's IDE.  I agree that Eclipse is not useful.

It's a very useful (and free) development environment for Java and
Android developers. I agree that it's bloated, but you get a lot for
your money!

I tend to use NetBeans for Java, but only because that's the environment
that I got used. It's just as bloated, but again, very capable.

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

#36112

On 27/01/2015 07:42, lynx wrote:
> Eclipse, OTOH, is a lumbering disaster conjured by marketing types and
> pitched as Everyone's IDE.  I agree that Eclipse is not useful.

Bollocks, I use it all the time for Forth programmming and other things. 
I may only use 10% of it but so what, the bloat doesn't matter on a desktop.

-- 
Gerry

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

#36034

Bernd Paysan <bernd.paysan@gmx.de> writes:
>IMHO you should rather view this as integration of the editor and the 
>compiler, and the benefits are obvious.

The drawback is similar as with any other IDE: Programmers used to a
different editor (i.e., initially all of them) will be reluctant to
switch to your integrated editor.

- 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 2014: http://www.euroforth.org/ef14/

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

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

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

csiph-web