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 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-15 14:09 -0800 |
| Message-ID | <273ada4b-484f-495c-99c6-269dac5567da@googlegroups.com> |
| In reply to | #54036 |
On Sunday, January 15, 2017 at 2:53:35 PM UTC-7, Ilya Tarasov wrote:
> I don't see major bloating here. Of course, LOC[ is not required or any word. More bloating code may appears with many stack manipulation words, when 5-10 parameters are required (this is poor architecture, but BOX is an example of word where 4 or more parameters is an objective requirement). So I hope code will be easier to read.
You are defining and initializing your pseudo-locals the same way that you define and initialize global variables.
The problem here is that you get your parameters backwards, similar to how LOCALS| got its parameters backwards --- the John Hopkins Format (I have { provided in the novice-package) gets the parameters in the correct order, and is much more concise.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-15 15:48 -0800 |
| Message-ID | <2e860acc-9900-4735-ac23-84ab8deed774@googlegroups.com> |
| In reply to | #54039 |
> You are defining and initializing your pseudo-locals the same way that you define and initialize global variables.
>
> The problem here is that you get your parameters backwards, similar to how LOCALS| got its parameters backwards --- the John Hopkins Format (I have { provided in the novice-package) gets the parameters in the correct order, and is much more concise.
I understand this, of course. I just mimic local variables, and this is not a goal but side effect. Original request: relax stack problems with minimum efforts using built-in Forth mechanism. A blind branch in vocabulary linked list may solve the problem of names conflict and name visibility area. Stack frames and separate memory areas are another solutions, but are they require any modifications to existing Forth behavior? I'm focused here on revealing how many changes may be done to enable as many approaches as possible, no matter they required immediately or not.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-15 16:00 -0800 |
| Message-ID | <9d3e2768-d0fd-4416-baea-94e019948527@googlegroups.com> |
| In reply to | #54043 |
On Sunday, January 15, 2017 at 4:48:25 PM UTC-7, Ilya Tarasov wrote:
> > You are defining and initializing your pseudo-locals the same way that you define and initialize global variables.
> >
> > The problem here is that you get your parameters backwards, similar to how LOCALS| got its parameters backwards --- the John Hopkins Format (I have { provided in the novice-package) gets the parameters in the correct order, and is much more concise.
>
> I understand this, of course. I just mimic local variables, and this is not a goal but side effect. Original request: relax stack problems with minimum efforts using built-in Forth mechanism. A blind branch in vocabulary linked list may solve the problem of names conflict and name visibility area. Stack frames and separate memory areas are another solutions, but are they require any modifications to existing Forth behavior? I'm focused here on revealing how many changes may be done to enable as many approaches as possible, no matter they required immediately or not.
I'm not saying that your idea is bad --- it is intriguing and I'm still thinking about it --- I'm just saying that it does result in more bloated source-code, and the awkward problem of having the parameters backwards.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-15 12:48 +0100 |
| Message-ID | <o5fnir$7au$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54015 |
In article <5399a1f4-2c56-4272-9588-9544e7b661e2@googlegroups.com>, <hughaguilar96@gmail.com> wrote: >On Saturday, January 14, 2017 at 11:43:03 AM UTC-7, Ilya Tarasov wrote: >> =D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 14 =D1=8F=D0=BD=D0=B2=D0=B0= >=D1=80=D1=8F 2017 =D0=B3., 9:20:11 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0= >=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C hughag...@gmail.com =D0=BD=D0=B0=D0= >=BF=D0=B8=D1=81=D0=B0=D0=BB: >> > On Friday, January 13, 2017 at 7:00:31 PM UTC-7, Ilya Tarasov wrote: >> > > : BOX >> > > LOC[ >> > > QUAN X1 QUAN X2 QUAN Y1 QUAN Y2 QUAN COLOR >> > > ]LOC >> > > TO COLOR TO Y2 TO X2 TO Y1 TO X1 >> > > =20 >> > > X1 Y1 X2 X1 - COLOR HLINE >> > > X1 Y1 Y2 Y1 - COLOR VLINE >> > > X1 Y2 X2 X1 - COLOR HLINE >> > > X2 Y1 Y2 Y1 - COLOR VLINE >> > > ; >> > >=20 >> > > 500 150 600 180 0xFF0000 BOX >> >=20 >> > Other than your different way to define locals, this could be done in A= >NS-Forth --- I am assuming that QUAN defines a single-precision integer ---= > your example would have not been able to be done in ANS-Forth if you had l= >ocals of different types than single-precision integers. >>=20 >> This is not a special type of locals. Inside the block LOC[ ]LOC any code= > may be inserted. >>=20 >> : MYWORD >> LOC[ >> VARIABLE X >> FLOAT Y >> : SQR DUP * ; \ yes, even this way >> ]LOC >> ; >>=20 >> : NEWWORD ... >>=20 >> This requires a pair of push/pop of CURRENT content at : and ; respective= >ly. In normal case, it is useless, but when LOC[ switches Forth to interpre= >ting mode, any text after this will be interpreted/compiled, and all variab= >les, arrays or even words will be compiled inside a MYWORD. A linked list w= >ill be expanded until final ; will restore CURRENT value, so NEWWORD will p= >oint to MYWORD, not to the latest definition inside LOC[ ]LOC. A chain 'MYW= >ORD - X - Y - SQR' is visible only while MYWORD definition is not completed= >. >>=20 >> This code is static and local object of this kind are not created every t= >ime for recursive words. This is not important limitation for me and for a = >man who asks me for doing something with name visibility. > >This is an interesting idea. I will give some thought to it.=20 I posed the same idea some time back, but slightly different. A :: name .... ;; definition would have such an internal wordlist. Then there is no need to have LOC[. We just demand that [ .. ] accomdates nested words. Ilya proposes to chain the internal wordlist to the current wordlist, which is fine. my implementation is about one screen, and it has a separate wordlist that can be inspected at later times. Also some Forths (not ciforth) may implement a wordlist as a has table, which would make this more difficult to implement. When will we have a definitive version of StraightForth? Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-14 10:10 -0800 |
| Message-ID | <119731ae-c858-475b-bad7-aad245dc4674@googlegroups.com> |
| In reply to | #53992 |
> > I state this before. I'm sure this must be an equal abilities to share > > ideas and compare approaches, which show success, no matter how close > > it to ANS. > > I keep waiting to see examples comparing your approach vs. the ANS > approach. If your way is better, that's great, I want to look closely. > If it's only equally good, why not use ANS? First of all, I don't want to replace ANS approach by my approach, or by any other single approach. There is no silver bullet and many approaches may exist at the same time. Many solutions are mutually exclusive, but can be used for so simple idea as Forth. Standartization efforts should be removed to the another level, not to the level of listing words and state their semantics. Also, programming consists not only of code writing and debugging. Research and management efforts must be applied too, and the best code writer may be not the best expert or a man who can combine all thing together and find the best way to develop Forth at _this_ moment. So, comparing lists of words is almost useless. Most important question is 'what YOU want?'. If you want to sit still, remembering past glory and dreaming on the future, it is not a deal I want to take part. But I don't let you waste Forth knowledge base by stories how smart ANS and Forth Inc are, which are disoriented other programmers and may forces them to wait the next brilliant translator for their bright future. Forth Inc. products are for Forth Inc. I think this is a time to carefully study current programming world, mainly in non-Forth area and determining main trends in the abstract terms (i.e. not in the terms of object-oriented, functional, high-level or any else, but in the pure CS terms, still applicable for Forth). This must give a base to evaluate ideas from the scratch and without constantly comparing with 'how it was done 20 years ago'. My evaluation of overview size is about 30-50 pages minimum, so it is a hard work. I think it is a wasting time for me, if most of newsgroup users will be ready only to destroy it at glance, just because I'm posting uncomfortable texts. Also, I clearly understand my Forth applications covering not a 100% area, so only combined efforts may give valuable results. I wonder how Forth Inc. may ignore this. I know brilliant programmers who add their Forth and non-Forth features to my products and I feel no discomfort. I'm thankful to them for their ideas, even when it forces me to significantly change Forth engine. So before I will switch to English in my mind to write a complete descriptions of my vision, I want to understand, who are peoples to conversation here.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-15 17:56 -0600 |
| Message-ID | <z_WdnSNtn5nfkeHFnZ2dnUU7-X_NnZ2d@supernews.com> |
| In reply to | #54006 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > > I think this is a time to carefully study current programming world, > mainly in non-Forth area and determining main trends in the abstract > terms (i.e. not in the terms of object-oriented, functional, > high-level or any else, but in the pure CS terms, still applicable > for Forth). This must give a base to evaluate ideas from the scratch > and without constantly comparing with 'how it was done 20 years > ago'. That's not a bad idea. It might make sense to develop a new system from scratch, based on some of the same principles as Forth. However, it probably won't be recognizable as Forth: it will be something new. Other people have tried to do so in the past. Standard Forth is evolutionary, based on a continuous line of systems which started in 1970. It's not based on re-evaluating ideas from scratch. That's a different approach from what you want to do. But if it takes 50-odd pages to describe your system, then it will certainly lack simplicity, Forth's most distinguishing feature. Andrew,
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-15 17:05 -0800 |
| Message-ID | <ee9e760f-2f45-4e43-a5f1-a40713b5a87b@googlegroups.com> |
| In reply to | #54045 |
> That's not a bad idea. It might make sense to develop a new system > from scratch, based on some of the same principles as Forth. However, > it probably won't be recognizable as Forth: it will be something new. > Other people have tried to do so in the past. No, this will not be something new. This is the way to architect a new Forth system, just like other languages and software applications are architectured novadays. There are many areas in computer science evolved since 1994 (and more since 1970). I'm not talking how to add objects, lambda calculus, garbage collector or other 'cool stuff' and make Forth non-recognizable. > Standard Forth is evolutionary, based on a continuous line of systems > which started in 1970. It's not based on re-evaluating ideas from > scratch. That's a different approach from what you want to do. But > if it takes 50-odd pages to describe your system, then it will > certainly lack simplicity, Forth's most distinguishing feature. Starting from scratch each time is not necessary. I see _your_ evolutionary Forth need to be started from scratch. I suppose you not clearly understand what I'm talking about. 50 pages is not a volume of Forth description. It is an approximate size of a document describing what happening in computer science from a forther's point of view. Without it, all proposals will be chaotic and non-system. For example (this is NOT complete and well-organized!!!): 1. What happens with programming - grows up, falls down? Programming languages - more or less? How a new language lifecycle looks now? 2. Computers - desktop, network, embedded, IoT, other. 3. What about CPU parameters - clock speed, datawidth, memory size? 32 bits - actual, obsolete? 64 bits? 128 bits? When? What markers should be observed to determine when to switch to 64, 128 (256) bits? What memory size is enough for current asks? Display resolution, network speed and traffic? Other applicable parameters describing application domains? 4. Hardware platforms, OS - more or less? Cross-platform or specialization - what is more important? Specialization for performance, verification, other feature? 5. Focus customer groups - what kind of customers require something like Forth right now. What data formats they use - numbers, strings. What kind of algorithms are typical. What out-of-box features they need? Completing this is not an easy, but otherwise you will continue to add little changes and hope it is useful for all.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-15 17:35 -0800 |
| Message-ID | <4bafdffe-17f6-4ad5-878e-6108897d0e04@googlegroups.com> |
| In reply to | #54047 |
On Sunday, January 15, 2017 at 6:05:02 PM UTC-7, Ilya Tarasov wrote: > > That's not a bad idea. It might make sense to develop a new system > > from scratch, based on some of the same principles as Forth. However, > > it probably won't be recognizable as Forth: it will be something new. > > Other people have tried to do so in the past. > > No, this will not be something new. This is the way to architect a new Forth system, just like other languages and software applications are architectured novadays. There are many areas in computer science evolved since 1994 (and more since 1970). I'm not talking how to add objects, lambda calculus, garbage collector or other 'cool stuff' and make Forth non-recognizable. Ilya is responding to Andrew Haley here. Andrew Haley is an employee of Forth Inc. and was appointed to the Forth 200x committee by Elizabeth Rather. Essentially, what Andrew Haley is saying is that Forth Inc. alone decides what "Forth" is --- anybody with a Forth compiler that contradicts ANS-Forth does not have a "Forth" compiler, but only has a non-standard wannabe --- this is grossly arrogant salesmanship from a Forth Inc. salesman. > > Standard Forth is evolutionary, based on a continuous line of systems > > which started in 1970. It's not based on re-evaluating ideas from > > scratch. This is more arrogant salesmanship from a Forth Inc. salesman --- Andrew Haley is saying that Forth Inc. knows everything there is to know about Forth, and has known everything that there is to know since 1970 --- in truth, we need to re-evaluate ideas from scratch --- that is called: "thinking."
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-15 19:20 -0800 |
| Message-ID | <87lguby9kr.fsf@nightsong.com> |
| In reply to | #54047 |
Ilya Tarasov <ilya74.tarasov@gmail.com> writes: > There are many areas in computer science evolved since 1994 ... Forth has never been big on "computer science" and for some people that's one of its strengths. The stuff you list below doesn't seem to be CS either. > 1. What happens with programming - grows up, falls down? Programming > languages - more or less? How a new language lifecycle looks now? > 2. Computers - desktop, network, embedded, IoT, other. > 3. What about CPU parameters - clock speed, datawidth, ... None of that is CS, and what much does it have to do with Forth? Forth did ok in a particular segment, is still relevant in that segment, and never did all that well in other segments though it has always had a little bit of success in them. > Completing this is not an easy, but otherwise you will continue to add > little changes and hope it is useful for all. Does your system address those issues? I'd be interest in a brief general summary of the differences between your system and ANS, since you're not big on concrete examples. If I were learning from history in order to write a Forth from scratch, I'd probably look at Colorforth at least as closely as I'd look at ANS, but the end result would be on around the same level.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-15 23:51 -0500 |
| Message-ID | <20170115235156.35a042a4@_> |
| In reply to | #54053 |
On Sun, 15 Jan 2017 19:20:36 -0800 Paul Rubin <no.email@nospam.invalid> wrote: > If I were learning from history in order to write a Forth from > scratch, I'd probably look at Colorforth at least as closely as I'd > look at ANS, but the end result would be on around the same level. Why Colorforth? Why not start with fig-Forth and proceed from there? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-15 19:22 -1000 |
| Message-ID | <dqidnfWFmak5xeHFnZ2dnUU7-KnNnZ2d@supernews.com> |
| In reply to | #54054 |
On 1/15/17 6:51 PM, Rod Pemberton wrote: > On Sun, 15 Jan 2017 19:20:36 -0800 > Paul Rubin <no.email@nospam.invalid> wrote: > >> If I were learning from history in order to write a Forth from >> scratch, I'd probably look at Colorforth at least as closely as I'd >> look at ANS, but the end result would be on around the same level. > > Why Colorforth? > > Why not start with fig-Forth and proceed from there? Because FigForth was really bad code. And colorforth suffers from some serious and irrelevant eccentricities, such as Chuck's keyboard and some other bad ideas. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-18 16:24 -0800 |
| Message-ID | <7cb526d6-1280-4afa-9c1a-7dbcc593ce63@googlegroups.com> |
| In reply to | #54053 |
> > 1. What happens with programming - grows up, falls down? Programming
> > languages - more or less? How a new language lifecycle looks now?
> > 2. Computers - desktop, network, embedded, IoT, other.
> > 3. What about CPU parameters - clock speed, datawidth, ...
>
> None of that is CS, and what much does it have to do with Forth? Forth
> did ok in a particular segment, is still relevant in that segment, and
> never did all that well in other segments though it has always had a
> little bit of success in them.
You may refer to IEEE 1074. This is not pure CS, but before start to write code we must clearly understand what exactly we want to do. Particular segment for Forth now looks like found intuitive rahter when predicted and planned. CS achievements are known, and market trends are changes for last 20 years, so it may be very productive to review that segments and find some new.
> > Completing this is not an easy, but otherwise you will continue to add
> > little changes and hope it is useful for all.
>
> Does your system address those issues? I'd be interest in a brief
> general summary of the differences between your system and ANS, since
> you're not big on concrete examples.
I can't say I pass this procedure each time during my Forth history. More exact, this is a summary of projects done, including some big enough, where serious project planning was used.
From my earlier success stories I note two things:
1. Forth is very good for hardware management, not for replace general calculations. This means MMX/SSE/SSE2 extentions, assembler primitives with Forth wrappers, direct access to video memory etc. FPU is also in this list, because x87 is stack in nature and floating point calculations is fast enough, especially when wrote by skilled programmer, who focused on low-level optimization. After this kind of hard low-level work is done, interpreting mode allow to use simple and fast interface to test and debug.
2. Forth flexibility means customer-facing system. Literally all of ANS incompatibility based on requests of my customers ('you told Forth is very flexible, so why don't modify this feature according to our wishes?').
Briefly, I can highlight next major differencies:
1. Floating point.
It is based on requirements of physics and DSP specialists, where floating point is required. Forth has a niche as a simple Matlab replacement for tasks with strong mathematical basics, solving from scratch. With little or no libraries, it is no benefits from Matlab itself, and one who is not a pure programmer, but engineer/researcher with some programmer's skills prefer flexible tool instead Matlab.
They told 1.23 is a floating-point number. 3.1415 is also a floating point, not only 1.23E0 and 3.1415E0. No discussion here (or they will gone from Forth). I'm completely agreed :)
2. OS interface.
POSIX-like functions are known for many programmers. It may be derived from Pascal or C. None of these returns two parameters. OPEN-FILE THROW is often in ANS Forth code, because it is hard to imagine what else I can do with ior except THROW. We may use DROP instead, but what problem is solved in this case and why don't hide THROW inside? It is rhetorical questions, I don't want to discuss ways to accept ANS formats. File operations are not invented by ANS committee, so I simple copy names from commonly used languages. File IO words returns one parameter, like these libraries.
Btw, strings are ASCIIZ, because it is natural for MS Windows API. I see no reasons to convert strings each time. When Borland Pascal was a mainstream tool, my preferred format was Addr, Count. No deep thoughts here, just taking a look how this solved in the host OS.
Oh, I can't remember a language where strings are represented by S" or STR" or something else. So " is enough. Also, I have a switchable mode, when "some text" will be recognized as string too (no space after first quote char).
3. Vectors.
When I feel any doubts this is only way to implement word, I make it vectored. NUMBER LITERAL EMIT PIXEL (and also <TIMER> K_F1, MOUSE_LEFT and more of same kind). Vectors are inserted in main INTERPRET loop, so I can modify behavior very easy using only one or little predefined places.
4. Vocabularies.
Old style. No ONLY ALSO, I have no use cases for ANS94 style. I have a set of cross-compilers for several MCU and a line of FPGA-based Forth CPUs. There must be a way to combine there approaches, but I see no reasons to rebuild vocabulary hierarchy each time I want to switch search order.
5. External interfaces.
Now I use two types of Forth applications.
1. DLL with Evaluate function. External program may include this library, initialize Forth with single Init() call, when pass strings via Evaluate(). It is a very powerful scripting tool with JIT compilation.
2. Compact application (~60 kb) with graphics window, preinitialized OpenGL (Canvas + 3D scene). Real-time sprites and 3D scenes out-of-box, graphics plotting and modelling visualization.
Again, all of these are not for make Forth more strange. Just acknowledge for customer demands. I have no goal to 'persuade' anyone or 'propose'. Just my
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-01-18 18:40 -0800 |
| Message-ID | <61ccf78b-715c-4f1a-b16b-46e1cc3e4fa6@googlegroups.com> |
| In reply to | #54136 |
On Wednesday, January 18, 2017 at 7:24:03 PM UTC-5, Ilya Tarasov wrote:
> > > 1. What happens with programming - grows up, falls down? Programming
> > > languages - more or less? How a new language lifecycle looks now?
> > > 2. Computers - desktop, network, embedded, IoT, other.
> > > 3. What about CPU parameters - clock speed, datawidth, ...
> >
> > None of that is CS, and what much does it have to do with Forth? Forth
> > did ok in a particular segment, is still relevant in that segment, and
> > never did all that well in other segments though it has always had a
> > little bit of success in them.
>
> You may refer to IEEE 1074. This is not pure CS, but before start to write code we must clearly understand what exactly we want to do. Particular segment for Forth now looks like found intuitive rahter when predicted and planned. CS achievements are known, and market trends are changes for last 20 years, so it may be very productive to review that segments and find some new.
>
> > > Completing this is not an easy, but otherwise you will continue to add
> > > little changes and hope it is useful for all.
> >
> > Does your system address those issues? I'd be interest in a brief
> > general summary of the differences between your system and ANS, since
> > you're not big on concrete examples.
>
> I can't say I pass this procedure each time during my Forth history. More exact, this is a summary of projects done, including some big enough, where serious project planning was used.
>
> From my earlier success stories I note two things:
> 1. Forth is very good for hardware management, not for replace general calculations. This means MMX/SSE/SSE2 extentions, assembler primitives with Forth wrappers, direct access to video memory etc. FPU is also in this list, because x87 is stack in nature and floating point calculations is fast enough, especially when wrote by skilled programmer, who focused on low-level optimization. After this kind of hard low-level work is done, interpreting mode allow to use simple and fast interface to test and debug.
>
> 2. Forth flexibility means customer-facing system. Literally all of ANS incompatibility based on requests of my customers ('you told Forth is very flexible, so why don't modify this feature according to our wishes?').
>
> Briefly, I can highlight next major differencies:
> 1. Floating point.
> It is based on requirements of physics and DSP specialists, where floating point is required. Forth has a niche as a simple Matlab replacement for tasks with strong mathematical basics, solving from scratch. With little or no libraries, it is no benefits from Matlab itself, and one who is not a pure programmer, but engineer/researcher with some programmer's skills prefer flexible tool instead Matlab.
>
> They told 1.23 is a floating-point number. 3.1415 is also a floating point, not only 1.23E0 and 3.1415E0. No discussion here (or they will gone from Forth). I'm completely agreed :)
>
> 2. OS interface.
> POSIX-like functions are known for many programmers. It may be derived from Pascal or C. None of these returns two parameters. OPEN-FILE THROW is often in ANS Forth code, because it is hard to imagine what else I can do with ior except THROW. We may use DROP instead, but what problem is solved in this case and why don't hide THROW inside? It is rhetorical questions, I don't want to discuss ways to accept ANS formats. File operations are not invented by ANS committee, so I simple copy names from commonly used languages. File IO words returns one parameter, like these libraries.
>
> Btw, strings are ASCIIZ, because it is natural for MS Windows API. I see no reasons to convert strings each time. When Borland Pascal was a mainstream tool, my preferred format was Addr, Count. No deep thoughts here, just taking a look how this solved in the host OS.
>
> Oh, I can't remember a language where strings are represented by S" or STR" or something else. So " is enough. Also, I have a switchable mode, when "some text" will be recognized as string too (no space after first quote char).
>
> 3. Vectors.
> When I feel any doubts this is only way to implement word, I make it vectored. NUMBER LITERAL EMIT PIXEL (and also <TIMER> K_F1, MOUSE_LEFT and more of same kind). Vectors are inserted in main INTERPRET loop, so I can modify behavior very easy using only one or little predefined places.
>
> 4. Vocabularies.
> Old style. No ONLY ALSO, I have no use cases for ANS94 style. I have a set of cross-compilers for several MCU and a line of FPGA-based Forth CPUs. There must be a way to combine there approaches, but I see no reasons to rebuild vocabulary hierarchy each time I want to switch search order.
>
> 5. External interfaces.
> Now I use two types of Forth applications.
> 1. DLL with Evaluate function. External program may include this library, initialize Forth with single Init() call, when pass strings via Evaluate(). It is a very powerful scripting tool with JIT compilation.
> 2. Compact application (~60 kb) with graphics window, preinitialized OpenGL (Canvas + 3D scene). Real-time sprites and 3D scenes out-of-box, graphics plotting and modelling visualization.
>
> Again, all of these are not for make Forth more strange. Just acknowledge for customer demands. I have no goal to 'persuade' anyone or 'propose'. Just my
It's very hard to dis-agree with this. I confess I like what Ilya is saying.
There are aspects of ANS/ISO Forth that moved away from some common practice in the general programming community that were arguably not ideal decisions for the
wider acceptance of Forth. File functions as Ilya mentioned and strings are
always a hot button. One could argue that Forth is a big enough shift for
newbies that providing some familiarity where possible is helpful.
Good to hear a new voice with customer field experience.
BF
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-01-19 06:46 +0200 |
| Message-ID | <o5pg7g$5gj$1@dont-email.me> |
| In reply to | #54136 |
I agree with much of what you say, and much of what you say is the way 8th is implemented in fact... On 19/01/2017 2:24, Ilya Tarasov wrote: > Briefly, I can highlight next major differencies: > 1. Floating point. > It is based on requirements of physics and DSP specialists, where floating point is required. Forth has a niche as a simple Matlab replacement for tasks with strong mathematical basics, solving from scratch. With little or no libraries, it is no benefits from Matlab itself, and one who is not a pure programmer, but engineer/researcher with some programmer's skills prefer flexible tool instead Matlab. > > They told 1.23 is a floating-point number. 3.1415 is also a floating point, not only 1.23E0 and 3.1415E0. No discussion here (or they will gone from Forth). I'm completely agreed :) Yep. > 2. OS interface. > POSIX-like functions are known for many programmers. It may be derived from Pascal or C. None of these returns two parameters. OPEN-FILE THROW is often in ANS Forth code, because it is hard to imagine what else I can do with ior except THROW. We may use DROP instead, but what problem is solved in this case and why don't hide THROW inside? It is rhetorical questions, I don't want to discuss ways to accept ANS formats. File operations are not invented by ANS committee, so I simple copy names from commonly used languages. File IO words returns one parameter, like these libraries. Sort of. "f:read" for instance returns the buffer or string into which the data were read, as well as the number of bytes read. The error result, if any, is available from 'f:err?' applied to the file item. > Btw, strings are ASCIIZ, because it is natural for MS Windows API. I see no reasons to convert strings each time. When Borland Pascal was a mainstream tool, my preferred format was Addr, Count. No deep thoughts here, just taking a look how this solved in the host OS. Yes. Not just Windows, but all common OSes use ASCIIZ underneath (or UTF*-Z or whatever). > Oh, I can't remember a language where strings are represented by S" or STR" or something else. So " is enough. Also, I have a switchable mode, when "some text" will be recognized as string too (no space after first quote char). Yep, Just " without a trailing space, like in most every other language. > 3. Vectors. > When I feel any doubts this is only way to implement word, I make it vectored. NUMBER LITERAL EMIT PIXEL (and also <TIMER> K_F1, MOUSE_LEFT and more of same kind). Vectors are inserted in main INTERPRET loop, so I can modify behavior very easy using only one or little predefined places. > > 4. Vocabularies. > Old style. No ONLY ALSO, I have no use cases for ANS94 style. I have a set of cross-compilers for several MCU and a line of FPGA-based Forth CPUs. There must be a way to combine there approaches, but I see no reasons to rebuild vocabulary hierarchy each time I want to switch search order. 8th uses 'namespaces' which also act like ANS vocabularies, but are primarily used to segregate words into logically related groups.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-18 23:25 -0800 |
| Message-ID | <7003e4eb-7914-4689-bd7f-0667c2fe62eb@googlegroups.com> |
| In reply to | #54146 |
четверг, 19 января 2017 г., 7:46:11 UTC+3 пользователь Ron Aaron написал: > I agree with much of what you say, and much of what you say is the way > 8th is implemented in fact... I'm keep in mind 8th as an example of Forth dialect based on customers demands. It was no chance to mention it... :) > Sort of. "f:read" for instance returns the buffer or string into which > the data were read, as well as the number of bytes read. The error > result, if any, is available from 'f:err?' applied to the file item. I think this is a simple rule - start with wrappers over OS API. Any desired library after this. > Yes. Not just Windows, but all common OSes use ASCIIZ underneath (or > UTF*-Z or whatever). Same thing here. Data formats, different from built-in in OS, causes hard fight for a long time. > Yep, Just " without a trailing space, like in most every other language. I just add a logical variable to allow recignizing such strings. Someone may want to start a word with " and this may match string literal. Words are recognized first, so this certainly will cause error. I think this is a good style to avoid names starting with " > 8th uses 'namespaces' which also act like ANS vocabularies, but are > primarily used to segregate words into logically related groups. Most demanded use case for me is cross-compilation. Names for target CPU are Forth names, so segregation is necessary. ASSEMBLER looks better than ONLY FORTH ALSO ASSEMBLER
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-19 09:47 +0000 |
| Message-ID | <2017Jan19.104746@mips.complang.tuwien.ac.at> |
| In reply to | #54136 |
Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
>They told 1.23 is a floating-point number. 3.1415 is also a floating point,=
> not only 1.23E0 and 3.1415E0. No discussion here (or they will gone from F=
>orth). I'm completely agreed :)
1.23 and 3.1415 have no standard meaning in Forth-94/2012, so you are
free to treat them as FP numbers. The problem here is that 123. is
required to be a double-cell integer. I hope we can get rid of this
soon. After all, we now have #123.
>2. OS interface.
>POSIX-like functions are known for many programmers. It may be derived from=
> Pascal or C. None of these returns two parameters. OPEN-FILE THROW is ofte=
>n in ANS Forth code, because it is hard to imagine what else I can do with =
>ior except THROW. We may use DROP instead, but what problem is solved in th=
>is case and why don't hide THROW inside?
The Forth-94 TC probably did not want to require the exception wordset
for systems that have the file or memory-access wordsets. CATCH and
THROW were very new then.
Interestingly, the actual (assembly-level) Unix system calls return
two values (and this has been maintained from the earliest Unix up to
Linux); the C wrappers then divide this into errno and the direct
return value, because C can only return one value (and originally
could not return structs).
>Btw, strings are ASCIIZ, because it is natural for MS Windows API.
Other people tell me that the Windows API uses UTF-16 instead of
ASCII.
Complicating Forth interfaces for the benefit of simpler
implementation on some systems has proved to be a mistake in the past
(in particular, having the parameters of foreign functions in
reverse), and is a mistake in this case, too. We have a standard
string representation (c-addr u), and we should use it all the time in
Forth, and convert at the borders. The alternative of having ASCIIZ
strings here, UTF-16 strings there, c-addr u UTF-8 strings yonder,
byte-counted strings in another place, and cell-counted strings
elsewhere is confusing and therefore error-prone.
>Also, I have a switchable mode, when "s=
>ome text" will be recognized as string too (no space after first quote char=
>).
Take a look at the recognizer proposal.
- 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 | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-19 02:44 -0800 |
| Message-ID | <7491c39b-06c8-479c-8f5c-e444d6c9217f@googlegroups.com> |
| In reply to | #54155 |
> 1.23 and 3.1415 have no standard meaning in Forth-94/2012, so you are > free to treat them as FP numbers. The problem here is that 123. is > required to be a double-cell integer. I hope we can get rid of this > soon. After all, we now have #123. Indeed, it is not user's problem. It is a Forth problem to have different meaning for very common used thing. My first reaction was to modify this, and all colleagues who was in the first wave of Forth users around me, think the same. If Forth is proposed to solve mathematical tasks, it must not dictate it's own rules. Especially if Forth is positioned as a flexible language. > The Forth-94 TC probably did not want to require the exception wordset > for systems that have the file or memory-access wordsets. CATCH and > THROW were very new then. Another trap. 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. Another side of a problem is server application. For servers, an ability to recover from such kind of errors is important. This is why I highlight a preliminary planning work - one solution is preferrable for server applications, and other for desktop/embedded. Missing file or file read error in embedded application usually means hardware failure with no possible software recovering. > Interestingly, the actual (assembly-level) Unix system calls return > two values (and this has been maintained from the earliest Unix up to > Linux); the C wrappers then divide this into errno and the direct > return value, because C can only return one value (and originally > could not return structs). Yes, pointer to structure is a solution for C, where one returning value is allowed. This is not a kind of fashion or C domination, just a question to programmers 'what kind of system calls you prefer to use?'. If Forth is positioning in the area, where another language is strong, naming conventions of that languages may be applied to minimize adaptation efforts for programmers. > >Btw, strings are ASCIIZ, because it is natural for MS Windows API. > > Other people tell me that the Windows API uses UTF-16 instead of > ASCII. Windows API use both encoding. Letter A or U is added for function name to explicitly describe which kind of string format is required. So, MessageBoxA and MessageBoxU are exist. > Complicating Forth interfaces for the benefit of simpler > implementation on some systems has proved to be a mistake in the past > (in particular, having the parameters of foreign functions in > reverse), and is a mistake in this case, too. We have a standard > string representation (c-addr u), and we should use it all the time in > Forth, and convert at the borders. The alternative of having ASCIIZ > strings here, UTF-16 strings there, c-addr u UTF-8 strings yonder, > byte-counted strings in another place, and cell-counted strings > elsewhere is confusing and therefore error-prone. With intensive use of API calls, many convertions are required. Also, programmers usually keeps in mind the most preferable representation of data and thinks about ways to work with them. If we declare flexibility is important Forth feature we need to support this and start with question 'what data format you prefer for your application domain? We are ready to support it without any significant troubles, because Forth is flexible'. > Take a look at the recognizer proposal. Recognizers looks opposite to Forth basics because raises complexity level too high. The question is not just 'how to provide anything user ask for', but 'what from user demands we can provide with minimum efforts'. Recognizers will lead to full-scale syntax analyzer, and this completely breaks the simplicity of Forth. Programmers may not want to implement Forth, because with an ability to write recognizers they certainly can implement other C-like language.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-19 06:16 -0600 |
| Message-ID | <8OSdnR8yu_SeMx3FnZ2dnUU7-f3NnZ2d@supernews.com> |
| In reply to | #54157 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> 1.23 and 3.1415 have no standard meaning in Forth-94/2012, so you are >> free to treat them as FP numbers. The problem here is that 123. is >> required to be a double-cell integer. I hope we can get rid of this >> soon. After all, we now have #123. > > Indeed, it is not user's problem. It is a Forth problem to have > different meaning for very common used thing. My first reaction was > to modify this, and all colleagues who was in the first wave of > Forth users around me, think the same. If Forth is proposed to solve > mathematical tasks, it must not dictate it's own rules. As you will have noticed, Forth does not "not dictate it's own rules". If you want 1.23 to be a floating-point value, you can do that. And still be standard. >> The Forth-94 TC probably did not want to require the exception wordset >> for systems that have the file or memory-access wordsets. CATCH and >> THROW were very new then. > > Another trap. 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. And that's what a THROW will do. But a THROW can also be caught, so it is better than ABORT. If this is a log file, then you stop logging and send an error report if there is anywhere to send one. This is obviously better than causing your rocket to self-destruct. >> two values (and this has been maintained from the earliest Unix up to >> Linux); the C wrappers then divide this into errno and the direct >> return value, because C can only return one value (and originally >> could not return structs). > > Yes, pointer to structure is a solution for C, where one returning > value is allowed. This is not a kind of fashion or C domination, > just a question to programmers 'what kind of system calls you prefer > to use?'. If Forth is positioning in the area, where another > language is strong, naming conventions of that languages may be > applied to minimize adaptation efforts for programmers. That makes perfect sense if one is not worse than the other. But Forth has the ability to return more than one value from a call. Languages that only allow a single value to be returned are worse in this regard. >> >Btw, strings are ASCIIZ, because it is natural for MS Windows API. >> >> Other people tell me that the Windows API uses UTF-16 instead of >> ASCII. > > Windows API use both encoding. Letter A or U is added for function > name to explicitly describe which kind of string format is > required. So, MessageBoxA and MessageBoxU are exist. And that's a twenty-four carat kludge. On stilts. Pace Dijkstra: If Windows is to be used as a point of departure, I can only recommend that you depart from it as far as possible. None of this is to say that Forth systems with special needs should not provide convenient interfaces for an OS or some hardware. Most of them do, of course. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-19 07:43 -0800 |
| Message-ID | <3eaba9f1-749e-418f-8062-ed736c2144e5@googlegroups.com> |
| In reply to | #54164 |
> As you will have noticed, Forth does not "not dictate it's own rules". > If you want 1.23 to be a floating-point value, you can do that. And > still be standard. I want also 1. to be a floating-point, and 1,23 too. Some programs may export results this way. > And that's what a THROW will do. But a THROW can also be caught, so > it is better than ABORT. If this is a log file, then you stop logging > and send an error report if there is anywhere to send one. This is > obviously better than causing your rocket to self-destruct. If Forth simply stop the program it is not a self-destruction. Unhandled THROW is worse than ABORT. Who must catch errors any time? I note many users are not pure programmers and don't want to play games with error processing. They want just open file, and ready to accept a message 'File not found'. If so, they need to correct name or check file is really copied. Many THROWs cause a simple question: 'if you need this word at certain place every time, why don't combine it with other words?'. C++ program will crash with exception, but restarting Forth interpreter is not a crush. > > to use?'. If Forth is positioning in the area, where another > > language is strong, naming conventions of that languages may be > > applied to minimize adaptation efforts for programmers. > > That makes perfect sense if one is not worse than the other. But > Forth has the ability to return more than one value from a call. > Languages that only allow a single value to be returned are worse in > this regard. I keep my previous sentence. Yes, Forth has this ability. Is this a reason to crush programmer's patterns? A simple principe - 'just like in your favourite language, but with postfix notation'. > And that's a twenty-four carat kludge. On stilts. Pace Dijkstra: If > Windows is to be used as a point of departure, I can only recommend > that you depart from it as far as possible. I don't believe to anyone irrevocably. Again, if Forth is smart and flexible, why don't write it for Windows? For Linux? For Android? For bare metal? There are many reasons to use Windows (or bare metal), and worldwide statistics confirms it. Bad character format is a weak argument for not to write Forth for Windows.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-01-19 11:07 -0600 |
| Message-ID | <KeOdneNQX_z2bx3FnZ2dnUU7-cmdnZ2d@supernews.com> |
| In reply to | #54169 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> As you will have noticed, Forth does not "not dictate it's own rules". >> If you want 1.23 to be a floating-point value, you can do that. And >> still be standard. > > I want also 1. to be a floating-point, and 1,23 too. Some programs may export results this way. > >> And that's what a THROW will do. But a THROW can also be caught, so >> it is better than ABORT. If this is a log file, then you stop logging >> and send an error report if there is anywhere to send one. This is >> obviously better than causing your rocket to self-destruct. > > If Forth simply stop the program it is not a self-destruction. It is if the program is contolling your rocket. > Unhandled THROW is worse than ABORT. No it isn't. Unhandled THROW is exactly the same as ABORT. >> And that's a twenty-four carat kludge. On stilts. Pace Dijkstra: If >> Windows is to be used as a point of departure, I can only recommend >> that you depart from it as far as possible. > > I don't believe to anyone irrevocably. Again, if Forth is smart and > flexible, why don't write it for Windows? For Linux? For Android? > For bare metal? There are many reasons to use Windows (or bare > metal), and worldwide statistics confirms it. Bad character format > is a weak argument for not to write Forth for Windows. Err, no. I didn't say don't write Forth for Windows. If you need to handle that system, you need Windows interface words. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web