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 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-01 19:55 -0800 |
| Message-ID | <b14d963b-744c-4cbf-88e8-e3f2cb31a002@googlegroups.com> |
| In reply to | #53633 |
On Friday, December 30, 2016 at 6:21:37 PM UTC-7, Elizabeth D. Rather wrote:
> On 12/30/16 2:49 PM, HAA wrote:
> > Removing choice is of course what standards do. Standards are an ever
> > narrowing jail that ultimately chokes on itself. 47 years of Forth standards,
> > 23 years since ANS, 10 years since 200x and no programs or users to
> > speak of. That's what standards in Forth have achieved.
>
> On the contrary, there are a number of standard systems available, and
> quite a few programmers using them. They have been the basis of some
> major projects, many of which I have referenced here over the years. The
> advent of ANS Forth liberated Forth system developers from the
> constraints of implementation specifications in Forth83, making possible
> the era of optimizing compilers and other advances that have led to
> faster, more powerful systems. It has brought freedom, not jail.
>
> Every significant language has standards, and all of them have their
> critics, just as Forth Standards do. But they are widely respected and
> influential, even in systems that do not choose to follow them rigorously.
>
> Cheers,
> Elizabeth
I don't agree with either of you.
HAA says: "Removing choice is of course what standards do." (true)
And he says: "Standards are an ever narrowing jail that ultimately chokes on itself." (not true).
A standard does remove choice, obviously, because the programmer is restrained by the rules (there should be rules; not ambiguity like ANS-Forth has). There is no reason for the rules to be "ever narrowing" though --- you adopt your standard and then you stick with it --- also, the point of the standard is portability of software (mostly code-libraries), so if people want to have code-libraries available then they voluntarily accept the rules (it is not a jail).
E.R. says: "The advent of ANS Forth liberated Forth system developers from the constraints of implementation specifications in Forth83, making possible the era of optimizing compilers and other advances that have led to
faster, more powerful systems."
This lie made Jeff Fox so mad! I would say that Elizabeth Rather falsely taking credit for making Forth optimizing compilers possible, was a major contributor to his death.
ANS-Forth is such a screwed up standard that any significant work in ANS-Forth is primarily involved in working around the idiotic problems of ANS-Forth, rather than solving the problem itself. For example, my early-binding MACRO: was written in UR/Forth initially and was Forth-83 compliant (almost all of MFX was Forth-83 compliant). In ANS-Forth my early-binding MACRO: had to wait until I had disambiguifiers available because FIND is broken in ANS-Forth. This is why it didn't get written until 2016. I knew about the disambiguifiers in 2010 and could have written the early-binding MACRO: then, but this had to wait until I wrote STR>NUM which I did in 2016. Even something trivial such as an early-binding MACRO:, which was easy in Forth-83, is difficult in ANS-Forth.
My MACRO: (both the late-binding and early-binding versions) do inlining. Inlining is a pretty easy optimization, and this was commonly done in Forth-83. For the most part, inlining is the only optimization being done in SwiftForth today.
: init-list 0 over ! ; ok
see over
405C5F 4 # EBP SUB 83ED04
405C62 EBX 0 [EBP] MOV 895D00
405C65 4 [EBP] EBX MOV 8B5D04
405C68 RET C3 ok
see !
40572F 0 [EBP] EAX MOV 8B4500
405732 EAX 0 [EBX] MOV 8903
405734 4 [EBP] EBX MOV 8B5D04
405737 8 # EBP ADD 83C508
40573A RET C3 ok
Notice how OVER and ! are just being pasted in unchanged:
see init-list
478F0F 4 # EBP SUB 83ED04
478F12 EBX 0 [EBP] MOV 895D00
478F15 0 # EBX MOV BB00000000 \ 0 ends here
478F1A 4 # EBP SUB 83ED04
478F1D EBX 0 [EBP] MOV 895D00
478F20 4 [EBP] EBX MOV 8B5D04 \ OVER ends here
478F23 0 [EBP] EAX MOV 8B4500
478F26 EAX 0 [EBX] MOV 8903
478F28 4 [EBP] EBX MOV 8B5D04
478F2B 8 # EBP ADD 83C508 \ ! ends here
478F2E RET C3 ok
So, how exactly did ANS-Forth make optimizing compilers possible? This is the same kind of optimization that was done in Forth-83. Also, this isn't really optimization --- all it does is get rid of the CALL/RET for each sub-function, but this has very little effect because the modern x86 does CALL/RET prediction anyway --- SwiftForth is still moving data on and off the data-stack needlessly, and all of this memory access is the major speed killer (optimization involves holding data in registers).
This is VFX:
see init-list
INIT-LIST
( 004E1030 C70300000000 ) MOV DWord Ptr 0 [EBX], 00000000
( 004E1036 C3 ) NEXT,
( 7 bytes, 2 instructions )
ok
For the most part, the point of having a standard is to support code-libraries. Elizabeth Rather has fought tooth and nail against code-libraries her entire career though. She refers to the call for code-libraries to be an "endless whine" --- that is grossly offensive! --- that is also abysmally ignorant. This is the primary reason why Forth has become obscure --- nobody is going to use a language that doesn't support code-libraries.
Straight Forth doesn't support parallelization, so Oforth would be a better choice for programs that need this. Oforth and Factor don't support cross-compilers though, so Straight Forth would be a better choice for that. Other than cross-compilers, Straight Forth is mostly for numeric programs --- Straight Forth does have a string-stack though, so it would be better than ANS-Forth (or C) for text handling.
Straight Forth has quotations, which C lacks, so Straight Forth is primarily competing against C --- competing against ANS-Forth is nonsense, because nobody uses ANS-Forth --- Straight Forth is not competing against all of the Scheme/Lisp derived languages such as Ruby, Python, Factor, etc. which are widely used for script-writing and web-servers.
I'm not saying that Straight Forth is the end-all of Forth. I'm just saying that Straight Forth would support code-libraries, so it would be an actual Standard, rather than just another toy Forth system like ANS-Forth or JonesForth. Straight Forth has quotations using the fat-xt method, so it supports general-purpose data-structures. Here is a snippet from my StraightForth.txt document (note that PTR and CNT are user-registers):
---------------------------------------------------------------------------
subsection 1.3.3. --- HOFs for chains
=====================================
A "chain" is a data-structure that is ordered by a key which is a string. A chain can be used as an association, which is like an array indexed by strings, although it is not going to be as fast as a hash-table (if this is a problem, I may implement hash-tables at some time in the future, but Straight Forth isn't competing against Lua so this may never be an issue). A chain is ordered, and it is expected that the key will typically be the string representation of a number (the strings should all be the same length and have the decimal point in the same position, so they compare the same as numbers would compare). In a cross-compiler, for example, the keys would be line-numbers --- also, numeric programs may use chains for sparse arrays.
In a chain, a pointer to a node indicates that this is the current node that we are interested in. This is not necessarily the head (left-most) or tail (right-most) in the chain.
|FULL-RITE ( xt -- ) needs PTR = current-node
Execute xt for each node in the entire list starting at the head-node and moving right.
When the xt function executes, PTR points to the current node.
|FULL-LEFT ( xt -- ) needs PTR = current-node
Execute xt for each node in the entire list starting at the tail-node and moving left.
When the xt function executes, PTR points to the current node.
|EACH-RITE ( xt -- ) needs PTR = current-node
Execute xt for each node starting at PTR@ and moving right.
When the xt function executes, PTR points to the current node.
|EACH-LEFT ( xt -- ) needs PTR = current-node
Execute xt for each node starting at PTR@ and moving left.
When the xt function executes, PTR points to the current node.
|FULL-RITE-UNTIL ( xt -- false | node true ) needs PTR = current-node --- sets PTR= node right of found-node
Execute xt for each node in the entire list starting at the head-node and moving right.
When the xt function executes, PTR points to the current node.
The xt function must return a flag. If the FLAG is TRUE then early-exit.
Return the node that caused the early-exit if there was an early-exit.
PTR is set to the node right of found-node (NIL if found-node was the right-most node).
PTR is restored if there was no early-exit.
|FULL-LEFT-UNTIL ( xt -- false | node true ) needs PTR = current-node --- sets PTR= node left of found-node
Execute xt for each node in the entire list starting at the tail-node and moving left.
When the xt function executes, PTR points to the current node.
The xt function must return a flag. If the FLAG is TRUE then early-exit.
Return the node that caused the early-exit if there was an early-exit.
PTR is set to the node left of found-node (NIL if found-node was the left-most node).
PTR is restored if there was no early-exit.
|EACH-RITE-UNTIL ( xt -- false | node true ) needs PTR = current-node --- sets PTR= node right of found-node
Execute xt for each node starting at PTR@ and moving right.
When the xt function executes, PTR points to the current node.
The xt function must return a flag. If the FLAG is TRUE then early-exit.
Return the node that caused the early-exit if there was an early-exit.
PTR is set to the node right of found-node (NIL if found-node was the right-most node).
PTR is restored if there was no early-exit.
|EACH-LEFT-UNTIL ( xt -- false | node true ) needs PTR = current-node --- sets PTR= node left of found-node
Execute xt for each node starting at PTR@ and moving left.
When the xt function executes, PTR points to the current node.
The xt function must return a flag. If the FLAG is TRUE then early-exit.
Return the node that caused the early-exit if there was an early-exit.
PTR is set to the node left of found-node (NIL if found-node was the left-most node).
PTR is restored if there was no early-exit.
The following aren't HOFs, but are just some functions for chains:
LEFT-LENGTH ( -- n ) needs PTR = current-node
Returns the number of nodes to the left of PTR@.
RITE-LENGTH ( -- n ) needs PTR = current-node
Returns the number of nodes to the right of PTR@.
LENGTH ( -- n ) needs PTR = current-node
Returns the total number of nodes in the chain.
HEAD ( -- flag ) needs PTR = current-node --- sets PTR= head-node
Returns TRUE if PTR@ was already the head-node, or FALSE if PTR was changed.
TAIL ( -- flag ) needs PTR = current-node --- sets PTR= tail-node
Returns TRUE if PTR@ was already the tail-node, or FALSE if PTR was changed.
LEFT ( -- flag ) needs PTR = current-node --- sets PTR= left-of-current-node
Returns TRUE if PTR changed, or FALSE if PTR@ was already the left-most node.
PTR is set to the node left of the current-node if possible.
PTR is restored if it is already the left-most node.
RITE ( -- flag ) needs PTR = current-node --- sets PTR= rite-of-current-node
Returns TRUE if PTR changed, or FALSE if PTR@ was already the right-most node.
PTR is set to the node right of the current-node if possible.
PTR is restored if it is already the right-most node.
INSERT-WEAK ( chain -- clash-chain ) needs PTR = current-node
Abort if CHAIN is already in the current chain.
Insert CHAIN into the current chain.
If any of CHAIN's nodes clash (have the same key as a node in the current chain),
then no insertion is done and the clashing node is inserted into CLASH-CHAIN instead.
INSERT-STRONG ( chain -- clash-chain ) needs PTR = current-node
Abort if CHAIN is already in the current chain.
Insert CHAIN into the current chain.
If any of CHAIN's nodes clash (have the same key as a node in the current chain),
then the insertion is done, but first the old node is removed and inserted into CLASH-CHAIN.
It is illegal to have multiple nodes in a chain with the same key. INSERT-WEAK and INSERT-STRONG remove the nodes with duplicate keys rather than mix them together in the same chain, and these duplicates are all put in a new clash-chain. Normally the clash-chain should be empty (returned as a NIL node) --- if any nodes get put in the clash-chain, this usually means that there is a bug in the program.
SAFE-REMOVE ( node -- ) needs PTR = current-node --- sets PTR= head-node
Remove NODE from the list.
Set PTR to the head-node (not necessarily the same as the previous head-node).
REMOVE ( node -- ) needs PTR = current-node
Abort if NODE = PTR@.
Remove NODE from the list.
Removing a node is problematic because you have to be careful not to remove the only node in the chain that you have a pointer for. SAFE-REMOVE solves this problem by setting PTR to a valid node, but you lose track of which node is your current-node. If you are sure that your current-node is not the node that you are removing (you usually are) then REMOVE lets you keep your current-node in PTR.
DELINK-LEFT ( -- left-chain ) needs PTR = current-node
Split the chain to the left of PTR@ so PTR@ becomes the head of the current chain.
Return LEFT-CHAIN as the tail of a new chain.
DELINK-RITE ( -- rite-chain ) needs PTR = current-node
Split the chain to the right of PTR@ so PTR@ becomes the tail of the current chain.
Return RITE-CHAIN as the head of a new chain.
SEARCH ( -- false | node true ) s( str -- ) needs PTR = current-node
Search the current chain for a node with STR as its key.
Return the found node, or FALSE if nothing was found.
OPTIMIZE-SEARCH ( -- ) needs PTR = current-node
Make the chain more efficient for future calls to SEARCH.
The programmer shouldn't bother with this unless he has reason to believe that it will improve his program's speed.
Overuse of this may degrade a program's speed, so it should be used judiciously
Straight Forth standardizes behavior, not implementation, so the programmer shouldn't rely on any assumptions about implementation. Just to satisfy curiosity though, I will mention that I'm implementing chains as AVL trees. Each node has three pointers, which are left-down, rite-down and up. The up-pointer is needed so LEFT and RITE will work, as PTR does not necessarily point to the root node. Each node also keeps track of its weight which is used by the AVL self-balancing algorithm. OPTIMIZE-SEARCH doesn't do anything at all. I used the name "chain" rather than "tree" (my original name) because binary-trees aren't the only reasonable way that chains could be implemented --- doubly linked lists would also work and would save some memory --- different implementations of Straight Forth may have different implementations of chains.
---------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-01 21:13 -0800 |
| Message-ID | <ba246ad4-43b3-4533-b018-8b490c5075e8@googlegroups.com> |
| In reply to | #53653 |
On Sunday, January 1, 2017 at 8:55:47 PM UTC-7, hughag...@gmail.com wrote: > E.R. says: "The advent of ANS Forth liberated Forth system developers from the constraints of implementation specifications in Forth83, making possible the era of optimizing compilers and other advances that have led to > faster, more powerful systems." > > This lie made Jeff Fox so mad! I would say that Elizabeth Rather falsely taking credit for making Forth optimizing compilers possible, was a major contributor to his death. Jeff Fox was very proud of his work in Forth and every time that Elizabeth Rather tells a lie about how none of his work exists and/or that she deserves credit for everything that anybody has ever been written in Forth, it was like stabbing him through the heart with a big knife. I don't have much experience with F83 --- IIRC, it did inlining --- it had something similar to my early-binding MACRO: or maybe it just inlined the compiled code similar to ICODE in SwiftForth. There were several Forth-83 systems that went beyond simple inlining. I used TCOM (written by Tom Zimmer) and ForthCMP (written by Tom Almy). Both of these were cross-compilers. There was also FPC from Tom Zimmer that was a more traditional interactive system --- I don't have much experience with FPC, though. I mostly used UR/Forth. That was the primary Forth-83 system for professional work in MS-DOS days. To get a job as a Forth programmer, it was primarily necessary to know UR/Forth --- the others were much less used. UR/Forth was interactive, so was easy to work with. There were cross-compilers available from LMI for it though, to a variety of targets, from the 80186 to the 80c320. Testra used their 80c320 cross-compiler for their motion-control program. Later though, I wrote MFX in UR/Forth to target the MiniForth processor which was much more powerful than the 80c320. There is nothing about Forth-83 that prevents optimizing compilers from being written. ANS-Forth's FIND is broken, so it can't be used for optimizing compilers, at least not until the disambiguifiers are made available. Why do Elizabeth Rather's sycophants hate the disambiguifiers? It seems obvious that they want FIND to remain broken in order to prevent common Forth programmers from writing code such as my early-binding MACRO: that do optimization (you can't do any optimization unless you can obtain xt values). ANS-Forth is a cult --- it is all about preventing common Forth programmers from writing code --- simultaneously, there is a great deal of braying about "freedom" from Elizabeth Rather.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2017-01-02 07:14 -0800 |
| Message-ID | <31bfc263-af61-44b7-850d-d366cab82d68@googlegroups.com> |
| In reply to | #53654 |
On Monday, January 2, 2017 at 12:13:56 AM UTC-5, hughag...@gmail.com wrote: > On Sunday, January 1, 2017 at 8:55:47 PM UTC-7, hughag...@gmail.com wrote: > > E.R. says: "The advent of ANS Forth liberated Forth system developers from the constraints of implementation specifications in Forth83, making possible the era of optimizing compilers and other advances that have led to > > faster, more powerful systems." > > > > This lie made Jeff Fox so mad! I would say that Elizabeth Rather falsely taking credit for making Forth optimizing compilers possible, was a major contributor to his death. > > Jeff Fox was very proud of his work in Forth and every time that Elizabeth Rather tells a lie about how none of his work exists and/or that she deserves credit for everything that anybody has ever been written in Forth, it was like stabbing him through the heart with a big knife. > > I don't have much experience with F83 --- IIRC, it did inlining --- it had something similar to my early-binding MACRO: or maybe it just inlined the compiled code similar to ICODE in SwiftForth. > > There were several Forth-83 systems that went beyond simple inlining. I used TCOM (written by Tom Zimmer) and ForthCMP (written by Tom Almy). Both of these were cross-compilers. There was also FPC from Tom Zimmer that was a more traditional interactive system --- I don't have much experience with FPC, though. > > I mostly used UR/Forth. That was the primary Forth-83 system for professional work in MS-DOS days. To get a job as a Forth programmer, it was primarily necessary to know UR/Forth --- the others were much less used. UR/Forth was interactive, so was easy to work with. There were cross-compilers available from LMI for it though, to a variety of targets, from the 80186 to the 80c320. Testra used their 80c320 cross-compiler for their motion-control program. Later though, I wrote MFX in UR/Forth to target the MiniForth processor which was much more powerful than the 80c320. > > There is nothing about Forth-83 that prevents optimizing compilers from being written. ANS-Forth's FIND is broken, so it can't be used for optimizing compilers, at least not until the disambiguifiers are made available. Why do Elizabeth Rather's sycophants hate the disambiguifiers? It seems obvious that they want FIND to remain broken in order to prevent common Forth programmers from writing code such as my early-binding MACRO: that do optimization (you can't do any optimization unless you can obtain xt values). ANS-Forth is a cult --- it is all about preventing common Forth programmers from writing code --- simultaneously, there is a great deal of braying about "freedom" from Elizabeth Rather. For the record on optimizing Forth compilers, Hs/Forth 1992 or so could do this: : BOUNDS OPT" OVER + SWAP" ; and it created in-lined code with push/pop optimizations and a few other substitutions as well. Speed up was about 4 to 10 times vs the normal ITC code. Funnily enough Jim Calihan didn't like Forth 83 so he stuck with 79. :) But he provided a Forth 83 Harness that worked correctly. For the historians. RIP Jim Calihan BF
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-02 07:42 -1000 |
| Message-ID | <l9qdnfKSwpKYDPfFnZ2dnUU7-bfNnZ2d@supernews.com> |
| In reply to | #53666 |
On 1/2/17 5:14 AM, foxaudioresearch@gmail.com wrote: > On Monday, January 2, 2017 at 12:13:56 AM UTC-5, hughag...@gmail.com wrote: >> On Sunday, January 1, 2017 at 8:55:47 PM UTC-7, hughag...@gmail.com wrote: >>> E.R. says: "The advent of ANS Forth liberated Forth system developers from the constraints of implementation specifications in Forth83, making possible the era of optimizing compilers and other advances that have led to >>> faster, more powerful systems." >>> >>> This lie made Jeff Fox so mad! I would say that Elizabeth Rather falsely taking credit for making Forth optimizing compilers possible, was a major contributor to his death. >> >> Jeff Fox was very proud of his work in Forth and every time that Elizabeth Rather tells a lie about how none of his work exists and/or that she deserves credit for everything that anybody has ever been written in Forth, it was like stabbing him through the heart with a big knife. >> >> I don't have much experience with F83 --- IIRC, it did inlining --- it had something similar to my early-binding MACRO: or maybe it just inlined the compiled code similar to ICODE in SwiftForth. >> >> There were several Forth-83 systems that went beyond simple inlining. I used TCOM (written by Tom Zimmer) and ForthCMP (written by Tom Almy). Both of these were cross-compilers. There was also FPC from Tom Zimmer that was a more traditional interactive system --- I don't have much experience with FPC, though. >> >> I mostly used UR/Forth. That was the primary Forth-83 system for professional work in MS-DOS days. To get a job as a Forth programmer, it was primarily necessary to know UR/Forth --- the others were much less used. UR/Forth was interactive, so was easy to work with. There were cross-compilers available from LMI for it though, to a variety of targets, from the 80186 to the 80c320. Testra used their 80c320 cross-compiler for their motion-control program. Later though, I wrote MFX in UR/Forth to target the MiniForth processor which was much more powerful than the 80c320. >> >> There is nothing about Forth-83 that prevents optimizing compilers from being written. ANS-Forth's FIND is broken, so it can't be used for optimizing compilers, at least not until the disambiguifiers are made available. Why do Elizabeth Rather's sycophants hate the disambiguifiers? It seems obvious that they want FIND to remain broken in order to prevent common Forth programmers from writing code such as my early-binding MACRO: that do optimization (you can't do any optimization unless you can obtain xt values). ANS-Forth is a cult --- it is all about preventing common Forth programmers from writing code --- simultaneously, there is a great deal of braying about "freedom" from Elizabeth Rather. > > For the record on optimizing Forth compilers, Hs/Forth 1992 or so could do this: > > : BOUNDS OPT" OVER + SWAP" ; > > and it created in-lined code with push/pop optimizations and a few other substitutions as well. Speed up was about 4 to 10 times vs the normal ITC code. Sure, one *could* make optimizing compilers at any time, but they would be in direct violation of Forth 83 (as well as Forth 79) since both mandated 16-bit ITC. Cheers, Elizabeth > Funnily enough Jim Calihan didn't like Forth 83 so he stuck with 79. :) > But he provided a Forth 83 Harness that worked correctly. > > For the historians. > > RIP Jim Calihan > > BF > -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-03 02:00 +0100 |
| Message-ID | <o4et35$nfh$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53670 |
In article <l9qdnfKSwpKYDPfFnZ2dnUU7-bfNnZ2d@supernews.com>, Elizabeth D. Rather <erather@forth.com> wrote: <SNIP> > >Sure, one *could* make optimizing compilers at any time, but they would >be in direct violation of Forth 83 (as well as Forth 79) since both >mandated 16-bit ITC. I wonder. There is a straightforward way to optimise ITC quite a bit. Inline everything until code words remain, then replace by the code itself, leaving out the next's, replacing branches whith machine code jumps. Would anyone be upset? What would be the argument that the resulting code is not Forth-83, given that nobody argues that there can't be code words? Those words could have been written in code to begin with. > >Cheers, >Elizabeth 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 | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-01-03 00:13 -0500 |
| Message-ID | <20170103001354.68180c0a@_> |
| In reply to | #53681 |
On Tue, 3 Jan 2017 02:00:21 +0100 (CET) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote: > I wonder. There is a straightforward way to optimise ITC quite a bit. ... > Inline everything until [only] code words remain, Yes. Perhaps, a variant of SEE could do this? > then replace by the code itself, Once inlined, you might just convert them from addresses or offsets into assembly subroutine calls. E.g., in Forth, DUP SWAP +! I.e., becomes in x86 assembly, call dup call swap call plus_store The "code words" or "primitives" for dup, swap, or plus_store would remain as assembly routines (or C etc) and simply be called. This should be ITC converted to STC, or something very similar to it. > leaving out the next's, Yes. > replacing branches whith machine code jumps. Yes, but more likely, they'd be converted to absolute branches and conditional branches, unless they don't have sufficient range. > Would anyone be upset? I don't know. There might be issues with converting certain Forth words, such as DOES> or S" which inline data within the threaded code. You'd need to insert branches around the data. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-01-02 22:02 -1000 |
| Message-ID | <dOydnY_RA-Xhx_bFnZ2dnUU7-K3NnZ2d@supernews.com> |
| In reply to | #53687 |
On 1/2/17 7:13 PM, Rod Pemberton wrote: > On Tue, 3 Jan 2017 02:00:21 +0100 (CET) > albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote: > >> I wonder. There is a straightforward way to optimise ITC quite a bit. > ... > >> Inline everything until [only] code words remain, > > Yes. Perhaps, a variant of SEE could do this? > >> then replace by the code itself, > > Once inlined, you might just convert them from addresses or offsets > into assembly subroutine calls. > > E.g., in Forth, > > DUP SWAP +! > > I.e., becomes in x86 assembly, > > call dup > call swap > call plus_store Surely any compiler worth its salt would know that SWAP following DUP is a no-op and skip it? Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-03 11:19 +0000 |
| Message-ID | <2017Jan3.121900@mips.complang.tuwien.ac.at> |
| In reply to | #53695 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>Surely any compiler worth its salt would know that SWAP following DUP is
>a no-op and skip it?
Depends on the technology used by the compiler. For compilers that
just use peephole optimization (like SwiftForth and gforth-fast) would
need a peephole optimization rule for this combination, and since this
sequence does not occur in real-world code, the compiler maintainer is
unlikely to add this rule. Let's see:
[~:92330] sf
SwiftForth i386-Linux 3.4.4 31-Jul-2012
: x dup ; ok
: y dup swap ; ok
see x
8082ADF 4 # EBP SUB 83ED04
8082AE2 EBX 0 [EBP] MOV 895D00
8082AE5 RET C3 ok
see y
8082AFF 4 # EBP SUB 83ED04
8082B02 EBX 0 [EBP] MOV 895D00
8082B05 0 [EBP] EAX MOV 8B4500
8082B08 EBX 0 [EBP] MOV 895D00
8082B0B EAX EBX MOV 8BD8
8082B0D RET C3 ok
Is SwiftForth not worth its salt?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-03 21:37 -0800 |
| Message-ID | <c9610d5c-7eff-4d8c-bed8-e84ec8346d52@googlegroups.com> |
| In reply to | #53695 |
On Tuesday, January 3, 2017 at 1:02:10 AM UTC-7, Elizabeth D. Rather wrote: > Surely any compiler worth its salt would know that SWAP following DUP is > a no-op and skip it? Is she trying to be funny??? As I said before; SwiftForth just inlines functions --- DUP and SWAP are both ICODE functions, so they get inlined: see dup 405C1F 4 # EBP SUB 83ED04 405C22 EBX 0 [EBP] MOV 895D00 405C25 RET C3 ok see swap 405C3F 0 [EBP] EAX MOV 8B4500 405C42 EBX 0 [EBP] MOV 895D00 405C45 EAX EBX MOV 8BD8 405C47 RET C3 ok : test dup swap ; test isn't unique. ok see test 478F7F 4 # EBP SUB 83ED04 478F82 EBX 0 [EBP] MOV 895D00 \ DUP ends here 478F85 0 [EBP] EAX MOV 8B4500 478F88 EBX 0 [EBP] MOV 895D00 478F8B EAX EBX MOV 8BD8 \ SWAP ends here 478F8D RET C3 ok
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-02 21:55 -0800 |
| Message-ID | <5a62b3a5-1973-4dca-b350-34fce7c145d0@googlegroups.com> |
| In reply to | #53681 |
On Monday, January 2, 2017 at 5:49:56 PM UTC-7, Albert van der Horst wrote: > In article <l9qdnfKSwpKYDPfFnZ2dnUU7-bfNnZ2d@supernews.com>, > Elizabeth D. Rather <erather@forth.com> wrote: > <SNIP> > > > >Sure, one *could* make optimizing compilers at any time, but they would > >be in direct violation of Forth 83 (as well as Forth 79) since both > >mandated 16-bit ITC. > > I wonder. There is a straightforward way to optimise ITC quite a bit. > Inline everything until code words remain, then replace by the code itself, > leaving out the next's, replacing branches whith machine code jumps. > Would anyone be upset? > What would be the argument that the resulting code is not Forth-83, > given that nobody argues that there can't be code words? > Those words could have been written in code to begin with. My Straight Forth initial version uses ITC and it does significant optimization. Maybe later I will delve into STC. The idea that I am dependent upon ANS-Forth to make optimization possible, is absurd --- ANS-Forth is a purely negative contribution to the Forth world. Also, while it is true that Forth-83 mandated ITC, it was easy to write compilers that would compile almost all Forth-83 code and yet used DTC or STC internally --- UR/Forth used DTC and generated code that was significantly faster than PolyForth and F83 etc. that used ITC --- to get portable code, the programmer had to never directly access the cfa pointer, which was theoretically allowed in Forth-83. I agree that Forth-83 was badly designed in regard to exposing the implementation to the user, but I blame Elizabeth Rather for that, and I think that Elizabeth Rather's ANS-Forth is also badly designed. Nothing that has come from Forth Inc. after Charles Moore got kicked out has been any good.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-03 11:26 +0000 |
| Message-ID | <2017Jan3.122636@mips.complang.tuwien.ac.at> |
| In reply to | #53681 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <l9qdnfKSwpKYDPfFnZ2dnUU7-bfNnZ2d@supernews.com>,
>Elizabeth D. Rather <erather@forth.com> wrote:
><SNIP>
>>
>>Sure, one *could* make optimizing compilers at any time, but they would
>>be in direct violation of Forth 83 (as well as Forth 79) since both
>>mandated 16-bit ITC.
I just looked into the Forth-83 standard document, and I see no
trace of that. The first mention of "threaded" is in Appendix C
"Experimental proposals", and it says there:
[The proposed header access words] can
be implemented in a FORTH system which uses any combination of
the following options for its dictionary structure:
Link fields first or second.
Fixed or variable length name fields.
Additional fields in the definitions structure.
Heads contiguous or separated from bodies.
Indirect, direct, subroutine, or token threaded code.
So at least that part does not assume indirect-threaded code.
Earlier, in the section "addressable memory", the document says:
A Standard Program may address:
1. parameter fields of words created with CREATE , VARIABLE ,
and user defined words which execute CREATE ;
[...]
A Standard Program may NOT address:
[...]
3. into a definition's parameter field if not stored by the
application.
This eliminates pretty much any use a Forth-83 program might want to
make of the knowledge about indirect-threaded code, if there was
really such a requirement/guarantee in Forth-83.
>I wonder. There is a straightforward way to optimise ITC quite a bit.
>Inline everything until code words remain, then replace by the code itself,
>leaving out the next's, replacing branches whith machine code jumps.
>Would anyone be upset?
>What would be the argument that the resulting code is not Forth-83,
>given that nobody argues that there can't be code words?
>Those words could have been written in code to begin with.
But they were not. So, if there was a guarantee that ITC is used, one
could do things like writing a decompiler, a call graph analyser, a
stepping debugger, or patch existing compiled words. These things
fail sooner or later when you deviate from ITC, e.g., in the direction
you indicated (which is not that far from what Gforth does with
dynamic native code generation). E.g., the current development
version of Gforth gives the following error when you try to use the
stepping debugger (DBG) on gforth or gforth-fast:
error: Only works on gforth-itc
- 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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-02 10:47 +0000 |
| Message-ID | <o4db1a$gvc$1@dont-email.me> |
| In reply to | #53653 |
On 1/2/2017 03:55, hughaguilar96@gmail.com wrote: > > A "chain" is a data-structure that is ordered by a key which is a string. AKA a wordlist. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-02 20:57 -0800 |
| Message-ID | <a7f59813-a4a8-47c5-877e-d1b8a587bb8d@googlegroups.com> |
| In reply to | #53659 |
On Monday, January 2, 2017 at 3:47:34 AM UTC-7, Alex wrote: > On 1/2/2017 03:55, hughaguilar96@gmail.com wrote: > > > > > A "chain" is a data-structure that is ordered by a key which is a string. > > AKA a wordlist. > > -- > Alex No it isn't. A chain is a general-purpose data-structure which is expected to be used by most application programs for their data --- you snipped the entire description --- a chain could be used internally to hold word-lists, but that is irrelevant. You don't really understand any of these subjects that you comment on.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-30 18:35 -0800 |
| Message-ID | <79395779-b242-4d52-8672-c59b3d0986ed@googlegroups.com> |
| In reply to | #53632 |
On Friday, December 30, 2016 at 5:48:49 PM UTC-7, HAA wrote:
> Removing choice is of course what standards do. Standards are an ever
> narrowing jail that ultimately chokes on itself. 47 years of Forth standards,
> 23 years since ANS, 10 years since 200x and no programs or users to
> speak of. That's what standards in Forth have achieved.
Charles Moore left Forth Inc. in 1982 --- both the Forth-83 and ANS-Forth standards came from Elizabeth Rather --- that is why they were no good and there are now "no programs or users to speak of.
I disagree though, that: "Standards are an ever narrowing jail that ultimately chokes on itself." Having a standard allows programs to be portable --- a standard has nothing to do with making educational classes easier to teach as Elizabeth Rather claims --- the *only* purpose of a standard is to allow programs to be portable between different vendors' compilers.
I am not saying that Straight Forth is the end-all of Forth. For one thing, it doesn't directly run on micro-controllers (it can be used to cross-compile for micro-controllers though) --- it is only for desktop computers --- for another thing, it doesn't compete directly against Factor and Oforth, which will continue to be used. It is not a "jail" --- programmers are free to use non-compliant systems, but they lose portability when they do that. Straight Forth is mostly for numerical programming and cross-compilation, whereas Factor is mostly for web-servers, and I don't know what Oforth is for (it is possible that Franck doesn't know either; he doesn't really have a "killer app" that I'm aware of).
I want Forth to be taken seriously. For this to happen, you have to have code-libraries that are portable between different vendors' compilers, Nobody is going to accept vendor lock-in; there is no vendor in the Forth world that is big enough to rule the way that MicroSoft does. If Forth is going to succeed, there has to be a standard that allows multiple vendors to thrive, with programmers moving back and forth between them.
In her own stupid way, Elizabeth Rather understands that the lack of code-libraries is what killed ANS-Forth:
On Thursday, December 29, 2016 at 6:04:07 PM UTC-7, Elizabeth D. Rather wrote:
> On 12/28/16 3:12 PM, HAA wrote:
> > Nobody writing a substantive
> > application for SwiftForth expects the code to compile and run on VFX.
>
> Not the whole application, certainly, but consider the never-ending
> whine about libraries: the ability to write a bunch of functions (or
> even adapt a useful function from an adapted form used in an
> application) depends on standards.
Notice that she still believes that the only way to write new programs is cut-and-paste-and-tweak of old programs ("adapt a useful function from an adapted form used in an application") --- she still doesn't understand the concept of a general-purpose data-structure --- she continues to fight against code-libraries tooth and nail because she doesn't understand the concept.
[toc] | [prev] | [next] | [standalone]
| From | awegel@arcor.de (Alexander Wegel) |
|---|---|
| Date | 2016-12-31 04:29 +0100 |
| Message-ID | <1mz3tjb.1hhgothl98iwyN%awegel@arcor.de> |
| In reply to | #53634 |
<hughaguilar96@gmail.com> wrote:
> In her own stupid way, Elizabeth Rather understands that the lack of
> code-libraries is what killed ANS-Forth:
>
> On Thursday, December 29, 2016 at 6:04:07 PM UTC-7, Elizabeth D. Rather wrote:
> > On 12/28/16 3:12 PM, HAA wrote:
> > > Nobody writing a substantive
> > > application for SwiftForth expects the code to compile and run on VFX.
> >
> > Not the whole application, certainly, but consider the never-ending
> > whine about libraries: the ability to write a bunch of functions (or
> > even adapt a useful function from an adapted form used in an
> > application) depends on standards.
>
> Notice that she still believes that the only way to write new programs is
> cut-and-paste-and-tweak of old programs ("adapt a useful function from
> an adapted form used in an application") --- she still doesn't understand
> the concept of a general-purpose data-structure --- she continues to
> fight against code-libraries tooth and nail because she doesn't
> understand the concept.
Your problem seems to be that you don't even understand what people
write. In this case (i removed the confusing part from the sentence, so
maybe you have a chance to understand it):
about libraries: the ability to write a bunch of functions depends on
standards.
What you make out of this is just a grotesque misinterpretation.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-31 10:19 +0000 |
| Message-ID | <o480kh$ou9$1@dont-email.me> |
| In reply to | #53632 |
On 12/31/2016 00:49, HAA wrote: > > Removing choice is of course what standards do. Standards are an > ever narrowing jail that ultimately chokes on itself. 47 years of > Forth standards, 23 years since ANS, 10 years since 200x and no > programs or users to speak of. That's what standards in Forth have > achieved. > Since I take that "of course" to mean that your assertion is true and widely accepted, can you demonstrate a specific case where a software standard has removed choice? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-02 17:08 +0000 |
| Message-ID | <2017Jan2.180829@mips.complang.tuwien.ac.at> |
| In reply to | #53632 |
"HAA" <someone@microsoft.com> writes:
>Removing choice is of course what standards do. Standards are an ever
>narrowing jail that ultimately chokes on itself.
First of all, you have the choice of complying with a standard or
not; standards don't remove that choice.
Ok, let's look at the case when you want to comply with a Forth
standard. There is is important to understand that a Forth standard
specifies an interface between a Forth system and a Forth program.
Removing choices of standard-system implementors adds choices for
standard-program writers and vice versa. E.g., at the 2015 meeting
the Forth200x committee decided to standardize 2s-complement
arithmetics and overflow behaviour, allowing Forth programmers to
write stuff like cryptographic functions without contorting
themselves, but of course also removing the standard-system
implementor's choice to use the native signed addition for + on
ones-complement hardware.
>47 years of Forth standards,
>23 years since ANS, 10 years since 200x and no programs or users to
>speak of.
Well, it's sufficient to support two commercial vendors of standard
systems, plus some more of non-standard systems. I don't think that
there are many languages left with that amount of commercial activity;
ok, that has to do with implementations of other languages often
having other business models, but in any case, it shows that the state
of Forth is not as dire as you want to make us believe.
- 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 | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-01-06 13:39 +1100 |
| Message-ID | <o4n002$8v9$1@gioia.aioe.org> |
| In reply to | #53672 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > >Removing choice is of course what standards do. Standards are an ever > >narrowing jail that ultimately chokes on itself. > > First of all, you have the choice of complying with a standard or > not; standards don't remove that choice. Compliance costs, if not money then time. You want to be sure you're getting something concrete for it in return, not a promise or dream. > > Ok, let's look at the case when you want to comply with a Forth > standard. There is is important to understand that a Forth standard > specifies an interface between a Forth system and a Forth program. > Removing choices of standard-system implementors adds choices for > standard-program writers and vice versa. E.g., at the 2015 meeting > the Forth200x committee decided to standardize 2s-complement > arithmetics and overflow behaviour, allowing Forth programmers to > write stuff like cryptographic functions without contorting > themselves, but of course also removing the standard-system > implementor's choice to use the native signed addition for + on > ones-complement hardware. ANS already lets you do those things. The fact that you removed the ANS documentary requirement is evidence forthers do not follow standards even when they have them. Another example of the dispensability of standards in Forth is Forth Inc which despite being on the 200x committee appears to be exercising its option not to implement 200x. > >47 years of Forth standards, > >23 years since ANS, 10 years since 200x and no programs or users to > >speak of. > > Well, it's sufficient to support two commercial vendors of standard > systems, plus some more of non-standard systems. I don't think that > there are many languages left with that amount of commercial activity; > ok, that has to do with implementations of other languages often > having other business models, but in any case, it shows that the state > of Forth is not as dire as you want to make us believe. > > - anton Standard Forth supports those who have sunk their reputation into it and/or wish to use it as a means of getting others to accept their choices or ideas. That's about it apart from the glossary of words that standards contain, but I wouldn't call referencing or using a selection of those as needing or supporting a standard.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-05 19:13 -0800 |
| Message-ID | <eb1f0865-ced6-4918-a871-20a7587653b6@googlegroups.com> |
| In reply to | #53773 |
On Thursday, January 5, 2017 at 7:39:03 PM UTC-7, HAA wrote: > Anton Ertl wrote: > > "HAA" <someone@microsoft.com> writes: > > >Removing choice is of course what standards do. Standards are an ever > > >narrowing jail that ultimately chokes on itself. > > > > First of all, you have the choice of complying with a standard or > > not; standards don't remove that choice. > > Compliance costs, if not money then time. You want to be sure you're > getting something concrete for it in return, not a promise or dream. With ANS-Forth, if your code runs under one ANS-Forth system, it won't run under another ANS-Forth system, then the fans of that system will howl that your code isn't ANS-Forth because it fails to run on an ANS-Forth system. You end up chasing your own tail --- this costs both money and time --- you can never prove that your code is ANS-Forth because somebody will always be able to prove that it isn't by showing an ANS-Forth system that it fails to run on. > > Ok, let's look at the case when you want to comply with a Forth > > standard. There is is important to understand that a Forth standard > > specifies an interface between a Forth system and a Forth program. > > Removing choices of standard-system implementors adds choices for > > standard-program writers and vice versa. E.g., at the 2015 meeting > > the Forth200x committee decided to standardize 2s-complement > > arithmetics and overflow behaviour, allowing Forth programmers to > > write stuff like cryptographic functions without contorting > > themselves, but of course also removing the standard-system > > implementor's choice to use the native signed addition for + on > > ones-complement hardware. > > ANS already lets you do those things. The fact that you removed the ANS > documentary requirement is evidence forthers do not follow standards even > when they have them. Another example of the dispensability of standards > in Forth is Forth Inc which despite being on the 200x committee appears > to be exercising its option not to implement 200x. ANS-Forth was rubber-stamped by ANSI in 1994. It took Forth Inc. until 1997 to write SwiftForth (written by Rick van Norman) which was the first ANS-Forth compiler, but SwiftForth was too bug-ridden to be useful until version-3 which came out years later. Most likely the reason why Forth Inc. isn't "exercising its option" to implement a Forth-200x compiler, is because they don't have any programmers who are capable of writing a compiler. Give them a few years and they will come out with a bug-ridden compiler that is supposedly Forth-200x... > > >47 years of Forth standards, > > >23 years since ANS, 10 years since 200x and no programs or users to > > >speak of. > > > > Well, it's sufficient to support two commercial vendors of standard > > systems, plus some more of non-standard systems. I don't think that > > there are many languages left with that amount of commercial activity; > > ok, that has to do with implementations of other languages often > > having other business models, but in any case, it shows that the state > > of Forth is not as dire as you want to make us believe. > > > > - anton > > Standard Forth supports those who have sunk their reputation into it and/or > wish to use it as a means of getting others to accept their choices or ideas. > That's about it apart from the glossary of words that standards contain, but > I wouldn't call referencing or using a selection of those as needing or supporting > a standard. The purpose of a standard is supposed to be portability of code. ANS-Forth was just a marketing gimmick whose purpose was to allow Forth Inc. to claim that they lead the entire Forth community and everybody depends upon them for guidance, and also to claim that UR/Forth is a non-standard wannabe, despite the fact that it had been the leader of the Forth industry prior to 1994.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-27 23:57 -0800 |
| Message-ID | <e7500f19-47c2-433d-bf16-7d4449938c3e@googlegroups.com> |
| In reply to | #53558 |
On Tuesday, December 27, 2016 at 6:27:58 AM UTC-7, Alexander Wegel wrote: > In the end, the problem isn't just the crappiness of the software, but > mostly that of its author. > > A tip: Whenever you think bad about someone, because he doesn't > "brown-nose" you or because what he writes doesn't seem to make sense to > you immediately, the first thing you need to check is your head! I don't think bad about people because they don't brown-nose me. I would never allow anybody to brown-nose me, and I would also never allow a homosexual to touch me --- for the same reason --- because it is profoundly disgusting and would make me feel dirty. I think bad about people who brown-nose, because they are disgusting ---Elizabeth Rather demands that all ANS-Forth programmers brown-nose her --- that is meta-disgusting! > Now go fix your crappage, i'm (not) waiting for more than half a decade > now (remember "alien alphabet"? your packages inflexibility kept you > from solving it - LOL). This is a reference to this thread: https://groups.google.com/forum/#!searchin/comp.lang.forth/Codejam%7Csort:relevance/comp.lang.forth/3Y4w_MdYl0k/kV-Cy3lwxMMJ I used my SEQ lists in my first solution. This worked for some of the versions of the problem, but didn't work for others because the SEQ strings are limited to 255 chars (I posted the code without testing it on all versions of the problem, so I didn't realize that some of the latter versions had strings over 255 chars). I then implemented SSEQ lists in LIST.4TH that allowed unlimited sized strings, and rewrote my program to use SSEQ rather than SEQ --- that worked for all versions of the problem. You said that my package's inflexibility kept me from solving the problem --- that is not true --- you are a very dishonest person! The two kinds of data that ANS-Forth is weak at, are numbers and strings. I've already discussed some of ANS-Forth's problems with numbers in this thread: https://groups.google.com/forum/#!topic/comp.lang.forth/uGAKvs8baQk%5B126-150%5D Strings are also poorly supported. For one thing, we have two representations of strings: 1.) a pointer to a counted string as provided by C" 2.) an address and count pair as provided by S" This is redundant. It is easy to convert #1 into #2 with COUNT but complicated and inefficient to convert #2 into #1. Which are we supposed to use? Some words such as WORD return #1 and some words such as PARSE return #2. Which are we supposed to use? Some words such as FIND take #1 and some words such as EVALUATE take #2. So confusing! So complicated! I don't blame ANS-Forth students for not being able to learn this stuff (I still have to look everything up in the ANS-Forth document to remember which is which). In the novice package, I mostly went with #1 (because most strings in most programs are <= 255 chars in length), but I sometimes went with #2. My SEQ used #1 which is what Alex Wegel is criticizing. As a practical matter, #2 is a big pain in the butt because having two items on the data-stack introduces a lot of stack-juggling. If you are working with two strings, you have 4 items on the data-stack, but it is well-known that 3 is the most you want lest that your stack-juggling makes your code unreadable. My STRING-STACK.4TH largely fixes the problem. The strings are #2 internally, so they can be any size (not limited to 255 chars). None of the strings are on the data-stack though, so there is no stack-juggling --- the strings are on the string-stack! --- how obvious is this solution? This solution is very obvious! Of course, implementing STRING-STACK.4TH took me something like 2 or 3 weeks --- just because a solution is obvious doesn't mean that it is trivial to implement --- this is some of my best Forth programming! Anyway, I don't think it is fair to criticize me because my SEQ used #1 and this was limited to 255 char strings --- I didn't invent ANS-Forth with its complicated and feature-bereft string support --- why not criticize the person who is guilty of pinching this loaf? This was Alex Wegel's solution to the "alien alphabet" CodeJAM problem: On Tuesday, May 1, 2012 at 5:29:10 PM UTC-7, Alex Wegel wrote: > <..x.nl> wrote: > > > awe..cor.de (Alex Wegel) writes Re: Google CodeJam? > > > > > As i said, it's another ugly solution - my "philosophy" was to leave > > > everything out that wasn't really needed for the question. (This way, > > > there's also less space for bugs to hide.) > > > > > I didn't put comments into the code (quel surprise!), but the basic > > > concept is: The alien digits are already ordered (1,0,2,3,4,5,...), so > > > it's easy to build a table for translating them. After the table has > > > been built, the alien number-base is known, and i can feed the > > > transliterated alien numeral to forth to get the numerical value. > > > > So why not add the above small explanation and some stack comments > > to your code? I almost suspect that you deliberately deleted them :-) > > Actually i think i had 2 of them at some point in time, but that was > about it, and then they went stale. They not so interesting anyway :-) > See: > > #! /usr/local/bin/gforth-fast > 0 value hi \ highest digit-value found so far > create d 36 allot \ digit string containing all alien digits > : wipe ( ) d 36 erase 0 to hi ; \ housekeeping > : +dig ( c) d hi + c! 1 hi + to hi ; \ add newly learned digit to d > : >dig? ( c -- +n true|c false) \ lookup alien digit > hi begin dup while > 1 - 2dup d + c@ = if nip true exit then > repeat drop false ; > : twiddle ( ca) dup >r c@ r@ char+ c@ r@ c! r> char+ c! ; \ exch 2 bytes > : pars ( ca u) \ read alien numeral to determine digits & number base > bounds do > i c@ >dig? if drop else +dig then > loop d twiddle hi 2 max to hi ; > : dig> (+n--c) dup 9 > if 7 + then [char] 0 + ; \ convert 1 dig to text > : eval ( ca u) \ evaluate alien number string > 2dup pars 2dup bounds do i c@ >dig? drop dig> i c! loop > hi base ! s>unumber? drop decimal ; > : getl pad dup 64 stdin read-line throw drop ; > : .. ." Case #" 1 .r ." : " 1 ud.r cr ; > : app getl evaluate 0 do getl eval i 1+ .. wipe loop ; > ' noop is bootmessage > app bye > > Main thing to remember when reading the source is that in bottom up > programming, the top is down. Note that I didn't modify this code to make it obfuscated (the way that he modified my EXCHANGE function to make it obfuscated). I showed this code exactly as he wrote it. I said this: On Tuesday, May 1, 2012 at 8:45:08 PM UTC-7, Hugh Aguilar wrote: > Your "plain Forth" would more accurately be called "obfuscated Forth" > --- I've never written that in my life --- and I never will. > > I don't think that I could write a Forth program without stack-picture > comments, as I would confuse myself. I think that you used stack- > picture comments just like everybody else when you wrote your program, > but then removed them afterward to obfuscate your code. > > We've been quoting poetry in this thread --- here is what another > German said on the subject: > "Nor are poets clean enough for me --- they muddy the water to make it > appear deep."
[toc] | [prev] | [next] | [standalone]
Page 12 of 14 — ← Prev page 1 … 10 11 [12] 13 14 Next page →
Back to top | Article view | comp.lang.forth
csiph-web