From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.182.81.7 with SMTP id v7mr6287736obx.28.1390213150595;
 Mon, 20 Jan 2014 02:19:10 -0800 (PST)
X-Received: by 10.140.93.109 with SMTP id c100mr31737qge.16.1390213150554;
 Mon, 20 Jan 2014 02:19:10 -0800 (PST)
Path: 
 border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!p15no23964899qaj.0!news-out.google.com!gg4ni10838qab.0!nntp.google.com!p15no23964896qaj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 20 Jan 2014 02:19:10 -0800 (PST)
In-Reply-To: <lbgl80$n0m$1@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=2001:690:2200:9aa1:71ba:a0cb:6f9:9eb8;
 posting-account=3cDqWgoAAAAZXc8D3pDqwa77IryJ2nnY
NNTP-Posting-Host: 2001:690:2200:9aa1:71ba:a0cb:6f9:9eb8
References: <alpine.LNX.2.00.1401181334560.23391@anapnea.net>
 <lbdu30$h79$1@dont-email.me>
 <alpine.LNX.2.00.1401181532250.23391@anapnea.net>
 <lbe630$sh6$1@dont-email.me>
 <d0713f85-d6de-44be-85a5-7fc2e2a1c075@googlegroups.com>
 <e15dba8b-7437-4abc-8f34-ffbefccb7aef@googlegroups.com>
 <lbgiej$kcv$1@speranza.aioe.org> <lbgl80$n0m$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b7a0fa1f-ac15-4992-b888-ed257690f9c1@googlegroups.com>
Subject: Re: Delays for implementations of Fortran features
From: Marius Amado-Alves <amado.alves@gmail.com>
Injection-Date: Mon, 20 Jan 2014 10:19:10 +0000
Content-Type: text/plain; charset=ISO-8859-1
X-Original-Bytes: 1876
Xref: number.nntp.dca.giganews.com comp.lang.ada:184487
Date: 2014-01-20T02:19:10-08:00
List-Id: <comp.lang.ada>

> I _really_ like Wirth's approach with his active effort to reduce a
> language to it's required core elements (I'm thinking about the Oberon
> variants here). (Simon)

Yes, fine approach and language. I've tried it some years ago and didn't stick with it because the implementation was too limited and non portable and still a little buggy I think. I'll have to check how it is now.