From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id 90A8228151 for ; Thu, 4 Apr 2024 17:41:12 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 8EEFE41346; Fri, 5 Apr 2024 01:41:10 +1000 (AEST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by minnie.tuhs.org (Postfix) with ESMTPS id 8E3C54132D for ; Fri, 5 Apr 2024 01:41:02 +1000 (AEST) Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-6ecee5c08e6so713340b3a.3 for ; Thu, 04 Apr 2024 08:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712245261; x=1712850061; darn=tuhs.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=GLYKVeD1Wc/dZc5Jvhx72kKAz3HWLgls2MbpPKomewo=; b=kmzXCh5g11DbOpleZSdH/k1dN2TD+bmH2OUmLYMoW+WYvIZ5uXLqlC6LEbooMPEGRP 2bA8RmJmkO78HPHgjKo8a2DsnTpazU3icpOiaUvjzJLHiz/uO2PTiGvkCyag3CWiL7/i Tk0fK7ywOQ/rtB1pLtdTU9xbXgJDGr5WcqsaWNXqgFTaHR5uOJzcwBKkkMowHtco3M0C 1zNaS/N8XZh7uXJOIPq/ahVGxy8bc8OQz0dSoLRnJFKjz4LTjRkXFV95ceV0GUgi2s8X I02MqrgGVb9TdB9okisIO6S7jZ5keOYdq71SvFkASAi/sZ06HkqL4OXbi1NrRyUBej77 6ioA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712245261; x=1712850061; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GLYKVeD1Wc/dZc5Jvhx72kKAz3HWLgls2MbpPKomewo=; b=h2YV6korKpIYqCxthiG+h88wfq+SsQdjvHe2GwZTGsjx+AalCOlBvU6iHIVYOtGtGu nvieuxxga2Nb/cabF3iqdKPRyGWGc2kdP/sUaaQJCL4uza5nD0/qDlv81ZumrI+pHRjV qAZf2W7NX6vBlvoFTUhe3k/jK7tpisQlIeCXiOWWlIFQzG64AnBr+w1RmBtn5ez//Vp3 Hrp0TLQIFFpydwJImipRWZhPMn9D6id1HnBx1YFLG5ok0cqkqqMygTUz3IMvKtJZkxJ9 +N2sO4jaucswpPIdkkLhqXj5vchgZLWHdPGtK07uWs6osNJovRuF/DfCpOWktEt/2cgI JxTA== X-Gm-Message-State: AOJu0YznI7ADPzenuzENcsnHojR/fqi9IFVm6vMwFnWLqfuiddCBtyPj lx6alCBpOCErrxNzINTc5ywzjPJk41DxFw4ADxeF8NNU0SFPm7rk46l9dsYGEiOJeMibqa5Obfs buga/975Lw4F05xBEOlvNzBXFD6ou51qj X-Google-Smtp-Source: AGHT+IFxq8UHVLOWGJkylbJDslnQm8Iks9Pbb+tk19TYMxxPOuXyULakmx671B6zXHtrZa4Q85VapQisCO31GsOp0tM= X-Received: by 2002:a05:6a20:d706:b0:1a1:4aa9:96df with SMTP id iz6-20020a056a20d70600b001a14aa996dfmr142262pzb.30.1712245261172; Thu, 04 Apr 2024 08:41:01 -0700 (PDT) MIME-Version: 1.0 References: <1d3f129c-eafe-4fb2-9ea2-d949f3813c88@technologists.com> <516a4019-d987-4ca4-ac62-bd6b40841f93@gmail.com> In-Reply-To: <516a4019-d987-4ca4-ac62-bd6b40841f93@gmail.com> From: Paul Winalski Date: Thu, 4 Apr 2024 11:40:50 -0400 Message-ID: To: coff@tuhs.org Content-Type: multipart/alternative; boundary="0000000000008f85e20615472add" Message-ID-Hash: 34TAYSLSCAVNAXJ7OJ5KJFESQ3P54XOQ X-Message-ID-Hash: 34TAYSLSCAVNAXJ7OJ5KJFESQ3P54XOQ X-MailFrom: paul.winalski@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: Of PL/I List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000008f85e20615472add Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 3, 2024 at 11:37=E2=80=AFPM Wesley Parish wrote: > I learn C by reading Tanenbaum and Comer's OS books, and I cannot > imagine how putting variable declarations anywhere other than the top of > the function they belong to, would make sense. Unless they are global, > in which case they go in a suitably global header file. > > That's the way we always handled declarations in every PL/I shop I worked in. Local declarations always appeared immediately following the PROCEDURE or BEGIN statement that starts the scope to which the declaration applies. PL/I adopted the idea of nested scopes from Algol. One other programming convention we used was to keep variable scopes as localized as possible. Among other things, it makes lifetime analysis easier for the compiler. Another feature present in PL/I but not in C or most other languages is nested procedures. A nested procedure inherits all of the variables accessible in the scope of the containing procedure in which it's declared. Up-level addressing (use of variables declared outside the nested procedure) is somewhat error prone and less efficient than accessing data via a parameter. PL/I also supports recursion, something not provided for in the usual IBM S/360 ABI calling convention. A procedure that can be called recursively must be declared with the RECURSIVE attribute. Unlike C, in IBM S/360/370 PL/I recursion was disallowed by default. DEC's ABI for VMS supports recursion by default and so DEC PL/I dropped the RECURSIVE attribute. PL/I also supports an extended version of Fortran's computed GOTO via label variables. PL/I statements are labeled by name as opposed to Fortran's statement numbers. A label variable can be assigned a statement label value and a GOTO statement using the label variable transfers control to whichever statement label is held in the label variable. Label variables encourage rat's nest programming styles and very much went out of fashion when structured programming came along. -Paul W. --0000000000008f85e20615472add Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 3, 2024 at 11:37=E2=80=AFPM W= esley Parish <wobblygong@gmail.c= om> wrote:
I learn C by reading Tanenbaum and Comer's OS = books, and I cannot
imagine how putting variable declarations anywhere other than the top of the function they belong to, would make sense. Unless they are global,
in which case they go in a suitably global header file.

That's the way we always handled declarations in = every PL/I shop I worked in.=C2=A0 Local declarations always appeared immed= iately following the PROCEDURE or BEGIN statement that starts the scope to = which the declaration applies.=C2=A0 PL/I adopted the idea of nested scopes= from Algol.=C2=A0 One other programming convention we used was to keep var= iable scopes as localized as possible.=C2=A0 Among other things, it makes l= ifetime analysis easier for the compiler.

Another = feature present in PL/I but not in C or most other languages is nested proc= edures.=C2=A0 A nested procedure inherits all of the variables accessible i= n the scope of the containing procedure in which it's declared.=C2=A0 U= p-level addressing (use of variables declared outside the nested procedure)= is somewhat error prone and less efficient than accessing data via a param= eter.

PL/I also supports recursion, something not = provided for in the usual IBM S/360 ABI calling convention.=C2=A0 A procedu= re that can be called recursively must be declared with the RECURSIVE attri= bute.=C2=A0 Unlike C, in IBM S/360/370=C2=A0 PL/I recursion was disallowed = by default.=C2=A0 DEC's ABI for VMS supports recursion by default and s= o DEC PL/I dropped the RECURSIVE attribute.

PL/I a= lso supports an extended version of Fortran's computed GOTO via label v= ariables.=C2=A0 PL/I statements are labeled by name as opposed to Fortran&#= 39;s statement numbers.=C2=A0 A label variable can be assigned a statement = label value and a GOTO statement using the label variable transfers control= to whichever statement label is held in the label variable.=C2=A0 Label va= riables encourage rat's nest programming styles and very much went out = of fashion when structured programming came along.

-Paul W.
--0000000000008f85e20615472add--