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 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-03 09:07 -1000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <qKCdndYz261ibrPJnZ2dnUU7-Y2dnZ2d@supernews.com> |
| In reply to | #33679 |
On 10/3/14 8:59 AM, rickman wrote: > 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. That is what comments are for :-) > 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. Sure, every technology has its own unique needs and appropriate tools. > 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. No idea. I haven't been in touch with him since he started down that path, which is now many years ago. 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 17:28 -0400 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <m0n4eb$8oe$2@dont-email.me> |
| In reply to | #33680 |
On 10/3/2014 3:07 PM, Elizabeth D. Rather wrote: > On 10/3/14 8:59 AM, rickman wrote: >> 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. > > That is what comments are for :-) Yes, comments are ubiquitous in code aren't they... :P >> 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. > > Sure, every technology has its own unique needs and appropriate tools. > >> 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. > > No idea. I haven't been in touch with him since he started down that > path, which is now many years ago. > > Cheers, > Elizabeth > -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Howerd <howerdo@yahoo.co.uk> |
|---|---|
| Date | 2014-10-04 11:15 -0700 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <b8879d4c-54ef-42c3-bd3f-573aee6c2f6c@googlegroups.com> |
| In reply to | #33679 |
Hi Rick, > Speaking of hardware design... does Chuck's CAD system have any > simulation capability? Yes - I spoke to Chuck at a EuroForth in 2001 and he showed me the OKAD system running a simulation. Chuck also said that the parameters that he had been given by the IC fabrication company were inaccurate, and that he had added some calibration hardware to measure transistor gain, impedance etc, so that the simulation could be made better. In the OKAD system the chip is divided into cells, and each cell has its own set of variables - size location, layer, impedance etc, plus real-time parameters such as temperature, current flow etc. This makes it relatively easy to run a simulation. Best regards, Howerd On Friday, 3 October 2014 20:00:05 UTC+1, rickman wrote: > 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]
| From | Marc Olschok <nobody@nowhere.invalid> |
|---|---|
| Date | 2014-10-07 23:37 +0000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <m11tfa$off$1@news.albasani.net> |
| In reply to | #33678 |
Elizabeth D. Rather <erather@forth.com> 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. I have seen this cited several times, but I still fail to see its relevance to discussions about typing. Of course I do not know the original time and context of the above remark, but if a Forth programmer brought it up nowadays to argue against static typing, I would simply assume it illustrates ignorance. Because a strong enough type system as such does not prevent this. It would only ask, that the responsible programmer tells what "adding an integer to a letter" should mean, in particular what type the result should have; basically that is what I (as a human being) would also ask, if somebody wanted me to add 1 to 'B'. Now, most likely our Forth programmer just wants to do 1 'B + or 'B 1+ but then 'B is just a convenient shorthand for 33, he just adds integers and obtains an integer result. That is a sensible position: Forth operates with integers and any organisation of data along types is purely inside the programmers imagination. Nevertheless, in e.g. Haskell this can be done with 1 + fromEnum 'B' giving the integer 34 as result. On the other hand, if the programmer wants a char as result, this can be done with toEnum (1 + fromEnum 'B') ::Char giving the char 'C' as result. But perhaps the 1 had a special significance here and "add 1 to the letter B" was only a substitute for "I want the next letter after B". Then one can do this directly with succ 'B' giving 'C' as result. I do not mean to suggest that Forth is deficient because it does not have Haskell's type system. In fact I think that the advantages or disadvantages of different type systems cannot be discussed without reference to a particular language design. It just happens that in modern languages types do not need to be either a crutch for the incompetent or a shackle for the independent; the can be just a tool and a useful part of the language. Perhaps the aversion of some Forthers towards typing stems from their experience with C or Pascal only. But there is more out there. -- Marc
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-07 15:07 -1000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <kpudneC7Z_bcE6nJnZ2dnUU7-VmdnZ2d@supernews.com> |
| In reply to | #33741 |
On 10/7/14 1:37 PM, Marc Olschok wrote:
> Elizabeth D. Rather <erather@forth.com> 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.
>
> I have seen this cited several times, but I still fail to see its
> relevance to discussions about typing. Of course I do not know the
> original time and context of the above remark, but if a Forth
> programmer brought it up nowadays to argue against static typing,
> I would simply assume it illustrates ignorance.
>
> Because a strong enough type system as such does not prevent this.
> It would only ask, that the responsible programmer tells what
> "adding an integer to a letter" should mean, in particular what
> type the result should have; basically that is what I (as a human being)
> would also ask, if somebody wanted me to add 1 to 'B'.
>
> Now, most likely our Forth programmer just wants to do
>
> 1 'B + or 'B 1+
>
> but then 'B is just a convenient shorthand for 33, he just adds
> integers and obtains an integer result.
> That is a sensible position: Forth operates with integers and
> any organisation of data along types is purely inside the programmers
> imagination.
Yes, it's a glib and trivial example. In Forth it would be:
CHAR B 1+ EMIT ( produces 'C' )
> Nevertheless, in e.g. Haskell this can be done with
>
> 1 + fromEnum 'B'
>
> giving the integer 34 as result.
>
> On the other hand, if the programmer wants a char as result,
> this can be done with
>
> toEnum (1 + fromEnum 'B') ::Char
>
> giving the char 'C' as result.
>
> But perhaps the 1 had a special significance here and
> "add 1 to the letter B" was only a substitute for
> "I want the next letter after B". Then one can do this
> directly with
>
> succ 'B'
>
> giving 'C' as result.
But the point is, that's a lot of fuss, without adding any significant
value to the programming process.
> I do not mean to suggest that Forth is deficient because it does
> not have Haskell's type system. In fact I think that the advantages
> or disadvantages of different type systems cannot be discussed
> without reference to a particular language design. It just happens
> that in modern languages types do not need to be either a crutch for
> the incompetent or a shackle for the independent; the can be just a
> tool and a useful part of the language. Perhaps the aversion of some
> Forthers towards typing stems from their experience with C or Pascal
> only. But there is more out there.
In experienced Forth programmers the aversion is mostly due to the fact
that one comes to love simplicity, trust one's own judgement, and prefer
working that way to more complicated tools.
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 | Marc Olschok <nobody@nowhere.invalid> |
|---|---|
| Date | 2014-10-11 23:32 +0000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <m1celq$hlu$1@news.albasani.net> |
| In reply to | #33743 |
Elizabeth D. Rather <erather@forth.com> wrote: > On 10/7/14 1:37 PM, Marc Olschok wrote: > > Elizabeth D. Rather <erather@forth.com> 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. > > > > I have seen this cited several times, but I still fail to see its > > relevance to discussions about typing. Of course I do not know the > > original time and context of the above remark, but if a Forth > > programmer brought it up nowadays to argue against static typing, > > I would simply assume it illustrates ignorance. > > > > Because a strong enough type system as such does not prevent this. > > It would only ask, that the responsible programmer tells what > > "adding an integer to a letter" should mean, in particular what > > type the result should have; basically that is what I (as a human being) > > would also ask, if somebody wanted me to add 1 to 'B'. > > > > Now, most likely our Forth programmer just wants to do > > > > 1 'B + or 'B 1+ > > > > but then 'B is just a convenient shorthand for 33, he just adds > > integers and obtains an integer result. > > That is a sensible position: Forth operates with integers and > > any organisation of data along types is purely inside the programmers > > imagination. > > Yes, it's a glib and trivial example. In Forth it would be: > > CHAR B 1+ EMIT ( produces 'C' ) > > > Nevertheless, in e.g. Haskell this can be done with > > > > 1 + fromEnum 'B' > > > > giving the integer 34 as result. > > > > On the other hand, if the programmer wants a char as result, > > this can be done with > > > > toEnum (1 + fromEnum 'B') ::Char > > > > giving the char 'C' as result. > > > > But perhaps the 1 had a special significance here and > > "add 1 to the letter B" was only a substitute for > > "I want the next letter after B". Then one can do this > > directly with > > > > succ 'B' > > > > giving 'C' as result. > > But the point is, that's a lot of fuss, without adding any significant > value to the programming process. Well, I find "succ 'B'" not more complicated than "char B 1+", in particular when "producing the next char after B" is what was originally intended. It also works with other types than Char if they share the same typeclass. But of course it is a matter of taste and language. Imagine a Perl programmer looking at Forth and remarking "If I want to add an integer to a float I don't want some compiler telling me I can't". You can then explain to him that he can indeed do so in Forth with either "s>f f+" or "f>s +" depending on what he wants as a result. But he might find this too much fuss. > > > I do not mean to suggest that Forth is deficient because it does > > not have Haskell's type system. In fact I think that the advantages > > or disadvantages of different type systems cannot be discussed > > without reference to a particular language design. It just happens > > that in modern languages types do not need to be either a crutch for > > the incompetent or a shackle for the independent; the can be just a > > tool and a useful part of the language. Perhaps the aversion of some > > Forthers towards typing stems from their experience with C or Pascal > > only. But there is more out there. > > In experienced Forth programmers the aversion is mostly due to the fact > that one comes to love simplicity, trust one's own judgement, and prefer > working that way to more complicated tools. That love of simplicity etc. may explain why they use Forth. And I will happily admit that I never felt the need to have a strong type system added to Forth. But my impression from ongoing discussions on typing was, that most Forthers viewed a type system *only* as a mechanism that safeguards programmers against errors, but provides nothing else and sometimes is more like an obstacle to be fought against. Surely such ideas about the role of a type system within a language did not come out of thin air but must have been shaped by some real experience with languages where this is indeed the case. -- Marc
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-12 03:03 +0200 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <m1ck1p$n1l$1@online.de> |
| In reply to | #33850 |
Marc Olschok wrote: >> In experienced Forth programmers the aversion is mostly due to the fact >> that one comes to love simplicity, trust one's own judgement, and prefer >> working that way to more complicated tools. > > That love of simplicity etc. may explain why they use Forth. > And I will happily admit that I never felt the need to have a > strong type system added to Forth. But my impression from ongoing > discussions on typing was, that most Forthers viewed a type system > *only* as a mechanism that safeguards programmers against errors, > but provides nothing else and sometimes is more like an obstacle to > be fought against. Surely such ideas about the role of a type system > within a language did not come out of thin air but must have been > shaped by some real experience with languages where this is indeed > the case. Well, the real languages with type systems like that are quite likely the Algol family - which have ranges from weak (C) to strong (Ada) typechecking. The type checkers are usually advertized as "safeguards against errors", and you rarely hear anything else - apart from the C++ camp, who advocate types as a mean to overload operators. Especially you hear things like "programs in a typesafe language can't crash and are immune to malware injection threats"; so the advocates of typesafe languages see this feature as main distinction against C, which has types, but can't check for buffer overflows. The undetected buffer overflows are the actual harmfull part of C here, and Forth is doing better in this respect (with all the addr u buffers, where you can at least check for overflow). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-12 10:42 -0500 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <OO-dnZryCZXzPKfJnZ2dnUU7-YGdnZ2d@supernews.com> |
| In reply to | #33852 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > > The type checkers are usually advertized as "safeguards against > errors", and you rarely hear anything else - apart from the C++ > camp, who advocate types as a mean to overload operators. And Haskell. For them, the type system is a major way to convey meaning. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-13 00:26 +0200 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <m1ev65$d9c$1@online.de> |
| In reply to | #33860 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: >> >> The type checkers are usually advertized as "safeguards against >> errors", and you rarely hear anything else - apart from the C++ >> camp, who advocate types as a mean to overload operators. > > And Haskell. For them, the type system is a major way to convey > meaning. Well, they still advertize their type system as safeguards: "The main advantage of statically typed languages is well-known: All type errors are detected at compile-time. Not all errors are caught by the type system; an expression such as 1/0 is typable but its evaluation will result in an error at execution time. Still, the type system finds many program errors at compile time, aids the user in reasoning about programs, and also permits a compiler to generate more efficient code (for example, no run-time type tags or tests are required)." from http://www.haskell.org/tutorial/goodies.html I'd say that a value category system that conveys meaning is a class system, not a type system, and that a class then should be a first-class member in such a programming language - and the typing dynamic. The type tags (method tables or whatever dispatch mechanism you want to use) are important if the class conveys meaning, as polymorphism is a very elegant way to do that. You can define polymorphic functions in Haskell, and it's quite common to do so, but they are polymorphic in a pattern-matching sense, i.e. they infer their type if the type fits into the pattern of the declaration. This is different from the way e.g. Smalltalk does this: There, you look up the function in the context of the class, and if there is one of that name, you execute it. If you cross static typing and OOP, you get early binding, essentially just some sort of namespaces. That's only a very limited OOP. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-10-11 19:30 -1000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <oKidnXP-ioxtjKfJnZ2dnUU7-LmdnZ2d@supernews.com> |
| In reply to | #33850 |
On 10/11/14 1:32 PM, Marc Olschok wrote: > Elizabeth D. Rather <erather@forth.com> wrote: >> On 10/7/14 1:37 PM, Marc Olschok wrote: >>> Elizabeth D. Rather <erather@forth.com> wrote: >>>> [...] >>> I do not mean to suggest that Forth is deficient because it does >>> not have Haskell's type system. In fact I think that the advantages >>> or disadvantages of different type systems cannot be discussed >>> without reference to a particular language design. It just happens >>> that in modern languages types do not need to be either a crutch for >>> the incompetent or a shackle for the independent; the can be just a >>> tool and a useful part of the language. Perhaps the aversion of some >>> Forthers towards typing stems from their experience with C or Pascal >>> only. But there is more out there. >> >> In experienced Forth programmers the aversion is mostly due to the fact >> that one comes to love simplicity, trust one's own judgement, and prefer >> working that way to more complicated tools. > > That love of simplicity etc. may explain why they use Forth. > And I will happily admit that I never felt the need to have a > strong type system added to Forth. But my impression from ongoing > discussions on typing was, that most Forthers viewed a type system > *only* as a mechanism that safeguards programmers against errors, > but provides nothing else and sometimes is more like an obstacle to > be fought against. Surely such ideas about the role of a type system > within a language did not come out of thin air but must have been > shaped by some real experience with languages where this is indeed > the case. Although there are some Forth programmers who have never programmed in any other language, most of us do have experience with one or more others, and most of those are more strongly typed than Forth. Most of the Forthers I've worked with are in the practical business of getting applications to work for customers, often against tight deadlines. We are a practical sort: if we found ourselves slapping our foreheads and saying, "Oh rats, if only Forth had typechecking I wouldn't have spent the last [n] minutes finding this bug," you can bet Forth would have had typechecking 40 years ago. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-08 03:42 +0200 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <m124ps$a1r$1@online.de> |
| In reply to | #33741 |
Marc Olschok wrote:
> I do not mean to suggest that Forth is deficient because it does
> not have Haskell's type system. In fact I think that the advantages
> or disadvantages of different type systems cannot be discussed
> without reference to a particular language design. It just happens
> that in modern languages types do not need to be either a crutch for
> the incompetent or a shackle for the independent; the can be just a
> tool and a useful part of the language. Perhaps the aversion of some
> Forthers towards typing stems from their experience with C or Pascal
> only. But there is more out there.
This particular quote can't come from Pascal or C, as both allow adding 1 to
'B'. Both languages have a character type which is simply a byte (subset of
Integer), and 'B' is just 0x42. C's typing system is pretty weak, and it
provides ample of opportunities to surprise the naive user, e.g. "abc"+2 is
"c". Makes perfectly sense when you understood that a string is just a
character pointer, and adding 2 to it will put the pointer upwards by two
bytes. There are some chances that you get warnings about type errors out
of modern C compilers, but rarely any more. C has types, but its typechecks
are very weak. There's a lot of implicit conversion.
The stuff you illustrated from Haskell shows that this is much more like the
type system Chuck was thinking of: There, you need to either typecast the
character, or you need the special succ operator, but the compiler tells you
that you are not supposed to add a character and an integer.
I don't quite understand why a typecast is necessary here. Of course, I'm
coming from the Forth position that an ordered set is really just a number
plus a type information, so adding a plain integer to it has a very obvious
meaning - the type information (which is just imagination of the compiler)
of the enum may be retained, but you really add the two integers together.
Like Forth, C's type system is way weaker than that; when you do something
like
union { int foo; char a[4]; }
you can write four characters into a[0] to a[3], and then read foo, and it
will contain the four bytes - at least on byte addressed machines; little or
big endian depends on the hardware. And then, you can use this union e.g.
to calculate a hash over a string, by multiplying numbers to four characters
at a time, adding constants, and rotating the result bitwise. I'm sure the
type system of Haskell will make it way harder to achieve that than the type
system of C (in Forth, you don't even need the union or a typecast to (int
*); you just @ from the string's addresses).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-10-08 02:46 -0500 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <14SdnVVQO7tzdqnJnZ2dnUU7-LudnZ2d@supernews.com> |
| In reply to | #33745 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > This particular quote can't come from Pascal or C, as both allow > adding 1 to 'B'. Both languages have a character type which is > simply a byte (subset of Integer), and 'B' is just 0x42. Are you sure? Pascal has a separate char type and the transfer functions ord(char) and chr(int). Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-10-09 00:43 +0200 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <m14em9$s39$1@online.de> |
| In reply to | #33747 |
Andrew Haley wrote: > Bernd Paysan <bernd.paysan@gmx.de> wrote: > >> This particular quote can't come from Pascal or C, as both allow >> adding 1 to 'B'. Both languages have a character type which is >> simply a byte (subset of Integer), and 'B' is just 0x42. > > Are you sure? Pascal has a separate char type and the transfer > functions ord(char) and chr(int). Yes, indeed. It might have been Pascal, which Chuck had in mind. I might have been confused by Turbo Pascal, which didn't have the Char datatype until (I've just checked) version 4.0, so you just used a byte type instead, and that was an integer compatible type, no ord/chr needed. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Marc Olschok <nobody@nowhere.invalid> |
|---|---|
| Date | 2014-10-11 23:32 +0000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <m1cemc$hme$1@news.albasani.net> |
| In reply to | #33745 |
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Marc Olschok wrote:
> > I do not mean to suggest that Forth is deficient because it does
> > not have Haskell's type system. In fact I think that the advantages
> > or disadvantages of different type systems cannot be discussed
> > without reference to a particular language design. It just happens
> > that in modern languages types do not need to be either a crutch for
> > the incompetent or a shackle for the independent; the can be just a
> > tool and a useful part of the language. Perhaps the aversion of some
> > Forthers towards typing stems from their experience with C or Pascal
> > only. But there is more out there.
>
> This particular quote can't come from Pascal or C, as both allow adding 1 to
> 'B'. Both languages have a character type which is simply a byte (subset of
> Integer), and 'B' is just 0x42. C's typing system is pretty weak, and it
> provides ample of opportunities to surprise the naive user, e.g. "abc"+2 is
> "c". Makes perfectly sense when you understood that a string is just a
> character pointer, and adding 2 to it will put the pointer upwards by two
> bytes. There are some chances that you get warnings about type errors out
> of modern C compilers, but rarely any more. C has types, but its typechecks
> are very weak. There's a lot of implicit conversion.
My impression from ongoing discussions on typing was, that most
Forthers viewed a type system *only* as a mechanism that safeguards
programmers against errors, but provides nothing else and sometimes
is more of an obstacle than a tool. Surely such ideas about the role
of a type system within a language must have been shaped by some
experience with languages where this is indeed the case.
>
> The stuff you illustrated from Haskell shows that this is much more like the
> type system Chuck was thinking of: There, you need to either typecast the
> character, or you need the special succ operator, but the compiler tells you
> that you are not supposed to add a character and an integer.
Well, a Perl programmer might as well say that you are not supposed
to add an integer and a float in Forth. But of course you can do that
in Forth, you just have to say what you want, "s>f f+" or "f>s +".
>
> I don't quite understand why a typecast is necessary here. Of course, I'm
> coming from the Forth position that an ordered set is really just a number
> plus a type information, so adding a plain integer to it has a very obvious
> meaning - the type information (which is just imagination of the compiler)
> of the enum may be retained, but you really add the two integers together.
Yes, I understand that and I think it is a reasonable position for
Forth. Within Haskell the successor function succ has the obvious
meaning for instances of Enum and is nothing special. Of course it
also works with self defined types, like in
data Mainzelmann = Anton | Berti | Conni | Det | Edi | Fritzchen
deriving Enum
where indeed the enumeration is so obvious that even the compiler
will do the right thing, and hence the various maps of that typeclass
do not need to be specified (although the programmer can do so).
I never felt the need for such a type system in Forth, but if I
happen to use a language with types then I cartainly want control
about what is going on instead of having to rely on some implicit
conversion like in C or Perl, which may or may not do what I want.
It is mostly about being explicit about what you want; then the
compiler should obey.
>
> Like Forth, C's type system is way weaker than that; when you do something
> like
>
> union { int foo; char a[4]; }
>
> you can write four characters into a[0] to a[3], and then read foo, and it
> will contain the four bytes - at least on byte addressed machines; little or
> big endian depends on the hardware. And then, you can use this union e.g.
> to calculate a hash over a string, by multiplying numbers to four characters
> at a time, adding constants, and rotating the result bitwise. I'm sure the
> type system of Haskell will make it way harder to achieve that than the type
> system of C (in Forth, you don't even need the union or a typecast to (int
> *); you just @ from the string's addresses).
Well, Haskell chars are in unicode and its unions are disjoint but
I do not see why the typing should be a problem here. It is easy
to convert back and forth between Strings and Integers. Probably
operations on the bit level have to be supplied, perhaps they
are already somewhere inside the GHC (I do not know because the
Great Haskell Compiler Monster is a bit to much for my modest
diskspace, I only use Hugs).
Indeed, given the choice I would very much prefer the Forth way
over the C way here, because I have control over the data and do not
need (or guess) the implementation details of a particular compiler.
--
Marc
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-09-28 18:45 +0000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <20140928101013.735@kylheku.com> |
| In reply to | #33553 |
["Followup-To:" header set to comp.lang.misc.]
On 2014-09-25, Elizabeth D. Rather <erather@forth.com> wrote:
> 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."
"weakly typed "does not have a single widely-accepted definition, and should
probably be avoided. They are somewhat subjective terms. Basically "weakly
typed" means "having flexibilities, concessions, holes or pitfalls in the type
system (or even other safety-related aspects of the language) that I don't
agree with", whereas "strongly typed" means "exactly the type system I prefer,
or perhaps an even stricter one".
Some people in computing call a language weakly typed if a string which
contains the text "3.14" can be used in arithmetic expressions as if it
were a number. The language is actually keenly aware of type, and handles
the situation by supplying a conversion; but that handling is something
that the speaker disagrees with, and would like to see a diagnostic
which rejects the program. Not rejecting the program is "weakness";
the implementation "caves in" to the "demands of the idiot programmer"
and just makes it work.
Some languages will not implicitly do such a conversion, yet they will
implicitly do some others, such as floating to integer. Yet, that is still
called "weakly typed" by some.
Os it may be better to simply say that Forth is "typed, without type checking".
("Without type checking" also implies that there is no coercion to the
correct type, like "3.14" to floating-point; that implicitly requires a check:
a check whose result is handled by supplying a conversion rather than by
stopping the compilation or interpretation with a diagnostic.)
[toc] | [prev] | [next] | [standalone]
| From | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |
|---|---|
| Date | 2014-09-25 09:22 +0200 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <1scdsab9rg83g.170pdinu7yaai$.dlg@40tude.net> |
| In reply to | #33552 |
On Wed, 24 Sep 2014 21:07:45 -0400, Rod Pemberton wrote: > 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. There is a type algebra for doing this. You use types (and values too) to construct new types. That's the idea, since, let me guess, late 70's... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-09-28 17:09 +0000 |
| Subject | Re: Typing, was [Re: Metrics on stack usage] |
| Message-ID | <20140928100128.348@kylheku.com> |
| In reply to | #33552 |
["Followup-To:" header set to comp.lang.misc.] On 2014-09-25, Rod Pemberton <buzzoff@nonamewhichexists.cmm> 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) ... "Untyped language" could mean "a language in which any operation on any datum is well-defined by the detailed representation" or one in which "any operation can be expressed on any data, but is only well-defined when the data has the correct type expected by the operation, and there are no diagnostics to ensure this". I.e. untyped means either "without type" or "without type checking". Machine language instruction sets tend to be "without type", because the representations are defined to the bit level, and we can make sense of what it means to treat a 32 bit address as a 32 bit float. (If the architecture allows some padding bits with unspecified values, then we are somewhat in trouble: what is a single value in one type looks like multiple values in another.) Some languages without type checking, like BCPL, are de facto like this but with the provision that since they are also machine-independent, you cannot rely on the bitwise representational tricks to hold. Even if the specification were to explicitly say that the program will not crash no matter what operation it applies to a "cell" datum, the program which takes advantage of this is difficult to port (and perhaps to understand, even).
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-09-25 01:43 +0000 |
| Message-ID | <20140924183028.29@kylheku.com> |
| In reply to | #33548 |
On 2014-09-24, 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 C is typed ... just with some holes. Thanks for playing. > don't crash when there's a type error. C programs crash for a myriad reasons, not all of them related to type. Many C programs that crash do not do any type punning at all: they do not reinterpret a valid piece of memory of one type as another. A C program that passes all ISO C type checks and contains no casts, and no implicit conversions through (void *), can still crash miserably. Some crashes relate to C type being an incomplete description of some object, like a pointer used in place of an array without describing its size. Some relate to memory issues, like local variables disappearing when a block scope terminates, with the possibility that variables holding their addresses are still live. Or a malloc block being prematurely freed. That's not a type issue; those pointers carry a perfectly correct type of what once existed. Some crashes relate to uninitialized variables. (This is tangentially an issue of type; namely that C lets an object of some type to be instantiated without ensuring that it has a well-defined value that is in the valid domain of that type.) Some crashes are for other reasons, like runaway recursion, or out-of-memory and not checking for a null pointer. There are also numeric crashes: floating-point overflows, division by zero. Not a type error, unless you regard zero to be of the wrong "type" for a division operation's right hand side. C is a "crashy" language with lots of undefined behaviors, and opportunities for it; but it's far from a typeless language.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-09-25 01:15 -0700 |
| Message-ID | <eb96cfb8-77e9-4dc0-b53d-bec49d69da0b@googlegroups.com> |
| In reply to | #33555 |
On Thursday, 25 September 2014 02:44:07 UTC+1, Kaz Kylheku wrote: > C programs crash for a myriad reasons, not all of them related to type. > The main culprit for 99.9% of "crashes" is situated between the keyboard and the chair. The other .1% can be put down to power fluctuations, cosmic dust, ISIS, etc :-) I say: Define "crash". When a program has crashed it's simply not doing what we thought it would do. If you could ask a program if it's crashed, it would reply "of course not. I'm just doing what you told me to do."
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-09-25 10:19 +0000 |
| Message-ID | <5423ec41$0$6903$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #33561 |
In article <eb96cfb8-77e9-4dc0-b53d-bec49d69da0b@googlegroups.com>, Mark Wills <markwills1970@gmail.com> wrote: >On Thursday, 25 September 2014 02:44:07 UTC+1, Kaz Kylheku wrote: >> C programs crash for a myriad reasons, not all of them related to type. >> > >The main culprit for 99.9% of "crashes" is situated between the keyboard >and the chair. > >The other .1% can be put down to power fluctuations, cosmic dust, ISIS, etc :-) > >I say: Define "crash". When a program has crashed it's simply not doing >what we thought it would do. If you could ask a program if it's crashed, >it would reply "of course not. I'm just doing what you told me to do." You're missing the concept of specification. A defect is when a program doesn't conform to its specification. A crash is when a program cannot get into working order using normal inputs. E.g. an editor hangs. This is a kind of crash. Under Unix you can get it under control by killing it from an other terminal, which is foreseen. This means Unix didn't crash. 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]
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
Back to top | Article view | comp.lang.forth
csiph-web