Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #33379 > unrolled thread
| Started by | Walter Banks <walter@bytecraft.com> |
|---|---|
| First post | 2014-09-16 11:22 -0400 |
| Last post | 2014-09-19 02:53 -0700 |
| Articles | 20 on this page of 230 — 25 participants |
Back to article view | Back to comp.lang.forth
Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 11:22 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 11:41 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:20 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 13:39 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:11 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-16 17:24 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:58 -0400
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 08:47 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 14:41 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-16 18:55 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 14:33 -1000
Re: Metrics on stack usage barrym95838@yahoo.com - 2014-09-16 18:30 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-16 15:44 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 13:22 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 09:18 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:39 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:41 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-16 16:11 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 16:34 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-17 17:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 07:21 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 10:01 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 07:42 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 14:46 +0000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-19 08:09 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 03:41 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:31 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 14:53 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 16:44 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 15:52 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-09-30 00:08 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 04:26 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:48 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 12:26 -0500
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 17:07 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-17 07:20 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:03 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:40 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-19 09:56 -0400
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 10:54 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-22 15:13 +0000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 13:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 11:13 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-22 21:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 16:57 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-23 00:59 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-22 19:53 -1000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 03:48 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-23 16:01 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 08:07 -1000
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-09-23 22:11 +0100
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-23 16:22 -0500
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-23 11:28 -1000
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-24 11:56 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:52 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:00 -0400
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 17:04 -0400
Re: Metrics on stack usage Michael Barry <barrym95838@yahoo.com> - 2014-09-24 16:08 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 12:23 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 19:33 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:02 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-25 18:48 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 16:58 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-24 16:02 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-24 19:14 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 10:15 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 13:54 -1000
Typing, was [Re: Metrics on stack usage] "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-24 21:07 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 15:25 -1000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-24 18:43 -0700
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-09-24 16:08 -1000
Re: Typing, was [Re: Metrics on stack usage] Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:11 -0700
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-10-01 09:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:38 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-29 17:53 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-30 09:13 +0000
Re: Typing, was [Re: Metrics on stack usage] Paul Rubin <no.email@nospam.invalid> - 2014-09-30 22:37 -0700
Re: Typing, was [Re: Metrics on stack usage] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-03 16:10 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 08:42 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 14:59 -0400
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-03 09:07 -1000
Re: Typing, was [Re: Metrics on stack usage] rickman <gnuarm@gmail.com> - 2014-10-03 17:28 -0400
Re: Typing, was [Re: Metrics on stack usage] Howerd <howerdo@yahoo.co.uk> - 2014-10-04 11:15 -0700
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-07 23:37 +0000
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-07 15:07 -1000
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-12 03:03 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-12 10:42 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-13 00:26 +0200
Re: Typing, was [Re: Metrics on stack usage] "Elizabeth D. Rather" <erather@forth.com> - 2014-10-11 19:30 -1000
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-08 03:42 +0200
Re: Typing, was [Re: Metrics on stack usage] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-08 02:46 -0500
Re: Typing, was [Re: Metrics on stack usage] Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 00:43 +0200
Re: Typing, was [Re: Metrics on stack usage] Marc Olschok <nobody@nowhere.invalid> - 2014-10-11 23:32 +0000
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 18:45 +0000
Re: Typing, was [Re: Metrics on stack usage] "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-25 09:22 +0200
Re: Typing, was [Re: Metrics on stack usage] Kaz Kylheku <kaz@kylheku.com> - 2014-09-28 17:09 +0000
Re: Metrics on stack usage Kaz Kylheku <kaz@kylheku.com> - 2014-09-25 01:43 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:15 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 10:19 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 01:06 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 04:25 -0400
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 03:15 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-25 14:43 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-25 22:23 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-29 13:42 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 14:23 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 10:14 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 17:10 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-29 12:31 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-29 21:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 01:34 +0200
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-05 03:29 -0500
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-05 13:46 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-05 15:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 03:44 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 00:12 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-05 18:56 -1000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-06 01:34 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-06 19:57 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-07 04:49 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-07 16:21 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 05:43 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-09 02:35 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-08 21:48 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 05:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 01:07 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-10 21:27 +0200
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 00:01 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 19:59 -0400
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 03:33 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:30 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-11 15:22 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-11 22:24 -0400
Loading libraries (was: Metrics on stack usage) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-11 09:23 +0000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:11 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-10 16:36 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-10-10 22:38 -0400
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 23:39 -0400
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-11 12:25 +0100
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-07 07:52 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-25 00:34 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-01 23:26 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-01 16:15 -0700
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-01 21:57 -1000
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 01:20 -0700
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-02 15:59 +0200
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-10-02 19:29 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-03 15:03 +0000
Re: Metrics on stack usage Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-05 02:27 +0200
Re: Metrics on stack usage Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-10-05 09:22 +0100
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-23 19:36 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-24 13:40 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-16 17:06 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 07:43 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-16 15:04 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-16 09:34 -1000
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:30 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-17 12:42 -1000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-18 11:33 +0000
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-18 11:53 -1000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-19 01:14 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 03:32 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:41 +0000
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-19 12:14 -0500
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:41 +0000
Re: Metrics on stack usage mhx@iae.nl - 2014-09-19 12:31 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 12:59 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:05 +0000
Re: Metrics on stack usage Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-09-21 07:44 +0200
Re: Metrics on stack usage Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-09-17 11:10 +0200
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-17 14:20 -0700
Re: Metrics on stack usage Walter Banks <walter@bytecraft.com> - 2014-09-17 17:41 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-17 16:44 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-18 10:26 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-19 00:12 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-18 19:15 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-18 17:14 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:59 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-19 12:20 -0700
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-20 09:04 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-29 18:08 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-30 04:33 -0400
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 19:30 -0700
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-30 11:24 +0000
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-09-30 10:55 -0700
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-09-30 18:39 -0700
Re: Metrics on stack usage Mark Wills <markwills1970@gmail.com> - 2014-10-01 01:44 -0700
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-01 03:57 -0500
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-01 18:45 -0700
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-02 07:53 -0400
Re: Metrics on stack usage G Smith <do.not.use@tectimco.com> - 2014-10-02 13:22 +0100
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-10-02 08:36 -1000
Re: Metrics on stack usage hughaguilar96@yahoo.com - 2014-10-02 15:34 -0700
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-19 12:08 +0000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 18:58 -0400
Re: Metrics on stack usage "Elizabeth D. Rather" <erather@forth.com> - 2014-09-19 13:28 -1000
Re: Metrics on stack usage "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-09-19 19:57 -0400
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-21 13:09 +0000
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-20 13:27 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 08:04 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 08:55 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:01 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:15 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:34 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 06:57 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 07:31 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:04 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:17 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 18:49 -0400
Re: Metrics on stack usage Paul Rubin <no.email@nospam.invalid> - 2014-09-21 15:57 -0700
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 19:47 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-22 02:58 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:28 -0400
Re: Metrics on stack usage albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-09-21 11:24 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:55 -0400
Re: Metrics on stack usage Coos Haak <chforth@hccnet.nl> - 2014-09-20 14:57 +0200
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:22 +0000
Re: Metrics on stack usage anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-09-20 15:25 +0000
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 15:08 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-20 17:38 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-20 19:19 -0400
Re: Metrics on stack usage Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-09-21 03:35 -0500
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-21 07:00 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 08:54 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 03:26 -0400
Re: Metrics on stack usage Celeros <kerneels@gmail.com> - 2014-09-22 10:03 +0200
Re: Metrics on stack usage rickman <gnuarm@gmail.com> - 2014-09-22 05:29 -0400
Re: Metrics on stack usage stephen@mpeforth.com - 2014-09-19 02:53 -0700
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-09-25 10:02 +0000 |
| Message-ID | <5423e82d$0$6903$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #33543 |
In article <905a62e7-20e8-4a3a-ac05-0a9f3ef2a903@googlegroups.com>, <hughaguilar96@yahoo.com> wrote: >On Wednesday, September 24, 2014 4:56:21 AM UTC-7, Albert van der Horst wrote: >> I would have the rules: >> casts in c are not allowed. Exceptions must be run by the Senior >Programmer >> (that's me). >> >> Warnings must be collected. A separate document explains why the >code gives those. >> Regression tests are run against those warning files. > >You have previously represented yourself as being a Wikipedia editor: >https://groups.google.com/forum/#!topicsearchin/comp.lang.forth/lc53/comp.lang.forth/qqlp1gZnVic > >Now you represent yourself as being a Senior Programmer. These >categories are mutually exclusive --- you can't be both a Wikipedia >editor and a Senior Programmer --- Wikipedia editors are just trolls >pretending to be experts on everything, whereas a Senior Programmer has >to actually know something about programming. > >Also, I would appreciate it if you did not refer to programmers as >"douche bags" on comp.lang.forth --- that is just disgusting --- go back >to Wikipedia where you belong! Thanks for a good laugh! (That what's you're not in my kill file.) 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]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-09-25 18:48 -0700 |
| Message-ID | <cd6e78c6-f09f-4b29-8928-abf056cc96fa@googlegroups.com> |
| In reply to | #33563 |
On Thursday, September 25, 2014 3:02:23 AM UTC-7, Albert van der Horst wrote: > In article <905a62e7-20e8-4a3a-ac05-0a9f3ef2a903@googlegroups.com>, > <hughaguilar96@yahoo.com> wrote: > >On Wednesday, September 24, 2014 4:56:21 AM UTC-7, Albert van der Horst wrote: > >> I would have the rules: > >> casts in c are not allowed. Exceptions must be run by the Senior > >Programmer > >> (that's me). > > >> Warnings must be collected. A separate document explains why the > >code gives those. > >> Regression tests are run against those warning files. > > >You have previously represented yourself as being a Wikipedia editor: >https://groups.google.com/forum/#!topicsearchin/comp.lang.forth/lc53/comp.lang.forth/qqlp1gZnVic > > >Now you represent yourself as being a Senior Programmer. These > >categories are mutually exclusive --- you can't be both a Wikipedia > >editor and a Senior Programmer --- Wikipedia editors are just trolls > >pretending to be experts on everything, whereas a Senior Programmer has > >to actually know something about programming. > > >Also, I would appreciate it if you did not refer to programmers as > >"douche bags" on comp.lang.forth --- that is just disgusting --- go back > >to Wikipedia where you belong! > > Thanks for a good laugh! > (That what's you're not in my kill file.) I that thread that I mentioned, you repeatedly posted non-working code that you claimed to be my LC53 function from my novice package, and offered this as proof that my LC53 did not work and should be removed from the Wikipedia article on Linear-Congruential prngs. None of that code was mine --- you just made that stuff up. Considering that LC53 is a one-line function, these weren't honest mistakes on your part --- you were lying. You're a troll! Now you describe this as "a good laugh" --- this is troll behavior --- you get your jollies out of lying about people on the internet to get an emotional response out of them. You are also grossly vulgar, describing programmers as "douche bags" --- this is also typical troll behavior --- in terms of vulgar language, you're the new Passaniti (he would speak openly about masturbation and gay group sex on comp.lang.forth). You demanded that I remove all mention of my novice package from Wikipedia. I complied (I don't actually care about Wikipedia, and have no desire to get into an edit war). You continued to attack my code however, so you didn't really care about the integrity of the Wikipedia article --- you were just attacking me because it was a good laugh for you, and you were going to continue to do so for as long as you could continue to get some response out of your attack. Here is a quote from that thread: On Tuesday, November 26, 2013 7:21:20 AM UTC-7, Albert van der Horst wrote: > In article <ivudnSVTlIfurQnPnZ2dnUVZ_gSdnZ2d@supernews.com>, > Elizabeth D. Rather <erather@forth.com> wrote: > >On 11/25/13 9:32 AM, Albert van der Horst wrote: > >> Hugh suggests that the only difference with his LC53 is that > >> Anton Ertl and Elizabeth Rather inspire more confidence than he does. > > >Thank you, but I never wrote a random number generator and don't intend > >to! I've been blessed by having some brilliant programmers around me. > >But most of FORTH, Inc.'s customers aren't in fields where a strong RNG > >is a necessity, so we keep it simple. > > Hugh can learn something from this. > > Why does this answer inspire confidence? > 1. Offloading work to experts > 2. A conscious decision about quality > 3. polite, well formulated and to the point This is why I consider ANS-Forth to be a cult. You tell blatant lies about outsiders such as myself. Your lies are blatant because anybody can download my novice package and see that what you claim to be my code is not what I have in the novice package. Bernd Payson did point this out to you, but you just told some new lies. So long as you brown-nose Elizabeth Rather however, everybody overlooks the fact that you are a liar --- being a member of the ANS-Forth cult is all about loyalty to Elizabeth Rather --- lying about non-members is not only accepted, but expected. You claim to be a "Senior Programmer" and all the other cult members cheerfully agree --- being in the cult is all about supporting each other's fantasies --- Elizabeth Rather even claims to work for NASA. You imagine yourself as a Senior Programmer giving the feebs permission to use various language features --- this is not actually how programming shops work though --- this is just your fantasy. This is the same fantasy that Passaniti had --- he would often say that if he were the Senior Programmer and I was one of his trainees, he would require me to trash my novice package and rewrite my code in such-and-such way... Passaniti was going great guns here on comp.lang.forth, and getting praised to the sky by Elizabeth Rather, and then he suddenly disappeared. He was enjoying himself so much that I can't believe he voluntarily left. Maybe he is in jail or in a psychiatric facility, and they don't allow him access to the internet. It is also possible that he found a new "husband" who keeps him on a short leash and does not allow him to play on the internet. In any case, he is gone. He was really Elizabeth Rather's pet --- now that he is gone, the question is who will be her new pet? --- in that thread mentioned above, I think that you were applying for the job. So, what do you say Queen Bee? --- is Albert your new pet, or do you prefer Alex or Rickman? --- there are so many exceptional candidates, you must be having a difficult time deciding...
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-24 16:58 -0400 |
| Message-ID | <lvvb9i$5fp$1@dont-email.me> |
| In reply to | #33541 |
On 9/24/2014 7:56 AM, Albert van der Horst wrote: > In article <c8e60pFd823U1@mid.individual.net>, > Paul E Bennett <Paul_E.Bennett@topmail.co.uk> wrote: >> Elizabeth D. Rather wrote: >> >> [%X] >> >>> A number of years ago we developed a Forth to use in courses that >>> checked all kinds of things: inappropriate fetch/store operators, bounds >>> on arrays, incomplete structures, illegal addresses, etc. It was a lot >>> of work, but a fun project. As a teaching tool, it was useless, though. >>> Students still called the instructor over to help figure out what was >>> wrong. Instructor would say, "See that message?" and the student would >>> say, "Oh, yeah, I'm getting a lot of messages, but I just ignore them. >>> Why doesn't this work?" >> >> For those that follow such bloggings, we have heard from Jack Ganssle, Phil >> Koopman and Chris Hills that the one thing you do not do is ignore warnings >> and error messages. These warnings and error messages should all be >> investigated and eliminated, usually by changing your code to behave >> properly. > > I'm all with you, but there is a catch. Some employers wants to run the > code without warnings and the employees duely comply. > Now suppose we have the following in C: > " > int a; > long int b; > ... > a = b; > " > > The compiler gives the warning: > possible loss of precision > (which should be : possible run time overflow error) > > This code is mine, and it is perfectly ligit. I needed a larger intermediate > result. > > Now those douche back's are going to change that into > a = (int) b; > so that helpfully the next generation of programmers doesn't realize > there is a potential problem. > The (int) says: "compiler shut up. I know better." > But they don't know better, they just shoot the messenger. > > So instead I would have the rules: > casts in c are not allowed. Exceptions must be run by the Senior Programmer > (that's me). > Warnings must be collected. A separate document explains why the code gives those. > Regression tests are run against those warning files. > > (And I'm all for error numbers, and also warning numbers. If an error changes so > does its number. A message is a bad identification for an error, especially if > the compiler writer helpfully changes the message to a better understandable one, > or one that is less likely to get them into legal trouble.) > > You'll see that the document with explanations is the first thing to read > when there are mysterious errors. > A a side effect I surmise that programmers will try to get rid of warnings > in the good way, to forego the trouble of documenting why the warning is > there. > > Example of motivation: > b cannot overflow because x is in mm and cannot be larger than ca 5000 > for a car. With an material modulus of bla bla .. precision of 32 bits > bla bla. > > Now there is red light if x is going to be measured in nano meters. > (If you change a program part, then you better read the documentation > about warnings generated there about). > >> >> To programme properly, one has to learn to observe and see the failings of >> ones own codings. Forth helps enforce the self-discipline needed but remains >> an amplifier of the programmers skills (good or bad). > > Crashing is certainly the best way to enforce that a bug be fixed. > >> >> -- >> Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> > > Groetjes Albert I think your philosophy is a bit extreme. In strongly typed languages the idea is not to get "permission" from a lead programmer. It is to use a type cast to *indicate* what you are trying to do. I would suggest that education of the implication of using casts be stressed. Code reviews are the place where casts can be questioned or possibly their use would be documented in the same way you indicate above. If I had to do all this in VHDL every time I used a type conversion I'd never get any work done. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-24 16:02 -0700 |
| Message-ID | <7xk34swrjl.fsf@ruckus.brouhaha.com> |
| In reply to | #33541 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes: > Crashing is certainly the best way to enforce that a bug be fixed. The worst property of untyped languages like C and Forth is that they don't crash when there's a type error. They can corrupt data or memory and the program keeps running. I like the Chris Smith quote: "I find it amusing when novice programmers believe their main job is preventing programs from crashing. More experienced programmers realize that correct code is great, code that crashes could use improvement, but incorrect code that doesn't crash is a horrible nightmare."
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-09-24 19:14 -0400 |
| Message-ID | <lvvj9k$t5b$1@dont-email.me> |
| In reply to | #33548 |
On 9/24/2014 7:02 PM, Paul Rubin wrote: > albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >> Crashing is certainly the best way to enforce that a bug be fixed. > > The worst property of untyped languages like C and Forth is that they > don't crash when there's a type error. They can corrupt data or memory > and the program keeps running. I like the Chris Smith quote: > > "I find it amusing when novice programmers believe their main job is > preventing programs from crashing. More experienced programmers > realize that correct code is great, code that crashes could use > improvement, but incorrect code that doesn't crash is a horrible > nightmare." That point was made to me some time back when I was working with Transputers. There was a Transputer advocate in the company who paid attention to things like this rather than just pushing to bang out code. He was talking to me about an overflow stopping the processor. Obviously if an overflow and halt happens while navigating an airplane it is a problem, but the problem isn't in the stopping, it is in the overflow! The halting is a clear indication that the error happened and a dump could potentially give a clue to the cause and eventual fix. But the system could be restarted and the plane would not likely crash. Continuing to run without flagging the error could cause the plane to drift off course or fly too low, both of which can have serious consequences. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-29 10:15 +0000 |
| Message-ID | <2014Sep29.121521@mips.complang.tuwien.ac.at> |
| In reply to | #33550 |
rickman <gnuarm@gmail.com> writes:
>Obviously if an overflow and halt happens while navigating an airplane
>it is a problem, but the problem isn't in the stopping, it is in the
>overflow! The halting is a clear indication that the error happened and
>a dump could potentially give a clue to the cause and eventual fix. But
>the system could be restarted and the plane would not likely crash.
>Continuing to run without flagging the error could cause the plane to
>drift off course or fly too low, both of which can have serious
>consequences.
The funny thing about this example is that there was actually a case
of an overflow in flight control software and it caused a catastrophic
failure; but it caused the failure because it caught and reported the
overflow, and it would not have failed if it had not caught the
overflow (because the result was not used). This case was the Ariane 5.
There were lots of contributing factors in this failure, but my point
is that there is no single right answer. If the system is not
prepared to handle exceptions, as in the Ariane 5, it's not a good
idea to catch overflow. Restarting may not be the solution, either,
if it takes too long, or if the overflow happens again. Wraparound
may produce wrong results. Bigints may be too slow. There is no
single right answer for every case.
- 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]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-24 13:54 -1000 |
| Message-ID | <rvWdnfluzsEDxL7JnZ2dnUU7-TudnZ2d@supernews.com> |
| In reply to | #33548 |
On 9/24/14 1:02 PM, Paul Rubin wrote: > albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >> Crashing is certainly the best way to enforce that a bug be fixed. > > The worst property of untyped languages like C and Forth is that they > don't crash when there's a type error. They can corrupt data or memory > and the program keeps running. I like the Chris Smith quote: > > "I find it amusing when novice programmers believe their main job is > preventing programs from crashing. More experienced programmers > realize that correct code is great, code that crashes could use > improvement, but incorrect code that doesn't crash is a horrible > nightmare." > The observation about incorrect code that doesn't crash is certainly correct. Again, my experience is that "type errors" in Forth are usually quite obvious assuming a responsible level of testing. There's a large space between "correct code" and "code that crashes" that requires thorough testing to verify correctness. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> |
|---|---|
| Date | 2014-09-24 21:07 -0400 |
| Subject | Typing, was [Re: Metrics on stack usage] |
| Message-ID | <op.xmpxe7xbmk81un@localhost> |
| In reply to | #33548 |
On Wed, 24 Sep 2014 19:02:38 -0400, Paul Rubin <no.email@nospam.invalid> wrote: > albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >> Crashing is certainly the best way to enforce that a bug be fixed. > > The worst property of untyped languages like C and Forth is that > they don't crash when there's a type error. Forth is untyped. Although, someone other than me, perhaps Ms. Rather, could argue that characters, integer cells, floating point, and control-flow returns are effectively typed in Forth by the correct usage of Forth words (AKA procedures or functions in other languages) ... I.e., if you don't use the wrong word, you won't access the wrong type. Of course, there is no differentation between a cell and an address of a cell (or pointer) in Forth ... ;-) C is typed. You have to use casts or (ab)use the valid type conversion rules to not get warnings for usage of incompatible types or type punning with most C compilers. Or, you can not enable warnings or disregard them, but most do enable warnings and also take care of them. So, do you mean strongly typed instead of weakly typed here? ... Strong typing is generally bad, IMO. If the language doesn't have a way to access an object or item via different methods, then there is no way to do so. You can't override the type system in strongly typed languages, nor can you extend the language to allow you to do so. But, you might need to do so. The problem here is that the language designer may not have thought of or come across all needed conversions. So, they didn't implement something. Think unions in C which allow multiple types to access the same storage, or pointer to integer casts and conversions in C which are needed to allow storage of addresses and their use as in the original type later on. Weakly typed languages allow you to use a item or object which is normally used in one manner, to be used in another. A common situation is where a pointer or address is used to fetch another repeatedly, such as some implementations of linked-lists and interpreters. This violates the type system of most languages. Dereferencing or fetching an item changes the type of the item or object. I.e., "pointer to type" or "address of object" when dereferenced or fetched becomes "type" or "object". Sometimes you want "pointer to type" or "address of object" to remain "pointer to type" or "address of object" when fetched or dereferenced. > They can corrupt data or memory and the program keeps running. There are generally no runtime checks in many languages due to slowness. You bring up typing frequently, Paul. So, I added comp.lang.misc. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-24 15:25 -1000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <H5-dnXDawpiW8r7JnZ2dnUU7-IGdnZ2d@supernews.com> |
| In reply to | #33552 |
On 9/24/14 3:07 PM, Rod Pemberton wrote: > On Wed, 24 Sep 2014 19:02:38 -0400, Paul Rubin <no.email@nospam.invalid> > wrote: >> albert@spenarnc.xs4all.nl (Albert van der Horst) writes: > >>> Crashing is certainly the best way to enforce that a bug be fixed. >> >> The worst property of untyped languages like C and Forth is that >> they don't crash when there's a type error. > > Forth is untyped. > > Although, someone other than me, perhaps Ms. Rather, could argue that > characters, integer cells, floating point, and control-flow returns > are effectively typed in Forth by the correct usage of Forth words > (AKA procedures or functions in other languages) ... > > I.e., if you don't use the wrong word, you won't access the wrong type. > Of course, there is no differentation between a cell and an address > of a cell (or pointer) in Forth ... > > ;-) It doesn't take me to argue it, Section 3.1 of both ANS Forth and Forth 200x is entitled "Data Types" and has a nice chart of the hierarchy. It also includes the statement, "No data-type checking is required of a system. An ambiguous condition exists if an incorrectly typed data object is encountered." So I think the correct statement is, "Forth is weakly typed." Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-24 18:43 -0700 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <7xegv0scdn.fsf@ruckus.brouhaha.com> |
| In reply to | #33553 |
"Elizabeth D. Rather" <erather@forth.com> writes: > "No data-type checking is required of a system. An ambiguous condition > exists if an incorrectly typed data object is encountered." So I > think the correct statement is, "Forth is weakly typed." I've never heard of a Forth system do any type checking to speak of: it's more like an assembly language, where there's conceptually a type system but it's enforced purely by the programmer, so I think of that as untyped. C has a little bit more checking so I guess "weakly typed" is apropos.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-09-24 16:08 -1000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <3sGdncduJ7-v5L7JnZ2dnUU7-YWdnZ2d@supernews.com> |
| In reply to | #33554 |
On 9/24/14 3:43 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> "No data-type checking is required of a system. An ambiguous condition >> exists if an incorrectly typed data object is encountered." So I >> think the correct statement is, "Forth is weakly typed." > > I've never heard of a Forth system do any type checking to speak of: > it's more like an assembly language, where there's conceptually a type > system but it's enforced purely by the programmer, so I think of that as > untyped. C has a little bit more checking so I guess "weakly typed" is > apropos. > Well, it's a matter of terminology, I guess. There are Forths, such as StrongForth, that do type checking, but it hasn't really caught on. At least types are *defined* in the standards, so a system could type-check if its author wanted to. The fact that most don't probably speaks volumes about the value of type-checking in Forth. After all, programmers working for a living and (usually) against deadline want any feature that could offer genuine help. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-09-25 01:11 -0700 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <5f84b0aa-7566-4b98-9d8f-c06c19b34950@googlegroups.com> |
| In reply to | #33554 |
On Thursday, 25 September 2014 02:43:50 UTC+1, Paul Rubin wrote: > I've never heard of a Forth system do any type checking to speak of: Strong Forth. Sorry, no time to find a link right now... SAP is down!
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-10-01 09:53 -0700 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <7xwq8j68au.fsf@ruckus.brouhaha.com> |
| In reply to | #33560 |
Mark Wills <markwills1970@gmail.com> writes: >> I've never heard of a Forth system do any type checking to speak of: > Strong Forth. > Sorry, no time to find a link right now... SAP is down! Oh yes, forgot about that one. I have a copy stashed away someplace.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-29 13:38 +0000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <2014Sep29.153837@mips.complang.tuwien.ac.at> |
| In reply to | #33554 |
Paul Rubin <no.email@nospam.invalid> writes:
>"Elizabeth D. Rather" <erather@forth.com> writes:
>> "No data-type checking is required of a system. An ambiguous condition
>> exists if an incorrectly typed data object is encountered." So I
>> think the correct statement is, "Forth is weakly typed."
>
>I've never heard of a Forth system do any type checking to speak of:
>it's more like an assembly language, where there's conceptually a type
>system but it's enforced purely by the programmer,
Right.
> so I think of that as
>untyped.
"Untyped" has been used for languages with very different type systems
and type checking, so using that term conveys nothing, except perhaps
that the person using that term does not really know what he is
talking about. One term that would be more desctiptive and mostly
fitting for Forth is "not type-checked".
- 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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-29 17:53 -0700 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <7xeguuq67i.fsf@ruckus.brouhaha.com> |
| In reply to | #33578 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > "Untyped" has been used for languages with very different type systems > and type checking, so using that term conveys nothing, except perhaps > that the person using that term does not really know what he is > talking about. Well, I'm going by the sense that has been used by Cardelli and others (shortened from http://www.lucacardelli.name/Papers/TypeSystems.pdf ): Typed and untyped languages A program variable can assume a range of values during the execution of a program. An upper bound of such a range is called a type of the variable. For example, a variable x of type Boolean is supposed to assume only boolean values during every run of a program... Languages that do not restrict the range of variables are called untyped languages... In these languages, operations may be applied to inappropriate arguments: the result may be a fixed arbitrary value, a fault, an exception, or an unspecified effect. Execution errors and safety It is useful to distinguish between two kinds of execution errors: the ones that cause the computation to stop immediately, and the ones that go unnoticed (for a while) and later cause arbitrary behavior. The former are called trapped errors, whereas the latter are untrapped errors.... A program fragment is safe if it does not cause untrapped errors to occur. ... Most untyped languages are, by necessity, completely safe (e.g., LISP). Otherwise, programming would be too frustrating in the absence of both compile time and run time checks to protect against corruption. Assembly languages belong to the unpleasant category of untyped unsafe languages. By this definition, Forth is both untyped and unsafe. > One term that would be more desctiptive and mostly fitting for Forth > is "not type-checked". That's reasonable if you go by the notion that you can still call something a type system if it's not enforced by the compiler.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-09-30 09:13 +0000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <2014Sep30.111305@mips.complang.tuwien.ac.at> |
| In reply to | #33588 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> "Untyped" has been used for languages with very different type systems
>> and type checking, so using that term conveys nothing, except perhaps
>> that the person using that term does not really know what he is
>> talking about.
>
>Well, I'm going by the sense that has been used by Cardelli and others
>(shortened from http://www.lucacardelli.name/Papers/TypeSystems.pdf ):
Only Cardelli is on that paper.
>
> Typed and untyped languages
>
> A program variable can assume a range of values during the execution
> of a program. An upper bound of such a range is called a type of the
> variable. For example, a variable x of type Boolean is supposed to
> assume only boolean values during every run of a program... Languages
> that do not restrict the range of variables are called untyped
> languages...
So he calls a language with untyped variables an "untyped language".
...
> Execution errors and safety
...
> A program fragment is safe if it does not cause untrapped errors to
> occur. ... Most untyped languages are, by necessity, completely safe
> (e.g., LISP). Otherwise, programming would be too frustrating in the
> absence of both compile time and run time checks to protect against
> corruption. Assembly languages belong to the unpleasant category of
> untyped unsafe languages.
But assembly languages don't have variables. It's as I wrote: People
using the term "untyped language" typically don't really know what
they are talking about. One might think that an expert on static type
checkers like Cardelli should also be knowledgeable when it comes to
dynamically type-checked and non-type-checked languages, but
apparently this is not the case. Or maybe he just tried to find a
definition for the usages of "untyped" or "typeless" that crop up here
and there, but failed; OTOH, realizing when it does not make sense to
try to define a term that is in usage is also part of being
knowledgeable.
>By this definition, Forth is both untyped and unsafe.
Forth variables have restricted range. You must not store a double or
a float in a cell variable. So, by that definition, Forth is not an
"untyped language". I don't find that definition very useful, though,
just as the term.
>> One term that would be more desctiptive and mostly fitting for Forth
>> is "not type-checked".
>
>That's reasonable if you go by the notion that you can still call
>something a type system if it's not enforced by the compiler.
Sure we do. The type system is in the programmer's head. If a
programmer considers it an error when
abs 2* .
prints a negative number, he will typically consider it a type error.
- 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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-09-30 22:37 -0700 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <7x38b8bba4.fsf@ruckus.brouhaha.com> |
| In reply to | #33594 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> Cardelli and others > Only Cardelli is on that paper. I mean others say similar things in other places. E.g. here is Robert Harper: http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/ "To borrow an apt description from Dana Scott, the so-called untyped (that is "dynamically typed") languages are, in fact, unityped...." > One might think that an expert on static type checkers like Cardelli > should also be knowledgeable when it comes to dynamically type-checked > and non-type-checked languages, but apparently this is not the case. He is of course completely knowledgeable of these topics > Or maybe he just tried to find a definition for the usages of > "untyped" or "typeless" that crop up here and there, but failed; No I don't think so; his usage is consistent with other people in the PLT community as well as with Alonzo Church's concepts of typed and untyped lambda calculi going back to the 1930's, way before computers. E.g. Pierce's book Types and Programming languages defines: "A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kind of values they compute." "Syntactic" of course means compile-time. Some exegesis: http://alleystoughton.us/705/slides-tapl-1.pdf On the other hand other parts of the programming community use the terms somewhat differently, which is ok. E.g. some of us would consider Lisp-like languages to be typed, with the type system operating at runtime, while someone like Harper would call them merely "tagged" or "checked" but that "types" are always static. > OTOH, realizing when it does not make sense to try to define a term > that is in usage is also part of being knowledgeable. There are multiple definitions that are precise and that are accepted in various communities and contexts. This article goes into that a little bit: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ > Forth variables have restricted range. You must not store a double or > a float in a cell variable. So, by that definition, Forth is not an > "untyped language". No, unless the restriction is enforced by the compiler or the runtime, it's not a restriction, it's just an expectation. Like if I have a box of 12 donuts and I want to eat just one per day, but nothing is really stopping me from eating all 12 at once, that's not a restriction. > Sure we do. The type system is in the programmer's head. Well, that's consistent with the Forth Zen of moving some burdens to the programmer to simplify the implementation, but I'd expect most PL people wouldn't consider that to be a type system. Also, Forth's types as normally thought of are rather primitive (int, float, etc). compared with Cardelli's notion of typeful programming. > abs 2* . > prints a negative number, he will typically consider it a type error. It wouldn't have occurred to me to call that a type error.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-10-03 16:10 +0000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <2014Oct3.181023@mips.complang.tuwien.ac.at> |
| In reply to | #33601 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> Cardelli and others
>> Only Cardelli is on that paper.
>
>I mean others say similar things in other places. E.g. here is Robert
>Harper:
>
>http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/
A web page that starts with a number of straw man arguments, with a
signal/noise ratio of zero in the paragraphs that I read (the first
five or so). Do you really expect me to read this and take it
seriously?
>> Or maybe he just tried to find a definition for the usages of
>> "untyped" or "typeless" that crop up here and there, but failed;
>
>No I don't think so; his usage is consistent with other people in the
>PLT community as well as with Alonzo Church's concepts of typed and
>untyped lambda calculi going back to the 1930's, way before computers.
I did not deny that there are people who are using "untyped", I just
wrote that they usually don't really know what they are talking about.
There are lots of static type-checking fans around, and they know very
little about run-time type-checked and non-type-checked languages
except they don't like them; so why should they be more discerning
about them than just calling them all "untyped" or "typeless". And
they don't.
>There are multiple definitions that are precise and that are accepted in
>various communities and contexts. This article goes into that a little
>bit:
>
>http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
That's a more discerning article, and guess what, "untyped" does not
appear in it.
>> Forth variables have restricted range. You must not store a double or
>> a float in a cell variable. So, by that definition, Forth is not an
>> "untyped language".
>
>No, unless the restriction is enforced by the compiler or the runtime,
>it's not a restriction, it's just an expectation.
If you 2! into a variable, you typically destroy some data you did not
intend to (and often data that is managed by code that you did not
write), with arbitrary consequences. A Forth programmer considers
that a restriction.
>> Sure we do. The type system is in the programmer's head.
>
>Well, that's consistent with the Forth Zen of moving some burdens to the
>programmer to simplify the implementation, but I'd expect most PL people
>wouldn't consider that to be a type system. Also, Forth's types as
>normally thought of are rather primitive (int, float, etc). compared
>with Cardelli's notion of typeful programming.
Maybe when *you* think of Forth types. When I pass an unsorted array to
a binary search, that's a type error. And it's a type error that no
static type system will catch, and the usual dynamic type systems
don't catch it, either. A static type system may help in assigning
blame for that type error, though.
>> abs 2* .
>> prints a negative number, he will typically consider it a type error.
>
>It wouldn't have occurred to me to call that a type error.
Seems a pretty basic type error to me.
- 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]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-03 08:42 -1000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <c8KdnX9IxaiZc7PJnZ2dnUU7-dGdnZ2d@supernews.com> |
| In reply to | #33677 |
On 10/3/14 6:10 AM, Anton Ertl wrote: > Paul Rubin <no.email@nospam.invalid> writes: ... >> No, unless the restriction is enforced by the compiler or the runtime, >> it's not a restriction, it's just an expectation. > > If you 2! into a variable, you typically destroy some data you did not > intend to (and often data that is managed by code that you did not > write), with arbitrary consequences. A Forth programmer considers > that a restriction. In integrated code/data implementations (which are the most common), you'll most likely clobber the head of the next definition. That'll show up pretty quickly! But, seriously, programmers can manage data space. It isn't that hard. And it's only the programmer who knows, for example, whether the content of a 2VARIABLE is a double-length integer or a pair of values that are usually handled together (but might occasionally be accessed individually). A zoo of checkable types that can handle all the uses you might want to make of data space yields a compiler that is immensely large and complex and has a whole host of other issues that small, simple Forth compilers don't. Chuck's famous remark, "If I want to add 1 to the letter B I don't want some compiler telling me I can't" illustrates the concept of independence and responsibility that is characteristic of Forth programmers. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2014-10-03 14:59 -0400 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <m0mrnj$nbs$1@dont-email.me> |
| In reply to | #33678 |
On 10/3/2014 2:42 PM, Elizabeth D. Rather wrote: > > Chuck's famous remark, "If I want to add 1 to the letter B I don't want > some compiler telling me I can't" illustrates the concept of > independence and responsibility that is characteristic of Forth > programmers. That is a very common misrepresentation of what type checking does. I use VHDL in my hardware design work so I know just how bothersome it can be. But it never stops me from doing what I want. I just have to do it in a way that is explicit rather than implicit. The idea is that if you want to add an integer to a character you simply need to indicate that in the code rather than writing it in a way that leaves open for interpretation what the intent was. I have no problem with type checking. I'm sure it has saved me from needing to debug a few messy problems. But then there is *nothing* Forth like about VHDL. Every aspect of the system isolates the coder from the result. But that is largely a result of the complexity of hardware design these days. Speaking of hardware design... does Chuck's CAD system have any simulation capability? I've never tried to use it and doubt I will since it is for ASICs. I have considered a Forth like hardware design language. I'm just not sure I'm ready to give up my conventional tools just yet. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web