Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #53455 > unrolled thread
| Started by | awegel@arcor.de (Alexander Wegel) |
|---|---|
| First post | 2016-12-21 01:19 +0100 |
| Last post | 2017-01-08 16:55 -0800 |
| Articles | 20 on this page of 266 — 26 participants |
Back to article view | Back to comp.lang.forth
"Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-21 01:19 +0100
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-24 05:40 -0600
Re: "Hello world" using Hughs novice package Julian Fondren <julian.fondren@gmail.com> - 2016-12-24 06:01 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-25 19:27 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-26 18:16 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-27 14:27 +0100
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-27 14:29 +0100
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-27 14:27 +0100
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-28 11:35 +1100
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2016-12-27 17:38 -0800
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-29 10:11 +1100
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2016-12-29 17:06 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-28 05:39 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-27 22:37 -0800
Re: "Hello world" using Hughs novice package crc <charles.childers@gmail.com> - 2016-12-28 05:40 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-28 23:03 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-30 20:54 +0100
Re: "Hello world" using Hughs novice package Coos Haak <htrofhc@gmail.com> - 2017-01-02 20:17 +0100
Re: "Hello world" using Hughs novice package mhx@iae.nl - 2017-01-02 12:22 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-02 22:08 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-02 21:40 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-03 13:51 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-03 21:51 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-06 19:36 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-07 14:55 +0100
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-07 19:01 +0100
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-08 12:06 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-08 16:46 -0800
Re: "Hello world" using Hughs novice package "Robert L." <No_spamming@noWhere_7073.org> - 2017-01-03 15:59 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-27 23:12 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-30 20:54 +0100
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-28 04:57 -0600
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-28 11:23 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-28 23:16 -0800
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-30 16:31 +0000
Re: "Hello world" using Hughs novice package "David N. Williams" <williams@umich.edu> - 2016-12-30 15:21 -0500
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-05 12:00 +0000
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-05 13:30 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-05 17:32 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-06 02:50 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-05 18:20 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-06 17:58 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-07 14:55 +0100
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 16:15 +0000
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-10 08:43 +0000
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-30 14:37 +0000
Re: "Hello world" using Hughs novice package john <anon@example.com> - 2016-12-30 15:57 +0000
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-30 17:19 +0000
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-30 21:10 +0000
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2016-12-30 12:44 -1000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 15:43 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-31 00:09 +0000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-03 17:25 +0000
Re: "Hello world" using Hughs novice package john <anon@example.com> - 2016-12-30 22:47 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-31 03:31 -0600
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-30 15:46 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 15:05 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-31 00:26 +0000
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-31 11:49 +1100
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2016-12-30 15:21 -1000
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2017-01-02 11:11 +1100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 00:28 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-01 17:45 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-01 20:57 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 06:55 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 10:44 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 07:01 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 15:46 +0000
Re: "Hello world" using Hughs novice package john <anon@example.com> - 2017-01-02 16:54 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 10:23 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 10:06 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 19:13 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 14:08 -0800
Re: "Hello world" using Hughs novice package mhx@iae.nl - 2017-01-02 14:46 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-02 17:10 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-02 21:58 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-03 15:54 -0800
Re: "Hello world" using Hughs novice package JUERGEN <epldfpga@aol.com> - 2017-01-04 06:21 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-04 11:19 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-04 22:34 +0100
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-04 14:44 -0800
Re: "Hello world" using Hughs novice package JUERGEN <epldfpga@aol.com> - 2017-01-04 15:13 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-05 08:18 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-04 23:17 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-05 04:15 -0600
Re: "Hello world" using Hughs novice package mhx@iae.nl - 2017-01-08 01:18 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-08 15:52 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-08 21:00 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-09 15:58 -0800
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-09 17:39 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-09 18:53 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-12 06:27 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-12 13:44 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-12 17:36 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-13 03:17 -0600
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-13 14:44 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-13 14:43 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 00:23 +0000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-14 11:52 +0000
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 16:00 +0000
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-14 11:51 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-14 15:06 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-15 14:54 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-15 13:33 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-13 16:06 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 00:25 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-13 18:00 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-13 22:17 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-13 16:04 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-13 15:08 -1000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-13 17:21 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 11:26 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-13 18:21 -0800
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-13 18:30 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-13 22:20 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-14 10:43 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-14 15:47 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-14 17:30 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-14 18:16 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-15 13:53 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-15 14:09 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-15 15:48 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-15 16:00 -0800
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-15 12:48 +0100
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-14 10:10 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-15 17:56 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-15 17:05 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-15 17:35 -0800
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-15 19:20 -0800
Re: "Hello world" using Hughs novice package Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-15 23:51 -0500
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-15 19:22 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-18 16:24 -0800
Re: "Hello world" using Hughs novice package foxaudioresearch@gmail.com - 2017-01-18 18:40 -0800
Re: "Hello world" using Hughs novice package Ron Aaron <rambamist@gmail.com> - 2017-01-19 06:46 +0200
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-18 23:25 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 09:47 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 02:44 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 06:16 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 07:43 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-19 11:07 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 14:58 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-20 03:48 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 06:54 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-20 09:11 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 07:30 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-20 12:12 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 16:27 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-21 03:24 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-22 12:47 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-22 14:41 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-22 15:57 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-23 04:05 -0600
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-23 10:47 -0800
Re: "Hello world" using Hughs novice package Mark Wills <markwills1970@gmail.com> - 2017-01-24 01:02 -0800
Re: "Hello world" using Hughs novice package Paul Rubin <no.email@nospam.invalid> - 2017-01-24 01:12 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-23 16:28 -0800
Re: "Hello world" using Hughs novice package Mark Wills <markwills1970@gmail.com> - 2017-01-24 01:06 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-24 03:22 -0600
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-24 14:19 +0100
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-24 03:13 -0600
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-24 08:08 -0500
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-24 14:23 +0100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-24 09:10 -0500
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-24 15:35 +0000
Persitent memory (was Re: "Hello world" using Hughs novice package) Alex <alex@rivadpm.com> - 2017-01-24 14:19 -0500
Re: Persitent memory (was Re: "Hello world" using Hughs novice package) Alex <alex@rivadpm.com> - 2017-01-24 15:00 -0500
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-24 14:49 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-25 03:26 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-26 04:27 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-26 08:35 -0600
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-21 14:19 +0100
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-22 12:55 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 15:28 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 14:44 -0800
Re: "Hello world" using Hughs novice package Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-19 20:30 -0500
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-20 18:21 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-20 03:52 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 06:58 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-20 12:57 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-20 16:31 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-20 17:31 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-19 08:48 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 17:18 +0000
Re: "Hello world" using Hughs novice package alex@rivadpm.com - 2017-01-19 11:01 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-19 14:51 -0800
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-19 13:07 +0100
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 14:26 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-16 09:03 -0600
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-15 15:08 -1000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-15 17:23 -0800
Re: "Hello world" using Hughs novice package Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-15 22:18 -0500
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-16 09:08 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-18 06:56 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-14 09:31 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-15 17:33 -0600
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-10 09:55 +0000
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-09 04:05 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-09 16:00 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-10 04:13 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-12 06:40 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-02 21:07 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-03 04:46 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-03 16:11 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-04 04:27 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-04 14:26 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-04 23:09 +0000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-05 00:02 +0000
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-05 02:19 -0800
Re: "Hello world" using Hughs novice package rickman <gnuarm@gmail.com> - 2017-01-05 05:56 -0500
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-05 06:33 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-05 16:56 +0100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-05 19:03 +0000
Re: "Hello world" using Hughs novice package rickman <gnuarm@gmail.com> - 2017-01-06 06:45 -0500
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-05 04:27 -0600
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-05 06:22 -0800
Re: "Hello world" using Hughs novice package Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-05 09:10 -0600
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-04 23:05 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-03 22:05 -0800
Re: "Hello world" using Hughs novice package Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-04 13:44 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-01 20:53 -1000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-01 19:55 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-01 21:13 -0800
Re: "Hello world" using Hughs novice package foxaudioresearch@gmail.com - 2017-01-02 07:14 -0800
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-02 07:42 -1000
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-03 02:00 +0100
Re: "Hello world" using Hughs novice package Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-03 00:13 -0500
Re: "Hello world" using Hughs novice package "Elizabeth D. Rather" <erather@forth.com> - 2017-01-02 22:02 -1000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-03 11:19 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-03 21:37 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-02 21:55 -0800
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-03 11:26 +0000
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-02 10:47 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-02 20:57 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 18:35 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-31 04:29 +0100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-31 10:19 +0000
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-02 17:08 +0000
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2017-01-06 13:39 +1100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-05 19:13 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-27 23:57 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2016-12-30 20:54 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-29 19:05 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-29 19:38 -0800
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-30 15:24 +1100
Re: "Hello world" using Hughs novice package Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-30 16:01 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 14:33 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-29 16:04 -0800
Re: "Hello world" using Hughs novice package "HAA" <someone@microsoft.com> - 2016-12-30 12:42 +1100
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-30 07:24 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 12:50 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-30 21:43 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-30 14:38 -0800
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2016-12-31 10:31 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-31 07:04 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-31 07:07 -0800
Re: "Hello world" using Hughs novice package Julian Fondren <julian.fondren@gmail.com> - 2016-12-31 07:46 -0800
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2016-12-31 08:28 -0800
Re: "Hello world" using Hughs novice package albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-30 16:53 +0100
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-06 20:49 -0800
Re: "Hello world" using Hughs novice package Cecil Bayona <cbayona@cbayona.com> - 2017-01-06 23:28 -0600
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-06 22:22 -0800
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-07 14:55 +0100
Re: "Hello world" using Hughs novice package Alex <alex@rivadpm.com> - 2017-01-07 21:20 +0000
Re: "Hello world" using Hughs novice package awegel@arcor.de (Alexander Wegel) - 2017-01-07 22:57 +0100
Re: "Hello world" using Hughs novice package anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-08 17:02 +0000
Re: "Hello world" using Hughs novice package hughaguilar96@gmail.com - 2017-01-08 16:55 -0800
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-05 18:20 -0800 |
| Message-ID | <1f6af8ef-a42e-4718-87ec-423847446043@googlegroups.com> |
| In reply to | #53771 |
On Thursday, January 5, 2017 at 6:50:58 PM UTC-7, Alexander Wegel wrote: > <hughaguilar96@gmail.com> wrote: > > > On Thursday, January 5, 2017 at 5:30:24 AM UTC-7, Alexander Wegel wrote: > > > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: > > > > > > > Perhaps that's > > > > why there is little interest in using Forth libraries - users find them > > > > bug-ridden due to poor testing. > > > > > > Hugh doesn't test properly either, otherwise he would have noticed > > > (sometimes in the last 7 years) that "concrete-alloc" in his package > > > doesn't work. > > > > > > (Just to somewhat get back to the topic.) > > > > CONCRETE-ALLOC works fine. > > > > : aaa <allocation> ; ok > > here . 4785429 ok > > > > dup aaa ok > > . -10 ok > > 20 resize ok > > . 0 ok > > dup aaa ok > > . 20 ok > > free ok > > . 0 ok > > 123 10 concrete-alloc drop ok > . 128 ok > > It corrupts the stack because you used ALIGNED where you should have > used ALIGN. Well, you got me on that one --- it should have been ALIGN rather than ALIGNED in there. > aaa? Cute. You're still a jerk...
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-06 17:58 -0800 |
| Message-ID | <34c5e08a-c623-4407-93fa-e5cea6e5fcc0@googlegroups.com> |
| In reply to | #53772 |
On Thursday, January 5, 2017 at 7:20:50 PM UTC-7, hughag...@gmail.com wrote: > On Thursday, January 5, 2017 at 6:50:58 PM UTC-7, Alexander Wegel wrote: > > <hughaguilar96@gmail.com> wrote: > > > > > On Thursday, January 5, 2017 at 5:30:24 AM UTC-7, Alexander Wegel wrote: > > > > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: > > > > > > > > > Perhaps that's > > > > > why there is little interest in using Forth libraries - users find them > > > > > bug-ridden due to poor testing. > > > > > > > > Hugh doesn't test properly either, otherwise he would have noticed > > > > (sometimes in the last 7 years) that "concrete-alloc" in his package > > > > doesn't work. > > > > > > > > (Just to somewhat get back to the topic.) > > > > > > CONCRETE-ALLOC works fine. > > > > > > : aaa <allocation> ; ok > > > here . 4785429 ok > > > > > > dup aaa ok > > > . -10 ok > > > 20 resize ok > > > . 0 ok > > > dup aaa ok > > > . 20 ok > > > free ok > > > . 0 ok > > > > 123 10 concrete-alloc drop ok > > . 128 ok > > > > It corrupts the stack because you used ALIGNED where you should have > > used ALIGN. > > Well, you got me on that one --- it should have been ALIGN rather than ALIGNED in there. > > > aaa? Cute. > > You're still a jerk... When I wrote CONCRETE-ALLOC I was still using SwiftForth version-2 (which I paid over $400 for). This is how ALIGN and ALIGNED are defined: ICODE ALIGNED ( a -- a ) RET END-CODE \ aligned is noop, no alignment enforced ICODE ALIGN ( -- ) RET END-CODE \ align is noop, no alignment enforced Alex Wegel was wrong when he said that I don't test my code. Testing ANS-Forth code under SwiftForth doesn't work very well because SwiftForth has bugs of its own. It is true however that I should have read the ANS-Forth document more closely so that I would know the difference between ALIGN and ALIGNED so that at some future date when my code runs on an ANS-Forth system other than SwiftForth it will work correctly. Later on when writing my array definers I discovered the bug in SwiftForth when I noticed that ALIGN and ALIGNED weren't working. I pointed this out here: https://groups.google.com/forum/#!searchin/comp.lang.forth/bug$20SwiftForth%7Csort:relevance/comp.lang.forth/YnJWfA31vww/B4XvvHSiKJwJ Not surprisingly, I was attacked for this. Stephen Pelc says: On Sunday, June 13, 2010 at 4:43:09 AM UTC-7, Stephen Pelc wrote: > On Fri, 11 Jun 2010 10:09:24 -0700 (PDT), Hugh Aguilar > <hughaguilar96@yahoo.com> wrote: > > >Check this out: > > > >see aligned > >403F5F RET C3 ok > >see align > >403F7F RET C3 ok > > If you read the ANS standard carefully, you will discover that these > definitions are perfectly legal. A careful reading of the ANS-Forth document does indicate that ALIGN and ALIGNED may or may not align. This is more ambiguity though! Words should do the same thing under every ANS-Forth system. It is ambiguous to have ALIGN and ALIGNED align on some ANS-Forth systems and do nothing on other ANS-Forth systems --- an application program that assumes that they work or that they don't work will not be portable to ANS-Forth systems that do the opposite. The purpose of a standard is portability. Words should be standardized in what they do, and they should do the same thing on every standard system --- all of this "may or may not" ambiguity prevents code from being portable. Also, as a practical matter, all modern processors get a major boost in speed from aligned data. The only x86 processor that didn't, was the 8088 (because it had an 8-bit data-bus), but every x86 from the 8086 upward has benefited from aligned data. Failure to make ALIGN and ALIGNED work properly in SwiftForth indicates a profound lack of knowledge of basic assembly-language programming at Forth Inc.. Here is a post (dated 2010) that really sets the tone for comp.lang.forth for the next 6 years: On Saturday, June 12, 2010 at 6:04:38 PM UTC-7, Josh Grams wrote: > Hugh Aguilar wrote: > > On Jun 12, 9:38?am, Josh Grams <j...@qualdan.com> wrote: > >> Hugh Aguilar wrote: > >>> Check this out: > >> > >>> see aligned > >>> 403F5F ? RET ? ? ? ? ? ? ? ? ? ? ? ? ? ?C3 ok > >>> see align > >>> 403F7F ? RET ? ? ? ? ? ? ? ? ? ? ? ? ? ?C3 ok > >> > >> Yes, on CPUs which don't require alignment, the standard allows them to > >> be no-ops. It's not a bug, just an implementation decision. > > > > The ANS-Forth standard (3.3.3.1) says this: > > "Most addresses used in ANS-Forth are aligned addresses (indicated by > > a-addr) or character-aligned (indicated by c-addr). ... The only way > > to find the next aligned address is with ALIGNED." > > > > Also, the stack picture for ALIGNED is: ( addr -- a-addr ) > > > > The description of ALIGNED says: > > "a-addr is the first aligned address greater than or equal to addr." > > > > What all this means is that ALIGNED is supposed to return an *aligned* > > address. It doesn't matter whether the processor "requires" the > > address to be aligned or not --- it is supposed to be aligned. > > Ah, but you missed the crucial bit: 3.1.3.3 (Addresses) says that "The > set of aligned addresses is an implementation-defined subset of > character-aligned addresses." And "The set of character-aligned > addresses, addresses at which a character can be accessed, is an > implementation-defined subset of all addresses." > > So on a CPU where alignment is not required, an implementation may > define the set of character-aligned addresses and aligned addresses to > be the full set of addresses. Confirming this, A.6.1.0705 ALIGN says > "Implementors may define these words as no-ops on systems for which they > aren't functional." There is language to similar effect in A.3.3.3.1 as > well. > > ALIGN and ALIGNED are present to allow standard programs to work > regardless of what alignment requirements are present, not to provide > natural alignment. > > > Besides that, as a practical matter, any processor bigger that a 65c02 > > is going to have a speed penalty for the use of unaligned addresses, > > even if they aren't strictly required. > > I didn't say that I agreed with the design decision, merely that it is > allowed under the Standard, and is probably intentional, not a bug. As > you found, it's easy enough to redefine them with versions which give > natural alignment, if that's what you want. > > >> Crappy code, as usual. > >> > >> Don't use mod: it's the remainder from a *signed* division. > > > > You are right that I shouldn't have used MOD because it is for signed > > numbers. > > > > But I also think that your remark, "crappy code, as usual," was > > uncalled for. Don't you have any self respect, that you use mean- > > spirited vulgar language like this in a public forum? > > > > When I complained about Passaniti saying that my code "sucks" and that > > After you whined and screamed about Passaniti doing a little bit of > analysis and pointing out that your algorithm wasn't particularly good > at the purpose for which you were recommending... Yeah, that was when I > stopped taking you even a little bit seriously. > > But then at one point I had occasion to say something somewhat > derogatory about your code and post a correction, and you didn't say > anything about it. > > Since then, I've been amusing myself by seeing how long I could get away > with it before you noticed...so I've been escalating. One time you even > complimented me on posting code here (all two or three lines worth!). I > think this is the third time? Quicker than I expected; I thought I'd > get one more round out of it. > > Anyway, I'm done now; I'll go back to ignoring you. > > --Josh
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2017-01-07 14:55 +0100 |
| Message-ID | <1mzhjwm.6lnscg1ulxxr1N%awegel@arcor.de> |
| In reply to | #53793 |
<hughaguilar96@gmail.com> wrote: > > On Thursday, January 5, 2017 at 6:50:58 PM UTC-7, Alexander Wegel wrote: > > > > > Hugh doesn't test properly either, > Alex Wegel was wrong when he said that I don't test my code. Maybe you should start by learning to read. And concerning testing: You left your "test" code in symtab.4th and in association.4th, so every "novice" who happens to try your package gets quite some garbage words for free. Also, because you redefined WITHIN, a forth system isn't ans anymore after loading association.4th.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-05 16:15 +0000 |
| Message-ID | <2017Jan5.171530@mips.complang.tuwien.ac.at> |
| In reply to | #53755 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 30/12/2016 20:21, David N. Williams wrote:
>> On 12/30/16 11:31 AM, Gerry Jackson wrote:
>>> On 28/12/2016 11:23, Anton Ertl wrote:
>>>> The other attitude is that libraries give certain guarantees, and that
>>>> any deviation from that behaviour is a bug in the library, and is
>>>> therefore the library author's responsibility. This means that,
>>>> instead of understanding and checking the whole code of the library,
>>>> you just need to understand the guarantees of the library words you
>>>> use. That attitude is necessary to make libraries practical.
>>>
>>> To back up any guarantees given by a library, my view is that the
>>> library download should include a comprehensive test file, including
>>> corner cases, with the advantages:
>>> - a user can have confidence that the library has been tested
>>> - it provides examples of usage to support any documentation
>>> - the user can easily test it on the Forth system to be used (the author
>>> cannot always do this)
>>> - if the author updates the library he has a regression test to help
>>> verify bugs haven't been introduced
>>>
>>> After all if the author hasn't such a test program available it raises
>>> the question of how thoroughly a system has been tested.
>>
>> Amen, Gerry!
>>
>-
>Yes David, I know you provide such test programs, the only other person
>I can think of who also does is Kishna Myneni. You can see the level of
>interest in this topic from the vast number of responses my post
>provoked:).
It was not provocative enough:-). Why would anybody respond who
agrees?
The only comment that comes to my mind is that I have a worry that a
focus on testing might lead people to neglect the specification side.
But it would still be an advance over the habit that some advocate and
practice of just providing an implementation.
> ISTM that the typical Forther's idea of testing is to type
>in a few tests interpretively and regard the job as done.
That's certainly touted as an advantage of Forth. It's an advantage
in explorative situations, but if it leads to not putting regression
tests in files, it's a disadvantage in the bottom line. Yes,
programmer's responsibility, but given the frequent references to
Forth philosophy or Forth spirit, if that spirit does not include
storing tests for rerunning them later, it has something to do with
programmers not doing it.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2017-01-10 08:43 +0000 |
| Message-ID | <o526oe$4ua$1@dont-email.me> |
| In reply to | #53762 |
On 05/01/2017 16:15, Anton Ertl wrote: > The only comment that comes to my mind is that I have a worry that a > focus on testing might lead people to neglect the specification side. What makes you think that people, in general, spend much time on the specification side? I suspect that is handled in an ad hoc manner. > But it would still be an advance over the habit that some advocate and > practice of just providing an implementation. > Yes and we had another recent example of this with Lehs Big integer package - no evidence of its quality provided at all. I think that lack of provision of test programs, as with lack of documentation, is a mixture of laziness, arrogance, lack of professionalism and just plain ignorance. Laziness because testing is regarded as boring and time consuming. Arrogance because of an attitude that users can report bugs and user's time is less valuable than the authors - the author thinks his programs are bug-free anyway. Unprofessional because it is. >> ISTM that the typical Forther's idea of testing is to type >> in a few tests interpretively and regard the job as done. > That's certainly touted as an advantage of Forth. It's an advantage > in explorative situations, but if it leads to not putting regression > tests in files, it's a disadvantage in the bottom line. Yes, > programmer's responsibility, but given the frequent references to > Forth philosophy or Forth spirit, if that spirit does not include > storing tests for rerunning them later, it has something to do with > programmers not doing it. > I don't understand why they don't do it as it's to their advantage as much as anyone else's. It's easy enough to set up a development environment where a test is developed in parallel with application development. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-12-30 14:37 +0000 |
| Message-ID | <o45rd9$4r3$1@dont-email.me> |
| In reply to | #53572 |
On 28/12/2016 00:35, HAA wrote: > Alexander Wegel wrote: >> <hughaguilar96@gmail.com> wrote: >> >>> So, the whole novice-package is now early-binding. Woo hoo! As a >>> practical matter, the late-binding was never a problem for me. >> Maybe - but in order to write anything worthwhile for others (you're not >> the only novice out there), only thinking of yourself won't cut it - i >> guess that's where you totally fail. >> ... > I don't agree. All that's been demonstrated is that it's difficult to write a > non-trivial ANS portable program that will tick all the boxes. Lots of things in programming are difficult if the programmer hasn't acquired the requisite knowledge and skills, and that includes writing portable programs. If a programmer is too lazy to read the ANS Forth standard and avoid using ambiguous conditions that is the programmer's fault, not the standard's fault. Most moaning seems to be about ambiguous conditions, these are listed in section 4.1.2 of the standard with equivalent sections in each optional wordlist - how difficult is it to read them? Note that I am not defending all the ambiguous conditions in the standard, on the contrary I think it would be better to remove some of them. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-12-30 15:57 +0000 |
| Message-ID | <MPG.32d0943af7f71b0c9896e2@news.virginmedia.com> |
| In reply to | #53608 |
In article <o45rd9$4r3$1@dont-email.me>, gerry@jackson9000.fsnet.co.uk says... > > Note that I am not defending all the ambiguous conditions in the > standard, on the contrary I think it would be better to remove some of them. > > -- > Gerry > A little exposure to first order predicate logic would teach you just how difficult it is not to be ambiguous about anything. I would consider every stack diagram ever produced as ambiguous. I don't see calls to ban them - much less replace them with something better. (in those terms; just to remove some ambiguiy from the statement) -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-12-30 17:19 +0000 |
| Message-ID | <o464rk$cb7$1@dont-email.me> |
| In reply to | #53610 |
On 30/12/2016 15:57, john wrote: > In article <o45rd9$4r3$1@dont-email.me>, gerry@jackson9000.fsnet.co.uk > says... >> >> Note that I am not defending all the ambiguous conditions in the >> standard, on the contrary I think it would be better to remove some of them. >> > > A little exposure to first order predicate logic would teach you just > how difficult it is not to be ambiguous about anything. I was referring to the list(s) of specified ambiguous conditions e.g. section 4.1.2 in the standard, not removing any ambiguities that may exist in the text of the standard. > > I would consider every stack diagram ever produced as ambiguous. To take an example, given the description of the stack notation in section 2.2.2 of the standard and the definition of x in section 3.1 what is ambiguous in the stack diagram for DROP ( x -- ) ? > I don't see calls to ban them - much less replace them with something better. Perhaps that's because people find them useful enough as they are. > (in those terms; just to remove some ambiguiy from the statement) ?? -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-30 21:10 +0000 |
| Message-ID | <o46idt$4en$1@dont-email.me> |
| In reply to | #53615 |
On 12/30/2016 17:19, Gerry Jackson wrote: > On 30/12/2016 15:57, john wrote: >> >> I would consider every stack diagram ever produced as ambiguous. > > To take an example, given the description of the stack notation in > section 2.2.2 of the standard and the definition of x in section 3.1 > what is ambiguous in the stack diagram for DROP ( x -- ) ? Perhaps John means it should be ( depth if " x -- " else "see section A.3.2.3" then ) There comes a point when ambiguity is not the right word (or concept), and I fear we are, courtesy of Hugh Aguilar's banging on about FIND et al's "ambiguities" and ANS Forth's liberal use of the term, well into a rabbit hole, and we need to extricate ourselves. A.3.2.3 (which calls stack underflow a "hard reality") should be considered as, in the defining words of the standard, implementation dependent. ANS Forth says: ambiguous condition: A circumstance for which this Standard does not prescribe a specific behavior for Forth systems and programs. Ambiguous conditions include such things as the absence of a needed delimiter while parsing, attempted access to a nonexistent file, or attempted use of a nonexistent word. An ambiguous condition also exists when a Standard word is passed values that are improper or out of range. implementation defined: Denotes system behaviors or features that must be provided and documented by a system but whose further details are not prescribed by this Standard. implementation dependent: Denotes system behaviors or features that must be provided by a system but whose further details are not prescribed by this Standard [which is the same as IMPLEMENTATION DEFINED but does not require to be documented]. There are 140 (!) uses of AMBIGUOUS CONDITION in the ANS 94 text, 63 of UNDEFINED, and 17 of IMPLEMENTATION DEPENDENT, 22 of IMPLEMENTATION DEFINED. UNDEFINED is undefined; uses of the word seem to be as a synonym of IMPLEMENTATION DEFINED or DEPENDENT. It would help if there were fewer of these definitions, but it would help more if we used the right term. Ambiguous is being used as a catch all, and that's just confusing everyone. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-12-30 12:44 -1000 |
| Message-ID | <quydnfzX59rCfvvFnZ2dnUU7-c_NnZ2d@supernews.com> |
| In reply to | #53622 |
On 12/30/16 11:10 AM, Alex wrote: > On 12/30/2016 17:19, Gerry Jackson wrote: >> On 30/12/2016 15:57, john wrote: > >>> >>> I would consider every stack diagram ever produced as ambiguous. >> >> To take an example, given the description of the stack notation in >> section 2.2.2 of the standard and the definition of x in section 3.1 >> what is ambiguous in the stack diagram for DROP ( x -- ) ? > > Perhaps John means it should be > > ( depth if " x -- " else "see section A.3.2.3" then ) Since the appendices are explicitly non-normative, I don't think it's appropriate to reference them. The text definition for DROP says, "Remove x from the stack." What's ambiguous about this? The ambiguous condition here is a potential stack underflow, which is not a property of DROP or its responsibility, but an appropriate concern of the programmer. It is globally the responsibility of a Forth programmer to provide appropriate stack items to definitions. > There comes a point when ambiguity is not the right word (or concept), > and I fear we are, courtesy of Hugh Aguilar's banging on about FIND et > al's "ambiguities" and ANS Forth's liberal use of the term, well into a > rabbit hole, and we need to extricate ourselves. > > A.3.2.3 (which calls stack underflow a "hard reality") should be > considered as, in the defining words of the standard, implementation > dependent. > > ANS Forth says: > > ambiguous condition: A circumstance for which this Standard does not > prescribe a specific behavior for Forth systems and programs. Ambiguous > conditions include such things as the absence of a needed delimiter > while parsing, attempted access to a nonexistent file, or attempted use > of a nonexistent word. An ambiguous condition also exists when a > Standard word is passed values that are improper or out of range. > > implementation defined: Denotes system behaviors or features that must > be provided and documented by a system but whose further details are not > prescribed by this Standard. > > implementation dependent: Denotes system behaviors or features that > must be provided by a system but whose further details are not > prescribed by this Standard [which is the same as IMPLEMENTATION DEFINED > but does not require to be documented]. > > There are 140 (!) uses of AMBIGUOUS CONDITION in the ANS 94 text, 63 of > UNDEFINED, and 17 of IMPLEMENTATION DEPENDENT, 22 of IMPLEMENTATION > DEFINED. > > UNDEFINED is undefined; uses of the word seem to be as a synonym of > IMPLEMENTATION DEFINED or DEPENDENT. The common synonym for "ambiguous condition" is "error" or "exception". In the development of ANS Forth arguments broke out as to which of those words should be used in various instances, as they have both formal and informal meanings in computing. Haskell.org, for example, warns, "There has been confusion about the distinction between errors and exceptions for a long time, repeated threads in Haskell-Cafe and more and more packages that handle errors and exceptions or something between. Although both terms are related and sometimes hard to distinguish, it is important to do it carefully." After that debate had raged in the Forth TC for some years, the TC finally decided to punt, and replaced all instances of either with "ambiguous condition." We also added the requirement that a compliant system should document its response to certain of them. > It would help if there were fewer of these definitions, but it would > help more if we used the right term. Ambiguous is being used as a catch > all, and that's just confusing everyone. If you or someone would like to undertake going through the current document and propose replacing all reference to "ambiguous condition" with either "error" or "exception" that might or might not be helpful, and would certainly give the committee something to talk about for many years. Meanwhile, programmers should just interpret any possibility of an "ambiguous condition" as something to take steps to avoid. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-30 15:43 -0800 |
| Message-ID | <3b0bc807-3bc5-45cf-865b-2e2e0735a055@googlegroups.com> |
| In reply to | #53626 |
On Friday, December 30, 2016 at 3:44:53 PM UTC-7, Elizabeth D. Rather wrote: > ...programmers should just interpret any possibility of > an "ambiguous condition" as something to take steps to avoid. In 1994 when ANS-Forth came out, approximately 99% of the Forth community noticed that ANS-Forth was infested with ambiguous conditions and so they "took steps to avoid" --- they migrated to C --- that was the only way they knew how to avoid the ambiguous conditions in ANS-Forth. I think that you were totally focused on being the "leading expert" of Forth --- you didn't care if the Forth community was reduced in size to 1% of its former population --- you only cared about being the queen bee, even if you retained only 20 unthinking drones out of the previous population of 2000 intelligent programmers. I would estimate that today there are maybe 20 ANS-Forth programmers in the world. ANS-Forth is a failure! My goal with Straight Forth is much different. I want to save Forth --- make Forth a viable language again. I will accept decisions that are contrary to my own opinion --- I will require that decisions be made though --- it is better to make a bad decision than no decision at all. I won't compromise by making an ambiguous condition in which two contradictory decisions are both accepted as standard, so that everybody can be happy, but ultimately everybody is unhappy because their programs aren't portable which was the whole point of having a standard. As an example, I think that TRUE should be 1 --- Ilya Tarasov thinks that TRUE should be -1 (at least we do agree that FALSE should be 0) --- he suggested having a switch so that the end-user could decide, but I said that that is a terrible idea because programs won't be portable; it is better to just make a decision one way or the other and stick with it (half the people will be unhappy, but they will get over it; this isn't kindergarten where everybody demands that things are done their way or they will cry).
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-31 00:09 +0000 |
| Message-ID | <o46stk$c6m$1@dont-email.me> |
| In reply to | #53626 |
On 12/30/2016 22:44, Elizabeth D. Rather wrote:
> On 12/30/16 11:10 AM, Alex wrote:
>> On 12/30/2016 17:19, Gerry Jackson wrote:
>>> On 30/12/2016 15:57, john wrote:
>>
>>>>
>>>> I would consider every stack diagram ever produced as ambiguous.
>>>
>>> To take an example, given the description of the stack notation in
>>> section 2.2.2 of the standard and the definition of x in section 3.1
>>> what is ambiguous in the stack diagram for DROP ( x -- ) ?
>>
>> Perhaps John means it should be
>>
>> ( depth if " x -- " else "see section A.3.2.3" then )
>
> Since the appendices are explicitly non-normative, I don't think it's
> appropriate to reference them. The text definition for DROP says,
> "Remove x from the stack." What's ambiguous about this?
>
Nothing, and that's my point below.
> The ambiguous condition here is a potential stack underflow, which is
> not a property of DROP or its responsibility, but an appropriate concern
> of the programmer. It is globally the responsibility of a Forth
> programmer to provide appropriate stack items to definitions.
Yes. I was only using it as an illustration of John's argument.
>
>> There comes a point when ambiguity is not the right word (or concept),
>> and I fear we are, courtesy of Hugh Aguilar's banging on about FIND et
>> al's "ambiguities" and ANS Forth's liberal use of the term, well into a
>> rabbit hole, and we need to extricate ourselves.
See point above.
>>
>> A.3.2.3 (which calls stack underflow a "hard reality") should be
>> considered as, in the defining words of the standard, implementation
>> dependent.
>>
>> ANS Forth says:
>>
>> ambiguous condition: A circumstance for which this Standard does not
>> prescribe a specific behavior for Forth systems and programs. Ambiguous
>> conditions include such things as the absence of a needed delimiter
>> while parsing, attempted access to a nonexistent file, or attempted use
>> of a nonexistent word. An ambiguous condition also exists when a
>> Standard word is passed values that are improper or out of range.
>>
>> implementation defined: Denotes system behaviors or features that must
>> be provided and documented by a system but whose further details are not
>> prescribed by this Standard.
>>
>> implementation dependent: Denotes system behaviors or features that
>> must be provided by a system but whose further details are not
>> prescribed by this Standard [which is the same as IMPLEMENTATION DEFINED
>> but does not require to be documented].
>>
>> There are 140 (!) uses of AMBIGUOUS CONDITION in the ANS 94 text, 63 of
>> UNDEFINED, and 17 of IMPLEMENTATION DEPENDENT, 22 of IMPLEMENTATION
>> DEFINED.
>>
>> UNDEFINED is undefined; uses of the word seem to be as a synonym of
>> IMPLEMENTATION DEFINED or DEPENDENT.
>
> The common synonym for "ambiguous condition" is "error" or "exception".
> In the development of ANS Forth arguments broke out as to which of those
> words should be used in various instances, as they have both formal and
> informal meanings in computing. Haskell.org, for example, warns, "There
> has been confusion about the distinction between errors and exceptions
> for a long time, repeated threads in Haskell-Cafe and more and more
> packages that handle errors and exceptions or something between.
> Although both terms are related and sometimes hard to distinguish, it is
> important to do it carefully." After that debate had raged in the Forth
> TC for some years, the TC finally decided to punt, and replaced all
> instances of either with "ambiguous condition." We also added the
> requirement that a compliant system should document its response to
> certain of them.
I disagree with the characterisation of "ambiguous condition" as error
or exception; rather it is an unclassified *state*. It's the ultimate
"here be dragons". The section 3.4.4 talks of *actions* on an ambiguous
condition, but declines to rule out anything; that's a different issue.
===
3.4.4 Possible actions on an ambiguous condition
When an ambiguous condition exists, a system may take one or more of the
following actions:
ignore and continue;
display a message;
execute a particular word;
set interpretation state and begin text interpretation;
take other implementation-defined actions;
take implementation-dependent actions.
The response to a particular ambiguous condition need not be the same
under all circumstances.
===
>
>> It would help if there were fewer of these definitions, but it would
>> help more if we used the right term. Ambiguous is being used as a catch
>> all, and that's just confusing everyone.
>
> If you or someone would like to undertake going through the current
> document and propose replacing all reference to "ambiguous condition"
> with either "error" or "exception" that might or might not be helpful,
As above, it's not what's required. Calling everything "ambiguous" is
not helpful, and Hugh is doing it (again) on another thread in reference
to the lack of specificity in relation to the control stack.
> and would certainly give the committee something to talk about for many
> years. Meanwhile, programmers should just interpret any possibility of
> an "ambiguous condition" as something to take steps to avoid.
It will not prevent Hugh's indignation.
>
> Cheers,
> Elizabeth
>
--
Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-03 17:25 +0000 |
| Message-ID | <2017Jan3.182539@mips.complang.tuwien.ac.at> |
| In reply to | #53630 |
Alex <alex@rivadpm.com> writes:
>I disagree with the characterisation of "ambiguous condition" as error
>or exception; rather it is an unclassified *state*. It's the ultimate
>"here be dragons".
In some cases it's just that different systems do different things,
and they could not agree (or saw no reason to agree) on a common
behaviour in the standards process. An example is
|An ambiguous condition exists if RECURSE appears in a definition after
|DOES>.
If you want to write a standard program, you will consider this an
error, but if you just want to run on one system and find that your
system does something you want to make use of for this condition, it's
not an error.
Of course, if a particular behaviour is considered useful by a number
of people, it may be a good idea to make it the standard behaviour
rather than just leaving is in limbo as ambiguous condition.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-12-30 22:47 +0000 |
| Message-ID | <MPG.32d0f4729fd30d6b9896e3@news.virginmedia.com> |
| In reply to | #53622 |
In article <o46idt$4en$1@dont-email.me>, alex@rivadpm.com says... > Perhaps John means it should be > > ( depth if " x -- " else "see section A.3.2.3" then ) > > There comes a point when ambiguity is not the right word (or concept), > and I fear we are, courtesy of Hugh Aguilar's banging on about FIND et > al's "ambiguities" and ANS Forth's liberal use of the term, well into a > rabbit hole, and we need to extricate ourselves. > Precisely. a stack diagram is a mechanics tool not a specification nor documentation. It's useful but must be used with care when transporting code. Assumptions must be made - ambiguity is the norm - on the surface. A standard can say the letter 'u' stands for a 4 byte unsigned integer but unless it also says what a byte is you have ambiguity. There are always limits. Specifications exist to resolve ambiguity - standards have another job. More wobbly bridges are built across rivers because people don't understand the difference between a standard and a specification than for many other reasons I suspect. A standard isn't there to be totally unambigous - it's there to point the way towards compatibility - ( "standard n : defn. a rallying point" ) following it means your code "should" "mostly" work elsewhere but always prepare for issues. Ambiguous use of the word ambiguous is unhelpful also I agree. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-31 03:31 -0600 |
| Message-ID | <TbCdnQj7zLVu5_rFnZ2dnUU7-L_NnZ2d@supernews.com> |
| In reply to | #53615 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: > > I was referring to the list(s) of specified ambiguous conditions e.g. > section 4.1.2 in the standard, not removing any ambiguities that may > exist in the text of the standard. There are some which should be very easy to remove, and some which are hard. Some wouldn't be very hard to remove, but would impose a runtime overhead. In some, removing an ambiguous condition would significantly increase the complexity of a small system. I don't think it makes sense to talk about ambiguous conditions in the abstract. Each one has its own meaning and they don't have very much to do with one another. It makes more sense to say "Let's remove this ambiguous condition. Here's how." Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-30 15:46 +0000 |
| Message-ID | <2016Dec30.164657@mips.complang.tuwien.ac.at> |
| In reply to | #53608 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 28/12/2016 00:35, HAA wrote:
>> Alexander Wegel wrote:
>>> <hughaguilar96@gmail.com> wrote:
>>>
>>>> So, the whole novice-package is now early-binding. Woo hoo! As a
>>>> practical matter, the late-binding was never a problem for me.
>>> Maybe - but in order to write anything worthwhile for others (you're not
>>> the only novice out there), only thinking of yourself won't cut it - i
>>> guess that's where you totally fail.
>>> ...
>> I don't agree. All that's been demonstrated is that it's difficult to write a
>> non-trivial ANS portable program that will tick all the boxes.
>
>Lots of things in programming are difficult if the programmer hasn't
>acquired the requisite knowledge and skills, and that includes writing
>portable programs. If a programmer is too lazy to read the ANS Forth
>standard and avoid using ambiguous conditions that is the programmer's
>fault, not the standard's fault.
That's debatable, but is not the issue at hand here. Hugh Aguilar
used EVALUATE-based macros extensively, despite their known and
well-publicized pitfalls
<https://www.complang.tuwien.ac.at/forth/why-evaluate-is-bad>. No
ambiguous condition is involved here; his program, including pitfalls,
is portable between systems, and you can portably fall into these
pitfalls on every standard system with the code posted by Alexander
Wegel.
So what has been demonstrated is that you can shoot your user in the
foot in ANS Forth, or, using another figure of speech, ANS Forth gives
you enough rope to hang your user, but that's what I expect from a
Forth standard: the programmer is responsible. The fact that many in
the Forth community neglect to take that responsibility serious, and
just say "it has never been a problem for me/my paying customers", and
think that's good enough, is, however, cause for worry.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-30 15:05 -0800 |
| Message-ID | <3e9b1681-4134-4685-8691-c0e395ee1c91@googlegroups.com> |
| In reply to | #53608 |
On Friday, December 30, 2016 at 7:37:56 AM UTC-7, Gerry wrote: > On 28/12/2016 00:35, HAA wrote: > > Alexander Wegel wrote: > >> <hughaguilar96@gmail.com> wrote: > >> > >>> So, the whole novice-package is now early-binding. Woo hoo! As a > >>> practical matter, the late-binding was never a problem for me. > >> Maybe - but in order to write anything worthwhile for others (you're not > >> the only novice out there), only thinking of yourself won't cut it - i > >> guess that's where you totally fail. > >> ... > > I don't agree. All that's been demonstrated is that it's difficult to write a > > non-trivial ANS portable program that will tick all the boxes. > > Lots of things in programming are difficult if the programmer hasn't > acquired the requisite knowledge and skills, and that includes writing > portable programs. If a programmer is too lazy to read the ANS Forth > standard and avoid using ambiguous conditions that is the programmer's > fault, not the standard's fault. Most moaning seems to be about > ambiguous conditions, these are listed in section 4.1.2 of the standard > with equivalent sections in each optional wordlist - how difficult is it > to read them? > > Note that I am not defending all the ambiguous conditions in the > standard, on the contrary I think it would be better to remove some of them. Here Gerry is parroting the same fake argument that Alex McDonald has used in the past --- that is, to claim that section 4.1.2. lists all of the ambiguous conditions in ANS-Forth --- that is totally untrue; the entire document is infested with ambiguous conditions from top to bottom. This is the thread where I figured out that disambiguifiers can be used to fix the broken FIND in ANS-Forth. Here we have a quote showing Alex McDonald using the bogus argument that section 4.1.2. lists all of the ambiguous conditions in ANS-Forth: On Friday, June 19, 2015 at 7:56:27 PM UTC-7, hughag...@gmail.com wrote: > On Thursday, June 18, 2015 at 11:58:39 PM UTC-7, Raimond Dragomir wrote: > > > > If you take out all ambiguities what does remain? How much of it? I > > > > said there are TOO MANY ambiguities. > > > > > > Section "4.1.2 Ambiguous conditions" covers them all. Which ones would > > > you make unambiguous? > > > > > TOO MANY. I don't have the time here to fix the standard. I also don't > > trust you that you really want this answer from me. I also don't believe > > that anybody that could really have the power to modify the standard > > will ever listen to me. Stephen Pelc said that clearly. > > Raimond, that was a trick question and you didn't notice. > > Section 4.1.2 "Ambiguous Conditions" doesn't cover all the ambiguous conditions. For example, in section 3.2.3.2 we have this: "The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack." That is pretty ambiguous --- the whole standard is corrupted with ambiguity such as this --- ambiguity is not limited to section 4.1.2. > ... > This thread has run for over 200 posts now, and Stephen Pelc has yet to say: "Thanks for fixing that bug in VFX; I'll put your disambiguifiers in my next VFX release." Apparently writing portable code isn't an entirely egoless discipline, but there are in fact some quite large egos involved who can't bring themselves to admit a mistake even after it has become abundantly obvious.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-31 00:26 +0000 |
| Message-ID | <o46tsj$f81$1@dont-email.me> |
| In reply to | #53628 |
On 12/30/2016 23:05, hughaguilar96@gmail.com wrote: > On Friday, December 30, 2016 at 7:37:56 AM UTC-7, Gerry wrote: >> >> Note that I am not defending all the ambiguous conditions in the >> standard, on the contrary I think it would be better to remove some >> of them. > > Here Gerry is parroting the same fake argument that Alex McDonald has > used in the past --- that is, to claim that section 4.1.2. lists all > of the ambiguous conditions in ANS-Forth --- that is totally untrue; > the entire document is infested with ambiguous conditions from top to > bottom. > > This is the thread where I figured out that disambiguifiers can be > used to fix the broken FIND in ANS-Forth. Here we have a quote > showing Alex McDonald using the bogus argument that section 4.1.2. > lists all of the ambiguous conditions in ANS-Forth: > > On Friday, June 19, 2015 at 7:56:27 PM UTC-7, hughag...@gmail.com > wrote: >> On Thursday, June 18, 2015 at 11:58:39 PM UTC-7, Raimond Dragomir >> wrote: >>>>> If you take out all ambiguities what does remain? How much of >>>>> it? I said there are TOO MANY ambiguities. >>>> >>>> Section "4.1.2 Ambiguous conditions" covers them all. Which >>>> ones would you make unambiguous? >>>> >>> TOO MANY. I don't have the time here to fix the standard. I also >>> don't trust you that you really want this answer from me. I also >>> don't believe that anybody that could really have the power to >>> modify the standard will ever listen to me. Stephen Pelc said >>> that clearly. >> >> Raimond, that was a trick question and you didn't notice. >> >> Section 4.1.2 "Ambiguous Conditions" doesn't cover all the >> ambiguous conditions. For example, in section 3.2.3.2 we have this: >> "The control-flow stack may, but need not, physically exist in an >> implementation. If it does exist, it may be, but need not be, >> implemented using the data stack." That is pretty ambiguous --- the It's not an "ambiguous condition", since the definition of ambiguous condition only talks about *dynamic state*. 3.2.3.2 is talking about implementation specification, and telling you explcitly that there are many ways of implementing the control stack; the standard doesn't exclude any. The same warning about implementation also applies to FIND. ambiguous condition: A circumstance for which this Standard does not prescribe a specific behavior for Forth systems and programs. Ambiguous conditions include such things as the absence of a needed delimiter while parsing, attempted access to a nonexistent file, or attempted use of a nonexistent word. An ambiguous condition also exists when a Standard word is passed values that are improper or out of range. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-31 11:49 +1100 |
| Message-ID | <o46v9d$uji$1@gioia.aioe.org> |
| In reply to | #53608 |
Gerry Jackson wrote: > On 28/12/2016 00:35, HAA wrote: > > Alexander Wegel wrote: > >> <hughaguilar96@gmail.com> wrote: > >> > >>> So, the whole novice-package is now early-binding. Woo hoo! As a > >>> practical matter, the late-binding was never a problem for me. > >> Maybe - but in order to write anything worthwhile for others (you're not > >> the only novice out there), only thinking of yourself won't cut it - i > >> guess that's where you totally fail. > >> ... > > I don't agree. All that's been demonstrated is that it's difficult to write a > > non-trivial ANS portable program that will tick all the boxes. > > Lots of things in programming are difficult if the programmer hasn't > acquired the requisite knowledge and skills, and that includes writing > portable programs. If a programmer is too lazy to read the ANS Forth > standard and avoid using ambiguous conditions that is the programmer's > fault, not the standard's fault. Most moaning seems to be about > ambiguous conditions, these are listed in section 4.1.2 of the standard > with equivalent sections in each optional wordlist - how difficult is it > to read them? > > Note that I am not defending all the ambiguous conditions in the > standard, on the contrary I think it would be better to remove some of them. Removing choice is of course what standards do. Standards are an ever narrowing jail that ultimately chokes on itself. 47 years of Forth standards, 23 years since ANS, 10 years since 200x and no programs or users to speak of. That's what standards in Forth have achieved.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-12-30 15:21 -1000 |
| Message-ID | <dqCdnYEY2vqBlfrFnZ2dnUU7-cvNnZ2d@supernews.com> |
| In reply to | #53632 |
On 12/30/16 2:49 PM, HAA wrote: > Gerry Jackson wrote: >> On 28/12/2016 00:35, HAA wrote: >>> Alexander Wegel wrote: >>>> <hughaguilar96@gmail.com> wrote: >>>> >>>>> So, the whole novice-package is now early-binding. Woo hoo! As a >>>>> practical matter, the late-binding was never a problem for me. >>>> Maybe - but in order to write anything worthwhile for others (you're not >>>> the only novice out there), only thinking of yourself won't cut it - i >>>> guess that's where you totally fail. >>>> ... >>> I don't agree. All that's been demonstrated is that it's difficult to write a >>> non-trivial ANS portable program that will tick all the boxes. >> >> Lots of things in programming are difficult if the programmer hasn't >> acquired the requisite knowledge and skills, and that includes writing >> portable programs. If a programmer is too lazy to read the ANS Forth >> standard and avoid using ambiguous conditions that is the programmer's >> fault, not the standard's fault. Most moaning seems to be about >> ambiguous conditions, these are listed in section 4.1.2 of the standard >> with equivalent sections in each optional wordlist - how difficult is it >> to read them? >> >> Note that I am not defending all the ambiguous conditions in the >> standard, on the contrary I think it would be better to remove some of them. > > Removing choice is of course what standards do. Standards are an ever > narrowing jail that ultimately chokes on itself. 47 years of Forth standards, > 23 years since ANS, 10 years since 200x and no programs or users to > speak of. That's what standards in Forth have achieved. On the contrary, there are a number of standard systems available, and quite a few programmers using them. They have been the basis of some major projects, many of which I have referenced here over the years. The advent of ANS Forth liberated Forth system developers from the constraints of implementation specifications in Forth83, making possible the era of optimizing compilers and other advances that have led to faster, more powerful systems. It has brought freedom, not jail. Every significant language has standards, and all of them have their critics, just as Forth Standards do. But they are widely respected and influential, even in systems that do not choose to follow them rigorously. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web