Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.prolog > #12554 > unrolled thread
| Started by | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| First post | 2022-01-28 07:41 -0800 |
| Last post | 2025-08-01 03:01 +0200 |
| Articles | 20 on this page of 200 — 6 participants |
Back to article view | Back to comp.lang.prolog
50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 07:41 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 07:47 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 07:49 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 07:59 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:07 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:10 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:15 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:33 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:35 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-28 08:52 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-02 03:46 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-04 03:18 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 06:04 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-02-08 15:06 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 13:23 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 13:35 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 13:42 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 13:48 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 16:17 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-02-08 16:34 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-04 01:01 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-04 01:03 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-04 13:10 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-05 15:32 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-16 17:30 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-17 05:10 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-17 13:39 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-17 13:53 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-23 13:57 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-24 05:32 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-24 11:47 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-24 14:49 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-04-29 13:27 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-04-29 13:37 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-30 08:38 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-04-30 08:45 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-04 11:35 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 00:21 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 00:52 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 00:58 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 01:23 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 03:04 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 03:08 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 03:19 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 03:56 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-05-05 04:07 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-01-29 15:56 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-01-29 16:05 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-01-29 16:56 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-31 10:37 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-01-31 10:45 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-02 12:03 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-03 02:44 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-03 02:49 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-03 03:11 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-10 05:54 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-25 02:39 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-06-25 02:41 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 00:45 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 01:03 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 01:28 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 01:28 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 01:40 -0700
Re: 50 Years of Prolog Nonsense Markus Triska <triska@logic.at> - 2022-07-12 19:25 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 14:50 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 15:01 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 15:16 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 16:02 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 16:22 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-12 16:32 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-07-13 07:08 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-04 17:58 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-04 18:01 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 01:16 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 01:19 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 04:07 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 04:25 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 07:56 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 07:56 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-05 08:14 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-06 12:45 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-06 12:47 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-07 05:24 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-07 05:26 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-07 05:32 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-07 06:50 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-08 15:07 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-08 15:16 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-09 03:23 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-09 12:27 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-09 12:33 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 04:13 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 04:41 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 05:19 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 07:20 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 07:30 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-13 07:46 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-18 07:16 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-18 07:17 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-18 15:13 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-08-28 15:04 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-21 10:42 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-22 06:13 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-22 06:23 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-22 06:41 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-23 07:44 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-25 07:10 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-25 07:11 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-25 08:55 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-25 08:56 -0700
Re: 50 Years of Prolog Nonsense Markus Triska <triska@logic.at> - 2023-08-31 21:32 +0200
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-09-01 12:02 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <janburse@fastmail.fm> - 2024-04-09 00:15 +0200
Re: 50 Years of Prolog Nonsense Mild Shock <janburse@fastmail.fm> - 2024-04-09 00:20 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2023-05-20 14:09 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-20 05:46 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-20 05:48 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-20 06:16 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-05-27 04:51 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-01 14:10 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-01 14:11 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-01 14:17 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-03 05:20 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-03 09:10 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-06-02 00:44 -0700
PIPs from the Basilisk Chamber (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-09-29 17:22 +0200
Prolog Pearls I: Barklund and Millroth (Was: PIPs from the Basilisk Chamber) Mild Shock <janburse@fastmail.fm> - 2024-11-08 15:07 +0100
Prolog Pearls II: Barklund and Millroth (Was: PIPs from the Basilisk Chamber) Mild Shock <janburse@fastmail.fm> - 2024-11-08 15:29 +0100
change_arg/3 = nb_linkarg/3 ? (Was: PIPs from the Basilisk Chamber) Mild Shock <janburse@fastmail.fm> - 2024-11-08 18:37 +0100
Re: change_arg/3 = nb_linkarg/3 ? (Was: PIPs from the Basilisk Chamber) Mild Shock <janburse@fastmail.fm> - 2024-11-08 18:39 +0100
Re: PIPs from the Basilisk Chamber (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-09 15:47 +0100
Re: PIPs from the Basilisk Chamber (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-09 15:48 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-09-25 21:19 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-09-25 21:21 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-27 10:11 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2022-09-27 19:13 +0200
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 03:33 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 03:34 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 03:37 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 03:56 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 05:01 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-09-28 06:44 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-18 16:21 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-18 16:22 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-25 16:00 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-30 21:53 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-30 22:03 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2022-12-30 22:29 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-02 10:51 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-03 21:17 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-03 21:36 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-03 21:50 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-07 07:35 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-14 07:53 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-22 08:54 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-22 10:02 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-22 15:37 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-29 07:19 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-29 07:20 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-29 07:32 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-29 07:55 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-01-30 07:06 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-02-06 00:49 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-02-06 00:53 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-02-20 06:23 -0800
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-02-20 06:31 -0800
How working with GitHub feels (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-03-13 14:45 +0100
Re: How working with GitHub feels (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-03-13 15:05 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-12 09:12 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-12 09:14 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-14 17:57 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2023-03-15 02:01 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <janburse@fastmail.fm> - 2023-03-15 02:09 +0100
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-28 06:07 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-28 06:30 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-28 10:04 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-03-28 10:05 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-04-02 15:10 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-25 08:48 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-25 08:53 -0700
Re: 50 Years of Prolog Nonsense Mostowski Collapse <bursejan@gmail.com> - 2023-05-25 09:02 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-07-29 04:57 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-07-29 05:10 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <janburse@fastmail.fm> - 2023-07-29 23:16 +0200
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-07-30 05:06 -0700
Re: 50 Years of Prolog Nonsense Mild Shock <bursejan@gmail.com> - 2023-08-01 01:09 -0700
How I got rid of term_variables/3 (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-10 12:37 +0100
Re: How I got rid of term_variables/3 (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-10 12:40 +0100
Re: How I got rid of term_variables/3 (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-10 12:42 +0100
How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-12 16:30 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-12 16:32 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-14 05:14 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-14 05:24 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Julio Di Egidio <julio@diegidio.name> - 2024-11-14 21:21 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-14 21:58 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Mild Shock <janburse@fastmail.fm> - 2024-11-14 22:10 +0100
Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) Julio Di Egidio <julio@diegidio.name> - 2024-11-15 15:42 +0100
Mode yfy to the rescue (Was: How Prolog became an education nightmare) Mild Shock <janburse@fastmail.fm> - 2024-11-14 22:30 +0100
Cyclic term predicates suffer from ambiguity (Was: How Prolog became an education nightmare) Mild Shock <janburse@fastmail.fm> - 2025-08-01 02:47 +0200
An ISO term_variables/2 for Cyclic Terms (Was: Cyclic term predicates suffer from ambiguity) Mild Shock <janburse@fastmail.fm> - 2025-08-01 03:01 +0200
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
| From | Mostowski Collapse <bursejan@gmail.com> |
|---|---|
| Date | 2023-05-25 09:02 -0700 |
| Message-ID | <d6346759-5a50-41ef-ad56-b0b3fcd5c1d2n@googlegroups.com> |
| In reply to | #13647 |
Oopsie, this guy possibly doesn't qualify anymore: 18. Sam Bankman-Fried Net worth: Estimated at less than $10 million (down from $24 billion) https://www.forbes.com/sites/johnhyatt/2023/04/07/bitcoin-crypto-billionaires-lost-110-billion-in-past-year Mostowski Collapse schrieb am Donnerstag, 25. Mai 2023 um 17:53:21 UTC+2: > I am 100% serious. Just knock on the door of a few > crypto billionaires. They take it from the confiture jar. > > LoL > Mostowski Collapse schrieb am Donnerstag, 25. Mai 2023 um 17:48:56 UTC+2: > > If they would increase the price money from: > > > > The winner receives a certificate and cash support of up to 2,000 Euros > > https://logicprogramming.org/the-alp-alain-colmerauer-prize/ > > > > to like for example 500’000 € this could help the recipients enterprise or pension. > > Maybe they can fork the price into a “lifetime archivement award”, besides > > some “recent practical accomplishments”.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <bursejan@gmail.com> |
|---|---|
| Date | 2023-07-29 04:57 -0700 |
| Message-ID | <e5616850-37a8-46fd-b2a8-e3ca252b8a5an@googlegroups.com> |
| In reply to | #12554 |
Can SWI-Prolog lean back concerning multi-threading? The Python store looks like a nice piece of darwinism. So there is some evolutionary pressure through some selection mechanism: > Allen Goodman, author of CellProfiler and staff engineer at Prescient Design and Genentech, describes how the GIL makes biological methods research more difficult in Python. So basically Python starts lacking behind as the datascience language. Oh the irony. But I would not blame it so much on the GIL. Deep down many programming languages have still a GIL, for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded because they started optimizing their virtual machine for multi-threaded. Such optiminzations do not only consists of removing the GIL, you need optimize malloc(). Some approaches uses thread affine memory areas, but this is also tricky, since not all objects have a clear thread affinity.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <bursejan@gmail.com> |
|---|---|
| Date | 2023-07-29 05:10 -0700 |
| Message-ID | <8f3f24d1-7258-4572-9b81-596f2139546bn@googlegroups.com> |
| In reply to | #13685 |
In as far, concerning thread affinity, one has to also watch what happens concerning JavaScript Worker concept adoptions in Python. Multi-threading can be optimized even more If you have such isolation concepts. In this respect there is also PEP 683 – Immortal Objects, which on the surface might not be related, but it also relates to the effort to better handle strings and make a GIL per-interpreter, the later could underly Workers. Mild Shock schrieb am Samstag, 29. Juli 2023 um 13:57:15 UTC+2: > Can SWI-Prolog lean back concerning multi-threading? The > Python store looks like a nice piece of darwinism. So there is some > evolutionary pressure through some selection mechanism: > > > Allen Goodman, author of CellProfiler and staff engineer at > Prescient Design and Genentech, describes how the GIL makes > biological methods research more difficult in Python. > > So basically Python starts lacking behind as the datascience language. > Oh the irony. But I would not blame it so much on the GIL. Deep down many > programming languages have still a GIL, > > for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration > even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded > because they started optimizing their virtual machine for multi-threaded. > > Such optiminzations do not only consists of removing the GIL, you > need optimize malloc(). Some approaches uses thread affine memory > areas, but this is also tricky, since not all objects have a clear thread affinity.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2023-07-29 23:16 +0200 |
| Message-ID | <ua3vjm$g8th$1@solani.org> |
| In reply to | #13686 |
There are a couple of non-GIL Pythons already around. For example Jython 2.7.3. But they are currently busy with migrating from Python 2 to Python 3. For example I cannot use it, it didn’t understand the “async” keyword. Async/await was introduced in Python version 3.5. There are more such no-GIL Pythons, like IronPython (for CLR) and GraalVM Python (for JVM). GraalVM Python is farther ahead, it supports Python 3.8, but is slower than PyPy. But with IronPython, one would also have less luck, its only Python 3.4 now. Mild Shock schrieb: > In as far, concerning thread affinity, one has to also watch what happens > concerning JavaScript Worker concept adoptions in Python. Multi-threading > can be optimized even more If you have such isolation concepts. > > In this respect there is also PEP 683 – Immortal Objects, which on the > surface might not be related, but it also relates to the effort to better handle > strings and make a GIL per-interpreter, the later could underly Workers. > > Mild Shock schrieb am Samstag, 29. Juli 2023 um 13:57:15 UTC+2: >> Can SWI-Prolog lean back concerning multi-threading? The >> Python store looks like a nice piece of darwinism. So there is some >> evolutionary pressure through some selection mechanism: >> >>> Allen Goodman, author of CellProfiler and staff engineer at >> Prescient Design and Genentech, describes how the GIL makes >> biological methods research more difficult in Python. >> >> So basically Python starts lacking behind as the datascience language. >> Oh the irony. But I would not blame it so much on the GIL. Deep down many >> programming languages have still a GIL, >> >> for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration >> even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded >> because they started optimizing their virtual machine for multi-threaded. >> >> Such optiminzations do not only consists of removing the GIL, you >> need optimize malloc(). Some approaches uses thread affine memory >> areas, but this is also tricky, since not all objects have a clear thread affinity.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <bursejan@gmail.com> |
|---|---|
| Date | 2023-07-30 05:06 -0700 |
| Message-ID | <5cc272c3-80cf-4a20-9ae2-ac80aa91c65dn@googlegroups.com> |
| In reply to | #13687 |
Whats quite interesting, is that PyPy, one of the fastest Pythons, isn’t based on ARC LLVM. i.e. Automatic Reference Counting (ARC). One effect is that dead objects, might be detected a little later than via reference counting, so it is recommended to explicitly close resources such as files, and not rely on reference counting. Having no reference counting, does also help multi-threading. So in PyPy there is no PL_register_atom or PL_unregister_atom. Memory systems without reference counting are usually associated with tracing garbage collectors, based on two color mark sweep. But I guess they get more bang out of it, if incremental garbage collection is deployed and if some escape analysis of the code is performed as well. Have to find a paper. Mild Shock schrieb am Samstag, 29. Juli 2023 um 23:16:41 UTC+2: > There are a couple of non-GIL Pythons already > around. For example Jython 2.7.3. But they are > currently busy with migrating from Python 2 to Python 3. > > For example I cannot use it, it didn’t understand > the “async” keyword. Async/await was introduced in > Python version 3.5. There are more such no-GIL Pythons, > > like IronPython (for CLR) and GraalVM Python (for JVM). > GraalVM Python is farther ahead, it supports Python 3.8, > but is slower than PyPy. But with IronPython, one would > > also have less luck, its only Python 3.4 now. > > Mild Shock schrieb: > > In as far, concerning thread affinity, one has to also watch what happens > > concerning JavaScript Worker concept adoptions in Python. Multi-threading > > can be optimized even more If you have such isolation concepts. > > > > In this respect there is also PEP 683 – Immortal Objects, which on the > > surface might not be related, but it also relates to the effort to better handle > > strings and make a GIL per-interpreter, the later could underly Workers. > > > > Mild Shock schrieb am Samstag, 29. Juli 2023 um 13:57:15 UTC+2: > >> Can SWI-Prolog lean back concerning multi-threading? The > >> Python store looks like a nice piece of darwinism. So there is some > >> evolutionary pressure through some selection mechanism: > >> > >>> Allen Goodman, author of CellProfiler and staff engineer at > >> Prescient Design and Genentech, describes how the GIL makes > >> biological methods research more difficult in Python. > >> > >> So basically Python starts lacking behind as the datascience language. > >> Oh the irony. But I would not blame it so much on the GIL. Deep down many > >> programming languages have still a GIL, > >> > >> for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration > >> even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded > >> because they started optimizing their virtual machine for multi-threaded. > >> > >> Such optiminzations do not only consists of removing the GIL, you > >> need optimize malloc(). Some approaches uses thread affine memory > >> areas, but this is also tricky, since not all objects have a clear thread affinity.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <bursejan@gmail.com> |
|---|---|
| Date | 2023-08-01 01:09 -0700 |
| Message-ID | <fb1ad6c6-5e41-4c21-94ac-994698a0200en@googlegroups.com> |
| In reply to | #13689 |
Why will this never fly?
https://www.swi-prolog.org/howto/http/
Because its too static. For example the
recent SVG example:
reply_html_page(title('SVG circle'),
Etc...
Looks a little pointless to me. Since its static,
You could store an `.svg` file on the server.
How do you draw 12 circles into SVG?
Computed into a grid of 3 x 4 via Prolog?
Make the number of columns and rows
a parameter to a Prolog predicate.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-10 12:37 +0100 |
| Subject | How I got rid of term_variables/3 (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vgq5ta$oq1o$1@solani.org> |
| In reply to | #13685 |
It all began with the bagof/3 choker:
test :-
bagof(X, N^(between(1,300,X), between(1,300,N),
length(_,N)), _), fail; true.
Which makes Prolog system tumble:
/* SWI-Prolog 9.3.14 */
?- time(test).
Action (h for help) ? abort
% 468,739 inferences, 52.016 CPU in 53.069 seconds (98% CPU, 9012 Lips)
Execution Aborted
/* Scryer Prolog 0.9.4-201 */
?- time(test).
^C % CPU time: 110.153s, 145_508_466 inferences
error('$interrupt_thrown',repl/0).
Its mostlikely the same old problem that was
observed years ago, in that the canonicalization
of variables before the keysort/2 creates long
instantiation chains. It can be solved by adjusting
the unification order. Here is a take in Dogelog Player:
/* Dogelog Player 1.2.5 */
?- time(test).
% Zeit 7405 ms, GC 21 ms, Lips 3962971, Uhr 10.11.2024 00:57
true.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-10 12:40 +0100 |
| Subject | Re: How I got rid of term_variables/3 (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vgq638$oq4a$1@solani.org> |
| In reply to | #14274 |
But we can also do without term_variables/3 or
term_variable/2. don’ have tries in my system.
But I recently introduced Okasaki tree, but it
turned out that they are totally useless. What
works better in my case was hash+keysort, as
strange as it may sound.
I believe it depends on the grouping factor.
If there is a high grouping factor there is
higher precentage of read from the grouping
datastructure and than write into the
grouping datastructure. So if read is only O(1)
as in hash, you have better preformance than if
read is O(log N) as in tree. And you can also
afford a later keysort. Here is the bagof/3 choker
with hash+keysort compared to tree:
/* Dogelog Player 1.2.5, tree */
?- time(test3).
% Zeit 6073 ms, GC 1 ms, Lips 5182931, Uhr 10.11.2024 00:58
true.
/* Dogelog Player 1.2.5, hash+keysort */
?- time(test4).
% Zeit 3070 ms, GC 2 ms, Lips 9808736, Uhr 10.11.2024 00:58
true.
Quite amazing, if we compare to the traditional bagof/3:
/* Trealla Prolog 2.59.17, keysort */
?- time(test).
% Time elapsed 13.280s, 16158649 Inferences, 1.217 MLips
true.
Mild Shock schrieb:
> It all began with the bagof/3 choker:
>
> test :-
> bagof(X, N^(between(1,300,X), between(1,300,N),
> length(_,N)), _), fail; true.
>
> Which makes Prolog system tumble:
>
> /* SWI-Prolog 9.3.14 */
> ?- time(test).
> Action (h for help) ? abort
> % 468,739 inferences, 52.016 CPU in 53.069 seconds (98% CPU, 9012 Lips)
> Execution Aborted
>
> /* Scryer Prolog 0.9.4-201 */
> ?- time(test).
> ^C % CPU time: 110.153s, 145_508_466 inferences
> error('$interrupt_thrown',repl/0).
>
> Its mostlikely the same old problem that was
> observed years ago, in that the canonicalization
> of variables before the keysort/2 creates long
>
> instantiation chains. It can be solved by adjusting
> the unification order. Here is a take in Dogelog Player:
>
> /* Dogelog Player 1.2.5 */
> ?- time(test).
> % Zeit 7405 ms, GC 21 ms, Lips 3962971, Uhr 10.11.2024 00:57
> true.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-10 12:42 +0100 |
| Subject | Re: How I got rid of term_variables/3 (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vgq66b$oq4a$2@solani.org> |
| In reply to | #14275 |
How did I solve the variant key problem,
which is present in the bagof/3 choker? I
went with numbervars/3 and unnumbervars/3.
But most likely if tries are used for tabling,
they can already do the same. I was looking
a little bit at the trie_insert() C implementation
used in SWI-Prolog distinct/1. It seems distinct/1
can solve the variant key problem by means of
trie_insert/2 alone, since for ordinary
terms it uses a no-op:
trieable(Term, ForTrie) :-
acyclic_term(Term),
term_attvars(Term, []),
!,
ForTrie = t(Term).
Not sure what is needed to enumerate variant key,
turn them back into ordinary terms together
with the associated values. I am also using the
nb_linkarg/3 trick for findall/3 inside bagof/3.
So the values are basically these single linked
lists. The same approach for bagof/3, is also
suitable for aggregate/3.
Mild Shock schrieb:
> But we can also do without term_variables/3 or
> term_variable/2. don’ have tries in my system.
> But I recently introduced Okasaki tree, but it
>
> turned out that they are totally useless. What
> works better in my case was hash+keysort, as
> strange as it may sound.
>
> I believe it depends on the grouping factor.
> If there is a high grouping factor there is
> higher precentage of read from the grouping
>
> datastructure and than write into the
> grouping datastructure. So if read is only O(1)
> as in hash, you have better preformance than if
>
> read is O(log N) as in tree. And you can also
> afford a later keysort. Here is the bagof/3 choker
> with hash+keysort compared to tree:
>
> /* Dogelog Player 1.2.5, tree */
> ?- time(test3).
> % Zeit 6073 ms, GC 1 ms, Lips 5182931, Uhr 10.11.2024 00:58
> true.
>
> /* Dogelog Player 1.2.5, hash+keysort */
> ?- time(test4).
> % Zeit 3070 ms, GC 2 ms, Lips 9808736, Uhr 10.11.2024 00:58
> true.
>
> Quite amazing, if we compare to the traditional bagof/3:
>
> /* Trealla Prolog 2.59.17, keysort */
> ?- time(test).
> % Time elapsed 13.280s, 16158649 Inferences, 1.217 MLips
> true.
>
> Mild Shock schrieb:
>> It all began with the bagof/3 choker:
>>
>> test :-
>> bagof(X, N^(between(1,300,X), between(1,300,N),
>> length(_,N)), _), fail; true.
>>
>> Which makes Prolog system tumble:
>>
>> /* SWI-Prolog 9.3.14 */
>> ?- time(test).
>> Action (h for help) ? abort
>> % 468,739 inferences, 52.016 CPU in 53.069 seconds (98% CPU, 9012 Lips)
>> Execution Aborted
>>
>> /* Scryer Prolog 0.9.4-201 */
>> ?- time(test).
>> ^C % CPU time: 110.153s, 145_508_466 inferences
>> error('$interrupt_thrown',repl/0).
>>
>> Its mostlikely the same old problem that was
>> observed years ago, in that the canonicalization
>> of variables before the keysort/2 creates long
>>
>> instantiation chains. It can be solved by adjusting
>> the unification order. Here is a take in Dogelog Player:
>>
>> /* Dogelog Player 1.2.5 */
>> ?- time(test).
>> % Zeit 7405 ms, GC 21 ms, Lips 3962971, Uhr 10.11.2024 00:57
>> true.
>>
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-12 16:30 +0100 |
| Subject | How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vgvsb7$3e31$1@solani.org> |
| In reply to | #13685 |
Concerning the input (xxx yyy zzz) the OP wrote: I would expect it to print zzz(xxx(yyy)). Where did he get this requirement from, he didn’t compare other Prolog systems, right? So it came from his applicationdomain. But what was his application domain? Ok, lets proceed to an example with multiple brakets. Lets make the Pascal “begin” “end” example, by replacing xxx and zzz by “begin” and “end”. I get this result: ?- member(X,[begin,end]), current_op(Y,Z,X). X = (begin), Y = 1100, Z = fy ; X = (end), Y = 1100, Z = yf. ?- X = (begin | x = 1; | y = 2; | begin | z = 3 | end | end). X = (begin x=1;y=2;begin z=3 end end). But is the abstract parse term, the Prolog result useful?
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-12 16:32 +0100 |
| Subject | Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vgvseq$3e31$2@solani.org> |
| In reply to | #14281 |
Here is the SWI-Prolog and the SICStus
Prolog abstract parse term. This is the real
nightmare of every computer science professor,
who wants to use Prolog in a compiler
construction course:
/* SWI-Prolog 9.3.14 */
end(end(begin(;(=(x,1),;(=(y,2),begin(=(z,3)))))))
/* SICStus Prolog 4.9.0 */
begin(;(=(x,1),;(=(y,2),begin(end(end(=(z,3)))))))
On the other hand mostlikely the OP @horsh
would expect:
/* What the End-User wants */
end(begin(;(=(x,1),;(=(y,2),end(begin(=(z,3)))))))
I think its impossible to do in any Prolog system,
you would need a programming language with the
possibility to do mixfix syntax definitions,
like for example in Isabelle/HOL:
(* Define the mixfix syntax for a Pascal-like block *)
syntax
"_begin_end" :: "'a ⇒ 'a" ("begin _ end")
Or otherwise use DCG to write your own parser
for the DSL at hand, that you want to parse.
Since Prolog operators cannot model mixfix syntax,
at least SWI-Prolog and SICStus Prolog fail,
and I guess other Prolog systems fail as well.
Mild Shock schrieb:
> Concerning the input (xxx yyy zzz) the OP wrote:
>
> I would expect it to print zzz(xxx(yyy)).
>
> Where did he get this requirement from, he didn’t
> compare other Prolog systems, right? So it came from
> his applicationdomain. But what was his application
>
> domain? Ok, lets proceed to an example with multiple
> brakets. Lets make the Pascal “begin” “end” example,
> by replacing xxx and zzz by “begin” and “end”.
>
> I get this result:
>
> ?- member(X,[begin,end]), current_op(Y,Z,X).
> X = (begin), Y = 1100, Z = fy ;
> X = (end), Y = 1100, Z = yf.
>
> ?- X = (begin
> | x = 1;
> | y = 2;
> | begin
> | z = 3
> | end
> | end).
> X = (begin x=1;y=2;begin z=3 end end).
>
> But is the abstract parse term, the Prolog result useful?
>
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-14 05:14 +0100 |
| Subject | Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vh3tel$57pk$1@solani.org> |
| In reply to | #14282 |
Lets cut through the thicket. There is no
real world use case of a (fy 1 yf). Take again
the Pascal “begin” “end” mixfix example.
Typically we want to then go on and write
for example a compiler:
:- op(1100,fy,begin).
:- op(1100,yf,end).
compile((begin X end)) --> compile(X). %%% scoping omitted
compile((X;Y)) --> compile(X), compile(Y).
compile((V=E)) --> [load(E),store(V)].
The problem is the pattern (begin X end) will
not work, if multiple (begin … end) are involved
in the compile/1 call. You can try yourself, no
Prolog system can do it:
/* SWI-Prolog */
?- X = (begin
x = 1;
begin
y = 2
end
end), compile(X, L, []).
false.
%%% expected L = [load(1),store(x),load(2),store(y)]
/* SICStus Prolog */
?- X = (begin
x = 1;
begin
y = 2
end
end), compile(X, L, []).
no.
%%% expected L = [load(1),store(x),load(2),store(y)]
The reason is that the parser will join multiple yf,
similarly it would join multiple fy. The parser will
not follow a braket pattern. At least I don’t know
any Prolog system that can do it.
Mild Shock schrieb:
> Here is the SWI-Prolog and the SICStus
> Prolog abstract parse term. This is the real
> nightmare of every computer science professor,
>
> who wants to use Prolog in a compiler
> construction course:
>
> /* SWI-Prolog 9.3.14 */
> end(end(begin(;(=(x,1),;(=(y,2),begin(=(z,3)))))))
>
> /* SICStus Prolog 4.9.0 */
> begin(;(=(x,1),;(=(y,2),begin(end(end(=(z,3)))))))
>
> On the other hand mostlikely the OP @horsh
> would expect:
>
> /* What the End-User wants */
> end(begin(;(=(x,1),;(=(y,2),end(begin(=(z,3)))))))
>
> I think its impossible to do in any Prolog system,
> you would need a programming language with the
> possibility to do mixfix syntax definitions,
>
> like for example in Isabelle/HOL:
>
> (* Define the mixfix syntax for a Pascal-like block *)
> syntax
> "_begin_end" :: "'a ⇒ 'a" ("begin _ end")
>
> Or otherwise use DCG to write your own parser
> for the DSL at hand, that you want to parse.
> Since Prolog operators cannot model mixfix syntax,
>
> at least SWI-Prolog and SICStus Prolog fail,
> and I guess other Prolog systems fail as well.
>
> Mild Shock schrieb:
>> Concerning the input (xxx yyy zzz) the OP wrote:
>>
>> I would expect it to print zzz(xxx(yyy)).
>>
>> Where did he get this requirement from, he didn’t
>> compare other Prolog systems, right? So it came from
>> his applicationdomain. But what was his application
>>
>> domain? Ok, lets proceed to an example with multiple
>> brakets. Lets make the Pascal “begin” “end” example,
>> by replacing xxx and zzz by “begin” and “end”.
>>
>> I get this result:
>>
>> ?- member(X,[begin,end]), current_op(Y,Z,X).
>> X = (begin), Y = 1100, Z = fy ;
>> X = (end), Y = 1100, Z = yf.
>>
>> ?- X = (begin
>> | x = 1;
>> | y = 2;
>> | begin
>> | z = 3
>> | end
>> | end).
>> X = (begin x=1;y=2;begin z=3 end end).
>>
>> But is the abstract parse term, the Prolog result useful?
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-14 05:24 +0100 |
| Subject | Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vh3u2h$5822$1@solani.org> |
| In reply to | #14283 |
So how will the computer science Professor help
himself, and nevertheless show some compiler
construction.
If he lowers the expectation, he will use the curly
braces, namely { .. }. This and the singleton list
are practically the only braket syntaxes available
in standard Prolog, that leave a term footprint. The
normal parenthesis don’t leave any abstract parse tree.
So this brave computer science Professor could go on:
ompile({X}) --> compile(X). %%% scoping omitted
compile((X;Y)) --> compile(X), compile(Y).
compile((V=E)) --> [load(E),store(V)].
And he would then succeed in demonstrating a toy compiler:
?- X = {
x = 1;
{
y = 2
}
}, compile(X, L, []).
L = [load(1), store(x), load(2), store(y)].
But this is very poor. It doesn’t allow for DSLs that
use different braketing syntax. And the computer science
professor will switch to Isabelle/HOL, since switching
to Prolog DCG is too painful?
Mild Shock schrieb:
>
> Lets cut through the thicket. There is no
> real world use case of a (fy 1 yf). Take again
> the Pascal “begin” “end” mixfix example.
> Typically we want to then go on and write
>
> for example a compiler:
>
> :- op(1100,fy,begin).
> :- op(1100,yf,end).
>
> compile((begin X end)) --> compile(X). %%% scoping omitted
> compile((X;Y)) --> compile(X), compile(Y).
> compile((V=E)) --> [load(E),store(V)].
>
> The problem is the pattern (begin X end) will
> not work, if multiple (begin … end) are involved
> in the compile/1 call. You can try yourself, no
>
> Prolog system can do it:
>
> /* SWI-Prolog */
> ?- X = (begin
> x = 1;
> begin
> y = 2
> end
> end), compile(X, L, []).
> false.
> %%% expected L = [load(1),store(x),load(2),store(y)]
>
> /* SICStus Prolog */
> ?- X = (begin
> x = 1;
> begin
> y = 2
> end
> end), compile(X, L, []).
> no.
> %%% expected L = [load(1),store(x),load(2),store(y)]
>
> The reason is that the parser will join multiple yf,
> similarly it would join multiple fy. The parser will
> not follow a braket pattern. At least I don’t know
> any Prolog system that can do it.
>
> Mild Shock schrieb:
>> Here is the SWI-Prolog and the SICStus
>> Prolog abstract parse term. This is the real
>> nightmare of every computer science professor,
>>
>> who wants to use Prolog in a compiler
>> construction course:
>>
>> /* SWI-Prolog 9.3.14 */
>> end(end(begin(;(=(x,1),;(=(y,2),begin(=(z,3)))))))
>>
>> /* SICStus Prolog 4.9.0 */
>> begin(;(=(x,1),;(=(y,2),begin(end(end(=(z,3)))))))
>>
>> On the other hand mostlikely the OP @horsh
>> would expect:
>>
>> /* What the End-User wants */
>> end(begin(;(=(x,1),;(=(y,2),end(begin(=(z,3)))))))
>>
>> I think its impossible to do in any Prolog system,
>> you would need a programming language with the
>> possibility to do mixfix syntax definitions,
>>
>> like for example in Isabelle/HOL:
>>
>> (* Define the mixfix syntax for a Pascal-like block *)
>> syntax
>> "_begin_end" :: "'a ⇒ 'a" ("begin _ end")
>>
>> Or otherwise use DCG to write your own parser
>> for the DSL at hand, that you want to parse.
>> Since Prolog operators cannot model mixfix syntax,
>>
>> at least SWI-Prolog and SICStus Prolog fail,
>> and I guess other Prolog systems fail as well.
>>
>> Mild Shock schrieb:
>>> Concerning the input (xxx yyy zzz) the OP wrote:
>>>
>>> I would expect it to print zzz(xxx(yyy)).
>>>
>>> Where did he get this requirement from, he didn’t
>>> compare other Prolog systems, right? So it came from
>>> his applicationdomain. But what was his application
>>>
>>> domain? Ok, lets proceed to an example with multiple
>>> brakets. Lets make the Pascal “begin” “end” example,
>>> by replacing xxx and zzz by “begin” and “end”.
>>>
>>> I get this result:
>>>
>>> ?- member(X,[begin,end]), current_op(Y,Z,X).
>>> X = (begin), Y = 1100, Z = fy ;
>>> X = (end), Y = 1100, Z = yf.
>>>
>>> ?- X = (begin
>>> | x = 1;
>>> | y = 2;
>>> | begin
>>> | z = 3
>>> | end
>>> | end).
>>> X = (begin x=1;y=2;begin z=3 end end).
>>>
>>> But is the abstract parse term, the Prolog result useful?
>>>
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Julio Di Egidio <julio@diegidio.name> |
|---|---|
| Date | 2024-11-14 21:21 +0100 |
| Subject | Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vh5m4u$2o1jf$1@dont-email.me> |
| In reply to | #14283 |
On 14/11/2024 05:14, Mild Shock wrote:
>
> Typically we want to then go on and write
> for example a compiler:
>
> :- op(1100,fy,begin).
> :- op(1100,yf,end).
>
> compile((begin X end)) --> compile(X). %%% scoping omitted
> compile((X;Y)) --> compile(X), compile(Y).
> compile((V=E)) --> [load(E),store(V)].
>
> The problem is the pattern (begin X end) will
> not work, if multiple (begin … end) are involved
> in the compile/1 call. You can try yourself, no
> Prolog system can do it:
>
> /* SWI-Prolog */
> ?- X = (begin
> x = 1;
> begin
> y = 2
> end
> end), compile(X, L, []).
> false.
> %%% expected L = [load(1),store(x),load(2),store(y)]
<snip>
This seems to do the trick:
```
% SWI-Prolog 9.2.7
:- op(1100, fy, begin).
:- op(1100, yf, end).
compile((begin XEnd)) --> compile(XEnd).
compile((X end)) --> compile(X).
compile((X;Y)) --> compile(X), compile(Y).
compile((V=E)) --> [load(E),store(V)].
compile_t(X, L) :-
X = (
begin
x = 1;
begin
y = 2
end
end
),
compile(X, L, []).
```
```
?- compile_t(X, L).
X = (begin x=1;begin y=2 end end),
L = [load(1),store(x),load(2),store(y)].
```
-Julio
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-14 21:58 +0100 |
| Subject | Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vh5o8p$6c48$1@solani.org> |
| In reply to | #14285 |
Yes, maybe, it depends. You would
need to fill in some logic for the
block functionality, like opening
and closing a table with variable
names. And try it as such with a larger
variety of example. Also compare whether
it works for both SWI-Prolog and SICStus
Prolog. What one can already see for sure,
the compile is not extremly safe anymore.
It would also accept non well formed
input. Like you can call it with unbalanced
begin end now, and the compile/1 clause
pattern matching will not fail, and it
will start producing some code:
?- compile((begin x=1 end end)).
But maybe this is a minor problem. Another
challenge is for example the Pascal if-then-else.
Basically a mixfix with 3 holes.
if _ then _ else _
https://www.tutorialspoint.com/pascal/pascal_if_then_else_statement.htm
Just like in the begin end case, where
we can provide non-well formed input
like (begin x=1 end end). Ordinary
Prolog operators will again not provide
the safety and versatility for writing rules.
Julio Di Egidio schrieb:
> This seems to do the trick:
>
> ```
> % SWI-Prolog 9.2.7
>
> :- op(1100, fy, begin).
> :- op(1100, yf, end).
>
> compile((begin XEnd)) --> compile(XEnd).
> compile((X end)) --> compile(X).
> compile((X;Y)) --> compile(X), compile(Y).
> compile((V=E)) --> [load(E),store(V)].
>
> compile_t(X, L) :-
> X = (
> begin
> x = 1;
> begin
> y = 2
> end
> end
> ),
> compile(X, L, []).
> ```
>
> ```
> ?- compile_t(X, L).
> X = (begin x=1;begin y=2 end end),
> L = [load(1),store(x),load(2),store(y)].
> ```
>
> -Julio
>
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-14 22:10 +0100 |
| Subject | Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vh5p03$6g0t$1@solani.org> |
| In reply to | #14286 |
This is also a rather frustrating case,
you might run into the same problem when
you would try doing if-then-else:
?- X = (begin x=1 end; y=2; begin z=3 end).
ERROR: Syntax error: Operator priority clash
Unparsable in both SWI-Prolog and SICStus
Prolog. On the other hand using {}/1 works:
?- X = ({x=1}; y=2; {z=3}).
X = ({x=1};y=2;{z=3}).
Mild Shock schrieb:
> Yes, maybe, it depends. You would
> need to fill in some logic for the
> block functionality, like opening
>
> and closing a table with variable
> names. And try it as such with a larger
> variety of example. Also compare whether
>
> it works for both SWI-Prolog and SICStus
> Prolog. What one can already see for sure,
> the compile is not extremly safe anymore.
>
> It would also accept non well formed
> input. Like you can call it with unbalanced
> begin end now, and the compile/1 clause
>
> pattern matching will not fail, and it
> will start producing some code:
>
> ?- compile((begin x=1 end end)).
>
> But maybe this is a minor problem. Another
> challenge is for example the Pascal if-then-else.
> Basically a mixfix with 3 holes.
>
> if _ then _ else _
>
> https://www.tutorialspoint.com/pascal/pascal_if_then_else_statement.htm
>
> Just like in the begin end case, where
> we can provide non-well formed input
> like (begin x=1 end end). Ordinary
>
> Prolog operators will again not provide
> the safety and versatility for writing rules.
>
> Julio Di Egidio schrieb:
>> This seems to do the trick:
>>
>> ```
>> % SWI-Prolog 9.2.7
>>
>> :- op(1100, fy, begin).
>> :- op(1100, yf, end).
>>
>> compile((begin XEnd)) --> compile(XEnd).
>> compile((X end)) --> compile(X).
>> compile((X;Y)) --> compile(X), compile(Y).
>> compile((V=E)) --> [load(E),store(V)].
>>
>> compile_t(X, L) :-
>> X = (
>> begin
>> x = 1;
>> begin
>> y = 2
>> end
>> end
>> ),
>> compile(X, L, []).
>> ```
>>
>> ```
>> ?- compile_t(X, L).
>> X = (begin x=1;begin y=2 end end),
>> L = [load(1),store(x),load(2),store(y)].
>> ```
>>
>> -Julio
>>
>
[toc] | [prev] | [next] | [standalone]
| From | Julio Di Egidio <julio@diegidio.name> |
|---|---|
| Date | 2024-11-15 15:42 +0100 |
| Subject | Re: How Prolog became an education nightmare (Was: 50 Years of Prolog Nonsense) |
| Message-ID | <vh7mjt$3bo7l$1@dont-email.me> |
| In reply to | #14286 |
On 14/11/2024 21:58, Mild Shock wrote: > Yes, maybe, it depends. You would > need to fill in some logic for the > block functionality, like opening Yes, the problem is a conflict in block scoping syntax, but it is only a problem with a shallow embedding *and* expecting to stay 100% faithful to the object language syntax. -Julio
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2024-11-14 22:30 +0100 |
| Subject | Mode yfy to the rescue (Was: How Prolog became an education nightmare) |
| Message-ID | <vh5q52$6gk9$1@solani.org> |
| In reply to | #14281 |
Ok, here is my minimal test case, to demonstrate that fy 2 yf has not much practical use. Irrespective how it is parsed. The test case is the computer science professor who wants to teach compiler construction, and defines a toy language that has among other things a Pascal begin end: :- op(1100, fy, begin). :- op(1100, yf, end). Neither SWI-Prolog nor SICStus Prolog can parse this: ?- X = (begin x=1 end; begin y=2 end). ERROR: Syntax error: Operator priority clash I am also not able to parse it in Dogelog Player, Trealla Prolog and Scryer Prolog. I guess it has to do that disjunction uses xfy mode. Mostlikely yfx mode would also not help? What would help if there were a yfy mode (sic!). Mild Shock schrieb: > Concerning the input (xxx yyy zzz) the OP wrote: > > I would expect it to print zzz(xxx(yyy)). > > Where did he get this requirement from, he didn’t > compare other Prolog systems, right? So it came from > his applicationdomain. But what was his application > > domain? Ok, lets proceed to an example with multiple > brakets. Lets make the Pascal “begin” “end” example, > by replacing xxx and zzz by “begin” and “end”. > > I get this result: > > ?- member(X,[begin,end]), current_op(Y,Z,X). > X = (begin), Y = 1100, Z = fy ; > X = (end), Y = 1100, Z = yf. > > ?- X = (begin > | x = 1; > | y = 2; > | begin > | z = 3 > | end > | end). > X = (begin x=1;y=2;begin z=3 end end). > > But is the abstract parse term, the Prolog result useful? >
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2025-08-01 02:47 +0200 |
| Subject | Cyclic term predicates suffer from ambiguity (Was: How Prolog became an education nightmare) |
| Message-ID | <106h2qj$366se$1@solani.org> |
| In reply to | #14281 |
Take this test case:
test1(X) :- X = f(g(X,_B),_A).
test2(X) :- Y = g(f(Y,A),_B), X = f(Y,A).
Now try this (numbervars/3):
/* SWI-Prolog 9.3.26 */
?- test1(X), numbervars(X,0,_).
X = f(g(X, A), B).
?- test2(X), numbervars(X,0,_).
X = f(_S1, A), % where
_S1 = g(f(_S1, A), B).
And try this (nonground/2):
?- test1(X), nonground(X, V).
X = f(g(X, V), _).
?- test2(X), nonground(X, V).
X = f(_S1, V), % where
_S1 = g(f(_S1, V), _).
And try this (term_variables/2):
?- test1(X), term_variables(X, [V,W]).
X = f(g(X, V), W).
?- test2(X), term_variables(X, [V,W]).
X = f(_S1, V), % where
_S1 = g(f(_S1, V), W).
All 3 predicates suffer from an similar anomaly,
namely, in the first query V appears 2nd
argument of g/2, and in the second query V
appears 2nd argument of f/2. Can this be fixed?
Mild Shock schrieb:
> Concerning the input (xxx yyy zzz) the OP wrote:
>
> I would expect it to print zzz(xxx(yyy)).
>
> Where did he get this requirement from, he didn’t
> compare other Prolog systems, right? So it came from
> his applicationdomain. But what was his application
>
> domain? Ok, lets proceed to an example with multiple
> brakets. Lets make the Pascal “begin” “end” example,
> by replacing xxx and zzz by “begin” and “end”.
>
> I get this result:
>
> ?- member(X,[begin,end]), current_op(Y,Z,X).
> X = (begin), Y = 1100, Z = fy ;
> X = (end), Y = 1100, Z = yf.
>
> ?- X = (begin
> | x = 1;
> | y = 2;
> | begin
> | z = 3
> | end
> | end).
> X = (begin x=1;y=2;begin z=3 end end).
>
> But is the abstract parse term, the Prolog result useful?
>
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2025-08-01 03:01 +0200 |
| Subject | An ISO term_variables/2 for Cyclic Terms (Was: Cyclic term predicates suffer from ambiguity) |
| Message-ID | <106h3kt$3677k$3@solani.org> |
| In reply to | #14747 |
Here is an implementation that doesn’t suffer from
the same anomaly. I get these results:
?- test1(X), term_vars(X, [V,W]).
X = f(g(X, W), V).
?- test2(X), term_vars(X, [V,W]).
X = f(_S1, V), % where
_S1 = g(f(_S1, V), W).
Only the algorithm is a little expensive. Whats
annonying that I backtrack over a bisimulation
equals. And can only collect the union find store
during a sucesss. But a failure of the bisimulation
equals does a local union find store rollback, without
keeping any partial union find results that were
from successful sub-equals calls:
term_vars(T, L) :-
term_vars([], T, []-[], L-_).
% term_vars(+List, +Term, +Pair, -Pair)
term_vars(_, V, L-P, L-P) :- var(V),
member(W, L), W == V, !.
term_vars(_, V, L-P, [V|L]-P) :- var(V), !.
term_vars(M, T, L-P, L-Q) :- compound(T),
member(S, M), equals(T, S, P, Q), !.
term_vars(M, T, L, R) :- compound(T), !,
T =..[_|A],
foldl(term_vars([T|M]), A, L, R).
term_vars(_, _, L, L).
The bisimulation equals itself is:
equals(X, Y) :-
equals(X, Y, [], _).
% equals(+Term, +Term, +List, -List)
equals(X, Y, L, R) :- compound(X), compound(Y), !,
union_find(X, L, Z),
union_find(Y, L, T),
equals2(Z, T, L, R).
equals(X, Y, L, L) :- X == Y.
equals2(X, Y, L, L) :-
same_term(X, Y), !.
equals2(X, Y, _, _) :-
functor(X, F, N),
functor(Y, G, M),
F/N \== G/M, !, fail.
equals2(X, Y, L, R) :-
X =.. [_|A],
Y =.. [_|B],
foldl(equals, A, B, [X-Y|L], R).
And the union find trivially:
union_find(X, L, T) :-
member(Y-Z, L),
same_term(X, Y), !,
union_find(Z, L, T).
union_find(X, _, X).
Mild Shock schrieb:
> Take this test case:
>
> test1(X) :- X = f(g(X,_B),_A).
>
> test2(X) :- Y = g(f(Y,A),_B), X = f(Y,A).
>
> Now try this (numbervars/3):
>
> /* SWI-Prolog 9.3.26 */
> ?- test1(X), numbervars(X,0,_).
> X = f(g(X, A), B).
>
> ?- test2(X), numbervars(X,0,_).
> X = f(_S1, A), % where
> _S1 = g(f(_S1, A), B).
>
> And try this (nonground/2):
>
> ?- test1(X), nonground(X, V).
> X = f(g(X, V), _).
>
> ?- test2(X), nonground(X, V).
> X = f(_S1, V), % where
> _S1 = g(f(_S1, V), _).
>
> And try this (term_variables/2):
>
> ?- test1(X), term_variables(X, [V,W]).
> X = f(g(X, V), W).
>
> ?- test2(X), term_variables(X, [V,W]).
> X = f(_S1, V), % where
> _S1 = g(f(_S1, V), W).
>
> All 3 predicates suffer from an similar anomaly,
> namely, in the first query V appears 2nd
> argument of g/2, and in the second query V
>
> appears 2nd argument of f/2. Can this be fixed?
>
> Mild Shock schrieb:
>> Concerning the input (xxx yyy zzz) the OP wrote:
>>
>> I would expect it to print zzz(xxx(yyy)).
>>
>> Where did he get this requirement from, he didn’t
>> compare other Prolog systems, right? So it came from
>> his applicationdomain. But what was his application
>>
>> domain? Ok, lets proceed to an example with multiple
>> brakets. Lets make the Pascal “begin” “end” example,
>> by replacing xxx and zzz by “begin” and “end”.
>>
>> I get this result:
>>
>> ?- member(X,[begin,end]), current_op(Y,Z,X).
>> X = (begin), Y = 1100, Z = fy ;
>> X = (end), Y = 1100, Z = yf.
>>
>> ?- X = (begin
>> | x = 1;
>> | y = 2;
>> | begin
>> | z = 3
>> | end
>> | end).
>> X = (begin x=1;y=2;begin z=3 end end).
>>
>> But is the abstract parse term, the Prolog result useful?
>>
>
[toc] | [prev] | [standalone]
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
Back to top | Article view | comp.lang.prolog
csiph-web