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 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-19 14:58 -0800 |
| Message-ID | <b8816559-4bd6-4166-adb6-61f51595154b@googlegroups.com> |
| In reply to | #54175 |
> > If Forth simply stop the program it is not a self-destruction. > > It is if the program is contolling your rocket. Not every Russian has a rocket in home :) Bear, barrel of vodka, nuclear reactor - probably, but rocket? > > Unhandled THROW is worse than ABORT. > > No it isn't. Unhandled THROW is exactly the same as ABORT. Ok, try to explain why THROW is required every time. Not to me, but to a customer who is ready to leave you with your Forth, unless you persuade him it is a great, simple and powerful language to describe anything he may want. > Err, no. I didn't say don't write Forth for Windows. If you need to > handle that system, you need Windows interface words. I did it, and now use Windows for system modelling when move code to an FPGA. I don't need a long list of rules and restrictions.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-20 03:48 -0600 |
| Message-ID | <JoCdnSRLXctDQRzFnZ2dnUU7-cnNnZ2d@supernews.com> |
| In reply to | #54186 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> > If Forth simply stop the program it is not a self-destruction. >> >> It is if the program is contolling your rocket. > > Not every Russian has a rocket in home :) Bear, barrel of vodka, > nuclear reactor - probably, but rocket? I'm assuming that your program is important because it is needed for a purpose. If your program has no purpose, it does not matter what it does when there has an error. >> > Unhandled THROW is worse than ABORT. >> >> No it isn't. Unhandled THROW is exactly the same as ABORT. > > Ok, try to explain why THROW is required every time. Not to me, but > to a customer who is ready to leave you with your Forth, unless you > persuade him it is a great, simple and powerful language to describe > anything he may want. OK, this is what I'd say. You must always be prepared to handle errors which may occur. Simply saying OPEN-FILE THROW is the simplest action during development, and if unhandled returns to the command line. The system cannot know which action to take. It may be necessary to perform a graceful shutdown if it's impossible to proceed. It may be that this action is inessential: for example, if this is a log file, you'd disable logging but continue to do other tasks. But you cannot simply proceed as though the OPEN-FILE succeeded. Andrew
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-20 06:54 -0800 |
| Message-ID | <e283b194-816d-4e24-97c6-c9a8f9e82869@googlegroups.com> |
| In reply to | #54197 |
> I'm assuming that your program is important because it is needed for a > purpose. If your program has no purpose, it does not matter what it > does when there has an error. It is important, but such things as file existence must be provided. Usually is no workaround when file is missing. > You must always be prepared to handle errors which may occur. Simply > saying OPEN-FILE THROW is the simplest action during development, and > if unhandled returns to the command line. > > The system cannot know which action to take. It may be necessary to > perform a graceful shutdown if it's impossible to proceed. It may be > that this action is inessential: for example, if this is a log file, > you'd disable logging but continue to do other tasks. But you cannot > simply proceed as though the OPEN-FILE succeeded. Ok, you are explaining why error checking must be in place. Next question - why don't hide THROW into file IO words? When programmer constantly see OPEN-FILE THROW .. READ-FILE THROW ... CLOSE-FILE THROW, the question is 'why do I need so many THROWs?'. Error while opening file don't cause the entire Forth system to crash. It is possible just returns to command line and wait for a new input. This is a desired behavior by many users. Typing many CATHC/THROW without clear effect is not what they want.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-20 09:11 -0600 |
| Message-ID | <EIOdnbS4w68GtR_FnZ2dnUU7-LXNnZ2d@supernews.com> |
| In reply to | #54203 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > >> You must always be prepared to handle errors which may occur. Simply >> saying OPEN-FILE THROW is the simplest action during development, and >> if unhandled returns to the command line. >> >> The system cannot know which action to take. It may be necessary to >> perform a graceful shutdown if it's impossible to proceed. It may be >> that this action is inessential: for example, if this is a log file, >> you'd disable logging but continue to do other tasks. But you cannot >> simply proceed as though the OPEN-FILE succeeded. > > Ok, you are explaining why error checking must be in place. Next > question - why don't hide THROW into file IO words? Because it's sometimes better to use a more lightweight way to handle failure, especially if failure is not exceptional, as in the case where a filename is provided by a user. It'd be a shame to tie the file I/O wordset to the (optional) exception wordset. That's the point: Standard Forth does force you do do it one way or the other way. > When programmer constantly see OPEN-FILE THROW .. READ-FILE THROW > ... CLOSE-FILE THROW, the question is 'why do I need so many > THROWs?'. It's a really good warning for the programmer. Look here! This word might throw an error! You need to do something! > Error while opening file don't cause the entire Forth system to > crash. It is possible just returns to command line and wait for a > new input. This is a desired behavior by many users. Typing many > CATHC/THROW without clear effect is not what they want. Tough for them. Real programs must handle errors. Of course you can fit a Forth with children's training wheels for beginners, but this is the real world, and stuff goes wrong. Time to put away childish things. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-20 07:30 -0800 |
| Message-ID | <844188a3-62af-416b-8b7d-e0db19d09b06@googlegroups.com> |
| In reply to | #54205 |
> > Ok, you are explaining why error checking must be in place. Next > > question - why don't hide THROW into file IO words? > > Because it's sometimes better to use a more lightweight way to handle > failure, especially if failure is not exceptional, as in the case > where a filename is provided by a user. It'd be a shame to tie the > file I/O wordset to the (optional) exception wordset. That's the > point: Standard Forth does force you do do it one way or the other > way. Yes, by slightly delay ABORT (by THROW) or by ignoring the error (by DROP). In any case, why this parameter ever leaved on stack? What else language or file IO library do it this way? > > When programmer constantly see OPEN-FILE THROW .. READ-FILE THROW > > ... CLOSE-FILE THROW, the question is 'why do I need so many > > THROWs?'. > > It's a really good warning for the programmer. Look here! This word > might throw an error! You need to do something! Do you think programmer don't know this may happens? Handle error properly, and don't provoke programmer to make errors in his code. > > Error while opening file don't cause the entire Forth system to > > crash. It is possible just returns to command line and wait for a > > new input. This is a desired behavior by many users. Typing many > > CATHC/THROW without clear effect is not what they want. > > Tough for them. Real programs must handle errors. Of course you can > fit a Forth with children's training wheels for beginners, but this is > the real world, and stuff goes wrong. Time to put away childish > things. You unreasonable bind THROW after file IO words with errors handling. Errors handling may be provided by many ways. THROW is only one of them. Other file IO libraries use file handler as a result, and programmer may check it. The fact is an attempt to open wrong file will not crash the program! Any action is allowed after having result, and ANS Forth doing exactly the same. If you OPEN-FILE so dangerous, how you can ever hope next word will be executed? However, you claim placing THROW after OPEN-FILE will fix the situation by some magic way. This is not true. a THROW words is just a next word, and OPEN-FILE must return control first. In this case, you can use other words to handle IO result. The difference here is ANS use (... -- handle, ior ) when common approach is to return handle, with known illegal values indicating operation failure. You can check it and use any error handling you want. This is want many programmers already know, and they may want to use common file IO libraries, instead of venerating Forth brilliant ideas. So I can't agreed ANS-Forth approach is 'not childish' while POSIX is 'childish' (???!!!!). I state this before - I just use POSIX for file IO (and other well-known approaches whenever possible) to minimize efforts to adapt Forth.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-20 12:12 -0600 |
| Message-ID | <GfSdnXBCyf-Bzh_FnZ2dnUU7-YXNnZ2d@supernews.com> |
| In reply to | #54206 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> > Ok, you are explaining why error checking must be in place. Next >> > question - why don't hide THROW into file IO words? >> >> Because it's sometimes better to use a more lightweight way to handle >> failure, especially if failure is not exceptional, as in the case >> where a filename is provided by a user. It'd be a shame to tie the >> file I/O wordset to the (optional) exception wordset. That's the >> point: Standard Forth does force you do do it one way or the other >> way. > > Yes, by slightly delay ABORT (by THROW) or by ignoring the error (by > DROP). In any case, why this parameter ever leaved on stack? So that you can say OPEN-FILE IF . > What else language or file IO library do it this way? > >> > When programmer constantly see OPEN-FILE THROW .. READ-FILE THROW >> > ... CLOSE-FILE THROW, the question is 'why do I need so many >> > THROWs?'. >> >> It's a really good warning for the programmer. Look here! This word >> might throw an error! You need to do something! > > Do you think programmer don't know this may happens? Handle error > properly, and don't provoke programmer to make errors in his code. :-) > The fact is an attempt to open wrong file will not crash the > program! Indeed it will not. > Any action is allowed after having result, and ANS Forth doing > exactly the same. If you OPEN-FILE so dangerous, how you can ever > hope next word will be executed? This question does not make any sense. > However, you claim placing THROW after OPEN-FILE will fix the > situation by some magic way. No, I do not claim that. > a THROW words is just a next word, and OPEN-FILE must return control > first. In this case, you can use other words to handle IO result. > The difference here is ANS use (... -- handle, ior ) when common > approach is to return handle, with known illegal values indicating > operation failure. This is one of the ways in which Forth is better. You don't have to say something like open-file dup 0= if io-error throw then ... actions you can just say open-file throw ... actions This is obviously superior. > This is want many programmers already know, and they may want to use > common file IO libraries, instead of venerating Forth brilliant > ideas. That's their loss. Forth has its own idioms. You can write Forth as some kind of reverse polish C but the result will not be pretty. > So I can't agreed ANS-Forth approach is 'not childish' while > POSIX is 'childish' (???!!!!). Neither can I. And you will note that I didn't say so. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-20 16:27 -0800 |
| Message-ID | <63f6f376-378a-4ab0-97e1-a78647f87663@googlegroups.com> |
| In reply to | #54207 |
> > Yes, by slightly delay ABORT (by THROW) or by ignoring the error (by > > DROP). In any case, why this parameter ever leaved on stack? > > So that you can say OPEN-FILE IF . I don't want to chaotically choose syntax when invent a workaround. I can use ( -- handle, ior ) notation by many ways. Why I even must think about this, if I have an experience in other languages and want just to copy that approach to Forth? This is what I want to say - be more customer-facing and don't dictate strange ways for common things if it is not critical. > > The fact is an attempt to open wrong file will not crash the > > program! > > Indeed it will not. This is a kind of trap you did for yourself :) I just run QuarkForth and type " 3645453633.txt" OPEN (I know there is no file with this name). I see -1 on the top of stack and Quark is ready for next command. What's wrong? If your Forth will crash in this situation, it is bad implementation. > > However, you claim placing THROW after OPEN-FILE will fix the > > situation by some magic way. > > No, I do not claim that. If you not claim that, why you want to leave ior for THROW at all cost? Why it is better? I told you this is uncommon, and many programmers know function, returning only one parameter. Why do you want to break their habit? > This is one of the ways in which Forth is better. You don't have to > say something like > > open-file dup 0= if io-error throw then ... actions > > you can just say > > open-file throw ... actions I don't want to throw anything :) CREATE CODE[] 16384 ALLOT " codelx4.dat" OPEN TO HF-OUT HF-OUT CODE[] 10374 READFILE HF-OUT CLOSE 99% chances to have all Ok. A message from OS or simple empty output is enough to identify something is wrong. For a rocket (bear, barrel of vodka etc) I will check file IO result. Engineer who work with pcb, soldering station and analog schemes, simple code is preferred and he can call programmer to add some safety. > This is obviously superior. Yes, this is a way to show superiority, but why? Ok, engineer leaving you (and muttering 'stay with your favourite toy, smart boy'). Two programmers for full-time at Forth Inc, right? > > This is want many programmers already know, and they may want to use > > common file IO libraries, instead of venerating Forth brilliant > > ideas. > > That's their loss. Forth has its own idioms. You can write Forth as > some kind of reverse polish C but the result will not be pretty. Two programmers, right? This is an answer :)
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-21 03:24 -0600 |
| Message-ID | <meOdnQFZF5YitR7FnZ2dnUU7-LnNnZ2d@supernews.com> |
| In reply to | #54211 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> > Yes, by slightly delay ABORT (by THROW) or by ignoring the error (by >> > DROP). In any case, why this parameter ever leaved on stack? >> >> So that you can say OPEN-FILE IF . > > I don't want to chaotically choose syntax when invent a > workaround. I can use ( -- handle, ior ) notation by many ways. Why > I even must think about this, if I have an experience in other > languages and want just to copy that approach to Forth? Becuase the Forth way is better. Obviously. >> > The fact is an attempt to open wrong file will not crash the >> > program! >> >> Indeed it will not. > > This is a kind of trap you did for yourself :) I just run QuarkForth > and type " 3645453633.txt" OPEN (I know there is no file with this > name). I see -1 on the top of stack and Quark is ready for next > command. What's wrong? If your Forth will crash in this situation, > it is bad implementation. Probably. I have no idea what you are talking about. >> > However, you claim placing THROW after OPEN-FILE will fix the >> > situation by some magic way. >> >> No, I do not claim that. > > If you not claim that, why you want to leave ior for THROW at all > cost? Why it is better? Already asked and answered. >> This is one of the ways in which Forth is better. You don't have to >> say something like >> >> open-file dup 0= if io-error throw then ... actions >> >> you can just say >> >> open-file throw ... actions > > I don't want to throw anything :) > > CREATE CODE[] 16384 ALLOT > > " codelx4.dat" OPEN TO HF-OUT > HF-OUT CODE[] 10374 READFILE > HF-OUT CLOSE > > 99% chances to have all Ok. This is horrible code. It is unsuitable for almost any use. 99% is not good enough. >> This is obviously superior. > > Yes, this is a way to show superiority, but why? Ok, engineer > leaving you (and muttering 'stay with your favourite toy, smart > boy'). Two programmers for full-time at Forth Inc, right? This makes no sense. >> > This is want many programmers already know, and they may want to use >> > common file IO libraries, instead of venerating Forth brilliant >> > ideas. >> >> That's their loss. Forth has its own idioms. You can write Forth as >> some kind of reverse polish C but the result will not be pretty. > > Two programmers, right? This is an answer :) An answer to what? You won't make any programming language more popular by making it worse. Especially in such tivial ways. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-22 12:47 -0800 |
| Message-ID | <ed02e6c2-cd65-4f49-9754-8af1ef0a32c7@googlegroups.com> |
| In reply to | #54221 |
> > I don't want to chaotically choose syntax when invent a > > workaround. I can use ( -- handle, ior ) notation by many ways. Why > > I even must think about this, if I have an experience in other > > languages and want just to copy that approach to Forth? > > Becuase the Forth way is better. Obviously. Sorry, I don't accept your right to determine what is a Forth way. File operations not invented by Moore and don't Forth-specific. Many things are similar for different languages, and Forth can't change it. > > This is a kind of trap you did for yourself :) I just run QuarkForth > > and type " 3645453633.txt" OPEN (I know there is no file with this > > name). I see -1 on the top of stack and Quark is ready for next > > command. What's wrong? If your Forth will crash in this situation, > > it is bad implementation. > > Probably. I have no idea what you are talking about. This is a key question here. You told having THROW after file IO is a key element of code safety. This is not an exclusive way to handle file IO errors. A disadvantage of ( -- handle, ior ) is this is incompatible with common file IO libraries, and programmers will need to learn this difference. My point we need to copy existing call conventions if it is not Forth-specific. > > CREATE CODE[] 16384 ALLOT > > > > " codelx4.dat" OPEN TO HF-OUT > > HF-OUT CODE[] 10374 READFILE > > HF-OUT CLOSE > > > > 99% chances to have all Ok. > > This is horrible code. It is unsuitable for almost any use. 99% is > not good enough. Again, I don't accept your right to give irrevocably marks to my code. This example was in use only once :) Looking for filename and explicit literals (not constants, as usual), I remember it was a simple conversion script for FPGA data exported by cross-compiler. So it is a script, not a program for rocket or nuclear reactor. It still can be made more safe by using ior checking, but why? This is a kind of command, typing in console for copying file. Are you require ior checking for 'copy file1.txt file2.txt'? Remember my first point. I wrote here it is required to determine purpose of Forth, application domains, and design word sets only after this. I wrote Forth is a smart scripting language and can be used as a Matlab replacement for science modelling and for simple, but smart scripts with floating point, file IO etc. If you force programmers to add complexity and write programs as it must be run on high-reliable systems, this is an advantage for rockets, but disadvantage for 'casual programming' and 'programming professionals'. If you make life harder for them, they will gone. > > Two programmers, right? This is an answer :) > > An answer to what? You won't make any programming language more > popular by making it worse. Especially in such tivial ways. 'Worse' is your opinion, supported by... two programmers and committee memners? I prefer to keep compatibility with POSIX, which has enormous popularity comparing with ANS Forth. POSIX open function returns one number, where -1 means operation error. It is easy. Look how much time we spend on this simple question. I post here a list of thing which are happened already. You seems to be not happy and tries to persuade I'm wrong with a syntax of application-level words?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-22 14:41 -0800 |
| Message-ID | <0c9a7842-882c-4e08-90b9-7194906cc0d7@googlegroups.com> |
| In reply to | #54249 |
On Sunday, January 22, 2017 at 1:47:57 PM UTC-7, Ilya Tarasov wrote: > > Becuase the Forth way is better. Obviously. > > Sorry, I don't accept your right to determine what is a Forth way. Andrew Haley and all of the other ANS-Forth cult members invariably resort to claiming that they alone know the "Forth Way" --- this is similar to how religious cults invariably resort to claiming that they alone know God's Way --- but I say that ultimately everybody must find their own path, and they are making a mistake when they demand that this be provided for them. I don't agree with everything that Ilya says, but I think that he is worth listening to because he has had a lot of success with Forth --- I don't listen to Forth "programmers" who have never written any Forth programs, and can't succeed even at easy Forth programming such as I have in the novice-package (for example: MACRO: and ALIAS etc.) --- Andrew Haley's background is that he was an employee of Forth Inc. and he taught the novice class at Forth Inc. when Elizabeth Rather couldn't do so herself, and then Elizabeth Rather appointed him to the Forth-200x committee so Forth Inc. could get yet another vote.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-22 15:57 -0800 |
| Message-ID | <b3e1d566-5290-4189-b69d-124e192a2771@googlegroups.com> |
| In reply to | #54258 |
> I don't agree with everything that Ilya says, but I think that he is worth listening to because he has had a lot of success with Forth I'm sure an ability to have different, but co-existing approaches is a major advantage. When any vendors have different goals and target domains, their solutions will be different too. This is why we need a kind of conferences, newsgroups etc. If I disagree with something, I can at least learn what reasons lead to this solution and maybe accept it later, when I'll face the same problem. Forth is not a widely-known language to ignore other forthers just because they don't want to be 100% agreed.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-23 04:05 -0600 |
| Message-ID | <zdCdncLV0YvySBjFnZ2dnUU7-NnNnZ2d@supernews.com> |
| In reply to | #54249 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> > I don't want to chaotically choose syntax when invent a >> > workaround. I can use ( -- handle, ior ) notation by many ways. Why >> > I even must think about this, if I have an experience in other >> > languages and want just to copy that approach to Forth? >> >> Becuase the Forth way is better. Obviously. > > Sorry, I don't accept your right to determine what is a Forth > way. Well, you did ask, so I answered. On my side there is less code used, and it's easier to read and analyse (IMO, YMMV, ect.) On your side, that's how C does it. It's a value judgement which of these is more persuasive. >> > This is a kind of trap you did for yourself :) I just run QuarkForth >> > and type " 3645453633.txt" OPEN (I know there is no file with this >> > name). I see -1 on the top of stack and Quark is ready for next >> > command. What's wrong? If your Forth will crash in this situation, >> > it is bad implementation. >> >> Probably. I have no idea what you are talking about. > > This is a key question here. You told having THROW after file IO is > a key element of code safety. I said that you must do something about errors, but I didn't say that required THROW. THROW is simply an easy way to do it. > Again, I don't accept your right to give irrevocably marks to my > code. This example was in use only once :) What, then, is so painful about having to THROW ? > Looking for filename and explicit literals (not constants, as > usual), I remember it was a simple conversion script for FPGA data > exported by cross-compiler. So it is a script, not a program for > rocket or nuclear reactor. It still can be made more safe by using > ior checking, but why? This is a kind of command, typing in console > for copying file. Are you require ior checking for 'copy file1.txt > file2.txt'? I would hope that the "copy" command did some checking that a file existed before trying to copy the data. > Remember my first point. I wrote here it is required to determine > purpose of Forth, application domains, and design word sets only > after this. It is very unlikely that anyone will disagree with that. > I wrote Forth is a smart scripting language and can be used as a > Matlab replacement for science modelling and for simple, but smart > scripts with floating point, file IO etc. Sure. That's one of the ways in which Forth may be used. Another way is in deeply-embedded real-time control systems which must work because they are a critical part of some system. > If you force programmers to add complexity and write programs as it > must be run on high-reliable systems, this is an advantage for > rockets, but disadvantage for 'casual programming' and 'programming > professionals'. If you make life harder for them, they will gone. OK, now that is a sensible argument. But IMO it argues for an OPEN-FILE which THROWs, not for one which doesn't check for errors. That is the simplest to use. But, as explained, OPEN-FILE doesn't do that by default. >> > Two programmers, right? This is an answer :) >> >> An answer to what? You won't make any programming language more >> popular by making it worse. Especially in such tivial ways. > > 'Worse' is your opinion, supported by... two programmers and > committee memners? I prefer to keep compatibility with POSIX, which > has enormous popularity comparing with ANS Forth. Let's unpick this. Firstly, Forth's OPEN-FILE is not incompatible with POSIX: POSIX language bindings can work this way. C language bindings for POSIX don't work this way, sure, because they can't: C functions can't do that. Secondly, there is no evidence that if Forth went over to C-style bindings Forth would be any more popular. And the argument is weak anyway: it implies that the goal of language design is to make popular languages, and the way to make languages popular is to make them similar to languges which are already popular. But Forth is different, and deliberately so. It never was designed to be as popular as possible. It was designed to be as useful as possible for the domains in which it was used. > POSIX open function returns one number, where -1 means operation > error. It is easy. It isn't. open returns a status and an error code in errno. It checks the return code from the kernel, sees if it is out of the range of a plausible file handle, and if so sets errno in thread-local storage. But there's a difference between what you can do in POSIX and what you can do in a portable programming language: POSIX knows that a valid return from open is a small integer. Portable programming languages don't know that, and have to allow the possibility that the return from open is an address. Sure, you can encode the possible errors as small negative integers, but then the receiver the has to unpack them. That's harder to use when you're checking for errors than what we have now in standard Forth. > Look how much time we spend on this simple question. I post here a > list of thing which are happened already. You seems to be not happy > and tries to persuade I'm wrong with a syntax of application-level > words? It takes two to argue. Remember how this started. You asked this question: > If file is missing or disk is damaged, what exactly my program can > do? How often THROW provide any kind of automatic workaround in real > programs? With built-in ABORT, any file IO word can just abort > execution and return to command line. This is not a crash of entire > Forth session. You were trying to persuade us that standard Forth was poorly-designed in the way it does its OS interface. And you produced an argument I thought was without very much weight. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-23 10:47 -0800 |
| Message-ID | <59a30422-c248-475a-9166-04e94e73c599@googlegroups.com> |
| In reply to | #54285 |
On Monday, January 23, 2017 at 3:05:41 AM UTC-7, Andrew Haley wrote: > Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > > I wrote Forth is a smart scripting language and can be used as a > > Matlab replacement for science modelling and for simple, but smart > > scripts with floating point, file IO etc. > > Sure. That's one of the ways in which Forth may be used. Another way > is in deeply-embedded real-time control systems which must work > because they are a critical part of some system. Apparently there are a lot of these "deeply-embedded real-time control systems" that have hard-disks and a file system --- LOL --- this is just fantasy! Straight Forth is not based on fantasy --- it is designed to be a desktop-computer Forth standard; it is not for micro-controllers --- mixing the two disparate purposes together in a single language design would be a descent into fantasy. I remember in the old days that there were cases in which MS-DOS was used in a micro-controller --- these were never hard real-time --- even soft real-time was a big stretch for such systems. It was a bad idea then, and it is a worse idea now.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-01-24 01:02 -0800 |
| Message-ID | <06000f2c-4085-415f-b66a-02e9fb254034@googlegroups.com> |
| In reply to | #54309 |
On Monday, 23 January 2017 18:47:37 UTC, hughag...@gmail.com wrote: > Straight Forth is not based on fantasy --- it is designed to be a desktop-computer Forth standard; it is not for micro-controllers --- mixing the two disparate purposes together in a single language design would be a descent into fantasy. > Not necessarily. Don't talk yourself down. If your language is good, there's no reason why an add-on library couldn't be developed that adds some functionality that one would expect to see on controllers. It's probably not realistic yet, since (IIRC) you are targeting 64-bit platforms, and it's going to be a while before we see 64-bit micro-controllers in the field, if ever. Does your system run on 32-bit? What are you using to compile Straight Forth? Is it a C program, or are you cross-compiling Forth?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-24 01:12 -0800 |
| Message-ID | <878tq0lt2m.fsf@nightsong.com> |
| In reply to | #54342 |
Mark Wills <markwills1970@gmail.com> writes: > It's probably not realistic yet, since (IIRC) you are targeting 64-bit > platforms, and it's going to be a while before we see 64-bit > micro-controllers in the field, if ever. I don't see the issue with the word size. Most Forths on 8-bit MCUs have 16 bit cells, and some have 32 bit cells. 64 bit cells is just more of the same, though maybe hard on the constraints of small chips. 64 bit cells on 32 bit MCUs (there are tons of those now) seems perfectly workable though, since those parts have lots more memory. Here's a 2 dollar ARM Cortex M3 module with 1 meg flash, 512k ram, and a wifi radio, all on a little board the size of a postage stamp: https://www.pine64.org/?page_id=917 Looks like a nice Forth platform to me.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-23 16:28 -0800 |
| Message-ID | <7f967935-55f4-4243-8fb7-23a47e34d5ca@googlegroups.com> |
| In reply to | #54285 |
> Well, you did ask, so I answered. On my side there is less code used, > and it's easier to read and analyse (IMO, YMMV, ect.) On your side, > that's how C does it. It's a value judgement which of these is more > persuasive. I don't plan to persuade you. I don't want to force others to use my syntax (indeed, it is POSIX-style, not mine). You declare your version is a standard, so it is your problem how to persuade others to agree. If many are disagree, what is the reason to declare file IO as a standard? It is library or even application-level words, not a part of language. > > Again, I don't accept your right to give irrevocably marks to my > > code. This example was in use only once :) > > What, then, is so painful about having to THROW ? Because even such simple question causes a big discussion. I see your position is still not absolutely clear. What do you want with standard? And how exactly you want to use it? > > for copying file. Are you require ior checking for 'copy file1.txt > > file2.txt'? > > I would hope that the "copy" command did some checking that a file > existed before trying to copy the data. Of course yes. Type this in console and check. I mean Windows command prompt, not Forth. If no file1.txt present, you will receive a message, but console will not crash. > > Remember my first point. I wrote here it is required to determine > > purpose of Forth, application domains, and design word sets only > > after this. > > It is very unlikely that anyone will disagree with that. It is not enough to declare you are agreed. Make an actions according to your declaration. > > I wrote Forth is a smart scripting language and can be used as a > > Matlab replacement for science modelling and for simple, but smart > > scripts with floating point, file IO etc. > > Sure. That's one of the ways in which Forth may be used. Another way > is in deeply-embedded real-time control systems which must work > because they are a critical part of some system. Again, you not imagine your position clearly and mixing different conditions of usage. I describe my use case several times. It is desktop application and simple scripts. Why do you try to switch me to real-time control systems? I design many embedded devices with my CPUs and bare metal software, so don't tell me about critical parts. Just one question for further deep thinking: if you add logging to you THROW handler, is it a part of error handling? When, if device, where log is located, will fail completely, you will receive first THROW at an attempt to work with file, but second error will appears inside (!) your error handler (logging is also unavailable because your hardware is completely broken). So, how critical systems must be designed and what part of this design focused on THROW mechanism? > > If you force programmers to add complexity and write programs as it > > must be run on high-reliable systems, this is an advantage for > > rockets, but disadvantage for 'casual programming' and 'programming > > professionals'. If you make life harder for them, they will gone. > > OK, now that is a sensible argument. But IMO it argues for an > OPEN-FILE which THROWs, not for one which doesn't check for errors. > That is the simplest to use. But, as explained, OPEN-FILE doesn't do > that by default. Ask your customers, what is simplest to use for them. And tell then you can always provide a library with their favourite set of functions, 'because this is Forth-way' :) > > POSIX open function returns one number, where -1 means operation > > error. It is easy. > > It isn't. open returns a status and an error code in errno. It I know how it works. Errno is a global variable in Quark. > It takes two to argue. > > Remember how this started. You asked this question: > > > If file is missing or disk is damaged, what exactly my program can > > do? How often THROW provide any kind of automatic workaround in real > > programs? With built-in ABORT, any file IO word can just abort > > execution and return to command line. This is not a crash of entire > > Forth session. > > You were trying to persuade us that standard Forth was poorly-designed > in the way it does its OS interface. And you produced an argument I > thought was without very much weight. You are thinking in the terms of word naming. I'm trying to switch you to overall strategy. What parts are Forth-specific? What parts should be imported from existing languages/libraries?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-01-24 01:06 -0800 |
| Message-ID | <ef70960c-75ff-4fa1-abeb-67f5a99c7e6c@googlegroups.com> |
| In reply to | #54329 |
On Tuesday, 24 January 2017 00:28:39 UTC, Ilya Tarasov wrote: > > Well, you did ask, so I answered. On my side there is less code used, > > and it's easier to read and analyse (IMO, YMMV, ect.) On your side, > > that's how C does it. It's a value judgement which of these is more > > persuasive. > > I don't plan to persuade you. I don't want to force others to use my syntax (indeed, it is POSIX-style, not mine). You declare your version is a standard, so it is your problem how to persuade others to agree. If many are disagree, what is the reason to declare file IO as a standard? It is library or even application-level words, not a part of language. > > > > Again, I don't accept your right to give irrevocably marks to my > > > code. This example was in use only once :) > > > > What, then, is so painful about having to THROW ? > > Because even such simple question causes a big discussion. I see your position is still not absolutely clear. What do you want with standard? And how exactly you want to use it? > > > > for copying file. Are you require ior checking for 'copy file1.txt > > > file2.txt'? > > > > I would hope that the "copy" command did some checking that a file > > existed before trying to copy the data. > > Of course yes. Type this in console and check. I mean Windows command prompt, not Forth. If no file1.txt present, you will receive a message, but console will not crash. > > > > Remember my first point. I wrote here it is required to determine > > > purpose of Forth, application domains, and design word sets only > > > after this. > > > > It is very unlikely that anyone will disagree with that. > > It is not enough to declare you are agreed. Make an actions according to your declaration. > > > > I wrote Forth is a smart scripting language and can be used as a > > > Matlab replacement for science modelling and for simple, but smart > > > scripts with floating point, file IO etc. > > > > Sure. That's one of the ways in which Forth may be used. Another way > > is in deeply-embedded real-time control systems which must work > > because they are a critical part of some system. > > Again, you not imagine your position clearly and mixing different conditions of usage. I describe my use case several times. It is desktop application and simple scripts. Why do you try to switch me to real-time control systems? I design many embedded devices with my CPUs and bare metal software, so don't tell me about critical parts. Just one question for further deep thinking: if you add logging to you THROW handler, is it a part of error handling? When, if device, where log is located, will fail completely, you will receive first THROW at an attempt to work with file, but second error will appears inside (!) your error handler (logging is also unavailable because your hardware is completely broken). So, how critical systems must be designed and what part of this design focused on THROW mechanism? > > > > If you force programmers to add complexity and write programs as it > > > must be run on high-reliable systems, this is an advantage for > > > rockets, but disadvantage for 'casual programming' and 'programming > > > professionals'. If you make life harder for them, they will gone. > > > > OK, now that is a sensible argument. But IMO it argues for an > > OPEN-FILE which THROWs, not for one which doesn't check for errors. > > That is the simplest to use. But, as explained, OPEN-FILE doesn't do > > that by default. > > Ask your customers, what is simplest to use for them. And tell then you can always provide a library with their favourite set of functions, 'because this is Forth-way' :) > > > > POSIX open function returns one number, where -1 means operation > > > error. It is easy. > > > > It isn't. open returns a status and an error code in errno. It > > I know how it works. Errno is a global variable in Quark. > > > It takes two to argue. > > > > Remember how this started. You asked this question: > > > > > If file is missing or disk is damaged, what exactly my program can > > > do? How often THROW provide any kind of automatic workaround in real > > > programs? With built-in ABORT, any file IO word can just abort > > > execution and return to command line. This is not a crash of entire > > > Forth session. > > > > You were trying to persuade us that standard Forth was poorly-designed > > in the way it does its OS interface. And you produced an argument I > > thought was without very much weight. > > You are thinking in the terms of word naming. I'm trying to switch you to overall strategy. What parts are Forth-specific? What parts should be imported from existing languages/libraries? I'm not seeing the objection to OPEN THROW (and similar) to be honest. I certainly wouldn't the throw to occur inside of OPEN, that's for sure. *I* want to be in control of what my application does and doesn't do. If it's a quick-and-dirty utility program to do something in the lab then sure, go right ahead, but in general I don't see the issue with it. I don't particularly like the way THROW/CATCH is used (requiring the target word to be ticked) but we are where we are.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-24 03:22 -0600 |
| Message-ID | <JdmdnTAEZdpUgRrFnZ2dnUU7-X2dnZ2d@supernews.com> |
| In reply to | #54343 |
Mark Wills <markwills1970@gmail.com> wrote: > > I don't particularly like the way THROW/CATCH is used (requiring the > target word to be ticked) but we are where we are. True, but quotations make that much nicer to read. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-24 14:19 +0100 |
| Message-ID | <o67k98$db4$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54348 |
In article <JdmdnTAEZdpUgRrFnZ2dnUU7-X2dnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Mark Wills <markwills1970@gmail.com> wrote: >> >> I don't particularly like the way THROW/CATCH is used (requiring the >> target word to be ticked) but we are where we are. > >True, but quotations make that much nicer to read. As do denotations/literals/recognizer ... 'read-configuration CATCH ... > >Andrew. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-24 03:13 -0600 |
| Message-ID | <JdmdnTYEZdo-hxrFnZ2dnUU7-X3NnZ2d@supernews.com> |
| In reply to | #54329 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> Well, you did ask, so I answered. On my side there is less code used, >> and it's easier to read and analyse (IMO, YMMV, ect.) On your side, >> that's how C does it. It's a value judgement which of these is more >> persuasive. > > I don't plan to persuade you. I don't want to force others to use my > syntax (indeed, it is POSIX-style, not mine). You declare your > version is a standard, It is. It's not my version of anything. > so it is your problem how to persuade others to agree. If many are > disagree, what is the reason to declare file IO as a standard? It is > library or even application-level words, not a part of language. I don't think that's right. AFAIK the last time anyone tried to standardize a language without I/O was ALGOL 60, and that was a major mistake: it was effectively impossible to ALGOL programs to do anything significant. Most people look up the way that I/O is done and just use it. >> > Again, I don't accept your right to give irrevocably marks to my >> > code. This example was in use only once :) >> >> What, then, is so painful about having to THROW ? > > Because even such simple question causes a big discussion. I see > your position is still not absolutely clear. What do you want with > standard? And how exactly you want to use it? That one has already been asked and answered, in particular by Elizabeth Rather. It's about portability for programs, libraries, and programmers. >> I would hope that the "copy" command did some checking that a file >> existed before trying to copy the data. > > Of course yes. Type this in console and check. I mean Windows > command prompt, not Forth. If no file1.txt present, you will receive > a message, but console will not crash. Right, and that happens because "cp" very carefully checks everything. It doesn't just throw an exception and exit the program. >> Sure. That's one of the ways in which Forth may be used. Another way >> is in deeply-embedded real-time control systems which must work >> because they are a critical part of some system. > > Again, you not imagine your position clearly and mixing different > conditions of usage. I describe my use case several times. It is > desktop application and simple scripts. Why do you try to switch me > to real-time control systems? I don't care to switch you. I merely explain why things are the way they are. > I design many embedded devices with my CPUs and bare metal software, > so don't tell me about critical parts. Just one question for further > deep thinking: if you add logging to you THROW handler, is it a part > of error handling? When, if device, where log is located, will fail > completely, you will receive first THROW at an attempt to work with > file, but second error will appears inside (!) your error handler > (logging is also unavailable because your hardware is completely > broken). Then the error handler itself will THROW. That THROW will be passed to its enclosing context, which will do something appropriate. Perhaps trigger an emergency shutdown, perhaps not. > So, how critical systems must be designed and what part of this > design focused on THROW mechanism? Very carefully. >> > POSIX open function returns one number, where -1 means operation >> > error. It is easy. >> >> It isn't. open returns a status and an error code in errno. It > > I know how it works. Errno is a global variable in Quark. What is Quark? Some kind of yogurty thing, isn't it? You were talking about POSIX. >> You were trying to persuade us that standard Forth was poorly-designed >> in the way it does its OS interface. And you produced an argument I >> thought was without very much weight. > > You are thinking in the terms of word naming. I'm not. And I'll thank you for not telling me what I'm thinking of. > I'm trying to switch you to overall strategy. What parts are > Forth-specific? What parts should be imported from existing > languages/libraries? That is a sensible question. Any standard is a compromise, of course: I think that what we have now is basically right, but it's worth discussing. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web