From Newsgroup: comp.lang.misc

At one time, we distinguished between “scripting” languages and “programming” languages. To begin with, the “scripting” languages were somehow more limited in functionality than full-fledged “programming” languages. Or they were slower, because they were interpreted.

Then languages like Perl and Java came along: both were compiled to a
bytecode, a sort of pseudo-machine-language, which was interpreted by
software, not CPU hardware. Were they “scripting” or “programming” languages? Some might have classed Perl as a “scripting” language to
begin with, but given it is must as powerful as Java, then why
shouldn’t Java also be considered a “scripting” rather than “programming” language? And before these two, there was UCSD Pascal,
which was probably the pioneer of this compile-to-bytecode idea.

So that terminology for distinguishing between classes of programming
languages became largely obsolete.

But there is one distinction that I think is still relevant, and that
is the one between shell/command languages and programming languages.

In a shell language, everything you type is assumed to be a literal
string, unless you use special substitution sequences. E.g. in a POSIX
shell:

ls -l thingy

“give me information about the file/directory named ‘thingy’”, vs.

ls -l $thingy

“give me information about the files/directories whose names are in
the value of the variable ‘thingy’”.

Whereas in a programming language, everything is assumed to be a
language construct, and every unadorned name is assumed to reference
some value/object, so you need quote marks to demarcate literal
strings, e.g. in Python:

os.listdir(thingy)

“return a list of the contents of the directory whose name is in the
variable ‘thingy’”, vs.

os.listdir("thingy")

“return a list of the contents of the directory named ‘thingy’”.

This difference in design has to do with their typical usage: most of
the use of a shell/command language is in typing a single command at a
time, for immediate execution. Whereas a programming language is
typically used to construct sequences consisting of multiple lines of
code before they are executed.

This difference is also why attempts to use programming languages as
though they were shell/command languages, entering and executing a
single line of code at a time, tend to end up being more trouble than
they are worth.

Conversely, using shell/command languages as programming languages, by collecting multiple lines of code into shell scripts, does work, but
only up to a point. The concept of variable substitution via string substitution tends to lead to trouble when trying to do more advanced
data manipulations.

So, in short, while there is some overlap in their applicable usage
areas, they are still very much oriented to different application
scenarios.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 01:14 this Friday (GMT):

At one time, we distinguished between “scripting” languages and “programming” languages. To begin with, the “scripting” languages were
somehow more limited in functionality than full-fledged “programming” languages. Or they were slower, because they were interpreted.

Then languages like Perl and Java came along: both were compiled to a bytecode, a sort of pseudo-machine-language, which was interpreted by software, not CPU hardware. Were they “scripting” or “programming” languages? Some might have classed Perl as a “scripting” language to begin with, but given it is must as powerful as Java, then why
shouldn’t Java also be considered a “scripting” rather than “programming” language? And before these two, there was UCSD Pascal, which was probably the pioneer of this compile-to-bytecode idea.

So that terminology for distinguishing between classes of programming languages became largely obsolete.

But there is one distinction that I think is still relevant, and that
is the one between shell/command languages and programming languages.

In a shell language, everything you type is assumed to be a literal
string, unless you use special substitution sequences. E.g. in a POSIX
shell:

ls -l thingy

“give me information about the file/directory named ‘thingy’”, vs.

ls -l $thingy

“give me information about the files/directories whose names are in
the value of the variable ‘thingy’”.

Whereas in a programming language, everything is assumed to be a
language construct, and every unadorned name is assumed to reference
some value/object, so you need quote marks to demarcate literal
strings, e.g. in Python:

os.listdir(thingy)

“return a list of the contents of the directory whose name is in the variable ‘thingy’”, vs.

os.listdir("thingy")

“return a list of the contents of the directory named ‘thingy’”.

This difference in design has to do with their typical usage: most of
the use of a shell/command language is in typing a single command at a
time, for immediate execution. Whereas a programming language is
typically used to construct sequences consisting of multiple lines of
code before they are executed.

This difference is also why attempts to use programming languages as
though they were shell/command languages, entering and executing a
single line of code at a time, tend to end up being more trouble than
they are worth.

Conversely, using shell/command languages as programming languages, by collecting multiple lines of code into shell scripts, does work, but
only up to a point. The concept of variable substitution via string substitution tends to lead to trouble when trying to do more advanced
data manipulations.

So, in short, while there is some overlap in their applicable usage
areas, they are still very much oriented to different application
scenarios.

Interesting, I never thought of it like that.
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 01:14:18 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

At one time, we distinguished between “scripting” languages and >“programming” languages. To begin with, the “scripting” languages were >somehow more limited in functionality than full-fledged “programming” >languages. Or they were slower, because they were interpreted.

Then languages like Perl and Java came along: both were compiled to a >bytecode, a sort of pseudo-machine-language, which was interpreted by >software, not CPU hardware. Were they “scripting” or “programming” >languages? Some might have classed Perl as a “scripting” language to

My rule of thimb is that a scripting language is one whereby the source code can be run immediately by the interpreter, eg perl, python, regardless of
what happens internally. A full fledged programming language is one that requires a compile/debug/link step first with the compiler and runtime (if required) being seperate. eg Java, C


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

At one time, we distinguished between “scripting” languages and “programming” languages. [...] But there is one distinction that I
think is still relevant, and that is the one between shell/command
languages and programming languages.

[...]

Consider looking at a shell language like a domain-specific programming language. A shell is a programming language made specifically for
running programs. When you write a shell line, you're specifying the
arguments of execve(2). In other words, a shell is a programming
language made to prepare the memory to be consumed by the system in a
specific way---execve(2). (Of course, the idea evolves and you want to
glue programs, do variable substitution et cetera.)

A scripting language is a programming language made for a hypothetical
machine, not too different from a programming language made for a real
machine, one made of hardware.

You seem to find trouble with using a programming language in a REPL.
It seems to contradict be the overall feeling of so many people who
understand a lot about programming---who made all of these things
actually work (and fun).
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 29.03.24 10:55, Muttley@dastardlyhq.com wrote:

On Fri, 29 Mar 2024 01:14:18 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

At one time, we distinguished between “scripting” languages and
“programming” languages. To begin with, the “scripting” languages were
somehow more limited in functionality than full-fledged “programming”
languages. Or they were slower, because they were interpreted.

Then languages like Perl and Java came along: both were compiled to a
bytecode, a sort of pseudo-machine-language, which was interpreted by
software, not CPU hardware. Were they “scripting” or “programming” >> languages? Some might have classed Perl as a “scripting” language to

My rule of thimb is that a scripting language is one whereby the source code can be run immediately by the interpreter, eg perl, python, regardless of what happens internally. A full fledged programming language is one that requires a compile/debug/link step first with the compiler and runtime (if required) being seperate. eg Java, C

I second that.

My 2€cts,
Josef

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Muttley@dastardlyhq.com writes:

My rule of thimb is that a scripting language is one whereby the source code can be run immediately by the interpreter, eg perl, python, regardless of what happens internally. A full fledged programming language is one that requires a compile/debug/link step first with the compiler and runtime (if required) being seperate. eg Java, C

C can be a scripting language by that rule:

$ cat t.c
#!/usr/bin/tcc -run
#include <stdio.h>

int main(void) {
return printf("Hello, world\n");
}
$ ./t.c
Hello, world
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 11:40:03 +0000
Richard Kettlewell <invalid@invalid.invalid> wrote:

Muttley@dastardlyhq.com writes:

My rule of thimb is that a scripting language is one whereby the source code >> can be run immediately by the interpreter, eg perl, python, regardless of
what happens internally. A full fledged programming language is one that
requires a compile/debug/link step first with the compiler and runtime (if >> required) being seperate. eg Java, C

C can be a scripting language by that rule:

No definition is perfect in this case, its all shades of grey.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 29/03/2024 02:14, Lawrence D'Oliveiro wrote:

At one time, we distinguished between “scripting” languages and “programming” languages. To begin with, the “scripting” languages were
somehow more limited in functionality than full-fledged “programming” languages. Or they were slower, because they were interpreted.

I don't think there has ever been a clear distinction.

A "script" is usually small and often written for a particular task on a particular system, while a "program" might be bigger and more generic, runnable on multiple systems by multiple people. But there is no
dividing point in the type of code, and plenty of overlap - even though
the difference is often clear ("This is a script for making backups of
my servers - it uses the rsync program to do the bulk of the work").

Similarly, there are not "scripting languages" and "programming
languages". There are languages that are more suitable for script work,
and languages that are more suitable for programming work, and languages
that are suitable for both.

Then there are "interpreted" languages and "compiled" languages. As you
say, this is not a binary distinction - there are shades between this, especially with byte compiling. Some languages, such as Python, are
used like interpreted language (you "run" the source code) but are byte-compiled on the fly. Some, like Java, are used like compiled
languages but generate byte code that is interpreted. Others use some byte-compiled code along with JIT machine code to blur the lines even more.

It is fair to say that "scripts" are usually written in interpreted
languages (or languages designed to look like they interpreted, by
compiling or byte-compiling on the fly). "Programs" can be written in interpreted or compiled languages - there is no consensus.

Then languages like Perl and Java came along: both were compiled to a bytecode, a sort of pseudo-machine-language, which was interpreted by software, not CPU hardware. Were they “scripting” or “programming” languages? Some might have classed Perl as a “scripting” language to begin with, but given it is must as powerful as Java, then why
shouldn’t Java also be considered a “scripting” rather than “programming” language? And before these two, there was UCSD Pascal, which was probably the pioneer of this compile-to-bytecode idea.

Such classification is just wrong, IMHO. You can write scripts in Perl,
and you can write programs in Perl. "APL" is invariably (AFAIK)
interpreted, and it is for programming rather than scripting - the
acronym stands for "A Programming Language".

And of course there are many computer languages whose prime purpose is
other tasks, even though they can be used for programming - TeX and
Postscript are examples.

So that terminology for distinguishing between classes of programming languages became largely obsolete.

I am not at all convinced it was ever relevant to distinguish between "scripting languages" and "programming languages". It was useful to distinguish between "interpreted" and "compiled" languages, and the
overlap and blurring has increased there.

But there is one distinction that I think is still relevant, and that
is the one between shell/command languages and programming languages.

In a shell language, everything you type is assumed to be a literal
string, unless you use special substitution sequences. E.g. in a POSIX
shell:

ls -l thingy

“give me information about the file/directory named ‘thingy’”, vs.

ls -l $thingy

“give me information about the files/directories whose names are in
the value of the variable ‘thingy’”.

Whereas in a programming language, everything is assumed to be a
language construct, and every unadorned name is assumed to reference
some value/object, so you need quote marks to demarcate literal
strings, e.g. in Python:

os.listdir(thingy)

“return a list of the contents of the directory whose name is in the variable ‘thingy’”, vs.

os.listdir("thingy")

“return a list of the contents of the directory named ‘thingy’”.

This difference in design has to do with their typical usage: most of
the use of a shell/command language is in typing a single command at a
time, for immediate execution. Whereas a programming language is
typically used to construct sequences consisting of multiple lines of
code before they are executed.

That is arguably a useful distinction in the style of programming
languages, and this difference makes the language more or less suited to particular tasks (such as typical short scripts).

Again, however, there are exceptions that mean a clear binary
distinction is not possible. Knuth did a lot of work on "literary programming", where documentation and source is combined along with
executable code, and used such languages and tools for programs like TeX
and Metafont. ("Linux from Scratch" is another example.)

TCL is a language that might be considered half-way between your
categories here.

This difference is also why attempts to use programming languages as
though they were shell/command languages, entering and executing a
single line of code at a time, tend to end up being more trouble than
they are worth.

Conversely, using shell/command languages as programming languages, by collecting multiple lines of code into shell scripts, does work, but
only up to a point. The concept of variable substitution via string substitution tends to lead to trouble when trying to do more advanced
data manipulations.

So, in short, while there is some overlap in their applicable usage
areas, they are still very much oriented to different application
scenarios.

<https://en.wikipedia.org/wiki/List_of_programming_languages_by_type>
gives something like 40 categories of programming languages, of which "scripting languages" is one type. I think any attempt at dividing up programming languages will either be so full of grey areas as to be
almost useless, or have so many categories that it is almost useless.
The best you can do is pick some characteristics of languages, or some
typical use-cases of languages, and ask if any given language fits there.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

My rule of thimb is that a scripting language is one whereby the
source code can be run immediately by the interpreter, eg perl,
python, regardless of what happens internally. A full fledged
programming language is one that requires a compile/debug/link step
first with the compiler and runtime (if required) being seperate. eg
Java, C

By *that* logic, even Lisp and Forth don't count as "full-fledged
programming languages" o_O Johanne's definition of a "scripting
language" as a DSL designed for directing the actions of the operating
system makes much more sense, IMHO.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 08:44:54 -0700
John Ames <commodorejohn@gmail.com> wrote:

On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

My rule of thimb is that a scripting language is one whereby the
source code can be run immediately by the interpreter, eg perl,
python, regardless of what happens internally. A full fledged
programming language is one that requires a compile/debug/link step
first with the compiler and runtime (if required) being seperate. eg
Java, C

By *that* logic, even Lisp and Forth don't count as "full-fledged
programming languages" o_O Johanne's definition of a "scripting

As a counter point, good luck writing a device driver in lisp. Forth maybe,
no idea.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 16:02:13 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

On Fri, 29 Mar 2024 08:44:54 -0700
John Ames <commodorejohn@gmail.com> wrote:

By *that* logic, even Lisp and Forth don't count as "full-fledged >programming languages" o_O Johanne's definition of a "scripting

As a counter point, good luck writing a device driver in lisp. Forth
maybe, no idea.

Well, suffice to say that Forth is bare-metal enough to serve as the
foundation for OpenFirmware systems... ;P

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 11:40:03 +0000
Richard Kettlewell <invalid@invalid.invalid> wrote:

Muttley@dastardlyhq.com writes:

My rule of thimb is that a scripting language is one whereby the source code
can be run immediately by the interpreter, eg perl, python, regardless of >>> what happens internally. A full fledged programming language is one that >>> requires a compile/debug/link step first with the compiler and runtime (if >>> required) being seperate. eg Java, C

C can be a scripting language by that rule:

No definition is perfect in this case, its all shades of grey.

Yes, a definition can be close to perfet here:

Scripting is an activity, a use case, not a language.

Scripting refers to executing commands which are so high level that they
are entire applications or functional blocks within an application.
Scripting automates applications or groups of applications.

A language can /support/ scripting (and other paradigms).

If a language only supports scripting well, and nothing else, then it's
a scripting language. That's exactly the same as that a language can be functional, or multi-paradigm with support for functional programming.

Scripting tend to have the attribute that they would never be used (and possibly could not be used) to write the functional building blocks
which their commands execute. It's possible for an application to be
written in a language in which it is scripted, but then that's almost
certainly not a scripting language.

Yes, an aspect of scripting is that scripts are taken as-is, in the representation in which they are written. Or at least, can be. If there
is a compiling step, it is either optional, or hidden by the
implementation. The requirement for some ahead-of-time compilation
ritual to prepare the script for execution by translating it to a
different file in a different format is anti-scripting, in a sense.

The ordinary meaning of the word "script" refers to a dialog followed by
an actor, in the same form in which it was written. The programming
word was almost certainly coined in reference to that.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-29, John Ames <commodorejohn@gmail.com> wrote:

On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

My rule of thimb is that a scripting language is one whereby the
source code can be run immediately by the interpreter, eg perl,
python, regardless of what happens internally. A full fledged
programming language is one that requires a compile/debug/link step
first with the compiler and runtime (if required) being seperate. eg
Java, C

By *that* logic, even Lisp and Forth don't count as "full-fledged
programming languages" o_O Johanne's definition of a "scripting
language" as a DSL designed for directing the actions of the operating
system makes much more sense, IMHO.

Common Lisp requires the implementation to be able to read
and execute printed expressions, without having them placed into
a file that must be translated to a compiled file.

The most prominent CL implementations compile every form before
executing it, even at the interactive prompt. It's invisible to the
user.

Scripting doesn't mean that the commands cannot be transparently
translated into antoher language before being executed.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 08:44:54 -0700
John Ames <commodorejohn@gmail.com> wrote:

On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

My rule of thimb is that a scripting language is one whereby the
source code can be run immediately by the interpreter, eg perl,
python, regardless of what happens internally. A full fledged
programming language is one that requires a compile/debug/link step
first with the compiler and runtime (if required) being seperate. eg
Java, C

By *that* logic, even Lisp and Forth don't count as "full-fledged >>programming languages" o_O Johanne's definition of a "scripting

As a counter point, good luck writing a device driver in lisp.

The Lisp machines had operating systems and device drivers written in
Lisp, interrupt-driven and all. Where do you perceive the difficulty?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 17:09:56 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 11:40:03 +0000
Richard Kettlewell <invalid@invalid.invalid> wrote: >>>Muttley@dastardlyhq.com writes:

My rule of thimb is that a scripting language is one whereby the source >code
can be run immediately by the interpreter, eg perl, python, regardless of >>>> what happens internally. A full fledged programming language is one that >>>> requires a compile/debug/link step first with the compiler and runtime (if

required) being seperate. eg Java, C

C can be a scripting language by that rule:

No definition is perfect in this case, its all shades of grey.

Yes, a definition can be close to perfet here:

Define perfect. Yours isn't.

Scripting is an activity, a use case, not a language.

So if I write a program to for example process some files in a directory by your argument its a script whether I write it in shell, python, C++ or assembler.

Umm, no, try again.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 17:13:47 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 08:44:54 -0700
John Ames <commodorejohn@gmail.com> wrote:

On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

My rule of thimb is that a scripting language is one whereby the
source code can be run immediately by the interpreter, eg perl,
python, regardless of what happens internally. A full fledged
programming language is one that requires a compile/debug/link step
first with the compiler and runtime (if required) being seperate. eg
Java, C

By *that* logic, even Lisp and Forth don't count as "full-fledged >>>programming languages" o_O Johanne's definition of a "scripting

As a counter point, good luck writing a device driver in lisp.

The Lisp machines had operating systems and device drivers written in
Lisp, interrupt-driven and all. Where do you perceive the difficulty?

Were the mucky bits actually written in Lisp or was Lisp simply calling some routines written in assembler? In the same sense that Python doesn't actually "do" AI, its way too slow, the AI but is done in libraries written in C++ that Python simply calls.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 17:09:56 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 11:40:03 +0000
Richard Kettlewell <invalid@invalid.invalid> wrote: >>>>Muttley@dastardlyhq.com writes:

My rule of thimb is that a scripting language is one whereby the source >>code
can be run immediately by the interpreter, eg perl, python, regardless of >>>>> what happens internally. A full fledged programming language is one that >>>>> requires a compile/debug/link step first with the compiler and runtime (if

required) being seperate. eg Java, C

C can be a scripting language by that rule:

No definition is perfect in this case, its all shades of grey.

Yes, a definition can be close to perfet here:

Define perfect. Yours isn't.

Scripting is an activity, a use case, not a language.

So if I write a program to for example process some files in a directory by your argument its a script whether I write it in shell, python, C++ or assembler.

I also wrote: "Scripting refers to executing commands which are so high
level that they are entire applications or functional blocks within an application."

If you write the program in assembler, are the instructions
"commands which are so high level that they are entire applications
or functional blocks within an application?"

In the assembly language program, mulitiple instructions, irrelevant
to the file processing task, are required just to correctly set up a
function call with parameters and return from it.

You're just being deliberately obtuse, not to mention snippy with the
scissors.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 17:13:47 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 08:44:54 -0700
John Ames <commodorejohn@gmail.com> wrote:

On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

My rule of thimb is that a scripting language is one whereby the
source code can be run immediately by the interpreter, eg perl,
python, regardless of what happens internally. A full fledged
programming language is one that requires a compile/debug/link step
first with the compiler and runtime (if required) being seperate. eg >>>>> Java, C

By *that* logic, even Lisp and Forth don't count as "full-fledged >>>>programming languages" o_O Johanne's definition of a "scripting

As a counter point, good luck writing a device driver in lisp.

The Lisp machines had operating systems and device drivers written in
Lisp, interrupt-driven and all. Where do you perceive the difficulty?

Were the mucky bits actually written in Lisp or was Lisp simply calling some routines written in assembler?

Sorry, could you demarcate where exactly the goalposts are? Which mucky
bits?

In kernels written in C, there are mucky bits in assembler, like
entry and exit into an trap/interrupt handler. You usually can't save
the machine state in an interrupt handler without some instruction that
is of no use in general code generation, not to mention detailed access
to all the working registers that are not normally manipulated from the
HLL.

Yes, the mucky bits of communicating with the device, like passing
frames to and from an ethernet card, would be written in Lisp.

Assembly routines in Lisps, though not Lisp, can at least be written
in Lisp notation and assembled within Lisp.

In machine-compiled Lisps, there is the possibility of inline code,
like in C or other languages.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

As a counter point, good luck writing a device driver in lisp.

Mmh--anybody know whether that was done for Lisp machines?
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

The distinctions between script and programming languages made sense when
they were first introduced. Later, the ability to compile scripts followed
by the things like java bytecode, and then the use of microcode in to make "machine language" act like a script have made the distinction murky to
the point of effectively being useless at the technical level.

From the user's point of view, text files the are executed by passing them
to an interpreter are best called scripts, and anything that goes through
some sort of compilation to a binary file that then gets executed are best called programs.

The terminology will continue to be used, but the distinction does not matter, except from a speed of processing difference.

Regards, Dave Hodgins
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

[...]

The terminology will continue to be used, but the distinction does not matter, except from a speed of processing difference.

Just to share that I, personally, don't use the distinction. For
instance, I say that

"the answer is %.2f\n"

is a program that builds a string given its usual context. I say that

awk '1; { print "" }'

is a program to double-space a file. I haven't said ``script'' in
years.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:

A scripting language is a programming language made for a hypothetical >machine, not too different from a programming language made for a real >machine, one made of hardware.

C is clearly a programming language, yet its specification
says, "The semantic descriptions in this document describe
the behavior of an abstract machine". And you cannot buy
this abstract C machine as a piece of hardware anywhere!
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 13:47:07 +0100, David Brown wrote:

TCL is a language that might be considered half-way between your
categories here.

TCL is definitely an interesting in-between case. In my limited use, I
recall it was awkward with data structures, just like shell languages. So maybe that puts it more on the shell side than the programming side.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 10:37:22 +0100, Janis Papanagnou wrote:

Program text is initially text.[*] During parsing (either in
an interpreted or in a compiled language) you split the text
in tokens.

And then, how do you interpret the tokens? In a shell language, you have
the assumption that “everything is literal text until indicated otherwise”; in a programming language, you have the assumption that “everything is a program construct until indicated otherwise”.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 08:09:46 -0300, Johanne Fairchild wrote:

Consider looking at a shell language like a domain-specific programming language. A shell is a programming language made specifically for
running programs. ... (Of course, the idea evolves and you want to
glue programs, do variable substitution et cetera.)

That’s the thing. The design for a “language made specifically for running programs” always seems to start with the assumption that what the user
types is to be passed as literal text, unless special markers are present
to indicate that they want to “glue programs, do variable substitution et cetera”. Notice your use of the term “variable substitution”, which is characteristic of a shell language: in a programming language, you don’t call it “substitution”, you call it “evaluation”.

A scripting language is a programming language made for a hypothetical machine, not too different from a programming language made for a real machine, one made of hardware.

In our CS classes we learned to think about “abstract machines”, and forget the distinction between “software” and “hardware”. Instead, we build layers of abstract machines, one on top of the other, getting more
and more specialized towards the particular class of problems we want to
solve at any particular time.

Command languages are just another such “abstract machine”, and the scripts we write in them are another layer on top.

The layering only stops when you get to a GUI; they can’t be used to build any further “machines” on top.

You seem to find trouble with using a programming language in a REPL.

I find REPLs annoying and inconvenient. If I want to do “scratchpad” programming, I do it in a Jupyter notebook.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 29.03.2024 21:59, Lawrence D'Oliveiro wrote:

On Fri, 29 Mar 2024 10:37:22 +0100, Janis Papanagnou wrote:

Program text is initially text.[*] During parsing (either in
an interpreted or in a compiled language) you split the text
in tokens.

And then, how do you interpret the tokens?

In an interpreter the tokens are interpreted, in a compiler
they are subject to the parsing. (But you know that I'm sure.)

What I was saying is that there's initially literal program text
that is transformed to tokens in the lexical analysis, and then
further processed.

It was a reply on your original statement which was:

In a shell language, everything you type is assumed to be a
literal string, unless you use special substitution sequences.

In a shell language, you have
the assumption that “everything is literal text until indicated otherwise”;

Who is that "you"? (Not me, for sure.) And where did you get that
from?

in a programming language, you have the assumption that
“everything is a program construct until indicated otherwise”.

So what is 'for i in a ; do ... ; done' then in your world?

This is one of many basic shell constructs that I use in shell
programming (not "shell scripting") regularly.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 29.03.2024 19:51, David W. Hodgins wrote:

The distinctions between script and programming languages made sense when they were first introduced. [...]

I abandoned the term "shell script" as soon as I got aware that
writing a reliable piece of software with "scripts" follows the
same engineering techniques and requires the same quality means
as non-"scripts". (Occasionally I still use the term informally
though I don't see any formal, technical, or practical necessity
for any such distinction between Command and Programming Language
as far as _programming_ is concerned.)

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 30.03.2024 00:14, Janis Papanagnou wrote:

On 29.03.2024 21:59, Lawrence D'Oliveiro wrote:

On Fri, 29 Mar 2024 10:37:22 +0100, Janis Papanagnou wrote:

Program text is initially text.[*] During parsing (either in
an interpreted or in a compiled language) you split the text
in tokens.

And then, how do you interpret the tokens?

In an interpreter the tokens are interpreted, in a compiler
they are subject to the parsing. [...]

Just noticed that this may be misleading. Of course the shell
does also a syntax analysis step and report syntax errors. So
don't get me wrong here.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sat, 30 Mar 2024 00:14:42 +0100, Janis Papanagnou wrote:

What I was saying is that there's initially literal program text
that is transformed to tokens in the lexical analysis, and then
further processed.

In a shell language, that is “further processed” as literal text, except for any instances of substitution markers.

in a programming language, you have the assumption that
“everything is a program construct until indicated otherwise”.

So what is 'for i in a ; do ... ; done' then in your world?

“for” is just the name of a command, like any other. In POSIX, this one happens to be built into the shell; it might not in other shells.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 29.03.2024 21:59, Lawrence D'Oliveiro wrote:

On Fri, 29 Mar 2024 10:37:22 +0100, Janis Papanagnou wrote:

Program text is initially text.[*] During parsing (either in
an interpreted or in a compiled language) you split the text
in tokens.

And then, how do you interpret the tokens?

In an interpreter the tokens are interpreted, in a compiler
they are subject to the parsing. (But you know that I'm sure.)

Are you suggesting that interpreters don't parse their input? No doubt
there are interpreters that handle tokens one at a time, but shells
typically don't work that way.

There are a lot of different ways to distinguish between languages like sh/ksh/bash that are normally interpreted and languages like C that are normally compiled to machine code:

- Is the language primarily designed for interactive command-line use?
- Is the language normally compiled to machine code?
- Is the language compiled by some kind of byte code that is then
interpreted? Is that byte code *sometimes* translated to machine
code?
- Is foo treated by default as a string or as an identifier?
(Treating it as a string is convenient for interactive use.)
- Does a syntax error on line 10 prevent lines 1-9 from being executed?

I don't think *any* of these distinctions are fundamental.

For example, a Perl or Python program/script is parsed and "compiled"
into some in-memory form before execution begins. A syntax error
prevents the entire script from being executed. In Bourne-line shells,
a syntax error won't be detected until execution reaches that line.
(Things like Perl's BEGIN and eval can complicate things.)

Shells also have to parse their input, though it's done a bit
differently. Typically the entire script isn't parsed as a unit.

[...]

So what is 'for i in a ; do ... ; done' then in your world?

This is one of many basic shell constructs that I use in shell
programming (not "shell scripting") regularly.

I use it both in shell scripting/programming and interactively.

And the entire construct needs to be processed before the shell can
begin to execute it. Misspelling "done" prevents the whole thing from
running.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 30.03.2024 00:14, Janis Papanagnou wrote:

On 29.03.2024 21:59, Lawrence D'Oliveiro wrote:

On Fri, 29 Mar 2024 10:37:22 +0100, Janis Papanagnou wrote:

Program text is initially text.[*] During parsing (either in
an interpreted or in a compiled language) you split the text
in tokens.

And then, how do you interpret the tokens?

In an interpreter the tokens are interpreted, in a compiler
they are subject to the parsing. [...]

Just noticed that this may be misleading. Of course the shell
does also a syntax analysis step and report syntax errors. So
don't get me wrong here.

I did indeed get you wrong here (see my other followup).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 30.03.2024 01:03, Keith Thompson wrote:

Just noticed that this may be misleading. Of course the shell
does also a syntax analysis step and report syntax errors. So
don't get me wrong here.

I did indeed get you wrong here (see my other followup).

Sorry for the inconvenience!

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sat, 30 Mar 2024 00:14:42 +0100, Janis Papanagnou wrote:

What I was saying is that there's initially literal program text
that is transformed to tokens in the lexical analysis, and then
further processed.

In a shell language, that is “further processed” as literal text, except for any instances of substitution markers.

in a programming language, you have the assumption that
“everything is a program construct until indicated otherwise”.

So what is 'for i in a ; do ... ; done' then in your world?

“for” is just the name of a command, like any other. In POSIX, this one happens to be built into the shell; it might not in other shells.

"for" is not just a command. It's a keyword, part of the shell language syntax.

By contrast, "echo" is a command that may be built into the shell or
not, and behaves similarly either way. There's no way to implement
"for" as an external command.

(Very early UNIX shells had "goto" as an external command. The
implementation was convoluted.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:

A scripting language is a programming language made for a hypothetical >>machine, not too different from a programming language made for a real >>machine, one made of hardware.

C is clearly a programming language, yet its specification
says, "The semantic descriptions in this document describe
the behavior of an abstract machine". And you cannot buy
this abstract C machine as a piece of hardware anywhere!

Of course. :) But we both know what that means. It's abstract because
there are so many real machines for which this abstract one is an
abstraction of. And the real ones are the target of the language.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 29 Mar 2024 08:09:46 -0300, Johanne Fairchild wrote:

Consider looking at a shell language like a domain-specific programming
language. A shell is a programming language made specifically for
running programs. ... (Of course, the idea evolves and you want to
glue programs, do variable substitution et cetera.)

That’s the thing. The design for a “language made specifically for running
programs” always seems to start with the assumption that what the user types is to be passed as literal text, unless special markers are present
to indicate that they want to “glue programs, do variable substitution et cetera”. Notice your use of the term “variable substitution”, which is characteristic of a shell language: in a programming language, you don’t call it “substitution”, you call it “evaluation”.

That's right. Substitution is evaluation; a specific form of.

You seem to find trouble with using a programming language in a REPL.

I find REPLs annoying and inconvenient. If I want to do “scratchpad” programming, I do it in a Jupyter notebook.

That's something to think about. Your perception is wildly different
from a lot of people who have thought and think very deeply about the
whole craft.

Consider your Lisp writing, which violates the culture of Lisp writing.
Of course you should keep your independence, but maybe there are good
reasons why the culture is as it is---not all culture is fashion.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 30.03.2024 00:51, Lawrence D'Oliveiro wrote:

On Sat, 30 Mar 2024 00:14:42 +0100, Janis Papanagnou wrote:

So what is 'for i in a ; do ... ; done' then in your world?

“for” is just the name of a command, like any other. In POSIX, this one happens to be built into the shell; it might not in other shells.

'for' is a "reserved word" and part of a "compound command". It's
part of the _shell syntax_! - You get syntax errors like

$ for ; do : ; done
ksh: syntax error: `;' unexpected

And, specifically, "i in a" are *not* arguments of a 'for' command
but also part of the control construct syntax.

But, okay, I see where you're coming from.

Besides the naming, keep in mind that there's a semantical differences
between a "command", a "built-in command", and "shell construct". An
example where you can observe operational differences is:
'/bin/test' and '/bin/['
'test' and '['
'[['
where (for example) the latter does not need quoting.

$ x="Hello world" ; [[ $x == "Hello world" ]] ; echo $?
0
$ x="Hello world" ; [ $x == "Hello world" ] ; echo $?
ksh: [: world: unknown operator
2
$ x="Hello world" ; [ "$x" == "Hello world" ] ; echo $?
0

The distinction is important since there's operational differences
associated with these forms. The same holds for other control constructs ("built-in compound commands"), like 'case', or even simple assignments.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 30.03.2024 01:01, Keith Thompson wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

So what is 'for i in a ; do ... ; done' then in your world?

This is one of many basic shell constructs that I use in shell
programming (not "shell scripting") regularly.

I use it both in shell scripting/programming and interactively.

So do I. (To me there's no significant difference. Only that larger
projects I do not start to develop in interactive mode, of course.)

And the entire construct needs to be processed before the shell can
begin to execute it. Misspelling "done" prevents the whole thing from running.

Indeed.

From the other posters statements I got the impression that he may
think that control constructs is what makes the difference (between
scripting and programming, or, command interpreters and programming
languages; still not sure what he thinks). In a later post I read
it as if the naming of e.g. 'for' as a "command" leads to his view.
Anyway.

I can see a point where people use for interactive use other shells
than for programming; like tcsh (interactively) and bash (programming),
because of the powerful features tcsh supports. Since the increase of interactive features supported by the shells that are typically used
for programming I prefer to have the same shell with same syntax and
features for both, and to be able to pass code from one application
context to the other.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

I can see a point where people use for interactive use other shells
than for programming; like tcsh (interactively) and bash (programming), because of the powerful features tcsh supports. Since the increase of interactive features supported by the shells that are typically used
for programming I prefer to have the same shell with same syntax and
features for both, and to be able to pass code from one application
context to the other.

Indeed. I spent several years using tcsh interactively (because it had
a few interactive features that I found convenient) and bash for writing scripts (previously I had actually written *gasp* csh and tcsh scripts). Eventually I found that using a single shell for both was easier, and
that bash's interactive features are about as good as tcsh's. (And I
can write complex nested commands on one line, something I probably
wouldn't have attempted in [t]csh even if it were possible.) I haven't
looked back.

zsh has some nice features, but I haven't learned it well enough to
consider switching.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 21:24:01 -0300, Johanne Fairchild wrote:

Consider your Lisp writing, which violates the culture of Lisp writing.
Of course you should keep your independence, but maybe there are good
reasons why the culture is as it is---not all culture is fashion.

Let me know what they are. The only reasons I have seen offered so far are basically just “that’s the way it’s always been done”.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 17:08:35 -0700, Keith Thompson wrote:

"for" is not just a command. It's a keyword, part of the shell language syntax.

Remember, that’s only true of POSIX shells.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 29 Mar 2024 17:08:35 -0700, Keith Thompson wrote:

"for" is not just a command. It's a keyword, part of the shell language
syntax.

Remember, that’s only true of POSIX shells.

It may well be true of some non-POSIX shells as well (not that it
matters).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sat, 30 Mar 2024 01:30:53 +0100, Janis Papanagnou wrote:

Besides the naming, keep in mind that there's a semantical differences between a "command", a "built-in command", and "shell construct". An
example where you can observe operational differences is:
'/bin/test' and '/bin/['
'test' and '['
'[['
where (for example) the latter does not need quoting.

I know that there are places in POSIX shells where the usual rules for interpretation of special-substitution markers are altered or suspended.
But those situations are always delimited in some special way (distinctive syntactic constructs or reserved words). Throughout the entire rest of the language, the principles I have described still apply.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 29 Mar 2024 17:08:35 -0700, Keith Thompson wrote:

"for" is not just a command. It's a keyword, part of the shell language
syntax.

Remember, that’s only true of POSIX shells

Not necessarily. Bash is not a POSIX shell. It can be,
but without special configuration it is not POSIX.

ksh is as close as one might get to a true POSIX shell,
but even ksh has extensions.

But nitpicking aside, the context of the discussion that
you responded to was about clearly POSIX-like shells.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 15:38:48 -0400, Johanne Fairchild <jfairchild@tudado.org> wrote:

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

[...]

The terminology will continue to be used, but the distinction does not
matter, except from a speed of processing difference.

Just to share that I, personally, don't use the distinction. For
instance, I say that

"the answer is %.2f\n"

is a program that builds a string given its usual context. I say that

awk '1; { print "" }'

is a program to double-space a file. I haven't said ``script'' in
years.

I still refer to text files, intended to be run through an interpreter such
as bash, as scripts, while things like c text files that must be compiled to
an object file and then linked to be executable as programs.

Regards, Dave Hodgins
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted: >ram@zedat.fu-berlin.de (Stefan Ram) writes:

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:

A scripting language is a programming language made for a hypothetical >>>machine, not too different from a programming language made for a real >>>machine, one made of hardware.

C is clearly a programming language, yet its specification
says, "The semantic descriptions in this document describe
the behavior of an abstract machine". And you cannot buy
this abstract C machine as a piece of hardware anywhere!

Of course. :) But we both know what that means. It's abstract because
there are so many real machines for which this abstract one is an
abstraction of. And the real ones are the target of the language.

If you want to see it this way ...

But look at Pascal, Java, or Python. They are usually compiled
into an intermediate code (called "p-code" in the case of
Pascal) which is then interpreted (the interpreter is called
"JVM" in the case of Java). Yet, we think of Pascal and Java
as programming languages and of Python as a scripting language.

But this is actually an implementation detail: Java also can
be compiled into machine code.

In any case, we can write a small batch file "execute" which
can be called for source code in any programming language and
will execute it:

execute Main.pas
execute Main.java
execute Main.py
execute main.c
execute main.cpp
execute main.bas
execute main.bat
...

They all will print "Hello World". Whether the execution happens
via translation to machine code or via interpretation by another
program or by a mixture of both is just an implementation
detail of "execute", that usually will not matter much for the
programmer. And often for the same language, one is free to
either compile it to machine language or interpret it via another
program.

Some language, like LISP or Python, have "eval": These languages
still can be compiled, but they require an interpreter at run-
time. Java often is executed by interpretation first, but when
the "Hotspot" interpreter sees that some code is executed often,
it will then decide /at run-time/ to compile it into actual
machine code! (And there are Python implementations that run
on the JVM.)

How can such implementation details matter for the question whether
a language is called a programming language or a scripting language,
when the programmer often does not even need to know about them?

Yes, there also are C interpreters IIRC, but they are rare.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 17:25:18 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote: >>>Scripting is an activity, a use case, not a language.

So if I write a program to for example process some files in a directory by >> your argument its a script whether I write it in shell, python, C++ or
assembler.

I also wrote: "Scripting refers to executing commands which are so high
level that they are entire applications or functional blocks within an >application."

So if I write:

int main()
{
system("ls | wc -l");
return 0;
}

Thats a script? No? What if I use popen() or execve() then? Where do you
draw the line?

You're just being deliberately obtuse, not to mention snippy with the >scissors.

I'm not being obtuse. There is no hard dividing line between scripts and programs - as I said, its shades of grey.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 29 Mar 2024 17:58:41 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

Were the mucky bits actually written in Lisp or was Lisp simply calling some >> routines written in assembler?

Sorry, could you demarcate where exactly the goalposts are? Which mucky
bits?

Oh I dunno, the parts that walk a kernel memory structure for example.

In kernels written in C, there are mucky bits in assembler, like
entry and exit into an trap/interrupt handler. You usually can't save

Sure, but far less that there would be in a higher level language.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 30.03.2024 08:47, Stefan Ram wrote:

But look at Pascal, Java, or Python. They are usually compiled
into an intermediate code (called "p-code" in the case of
Pascal) which is then interpreted (the interpreter is called
"JVM" in the case of Java). Yet, we think of Pascal and Java
as programming languages and of Python as a scripting language.

I never used an interpreted Pascal, nor one that produced p-code.
(As far as memory serves it was the UCSD Pascal dialect that
decided to use intermediate code to be interpreted.) My Pascal
programs have always been compiled.

And there were BASIC compilers on mainframes before the BASIC
interpreters on PCs became popular and widespread.

It's _the same_ language (modulo dialects), and languages are
usually defined by their grammar and semantics and not whether
it is interpreted/compiled or how it is run (VM or else).

I think it's obvious that interpretation vs. compilation or any
intermediate interpreted p-code is not an appropriate criterion
to declare something as a "scripting" language. You can't tell
whether a language, Pascal, BASIC, or any other language, is a
"scripting" language by that criterion. It's also generally a
fuzzy term; literature speaks vaguely about "typical" criteria
but cannot pin them down. - And that term isn't even helpful in
any way! - So why use it at all or religiously dispute about it.

Janis

But this is actually an implementation detail: Java also can
be compiled into machine code.

[...]

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 30.03.2024 11:16, Muttley@dastardlyhq.com wrote:

I'm not being obtuse. There is no hard dividing line between scripts and programs - as I said, its shades of grey.

The terms "script" and "scripting languages" are very fuzzy and
just trying to be descriptive, but are effectively meaningless,
the terms don't serve any practical purpose (in my book).

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-29 02:14, Lawrence D'Oliveiro wrote:

At one time, we distinguished between “scripting” languages and “programming” languages. To begin with, the “scripting” languages were
somehow more limited in functionality than full-fledged “programming” languages. Or they were slower, because they were interpreted.

[...]

The key difference is that a program in a scripting language need not to
be complete or known in order to be executed.

The limitations and ugliness of scripting languages is determined by
this requirement, but also easiness of use.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-30, Stefan Ram <ram@zedat.fu-berlin.de> wrote:

But look at Pascal, Java, or Python. They are usually compiled
into an intermediate code (called "p-code" in the case of
Pascal) which is then interpreted

Pascal is usually compiled to machine code. UCSD Pascal with its
intermediate p-code was an atypical case.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-30, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 17:25:18 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote: >>>>Scripting is an activity, a use case, not a language.

So if I write a program to for example process some files in a directory by
your argument its a script whether I write it in shell, python, C++ or
assembler.

I also wrote: "Scripting refers to executing commands which are so high >>level that they are entire applications or functional blocks within an >>application."

So if I write:

int main()
{
system("ls | wc -l");
return 0;
}

Thats a script?

The "ls | wc -l" part is a script, passed off for execution to a
language that mainly supports scripting.

Note the non-scripting features here like "int main",
which doesn't /do/ anything, and typically the need to compile
and link this in order to run it.

system() itself also isn't quite "command which is so high level that
it's an inter application or functional block within an application";
it's a shim whose argument might be such a command.

No? What if I use popen() or execve() then? Where do you
draw the line?

If you use popen and execve, you're using more systems programming
functional blocks that are not scripting commands.

You're just being deliberately obtuse, not to mention snippy with the >>scissors.

I'm not being obtuse. There is no hard dividing line between scripts and

Right now you're doubling down on obtusity, by my estimate.

programs - as I said, its shades of grey.

Would you say, fifty shades?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 29/03/2024 17:02, Muttley@dastardlyhq.com wrote:

On Fri, 29 Mar 2024 08:44:54 -0700
John Ames <commodorejohn@gmail.com> wrote:

On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

My rule of thimb is that a scripting language is one whereby the
source code can be run immediately by the interpreter, eg perl,
python, regardless of what happens internally. A full fledged
programming language is one that requires a compile/debug/link step
first with the compiler and runtime (if required) being seperate. eg
Java, C

By *that* logic, even Lisp and Forth don't count as "full-fledged
programming languages" o_O Johanne's definition of a "scripting

As a counter point, good luck writing a device driver in lisp. Forth maybe, no idea.

"Open Firmware" is an attempt to have device drivers for PCI cards (and
other hardware) included in flash on the cards, in a processor and
platform independent way. It uses Forth - so the device drivers are
provided as Forth source code or byte-compiled Forth, and can then be
executed with a simple Forth VM on the target system. They can also be
JIT compiled for the target.

<https://en.wikipedia.org/wiki/Open_Firmware>

It didn't really take off very well, but certainly people have written
device drivers in Forth.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-30, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 17:58:41 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

Were the mucky bits actually written in Lisp or was Lisp simply calling some
routines written in assembler?

Sorry, could you demarcate where exactly the goalposts are? Which mucky >>bits?

Oh I dunno, the parts that walk a kernel memory structure for example.

Well, since the kernel is written in Lisp, of course Lisp walks its own
data structures.

In a kernel, there often occur externally imposed memory structures,
like for instance lists of entries in a DMA buffer ring above an
ethernet device. Or banks of registers.

The kernel-writing Lisp dialect would have provisions for dealing
with binary structures like that.

The following example is not from a Lisp operating system, or a Lisp
that is known for operating system work. It's from my own application.

It shows how in CCL (Clozure Common Lisp) (note: note the Z, not Clojure
with a J) we can obtain a linked list C data structure and walk it,
using some CCL-specific concepts; CCL provides #> notations for C
types, and offsets into C structures and such.

The GetAdaptersInfo Win32 API is called, filling the list into a stack-allocated buffer, with the help of CCL's %stack-block operator.
We get a list of adapters, each of which is a list consisting of
a list of the mac bytes, IP address list, name and description.

(The information is then encrypted, hashed and tied to a software license, along with other bits of system info.)

(defun get-network-interface-list ()
(open-shared-library "iphlpapi.dll")
(let ((blk-size 65536) ;; crude!
(get-adapters-info (foreign-symbol-address "GetAdaptersInfo")))
(if get-adapters-info
(%stack-block ((blk blk-size))
(rlet ((len-inout #>ULONG blk-size))
(if (zerop (ff-call get-adapters-info :address blk
:address len-inout
#>DWORD))
(loop for ptr = blk then (pref ptr #>IP_ADAPTER_INFO.Next)
until (%null-ptr-p ptr)
collecting
(let ((alen (pref ptr #>IP_ADAPTER_INFO.AddressLength))
(addr (pref ptr #>IP_ADAPTER_INFO.Address))
(aname (pref ptr #>IP_ADAPTER_INFO.AdapterName))
(descr (pref ptr #>IP_ADAPTER_INFO.Description))
(iplist (pref ptr #>IP_ADAPTER_INFO.IpAddressList))
(type (pref ptr #>IP_ADAPTER_INFO.Type)))
(list type
(loop for i below alen
collecting (%get-unsigned-byte addr i)
into mac-bytes
finally
(return (mac-bytes-to-string mac-bytes)))
(get-ip-address-list iplist)
(%get-cstring aname)
(%get-cstring descr))))))))))

CCL is compiled; this just turns into a machine language function
poking at stack memory.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted: >>ram@zedat.fu-berlin.de (Stefan Ram) writes:

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:

A scripting language is a programming language made for a hypothetical >>>>machine, not too different from a programming language made for a real >>>>machine, one made of hardware.

C is clearly a programming language, yet its specification
says, "The semantic descriptions in this document describe
the behavior of an abstract machine". And you cannot buy
this abstract C machine as a piece of hardware anywhere!

Of course. :) But we both know what that means. It's abstract because >>there are so many real machines for which this abstract one is an >>abstraction of. And the real ones are the target of the language.

If you want to see it this way ...

But look at Pascal, Java, or Python. They are usually compiled
into an intermediate code (called "p-code" in the case of
Pascal) which is then interpreted (the interpreter is called
"JVM" in the case of Java). Yet, we think of Pascal and Java
as programming languages and of Python as a scripting language.

VAX Pascal (1980) was compiled directly to VAX machine code, as was
the Pascal compiler I wrote in the graduate compiler class.

UCSD Pascal used p-code, and IIRC Borland picked up
on that.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Muttley@dastardlyhq.com writes:

On Fri, 29 Mar 2024 17:25:18 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote: >>>>Scripting is an activity, a use case, not a language.

So if I write a program to for example process some files in a directory by
your argument its a script whether I write it in shell, python, C++ or
assembler.

I also wrote: "Scripting refers to executing commands which are so high >>level that they are entire applications or functional blocks within an >>application."

So if I write:

int main()
{
system("ls | wc -l");
return 0;
}

Thats a script? No? What if I use popen() or execve() then? Where do you
draw the line?

Technically, only the 'ls | wc -l' is a script. One that is passed
to the default SHELL.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-30, David Brown <david.brown@hesbynett.no> wrote: ><https://en.wikipedia.org/wiki/Open_Firmware>

It didn't really take off very well, but certainly people have written device drivers in Forth.

Unfortunately, the device tree crap from Open Firmware took off.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

On 2024-03-29 02:14, Lawrence D'Oliveiro wrote:

At one time, we distinguished between “scripting” languages and
“programming” languages. To begin with, the “scripting” languages were
somehow more limited in functionality than full-fledged “programming”
languages. Or they were slower, because they were interpreted.

[...]

The key difference is that a program in a scripting language need not
to be complete or known in order to be executed.

The limitations and ugliness of scripting languages is determined by
this requirement, but also easiness of use.

Perl, Python, and Lua are all considered scripting languages, and for
all of them a syntax error at the end of a script will prevent any of it
from being executed. The distinction is that they're not optimized for interactive use, as shell languages are (though they all can be used interactively).

If you want to say that Python isn't a scripting language because of
that, I won't argue, but others will.

There are a lot of dividing lines (compiled to machine code vs. compiled
to byte code (on each execution or just once) vs. interpreted (perhaps
with JIT), interactive vs. batch, strong vs. weak typing, static
vs. dynamic typing, etc.). None of them are rigorously defined, and
none of them particularly need to be.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-30, Scott Lurndal <scott@slp53.sl.home> wrote:

VAX Pascal (1980) was compiled directly to VAX machine code, as was
the Pascal compiler I wrote in the graduate compiler class.

UCSD Pascal used p-code, and IIRC Borland picked up
on that.

Borland's Turbo Pascal compiled to machine code.
--
Christian "naddy" Weisgerber naddy@mips.inka.de
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-03-30 22:28, Keith Thompson wrote:

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

On 2024-03-29 02:14, Lawrence D'Oliveiro wrote:

At one time, we distinguished between “scripting” languages and
“programming” languages. To begin with, the “scripting” languages were
somehow more limited in functionality than full-fledged “programming” >>> languages. Or they were slower, because they were interpreted.

[...]

The key difference is that a program in a scripting language need not
to be complete or known in order to be executed.

The limitations and ugliness of scripting languages is determined by
this requirement, but also easiness of use.

Perl, Python, and Lua are all considered scripting languages, and for
all of them a syntax error at the end of a script will prevent any of it
from being executed. The distinction is that they're not optimized for interactive use, as shell languages are (though they all can be used interactively).

I was not talking about [syntactically] incorrect incomplete programs.
In a scripting language an incomplete program can be correct and
executable. E.g. I type in bash:

ls

This is only a part of my program. Because then I inspect the output and
type:

rm foo.bar

After that I turn off the computer. My program is complete now.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sat, 30 Mar 2024 00:14:42 +0100, Janis Papanagnou wrote:

So what is 'for i in a ; do ... ; done' then in your world?

ldo@theon:~> for i in a b c; do echo i; done
i
i
i

Like I said, in a shell language, you have the assumption that “everything is literal text until indicated otherwise”.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sat, 30 Mar 2024 18:10:36 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-30, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

I also wrote: "Scripting refers to executing commands which are so high >>>level that they are entire applications or functional blocks within an >>>application."

So if I write:

int main()
{
system("ls | wc -l");
return 0;
}

Thats a script?

The "ls | wc -l" part is a script, passed off for execution to a
language that mainly supports scripting.

So its not a script.

Note the non-scripting features here like "int main",
which doesn't /do/ anything, and typically the need to compile
and link this in order to run it.

There may be plenty of surrounding code that does do something.

No? What if I use popen() or execve() then? Where do you
draw the line?

If you use popen and execve, you're using more systems programming
functional blocks that are not scripting commands.

They both call high level commands so is it scripting or programming?

I'm not being obtuse. There is no hard dividing line between scripts and

Right now you're doubling down on obtusity, by my estimate.

Perhaps you don't understand what being obtuse actually means.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sat, 30 Mar 2024 18:46:50 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

(defun get-network-interface-list ()
(open-shared-library "iphlpapi.dll")
(let ((blk-size 65536) ;; crude!
(get-adapters-info (foreign-symbol-address "GetAdaptersInfo")))
(if get-adapters-info
(%stack-block ((blk blk-size))
(rlet ((len-inout #>ULONG blk-size))
(if (zerop (ff-call get-adapters-info :address blk
:address len-inout
#>DWORD))
(loop for ptr = blk then (pref ptr #>IP_ADAPTER_INFO.Next)
until (%null-ptr-p ptr)
collecting
(let ((alen (pref ptr #>IP_ADAPTER_INFO.AddressLength))
(addr (pref ptr #>IP_ADAPTER_INFO.Address))
(aname (pref ptr #>IP_ADAPTER_INFO.AdapterName))
(descr (pref ptr #>IP_ADAPTER_INFO.Description))
(iplist (pref ptr #>IP_ADAPTER_INFO.IpAddressList))

(type (pref ptr #>IP_ADAPTER_INFO.Type)))
(list type
(loop for i below alen
collecting (%get-unsigned-byte addr i)
into mac-bytes
finally
(return (mac-bytes-to-string mac-bytes)))

(get-ip-address-list iplist)
(%get-cstring aname)
(%get-cstring descr))))))))))

Ugh. No wonder the language fell out of fashion. Looks like some kind of hacked up Basic.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Muttley@dastardlyhq.com writes:

On Sat, 30 Mar 2024 18:46:50 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

(defun get-network-interface-list ()
(open-shared-library "iphlpapi.dll")
(let ((blk-size 65536) ;; crude!
(get-adapters-info (foreign-symbol-address "GetAdaptersInfo")))
(if get-adapters-info
(%stack-block ((blk blk-size))
(rlet ((len-inout #>ULONG blk-size))
(if (zerop (ff-call get-adapters-info :address blk
:address len-inout
#>DWORD))
(loop for ptr = blk then (pref ptr #>IP_ADAPTER_INFO.Next)
until (%null-ptr-p ptr)
collecting
(let ((alen (pref ptr #>IP_ADAPTER_INFO.AddressLength)) >> (addr (pref ptr #>IP_ADAPTER_INFO.Address))
(aname (pref ptr #>IP_ADAPTER_INFO.AdapterName)) >> (descr (pref ptr #>IP_ADAPTER_INFO.Description)) >> (iplist (pref ptr #>IP_ADAPTER_INFO.IpAddressList))

(type (pref ptr #>IP_ADAPTER_INFO.Type)))
(list type
(loop for i below alen
collecting (%get-unsigned-byte addr i)
into mac-bytes
finally
(return (mac-bytes-to-string mac-bytes)))

(get-ip-address-list iplist)
(%get-cstring aname)
(%get-cstring descr))))))))))

Ugh. No wonder the language fell out of fashion. Looks like some kind of hacked up Basic.

Fashion and intelligence have never been very good friends.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:

A scripting language is a programming language made for a hypothetical >machine, not too different from a programming language made for a real >machine, one made of hardware.

I think of the type system:

In a non-scripting programming language, the types often are
based on hardware, like "16 bit integer", and typing is often
handled in a static and rather strict way. Higher types, like
strings whose size can change at run time, are often missing.

Scripting languages are often less strictly typed, some rely entirely
on strings which are interpreted as integers if necessary. Often
one has no control over the internal represention of data, so one
cannot access a library using the ABI or write a device driver in a
scripting language. Explicit type conversions are rarely required.

Also, resource handling:

Scripting languages handle the memory for you. In a scripting
language, you cannot call "malloc" to obtain the obligation to
free this piece of memory exactly once in the future. They are
garbage collected.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Mon, 01 Apr 2024 06:49:48 -0300
Johanne Fairchild <jfairchild@tudado.org> wrote:

Muttley@dastardlyhq.com writes:

On Sat, 30 Mar 2024 18:46:50 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

(defun get-network-interface-list ()
(open-shared-library "iphlpapi.dll")
(let ((blk-size 65536) ;; crude!
(get-adapters-info (foreign-symbol-address "GetAdaptersInfo")))
(if get-adapters-info
(%stack-block ((blk blk-size))
(rlet ((len-inout #>ULONG blk-size))
(if (zerop (ff-call get-adapters-info :address blk
:address len-inout
#>DWORD))
(loop for ptr = blk then (pref ptr #>IP_ADAPTER_INFO.Next)
until (%null-ptr-p ptr)
collecting
(let ((alen (pref ptr #>IP_ADAPTER_INFO.AddressLength))

(addr (pref ptr #>IP_ADAPTER_INFO.Address))
(aname (pref ptr #>IP_ADAPTER_INFO.AdapterName)) >>> (descr (pref ptr #>IP_ADAPTER_INFO.Description)) >>> (iplist (pref ptr >#>IP_ADAPTER_INFO.IpAddressList))

(type (pref ptr #>IP_ADAPTER_INFO.Type)))
(list type
(loop for i below alen
collecting (%get-unsigned-byte addr i) >>> into mac-bytes
finally
(return (mac-bytes-to-string >mac-bytes)))

(get-ip-address-list iplist)
(%get-cstring aname)
(%get-cstring descr))))))))))

Ugh. No wonder the language fell out of fashion. Looks like some kind of
hacked up Basic.

Fashion and intelligence have never been very good friends.

Readability of the flow of control matters. God knows whats going on with
all those nested statements.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fr 29 Mär 2024 at 17:20, Muttley@dastardlyhq.com wrote:

On Fri, 29 Mar 2024 17:13:47 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Fri, 29 Mar 2024 08:44:54 -0700
John Ames <commodorejohn@gmail.com> wrote:

On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

My rule of thimb is that a scripting language is one whereby the
source code can be run immediately by the interpreter, eg perl,
python, regardless of what happens internally. A full fledged
programming language is one that requires a compile/debug/link step
first with the compiler and runtime (if required) being seperate. eg >>>>> Java, C

By *that* logic, even Lisp and Forth don't count as "full-fledged >>>>programming languages" o_O Johanne's definition of a "scripting

As a counter point, good luck writing a device driver in lisp.

The Lisp machines had operating systems and device drivers written in
Lisp, interrupt-driven and all. Where do you perceive the difficulty?

Were the mucky bits actually written in Lisp or was Lisp simply calling some routines written in assembler? In the same sense that Python doesn't actually "do" AI, its way too slow, the AI but is done in libraries written in C++ that
Python simply calls.

It was Lisp all the way down. Even the machine langauge was quite lispy
simply because the processor was a lisp chip.
Go read about it - there is lots of info about it on the net and if you
want, you can even run the lisp machines (several implementations) on an emulator.

'Andreas
--
ceterum censeo redmondinem esse delendam
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 1 Apr 2024 14:16:33 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

In a non-scripting programming language, the types often are
based on hardware, like "16 bit integer", and typing is often
handled in a static and rather strict way. Higher types, like
strings whose size can change at run time, are often missing.

Notwithstanding the fuzziness granted by the use of "often" here, this
doesn't seem like a terribly accurate assessment. Lots of compiled/ "non-scripting" languages - *however* you define that - have dynamic
strings; even C++ provides that as part of the standard library
(admittedly, not as a basic language construct, but that's C for you -
*every* data structure is essentially pointers in a trenchcoat.) AFAIK
it's much rarer to *lack* that capability; C does, for aforementioned
reasons (although you can certainly roll your own,) O.G. Pascal did (as
a hideous misfeature,) probably a few other current systems languages...
but not many spring to mind.

It's also not terribly true that "non-scripting" languages are pre-
dominantly statically-typed. It's more common, certainly, but there are
still a number of compiled applications languages with some kind of
dynamic support. And while the division of number types into floating-
point and integer is very frequently the case, most language standards
don't specify word sizes that strictly (even in C, stdint.h wasn't
introduced until C99 - which lead to headaches of its own, as anyone
who's tried to run old code that makes assumptions about sizeof(int) on
targets that break those assumptions can attest.) Plenty of "non-
scripting" languages include or can be extended with support for
arbitrary bignum types, as well.

Scripting languages handle the memory for you. In a scripting
language, you cannot call "malloc" to obtain the obligation to
free this piece of memory exactly once in the future. They are
garbage collected.

And while this is pretty true of scripting languages, it doesn't make
for a good point-of-contrast with "non-scripting" languages; *piles* of
them include support for automatic memory management, and some (outside
of the C family) don't even include facilities for doing it "by hand."

Overall, this seems like a very narrow and C-centric view of programming language design - and while C is definitely *my* language-of-choice for application development,* let's not pretend it's the absolute be-all
and end-all, as if there *could* be such a thing in a field as vast and
diverse as this!

* (Funnily enough, for a lot of "scripting" type jobs, my go-to is
actually a compiled language - FreeBasic.)

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-04-01, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:

On Mon, 01 Apr 2024 06:49:48 -0300
Johanne Fairchild <jfairchild@tudado.org> wrote:

Muttley@dastardlyhq.com writes:

On Sat, 30 Mar 2024 18:46:50 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:

(defun get-network-interface-list ()
(open-shared-library "iphlpapi.dll")
(let ((blk-size 65536) ;; crude!
(get-adapters-info (foreign-symbol-address "GetAdaptersInfo"))) >>>> (if get-adapters-info
(%stack-block ((blk blk-size))
(rlet ((len-inout #>ULONG blk-size))
(if (zerop (ff-call get-adapters-info :address blk
:address len-inout
#>DWORD))
(loop for ptr = blk then (pref ptr #>IP_ADAPTER_INFO.Next) >>>> until (%null-ptr-p ptr)
collecting
(let ((alen (pref ptr #>IP_ADAPTER_INFO.AddressLength))

(addr (pref ptr #>IP_ADAPTER_INFO.Address)) >>>> (aname (pref ptr #>IP_ADAPTER_INFO.AdapterName))
(descr (pref ptr #>IP_ADAPTER_INFO.Description))
(iplist (pref ptr >>#>IP_ADAPTER_INFO.IpAddressList))

(type (pref ptr #>IP_ADAPTER_INFO.Type)))
(list type
(loop for i below alen
collecting (%get-unsigned-byte addr i) >>>> into mac-bytes
finally
(return (mac-bytes-to-string >>mac-bytes)))

(get-ip-address-list iplist)
(%get-cstring aname)
(%get-cstring descr))))))))))

Ugh. No wonder the language fell out of fashion. Looks like some kind of >>> hacked up Basic.

Fashion and intelligence have never been very good friends.

Readability of the flow of control matters. God knows whats going on with
all those nested statements.

I didn't spend a lot of time on that code in the first place, and have
not looked it in over ten years; yet it's trivially easily readable to me.

Anyway, it's in a high level language, yet following a linked list of
structs obtained from a Win32 function, which the code fetches into
a buffer allocated efficiently on the native stack.

The whole thing is compiled into native code.

CCL's primitives for accessing the C stuff aren't pretty, but they are
helpful. It's nice that it has the parsed information about the struct
offsets, like #>IP_ADAPTER_INFO.AdapterName. I didn't have to define
that anywhere. I remember it was pretty easy to figure the primtiies
out from CCL's reference documentation. Easy to write, easy to read
a decade later.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

John Ames <commodorejohn@gmail.com> writes:

On 1 Apr 2024 14:16:33 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

Scripting languages handle the memory for you. In a scripting
language, you cannot call "malloc" to obtain the obligation to
free this piece of memory exactly once in the future. They are
garbage collected.

And while this is pretty true of scripting languages, it doesn't make
for a good point-of-contrast with "non-scripting" languages; *piles* of
them include support for automatic memory management, and some (outside
of the C family) don't even include facilities for doing it "by hand."

Indeed, and if you use the set (resources) rather than a member
of the set (memory), even scripting languages allocate resources and
must free them. E.g. temporary files, with some garbage collection
(/tmp cleaners).

Why is it important that there be a distinction between "scripting"
and "non-scripting" languages at all?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Mon, 01 Apr 2024 19:42:05 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Why is it important that there be a distinction between "scripting"
and "non-scripting" languages at all?

Oh, it's an interesting question from a general standpoint, and I think
you could make an argument that it'd be "useful" to someone trying to
determine what the right tool for a given job would be.* The problem
seems to be that *A.* we're arguing from several wildly different
definitions of "scripting language" - is it a matter of problem domain? Implementation details? Both? Phase of the moon? - and nobody seems to
want to budge on their preferred line, and *B.* even with a given
definition, it's not exactly a firm line.

* (Funny story - when I was a young'un first dabbling with computer programming, I got the impression that a lot of DOS games were written
in Batch, of all things, because that was how you invoked them, and
spent several confused days poring over the MS documentation trying to
figure out how they could've done it!)

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Mon, 1 Apr 2024 11:15:52 -0700
John Ames <commodorejohn@gmail.com> wrote:

And while this is pretty true of scripting languages, it doesn't make
for a good point-of-contrast with "non-scripting" languages; *piles*
of them include support for automatic memory management, and some
(outside of the C family) don't even include facilities for doing it
"by hand."

And, in fact, C actually does one specific bit of automatic memory
management itself - the stack, which may or may not even *be* a true
hardware stack (depending on the architecture,) and which is handled in
an entirely transparent fashion* by compiler-generated entry/exit code generated by the compiler for each function.

* (Until you go and pass a pointer to a local variable to some piece of
code that expects it to still be valid later, natch.)

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

John Ames <commodorejohn@gmail.com> wrote or quoted:

And, in fact, C actually does one specific bit of automatic memory
management itself - the stack, which may or may not even *be* a true
hardware stack (depending on the architecture,) and which is handled in
an entirely transparent fashion* by compiler-generated entry/exit code >generated by the compiler for each function.

This stack "management" is "limited" in C:

|Unfortunately, the notion of stack overflow is not mentioned
|by the standard or the standard’s rationale at all. This is
|very troublesome, as for most actual implementations stack
|overflow is a real problem.
...
|in a real C implementation, a call like f(10000000) will not
|return 10000000, but instead will crash with a message like
|"segmentation fault". Furthermore, stack overflow does not
|necessarily have to result in a crash with a nice error
|message, but might also overwrite non-stack parts of the
|memory (possibly putting the address of virus code there).
|Stack overflow even can occur without function calls. For
|example, the program int main(void) { int a[10000000]; }
...
"Subtleties of the ANSI/ISO C standard" (2012); Robbert
Krebbers, Freek Wiedijk; Radboud University Nijmegen.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 1 Apr 2024 21:13:42 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

This stack "management" is "limited" in C:

True enough, although as noted that's an implementation issue as much
as it is a limitation of the language spec. (I'm not sure how you could
handle that in a way that's both robust and reasonably C-ish...)

|Stack overflow even can occur without function calls. For
|example, the program int main(void) { int a[10000000]; }

But I did have to have a chuckle at this reminder of the days when "try
to allocate < 40 MB on the stack" meant "automatic segfault." A lotta
modern developers should've had to cut their teeth in an environment
like that...!

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Mon, 1 Apr 2024 08:32:48 -0000 (UTC), Muttley wrote:

Ugh. No wonder the language fell out of fashion. Looks like some kind of hacked up Basic.

The BASIC comparison is just ignorant, but a lot of the ugliness comes
from the traditional “parenthesis pileup” layout. I prefer to write my LISP code in a different way.

One of the key things about LISP is homoiconicity. That is, the language explicitly includes an AST representation made out of objects defined in
the language itself. This allows for a robust token-based macro facility,
for example. Contrast this with the fiddliness and fragility of #define in
C and C++, for example.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 1 Apr 2024 14:16:33 GMT, Stefan Ram wrote:

Scripting languages handle the memory for you.

If I were to link compiled C code against a runtime that includes a
garbage collector, would that turn it into a “scripting” language?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

John Ames <commodorejohn@gmail.com> writes:

On 1 Apr 2024 21:13:42 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

This stack "management" is "limited" in C:

True enough, although as noted that's an implementation issue as much
as it is a limitation of the language spec. (I'm not sure how you could >handle that in a way that's both robust and reasonably C-ish...)

Modern (64-bit) linux systems leave large buffer zones (unmapped addresses)
on either side of the stack; a stack overflow or underflow will
immediately fault if the RLIMIT_STACK value is exceeded.

|Stack overflow even can occur without function calls. For
|example, the program int main(void) { int a[10000000]; }

POSIX and linux systems support limiting the amount of address
space an individual users stack can consume. 8MB is the default
on many linux distributions.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

ram@zedat.fu-berlin.de (Stefan Ram) writes:

John Ames <commodorejohn@gmail.com> wrote or quoted:

And, in fact, C actually does one specific bit of automatic memory >>management itself - the stack, which may or may not even *be* a true >>hardware stack (depending on the architecture,) and which is handled in
an entirely transparent fashion* by compiler-generated entry/exit code >>generated by the compiler for each function.

This stack "management" is "limited" in C:

|Unfortunately, the notion of stack overflow is not mentioned
|by the standard or the standard’s rationale at all. This is
|very troublesome, as for most actual implementations stack
|overflow is a real problem.
...
|in a real C implementation, a call like f(10000000) will not
|return 10000000, but instead will crash with a message like
|"segmentation fault". Furthermore, stack overflow does not
|necessarily have to result in a crash with a nice error
|message, but might also overwrite non-stack parts of the
|memory (possibly putting the address of virus code there).
|Stack overflow even can occur without function calls. For
|example, the program int main(void) { int a[10000000]; }
...
"Subtleties of the ANSI/ISO C standard" (2012); Robbert
Krebbers, Freek Wiedijk; Radboud University Nijmegen.

Available online at :

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Mon, 1 Apr 2024 13:44:57 -0700, John Ames wrote:

... the stack, which may or may not even *be* a true
hardware stack (depending on the architecture,) ...

This reinforces the point I made elsewhere about abstract machines being layered on top of other abstract machines, such that the line between “hardware” and “software” really becomes arbitrary.

What constitutes a “true” hardware stack? Does it have to be a reserved area, like page 1 on the 6502 family? Does the use of a particular
register as a stack pointer have to be defined by the instruction set, or
just by the ABI, as in many RISC architectures?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Mon, 01 Apr 2024 19:42:05 GMT, Scott Lurndal wrote:

Why is it important that there be a distinction between "scripting" and "non-scripting" languages at all?

Particularly since the point of this thread is that there isn’t an
important one.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Muttley@dastardlyhq.com writes:

[...]

Readability of the flow of control matters. God knows whats going on with
all those nested statements.

You don't seem to much of a Lisp writer. Lisp writers have no problem
reading that indentation.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.

No.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Mon, 01 Apr 2024 18:18:32 -0700, Keith Thompson wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.

No.

Don’t quote so deeply, then.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:

You don't seem to much of a Lisp writer. Lisp writers have no problem >reading that indentation.

Well, there is the expression "write-only code", which shows
that a good Lisp writer may not necessarily be a good reader.

This is an example of LISP code:

( SETQ DIFF
( LAMBDA( X )
( COND
( ( ATOMP X )
( COND
( ( = X 'X )
1 )
( T
0 )))
( T
( COND
( ( =( CAR X )'SUM )
( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

. For someone who has not learned LISP, this is difficult to read,
/not/ because of the indentation, but because the words used have no
meaning for him. Without the indentation it would be harder to read.

It defines ("SETQ") the name "DIFF" to be a function ("LAMBDA")
of one argument ("X"). When called, the functions tests
("COND") whether X is an atom ("ATOMP X"). In this case,
if X is the letter "X" the result is one, otherwise it's zero.
If X is not a atom, but a sum, we will return the sum of the
DIFFs of the augend and the added. This calls the same function
as the one defined. Yes! In LISP a function may call itself!
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

( SETQ DIFF
( LAMBDA( X )
( COND
( ( ATOMP X )
( COND
( ( = X 'X )
1 )
( T
0 )))
( T
( COND
( ( =( CAR X )'SUM )
( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

In Python:

def diff( x ):
return 1 if x == 'x' else 0 if type( x )is str
else[ 'sum', diff( x[ 1 ]), diff( x[ 2 ])]
if x[ 0 ]== 'sum' else None

. An attempt at indentation:

def diff( x ):
return \
1 if x == 'x' else 0 \
if type( x )is str else \
[ 'sum', diff( x[ 1 ]), diff( x[ 2 ])] \
if x[ 0 ]== 'sum' else None

. In a multiple-returns style:

def diff( x ):
if type( x )is str:
if x == 'x':
return 1
else:
return 0
else:
if x[ 0 ]== 'sum':
return [ 'sum', diff( x[ 1 ]), diff( x[ 2 ])]

.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

def diff( x ):
return 1 if x == 'x' else 0 if type( x )is str
else[ 'sum', diff( x[ 1 ]), diff( x[ 2 ])]
if x[ 0 ]== 'sum' else None

Oops! That was one long line starting with "return";
it was wrapped by the newsreader, but is not correct
Python anymore when wrapped this way.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 4/1/24 15:42, Scott Lurndal wrote:
...

Why is it important that there be a distinction between "scripting"
and "non-scripting" languages at all?

I don't know, which is why this discussion bores me. But when people
aren't in agreement about the definition of a term, it's often useful to consider what you might want to say using the term - not what you want
to say about the definition, but what you want to say that can be
non-trivially derived from the definition. Then you should carefully
choose a definition for the term so that makes what you want to say
about it both true, and even more important, useful.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 4/1/24 20:57, Lawrence D'Oliveiro wrote:

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.

By that same logic, if water is good, more water should be better. Tell
that to someone who is drowning.
For that matter, tell it to my mother who had a dangerous drug
interaction involving a diuretic, while (unknown to her doctor) she was following a recommendation that she drink 8 glasses of water a day "for
her health". Look up hyponatremia.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Scott Lurndal <scott@slp53.sl.home> wrote at 22:40 this Monday (GMT):

John Ames <commodorejohn@gmail.com> writes:

On 1 Apr 2024 21:13:42 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

This stack "management" is "limited" in C:

True enough, although as noted that's an implementation issue as much
as it is a limitation of the language spec. (I'm not sure how you could >>handle that in a way that's both robust and reasonably C-ish...)

Modern (64-bit) linux systems leave large buffer zones (unmapped addresses) on either side of the stack; a stack overflow or underflow will
immediately fault if the RLIMIT_STACK value is exceeded.

It still protects writing to memory outside that buffer, right?
[snip]
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Tue, 2 Apr 2024 15:30:09 -0000 (UTC)
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
wrote:

It still protects writing to memory outside that buffer, right?
[snip]

"Protecting memory" doesn't mean "no page fault," though, just that it
won't scribble all over some other process's memory. But I am curious
how universally various freenix distributions these days just let the application segfault vs. using that as a cue to allocate additional
stack space; a quick test with WSL (Debian somethingorother) runs that
test without complaint, but I don't have a genuine *nix box to hand to
try it with.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

John Ames <commodorejohn@gmail.com> writes:

On Tue, 2 Apr 2024 15:30:09 -0000 (UTC)
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
wrote:

It still protects writing to memory outside that buffer, right?
[snip]

"Protecting memory" doesn't mean "no page fault," though, just that it
won't scribble all over some other process's memory.

The regions each side of the stack are marked not-present. This supports automatic stack expansion, within the resource limit for the stack on
one side, and will produce a SIGSEGV or SIGBUS on the other end.

But I am curious
how universally various freenix distributions these days just let the >application segfault vs. using that as a cue to allocate additional
stack space; a quick test with WSL (Debian somethingorother) runs that
test without complaint, but I don't have a genuine *nix box to hand to
try it with.

All linux will allocate space, up to the stack resource limit.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-04-02, Stefan Ram <ram@zedat.fu-berlin.de> wrote:

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:

You don't seem to much of a Lisp writer. Lisp writers have no problem >>reading that indentation.

Well, there is the expression "write-only code", which shows
that a good Lisp writer may not necessarily be a good reader.

This is an example of LISP code:

( SETQ DIFF
( LAMBDA( X )
( COND
( ( ATOMP X )
( COND
( ( = X 'X )
1 )
( T
0 )))
( T
( COND
( ( =( CAR X )'SUM )
( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

. For someone who has not learned LISP, this is difficult to read,
/not/ because of the indentation, but because the words used have no
meaning for him. Without the indentation it would be harder to read.

I know all the words. It's still hard to read because of the weird
spaces.

This is the way of writing the code that the vast majority of the Lisp
word since gravitated toward:

(SETQ DIFF
(LAMBDA (X)
(COND
((ATOMP X)
(COND
((= X 'X) 1) ;; unnecessary line breaks shored up here
(T 0)))
(T
(COND
((= (CAR X) 'SUM)
(LIST 'SUM (DIFF (CADR X)) (DIFF (CADDR X)))))))))

The code is from just before MacCarthy invented the ternary IF, as a
shorthand for a one clause cond:

(SETQ DIFF
(LAMBDA (X)
(IF (ATOM X)
(IF (= X 'X) 1 0)
(IF (= (CAR X) 'SUM)
(LIST 'SUM (DIFF (CADR X)) (DIFF (CADDR X)))))))

Also, modern cond clauses are not strictly pairs,
which allows the T to be omitted:

(cond (this that) (else)) ;; rather than (t else)

when a cond clause consists of a single expression, then if that
expression is true, cond stops and yields that expression's value.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-04-02, Stefan Ram <ram@zedat.fu-berlin.de> wrote:

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

( SETQ DIFF
( LAMBDA( X )
( COND
( ( ATOMP X )
( COND
( ( = X 'X )
1 )
( T
0 )))
( T
( COND
( ( =( CAR X )'SUM )
( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

In Python:

def diff( x ):
return 1 if x == 'x' else 0 if type( x )is str
else[ 'sum', diff( x[ 1 ]), diff( x[ 2 ])]
if x[ 0 ]== 'sum' else None

n TXR Lisp:

(defun-match dif
((sum @left @right) ^(sum ,(dif left) ,(dif right)))
((@op . @args) (error "~s: unrecognized operator: ~s" 'dif op))
(x 1)
(@else 0))

diff is a built in, which we don't want to be redefining without
an exceptionally good reason, so I changed to dif.

If we compile 'dif we get unused variable warnings:

2> (compile 'dif)
** expr-1:1: warning: let*: variable args unused
** expr-1:1: warning: let*: variable else unused
#<vm fun: 0 param + 3 optional + variadic>

To suppress that, we use @nil instead of @args or @else; @nil is a
placeholder pattern that matches any object without binding a variable.

Otherwise we need more verbiage:

((@op . @args) (ignore args) (error ....))
...
(@else (ignore else) 0)
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.

Too much of a good thing is a bad thing.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Scott Lurndal <scott@slp53.sl.home> wrote at 16:09 this Tuesday (GMT):

John Ames <commodorejohn@gmail.com> writes:

On Tue, 2 Apr 2024 15:30:09 -0000 (UTC)
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
wrote:

It still protects writing to memory outside that buffer, right?
[snip]

"Protecting memory" doesn't mean "no page fault," though, just that it >>won't scribble all over some other process's memory.

The regions each side of the stack are marked not-present. This supports automatic stack expansion, within the resource limit for the stack on
one side, and will produce a SIGSEGV or SIGBUS on the other end.

But I am curious
how universally various freenix distributions these days just let the >>application segfault vs. using that as a cue to allocate additional
stack space; a quick test with WSL (Debian somethingorother) runs that
test without complaint, but I don't have a genuine *nix box to hand to
try it with.

All linux will allocate space, up to the stack resource limit.

Interesting.
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

In article <87plv762zt.fsf@tudado.org>,
Johanne Fairchild <jfairchild@tudado.org> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.

Too much of a good thing is a bad thing.

By definition. Because the definition of "too much" implies having crossed into the zone of being a bad thing.

I would like to argue that there are things that there is no such thing as
too much of, but I can't think of any examples off hand.
--

First of all, I do not appreciate your playing stupid here at all.

- Thomas 'PointedEars' Lahn -
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

gazelle@shell.xmission.com (Kenny McCormack) writes:

In article <87plv762zt.fsf@tudado.org>,
Johanne Fairchild <jfairchild@tudado.org> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.

Too much of a good thing is a bad thing.

By definition. Because the definition of "too much" implies having crossed >into the zone of being a bad thing.

I would like to argue that there are things that there is no such thing as >too much of, but I can't think of any examples off hand.

Money?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-04-02 20:59, Scott Lurndal wrote:

gazelle@shell.xmission.com (Kenny McCormack) writes:

In article <87plv762zt.fsf@tudado.org>,
Johanne Fairchild <jfairchild@tudado.org> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.

Too much of a good thing is a bad thing.

By definition. Because the definition of "too much" implies having crossed >> into the zone of being a bad thing.

I would like to argue that there are things that there is no such thing as >> too much of, but I can't think of any examples off hand.

Money?

Inflation.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 4/2/24 14:59, Scott Lurndal wrote:

gazelle@shell.xmission.com (Kenny McCormack) writes:

...

I would like to argue that there are things that there is no such thing as >> too much of, but I can't think of any examples off hand.

Money?

If you have lots of moeny, and insufficient protection, you can be in
danger. Also, a sufficiently large amount of money can crush you.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2 Apr 2024 08:26:14 GMT, Stefan Ram wrote:

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

def diff( x ):
return 1 if x == 'x' else 0 if type( x )is str else[ 'sum', diff( x[
1 ]), diff( x[ 2 ])]
if x[ 0 ]== 'sum' else None

Oops! That was one long line starting with "return";
it was wrapped by the newsreader, but is not correct Python anymore
when wrapped this way.

It’s bloody horrible Python even when wrapped correctly. I think Python’s version of the conditional expression is a complete abortion.

How about this, to at least get things the same way round as in the more
usual C-style conditional expression:

def diff(x) :
return \
[
lambda :
[
lambda :
[
lambda : None,
lambda : ['sum', diff(x[1]), diff(x[2])],
][x[0] == 'sum'](),
lambda : 0,
][isinstance(x, str)](),
lambda : 1,
][x == 'x']()
#end diff
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Tue, 02 Apr 2024 15:20:06 -0300, Johanne Fairchild wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.

Too much of a good thing is a bad thing.

Should that principle be carried to excess, though?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Tue, 2 Apr 2024 05:28:15 -0400, James Kuyper wrote:

By that same logic, if water is good, more water should be better. Tell
that to someone who is drowning.

Now there would be an example of too much logic, if you really want to
discuss such a thing with someone who is drowning, would it not?

... she was following a recommendation that she drink 8 glasses of water
a day "for her health".

Also look up “water intoxication”. Can kill anybody.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 03/04/2024 02:23, Lawrence D'Oliveiro wrote:

On 2 Apr 2024 08:26:14 GMT, Stefan Ram wrote:

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

def diff( x ):
return 1 if x == 'x' else 0 if type( x )is str else[ 'sum', diff( x[ >>> 1 ]), diff( x[ 2 ])]
if x[ 0 ]== 'sum' else None

Oops! That was one long line starting with "return";
it was wrapped by the newsreader, but is not correct Python anymore
when wrapped this way.

It’s bloody horrible Python even when wrapped correctly. I think Python’s version of the conditional expression is a complete abortion.

That's probably the reason almost no one uses it. That post is the
first time I have ever seen conditional expressions outside of a brief
mention in a tutorial on Python conditionals showing how to write normal conditionals in the language. I think Python stole this one from Perl.

How about this, to at least get things the same way round as in the more usual C-style conditional expression:

def diff(x) :
return \
[
lambda :
[
lambda :
[
lambda : None,
lambda : ['sum', diff(x[1]), diff(x[2])],
][x[0] == 'sum'](),
lambda : 0,
][isinstance(x, str)](),
lambda : 1,
][x == 'x']()
#end diff

How about just writing Python code the way pretty much everyone else
writes Python code? In a simple and obvious manner :

def diff(x) :
if x == 'x' :
return 1
if isinstance(x, str) :
return 0
if x[0] == 'sum' :
return ['sum', diff(x[1]), diff(x[2])]
return None




--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Wed, 3 Apr 2024 09:50:28 +0200, David Brown wrote:

How about just writing Python code the way pretty much everyone else
writes Python code?

That can be generalized to switch-expressions as well. See my notebook on “Simple Code-Shortening Idioms” at <https://gitlab.com/ldo/python_topics_notebooks/>.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Tue, 02 Apr 2024 15:20:06 -0300, Johanne Fairchild wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:

reading that indentation.

If indentation is good, more indentation should be better.

Too much of a good thing is a bad thing.

Should that principle be carried to excess, though?

Surely not if it's a good thing. :-)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

scott@slp53.sl.home (Scott Lurndal) writes:

John Ames <commodorejohn@gmail.com> writes:

On 1 Apr 2024 21:13:42 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

This stack "management" is "limited" in C:

True enough, although as noted that's an implementation issue as much
as it is a limitation of the language spec. (I'm not sure how you could >>handle that in a way that's both robust and reasonably C-ish...)

Modern (64-bit) linux systems leave large buffer zones (unmapped addresses) on either side of the stack; a stack overflow or underflow will
immediately fault if the RLIMIT_STACK value is exceeded.

...unless it’s exceeded by enough to reach some other mapped address.

https://blog.qualys.com/vulnerabilities-threat-research/2017/06/19/the-stack-clash
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Wed, 3 Apr 2024 09:50:28 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 03/04/2024 02:23, Lawrence D'Oliveiro wrote:

It’s bloody horrible Python even when wrapped correctly. I think Python’s version of the conditional expression is a complete
abortion.

That's probably the reason almost no one uses it. That post is the
first time I have ever seen conditional expressions outside of a
brief mention in a tutorial on Python conditionals showing how to
write normal conditionals in the language. I think Python stole this
one from Perl.

It's a real "Doc, it hurts when I do this!" situation.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

David Brown <david.brown@hesbynett.no> writes:

On 03/04/2024 02:23, Lawrence D'Oliveiro wrote:

On 2 Apr 2024 08:26:14 GMT, Stefan Ram wrote:

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

def diff( x ):
return 1 if x == 'x' else 0 if type( x )is str else[ 'sum', diff( x[ >>>> 1 ]), diff( x[ 2 ])]
if x[ 0 ]== 'sum' else None

Oops! That was one long line starting with "return";
it was wrapped by the newsreader, but is not correct Python anymore
when wrapped this way.

It’s bloody horrible Python even when wrapped correctly. I think
Python’s version of the conditional expression is a complete
abortion.

That's probably the reason almost no one uses it. That post is the
first time I have ever seen conditional expressions outside of a brief mention in a tutorial on Python conditionals showing how to write
normal conditionals in the language. I think Python stole this one
from Perl.

No, Perl's conditional expressions use the same syntax as C's.

As for whether Python's conditional expression syntax, it's not clear
that (cond ? expr1 : expr2) is better or worse than (expr1 if cond else
expr2) (unless you happen to be familiar with one of them).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

David Brown <david.brown@hesbynett.no> writes:

On 03/04/2024 02:23, Lawrence D'Oliveiro wrote:

It’s bloody horrible Python even when wrapped correctly. I think
Python’s version of the conditional expression is a complete
abortion.

That's probably the reason almost no one uses it. That post is the
first time I have ever seen conditional expressions outside of a brief
mention in a tutorial on Python conditionals showing how to write
normal conditionals in the language. I think Python stole this one
from Perl.

No, Perl's conditional expressions use the same syntax as C's.

As for whether Python's conditional expression syntax, it's not clear
that (cond ? expr1 : expr2) is better or worse than (expr1 if cond else expr2) (unless you happen to be familiar with one of them).

I’ve been familiar with both for years and I think the Python version is awful; in particular the ordering is a bizarre choice. The PEP where
they worked out the design acknowledges this but then they went ahead
and did it anyway...
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 03/04/2024 18:00, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 03/04/2024 02:23, Lawrence D'Oliveiro wrote:

On 2 Apr 2024 08:26:14 GMT, Stefan Ram wrote:

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

def diff( x ):
return 1 if x == 'x' else 0 if type( x )is str else[ 'sum', diff( x[ >>>>> 1 ]), diff( x[ 2 ])]
if x[ 0 ]== 'sum' else None

Oops! That was one long line starting with "return";
it was wrapped by the newsreader, but is not correct Python anymore >>>> when wrapped this way.

It’s bloody horrible Python even when wrapped correctly. I think
Python’s version of the conditional expression is a complete
abortion.

That's probably the reason almost no one uses it. That post is the
first time I have ever seen conditional expressions outside of a brief
mention in a tutorial on Python conditionals showing how to write
normal conditionals in the language. I think Python stole this one
from Perl.

No, Perl's conditional expressions use the same syntax as C's.

I am not very familiar with Perl, and don't know what are expressions or statements. Perhaps I have been imagining things. I had the idea that
in Perl you could write "<do_this> if <condition>" as an alternative to
the more common imperative language ordering "if <condition> then
<do_this>".

As for whether Python's conditional expression syntax, it's not clear
that (cond ? expr1 : expr2) is better or worse than (expr1 if cond else expr2) (unless you happen to be familiar with one of them).

I think expr1 and expr2 belong naturally together, as you are selecting
one or the other. If you are using a short-circuit evaluation, you
would express it in words as "evaluate cond, and based on that, evaluate either expr1 and expr2". Having "expr1" first is a bit like a recipe
that says "add the sugar to the egg whites, having first beaten the egg whites". It is an ordering that does not suit well in an imperative
language (I know Python is multi-paradigm, but it is basically imperative).

But I agree that familiarity could be a big factor in my subjective
opinion here.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Richard Kettlewell <invalid@invalid.invalid> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

John Ames <commodorejohn@gmail.com> writes:

On 1 Apr 2024 21:13:42 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

This stack "management" is "limited" in C:

True enough, although as noted that's an implementation issue as much
as it is a limitation of the language spec. (I'm not sure how you could >>>handle that in a way that's both robust and reasonably C-ish...)

Modern (64-bit) linux systems leave large buffer zones (unmapped addresses) >> on either side of the stack; a stack overflow or underflow will
immediately fault if the RLIMIT_STACK value is exceeded.

...unless it’s exceeded by enough to reach some other mapped address.

https://blog.qualys.com/vulnerabilities-threat-research/2017/06/19/the-stack-clash

Yes, clearly the buffer zones must be limited in size to allow space
for the rest of the application (and note that most extant processors
limit the virtual address space to 44 or 48 bits (up to 52 on ARM64)).

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

David Brown <david.brown@hesbynett.no> writes:

On 03/04/2024 18:00, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

[...]

That's probably the reason almost no one uses it. That post is the
first time I have ever seen conditional expressions outside of a brief
mention in a tutorial on Python conditionals showing how to write
normal conditionals in the language. I think Python stole this one
from Perl.

No, Perl's conditional expressions use the same syntax as C's.

I am not very familiar with Perl, and don't know what are expressions
or statements. Perhaps I have been imagining things. I had the idea
that in Perl you could write "<do_this> if <condition>" as an
alternative to the more common imperative language ordering "if
<condition> then <do_this>".

Yes, but it's not the same thing. Perl has postfix conditionals, so you
can write:

statement if condition;

but that's a statement, not an expression, and there's no form
equivalent to if/else. It's a specific case of "statement modifiers",
where the keyword can be any of if, unless, while, until, for, foreach,
or when. (The latter is for an experimental "switch" feature, disabled
by default in recent releases.)

https://perldoc.perl.org/perlsyn#Statement-Modifiers

As for whether Python's conditional expression syntax, it's not
clear
that (cond ? expr1 : expr2) is better or worse than (expr1 if cond else
expr2) (unless you happen to be familiar with one of them).

I think expr1 and expr2 belong naturally together, as you are
selecting one or the other. If you are using a short-circuit
evaluation, you would express it in words as "evaluate cond, and based
on that, evaluate either expr1 and expr2". Having "expr1" first is a
bit like a recipe that says "add the sugar to the egg whites, having
first beaten the egg whites". It is an ordering that does not suit
well in an imperative language (I know Python is multi-paradigm, but
it is basically imperative).

But I agree that familiarity could be a big factor in my subjective
opinion here.

I don't have a strong opinion one way or the other, beyond a willingness
to accept the syntax and other rules of whatever language I'm using.
But I suggest that Python's "expr1 if condition else expr2" is intended
to emphasize expr1 over expr2, treating the condition being true as the "normal" case. That's not necessarily a bad thing.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 03/04/2024 19:19, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 03/04/2024 18:00, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

[...]

That's probably the reason almost no one uses it. That post is the
first time I have ever seen conditional expressions outside of a brief >>>> mention in a tutorial on Python conditionals showing how to write
normal conditionals in the language. I think Python stole this one
from Perl.

No, Perl's conditional expressions use the same syntax as C's.

I am not very familiar with Perl, and don't know what are expressions
or statements. Perhaps I have been imagining things. I had the idea
that in Perl you could write "<do_this> if <condition>" as an
alternative to the more common imperative language ordering "if
<condition> then <do_this>".

Yes, but it's not the same thing. Perl has postfix conditionals, so you
can write:

statement if condition;

but that's a statement, not an expression, and there's no form
equivalent to if/else. It's a specific case of "statement modifiers",
where the keyword can be any of if, unless, while, until, for, foreach,
or when. (The latter is for an experimental "switch" feature, disabled
by default in recent releases.)

OK. That's a lot more than I knew.

However, I don't see a relevant distinction between a statement and an expression as particularly significant here, at least in terms of code clarity.

https://perldoc.perl.org/perlsyn#Statement-Modifiers

As for whether Python's conditional expression syntax, it's not
clear
that (cond ? expr1 : expr2) is better or worse than (expr1 if cond else
expr2) (unless you happen to be familiar with one of them).

I think expr1 and expr2 belong naturally together, as you are
selecting one or the other. If you are using a short-circuit
evaluation, you would express it in words as "evaluate cond, and based
on that, evaluate either expr1 and expr2". Having "expr1" first is a
bit like a recipe that says "add the sugar to the egg whites, having
first beaten the egg whites". It is an ordering that does not suit
well in an imperative language (I know Python is multi-paradigm, but
it is basically imperative).

But I agree that familiarity could be a big factor in my subjective
opinion here.

I don't have a strong opinion one way or the other, beyond a willingness
to accept the syntax and other rules of whatever language I'm using.

Of course we use the languages we use, warts and all. It's rare that
anyone uses a language for a significant amount of work and doesn't
dislike at least some aspects of the language.

But I suggest that Python's "expr1 if condition else expr2" is intended
to emphasize expr1 over expr2, treating the condition being true as the "normal" case. That's not necessarily a bad thing.

Perhaps.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

David Brown <david.brown@hesbynett.no> writes:

On 03/04/2024 19:19, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 03/04/2024 18:00, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

[...]

That's probably the reason almost no one uses it. That post is the
first time I have ever seen conditional expressions outside of a brief >>>>> mention in a tutorial on Python conditionals showing how to write
normal conditionals in the language. I think Python stole this one
from Perl.

No, Perl's conditional expressions use the same syntax as C's.

I am not very familiar with Perl, and don't know what are expressions
or statements. Perhaps I have been imagining things. I had the idea
that in Perl you could write "<do_this> if <condition>" as an
alternative to the more common imperative language ordering "if
<condition> then <do_this>".

Yes, but it's not the same thing. Perl has postfix conditionals, so
you
can write:
statement if condition;
but that's a statement, not an expression, and there's no form
equivalent to if/else. It's a specific case of "statement modifiers",
where the keyword can be any of if, unless, while, until, for, foreach,
or when. (The latter is for an experimental "switch" feature, disabled
by default in recent releases.)

OK. That's a lot more than I knew.

However, I don't see a relevant distinction between a statement and an expression as particularly significant here, at least in terms of code clarity.

One distinction is that, for example, you can't use
statement if condition;
as part of a larger expression. Also, there's no else clause.

Perl's statement modifiers are an alternative syntax for conditional *statements*. In particular, `statement if condition;` is equivalent to
`if (condition) { statement; }`. Their purpose is to allow some code to
be written more concisely. (Note that an if statement or other compound statement requires { and }.)

Perl adopted C's ?: syntax for conditional expressions with little or
no change.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Wed, 03 Apr 2024 17:16:31 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

David Brown <david.brown@hesbynett.no> writes:

On 03/04/2024 02:23, Lawrence D'Oliveiro wrote:

It’s bloody horrible Python even when wrapped correctly. I think
Python’s version of the conditional expression is a complete
abortion.

That's probably the reason almost no one uses it. That post is the
first time I have ever seen conditional expressions outside of a brief
mention in a tutorial on Python conditionals showing how to write
normal conditionals in the language. I think Python stole this one
from Perl.

No, Perl's conditional expressions use the same syntax as C's.

As for whether Python's conditional expression syntax, it's not clear
that (cond ? expr1 : expr2) is better or worse than (expr1 if cond else
expr2) (unless you happen to be familiar with one of them).

I’ve been familiar with both for years and I think the Python version is >awful; in particular the ordering is a bizarre choice. The PEP where
they worked out the design acknowledges this but then they went ahead
and did it anyway...

I believe its known as being different for the sake of being different which
is closely related to change for changes sake. Its the reason screwed up the WIndows GUI - a new generation of devs had to prove their could be different
to the previous one regardless of how badly their new version sucked. Or in more general cases - we've all seen new managers come in and change processes just to prove they were doing something.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Richard Kettlewell <invalid@invalid.invalid> wrote or quoted:

I’ve been familiar with both for years and I think the Python version is >awful; in particular the ordering is a bizarre choice.

The way this syntax is set up is apparently credited to
this guy named Guido, according to this PEP 308 thing.

Now, in English, we usually throw a comma in there when an
"if" clause comes first, 'cause it kinda throws off the normal
flow, you know? So that shows the default position for "if"
is actually after the main part. - Maybe Guido was making that
same kind of comparison to English, and that's why he decided
the post-"if" format works better.

In my example here, there were a whole bunch of these operators
all nested inside each other without any parentheses. And let
me tell you, when you start getting into that kind of nested
stuff with not parentheses in view, even the "?:" notation
can start looking pretty darn mysterious to some folks.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:

And let me tell you, when you start getting into that kind of nested
stuff with not parentheses in view, even the "?:" notation can start
looking pretty darn mysterious to some folks.

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:

And let me tell you, when you start getting into that kind of nested
stuff with not parentheses in view, even the "?:" notation can start
looking pretty darn mysterious to some folks.

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

Just use brackets. Saves a lot of pain.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 09:17 this Friday (GMT):

On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:

And let me tell you, when you start getting into that kind of nested
stuff with not parentheses in view, even the "?:" notation can start
looking pretty darn mysterious to some folks.

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

Just use brackets. Saves a lot of pain.

Or just use if blocks if it's too complex.
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 5 Apr 2024 12:40:02 -0000 (UTC)
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote: >Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 09:17 this Friday >(GMT):

On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:

And let me tell you, when you start getting into that kind of nested
stuff with not parentheses in view, even the "?:" notation can start
looking pretty darn mysterious to some folks.

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

Just use brackets. Saves a lot of pain.

Or just use if blocks if it's too complex.

Indeed. It might not look as "l33t", but with modern compilers it'll end
up as the same assembler anyway.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:

On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:

And let me tell you, when you start getting into that kind of nested
stuff with not parentheses in view, even the "?:" notation can start
looking pretty darn mysterious to some folks.

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

Indentation generally helps. In above code (in my book) it's not
that clear [from the indentation], e.g. where the last ':' 'else'
belongs to. So I'd have lined the colons up with the respective
'?'. (YMMV.)

Not all languages differentiate (per syntax) a conditional command
from a conditional expression. Here are the two forms supported by
Algol for both, statements and expressions (here the examples are
both depicted for expressions only)

a :=
( b | ( c | d | e )
| ( f | ( g | h | i )
| j ) );

The parenthesis are not used for grouping, but are the alternative
form for IF/THEN/ELSE/FI

a := IF b
THEN
IF c THEN d ELSE e FI
ELSE
IF f THEN
IF g THEN h ELSE i FI
ELSE j FI
FI

Pick your choice depending on the case (or taste).

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:

On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:

This is where indentation helps. E.g.
a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

Indentation generally helps.

Let me give it a try to find how I would indent that!

b?
c? d: e:
f?
g? h: i:
j;

The parenthesis are not used for grouping, but are the alternative
form for IF/THEN/ELSE/FI

It's funny how the discussion oscillates between
"too many parentheses" (LISP code) and "not enough parentheses"
("let me add some parens to improve readability").
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-04-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:

On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:

And let me tell you, when you start getting into that kind of nested
stuff with not parentheses in view, even the "?:" notation can start
looking pretty darn mysterious to some folks.

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

Indentation generally helps. In above code (in my book) it's not
that clear [from the indentation], e.g. where the last ':' 'else'
belongs to. So I'd have lined the colons up with the respective
'?'. (YMMV.)

Not all languages differentiate (per syntax) a conditional command
from a conditional expression. Here are the two forms supported by
Algol for both, statements and expressions (here the examples are
both depicted for expressions only)

a :=
( b | ( c | d | e )
| ( f | ( g | h | i )
| j ) );

The parenthesis are not used for grouping, but are the alternative
form for IF/THEN/ELSE/FI

a := IF b
THEN
IF c THEN d ELSE e FI
ELSE
IF f THEN
IF g THEN h ELSE i FI
ELSE j FI
FI

Pick your choice depending on the case (or taste).

#define XCAT(A, B) A ## B
#define CAT(A, B) XCAT(A, B)

#define IF(A, B, C) ((A) ? (B) : (C))

#define COND_2(cond, then, ...) IF(cond, then, 0)
#define COND_4(cond, then, ...) IF(cond, then, COND_2(__VA_ARGS__))
#define COND_6(cond, then, ...) IF(cond, then, COND_4(__VA_ARGS__))
#define COND_8(cond, then, ...) IF(cond, then, COND_6(__VA_ARGS__))

#define COND_1(...) {syntax error}
#define COND_3(...) {syntax error}
#define COND_5(...) {syntax error}
#define COND_7(...) {syntax error}

#define COUNT_ARGS(...) COUNT_ARGS_IMPL(__VA_ARGS__, 8, 7, 6, 5, 4, 3, 2, 1) #define COUNT_ARGS_IMPL(_1, _2, _3, _4, _5, _6, _7, _8, N, ...) N

#define COND(...) CAT(COND_, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)


Now we can do:

COND(b, ...,
f, ...
1, j)

filling in the ...:

COND(b, IF(c, d, e),
f, IF(g, h, i),
1, j)

The GNU preprocessor gives me this:

((b) ? (((c) ? (d) : (e))) : (((f) ? (((g) ? (h) : (i))) : (((1) ? (j) : (0))))))

which looks correct.

The code is readable now, and importantly, my editor can format it. If I
start adding line breaks, it's indented right. If I turn it into this:

COND(b, IF(c, d, e),
f, IF(g, h, i),
1, j)

then highlight it in Vim and hit =, it gets put back the way it was.

If I add line breaks into the IFs, they get automatically indented
right, just using Vim's support for basic C formatting of macro/function
calls:

cond(b, IF(c,
d,
e),
f, IF(g,
h,
i),
1, j)

Compared to wrestling with five ways of formatting the the ill-conceived
?: syntax, it's a complete no brainer.

Here is a version where the cond pairs have to be parenthesized.
We can lose the even/odd argument count handling, and might as well
extend to up to 8 clauses:

#define IF(A, B, C) ((A) ? (B) : (C))

#define XCAT(A, B) A ## B
#define CAT(A, B) XCAT(A, B)

#define COND_PAIR(pair, rest) IF(COND_COND pair, COND_THEN pair, rest)
#define COND_COND(cond, then) cond
#define COND_THEN(cond, then) then
#define COND_1(pair, ...) COND_PAIR(pair, 0)
#define COND_2(pair, ...) COND_PAIR(pair, COND_1(__VA_ARGS__))
#define COND_3(pair, ...) COND_PAIR(pair, COND_2(__VA_ARGS__))
#define COND_4(pair, ...) COND_PAIR(pair, COND_3(__VA_ARGS__))
#define COND_5(pair, ...) COND_PAIR(pair, COND_4(__VA_ARGS__))
#define COND_6(pair, ...) COND_PAIR(pair, COND_5(__VA_ARGS__))
#define COND_7(pair, ...) COND_PAIR(pair, COND_6(__VA_ARGS__))
#define COND_8(pair, ...) COND_PAIR(pair, COND_7(__VA_ARGS__))

#define COUNT_ARGS(...) COUNT_ARGS_IMPL(__VA_ARGS__, 8, 7, 6, 5, 4, 3, 2, 1) #define COUNT_ARGS_IMPL(_1, _2, _3, _4, _5, _6, _7, _8, N, ...) N

#define COND(...) CAT(COND_, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)

COND((b, IF(c,
d,
d)),
(f, IF(g,
h,
i)),
(1, j))

The expansion is still

((b) ? (((c) ? (d) : (d))) : (((f) ? (((g) ? (h) : (i))) : (((1) ? (j) : (0))))))
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 5 Apr 2024 18:30:12 +0200, Janis Papanagnou wrote:

Here are the two forms supported by Algol ...

Just a note, that’s Algol 68. In my time, “Algol” used unqualified was understood to refer to Algol 60.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:

On Thu, 4 Apr 2024 23:29:21 -0000 (UTC) Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

The improvement speaks for itself.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
...
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

A normal programmer would write something like:

a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;

I.e., she would allow herself to use spaces and newlines, and just
enough parentheses to make the structure clear.

- Alan
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 05 Apr 2024 19:35:37 -0400, Alan Bawden wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
...
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

A normal programmer would write something like:

a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;

I.e., she would allow herself to use spaces and newlines, and just
enough parentheses to make the structure clear.

It’s like, I don’t know ... you’re trying to save space. Why?

It’s like programming inside an apartment block, instead of having a bungalow with a yard of your own.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 2024-04-05, Alan Bawden <alan@csail.mit.edu> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
...
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

A normal programmer would write something like:

a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;

I.e., she would allow herself to use spaces and newlines, and just
enough parentheses to make the structure clear.

It looks good, undeniably.

However, I cannot tell at a glance whether or not the nice appearance
isn't telling me some kind of lie. That's an inherent problem with
the ternary operator.

I have to remember that = has lower precedence than ?:. But, ==
has higher precedence. So this careless edit makes it wrong,
even though it still looks just as nice:

a == b ? (c ? d : e) :
f ? (g ? h : i) :
j;
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 15:09 this Friday (GMT):

On Fri, 5 Apr 2024 12:40:02 -0000 (UTC)
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:

Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 09:17 this Friday >>(GMT):

On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:

And let me tell you, when you start getting into that kind of nested >>>>> stuff with not parentheses in view, even the "?:" notation can start >>>>> looking pretty darn mysterious to some folks.

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

Just use brackets. Saves a lot of pain.

Or just use if blocks if it's too complex.

Indeed. It might not look as "l33t", but with modern compilers it'll end
up as the same assembler anyway.

Yeah. Not everything needs to be a hyper optimized single line
statement.
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Alan Bawden <alan@csail.mit.edu> wrote at 23:35 this Friday (GMT):

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
...
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

A normal programmer would write something like:

a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;

v (she?)

I.e., she would allow herself to use spaces and newlines, and just
enough parentheses to make the structure clear.

- Alan

Yeah, a bit of space for the code to breathe goes a long way.
--
user <candycane> is generated from /dev/urandom
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 5 Apr 2024 17:37:52 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:

On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:

This is where indentation helps. E.g.
a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

Indentation generally helps.

Let me give it a try to find how I would indent that!

b?
c? d: e:
f?
g? h: i:
j;

The parenthesis are not used for grouping, but are the alternative
form for IF/THEN/ELSE/FI

It's funny how the discussion oscillates between
"too many parentheses" (LISP code) and "not enough parentheses"
("let me add some parens to improve readability").

Lisp overloads them as block markers which simply makes the code more confusing, not less.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Fri, 05 Apr 2024 19:35:37 -0400
Alan Bawden <alan@csail.mit.edu> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
...
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

A normal programmer would write something like:

a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;

I.e., she would allow herself to use spaces and newlines, and just

ITYM "he" would allow HIMself.

Lets give the woke BS a miss, 95% of developers are men. It doesn't give you any brownie points, just makes you look a try-hard ass.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 06/04/2024 03:01, Kaz Kylheku wrote:

On 2024-04-05, Alan Bawden <alan@csail.mit.edu> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
...
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

A normal programmer would write something like:

a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;

I.e., she would allow herself to use spaces and newlines, and just
enough parentheses to make the structure clear.

It looks good, undeniably.

However, I cannot tell at a glance whether or not the nice appearance
isn't telling me some kind of lie. That's an inherent problem with
the ternary operator.

That's a key point - and it is not just with the ternary operator, but a general issue. Good spacing, indentation, newlines and layout make code easier to read. But it is vital that there is never any doubt that the
layout matches the meaning of the code. If not, then you might be sure
what the programmer meant dues to the layout, but you are not sure that
the compiler sees it the same way. After all, this looks neat and clear
too :

a =
b & c +
d & e +
f & g

But the language viewpoint (assuming it is in C, or a language with
similar precedences) and the code appearance are very different.

Parentheses help, until there are too many to be easily tracked by the
reader. Splitting the expression into parts, adding new local
variables, using separate statements, making new helper functions -
these are all ways to improve the code, and have no efficiency cost with modern tools.

A lot of people think the layout of code should make the programmer's intentions clear, and make it easy to see what the code does. That's
true, but it is not enough. Code layout should also make it easy to see
that the code does what the programmer intended. It should be easy for
a maintainer to modify it without introducing errors. It should also be
hard for a reader to misinterpret it (which is not the same as saying it should be easy to interpret correctly). It should be hard for a
maintainer to make mistakes. It should be easy to spot any mistakes
that get made.

I have to remember that = has lower precedence than ?:. But, ==
has higher precedence. So this careless edit makes it wrong,
even though it still looks just as nice:

a == b ? (c ? d : e) :
f ? (g ? h : i) :
j;

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sat, 6 Apr 2024 15:44:13 +0200
David Brown <david.brown@hesbynett.no> wrote:

A lot of people think the layout of code should make the programmer's >intentions clear, and make it easy to see what the code does. That's

Unfortunately IME another lot (usually young) seem to think that the more complicated their make their code the more it will impress their peers and/or boss. This seems to be a particular problem with C++ as its current overspecced and overcomplicated syntax allows you to write code that would make a Perl dev envious.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 05.04.2024 19:37, Stefan Ram wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:

[ Algol syntax variants, keywords vs. parenthesis ("meek form" ?) ]

The parenthesis are not used for grouping, but are the alternative
form for IF/THEN/ELSE/FI

It's funny how the discussion oscillates between
"too many parentheses" (LISP code) and "not enough parentheses"
("let me add some parens to improve readability").

We should distinguish the various aspects posted over time.
Parenthesis used...
- to group sub-expressions (to make precedence clear or
fix some precedence inconsistency in the language)
=> that's IMO a Good Thing for non-trivial cases
- as necessary syntax of the language (like inherently
in Lisp, or in C's control structures)
=> I don't like them, but you have no choice here
(but changing the language, where/if possible)
- as an alternative syntactic form of conditionals
(as in Algol, where you can choose the syntax)
=> Personally I like the verbose keywords, but in
case of conditional expressions the concise form
with parenthesis might be better readable (though
this can be different in complex cases as posted)
Note that in Algol not only the 'IF's can be written
in that parenthesis syntax form, you can also use
the '(' and ')' instead of the 'BEGIN'/'END' keywords.

It boils down to: to each his own, and, use what's most
appropriate depending on context.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 06.04.2024 01:08, Lawrence D'Oliveiro wrote:

On Fri, 5 Apr 2024 18:30:12 +0200, Janis Papanagnou wrote:

Here are the two forms supported by Algol ...

Just a note, that’s Algol 68. In my time, “Algol” used unqualified was understood to refer to Algol 60.

This seems to have been the case before Algol 68 appeared.
(I'm not sure this matches with what you call "in my time".)

I named it always explicitly as "Algol 60" and "Algol 68".
But at some instance of time I read somewhere that "Algol"
would "now" refer to Algol 68, so I changed my habit.

But since your post shows that this may not (not yet?) be
common usage I'll be more specific in future. - Thanks for
the hint!

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 06/04/2024 17:57, Janis Papanagnou wrote:

I named it always explicitly as "Algol 60" and "Algol 68".
But at some instance of time I read somewhere that "Algol"
would "now" refer to Algol 68, so I changed my habit.

Quite right. Algol 60 died, for all practical purposes,
half a century ago. Algol 68 may be a niche interest, but it is
still a nice language, and its [dwindling] band of adherents and
practitioners still use it and prefer it to C and other more
recent languages.

But since [LD'O's] post shows that this may not (not yet?) be
common usage I'll be more specific in future. - Thanks for
the hint!

For how long? Does anyone still think that an unadorned
"Unix" must refer to 6th Edition [or earlier], "C" to K&R, "Fortran"
to Fortran IV, and so on? Clearly, there /are/ occasions when it is
necessary to specify which version of a language/OS/computer/... is
being referred to, and there is often a change-over period of a few
years when an older version is still sufficiently current. But fifty
years is surely long enough to get used to the newer version!
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Godfrey
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 06.04.2024 20:32, Andy Walker wrote:

On 06/04/2024 17:57, Janis Papanagnou wrote:

I named it always explicitly as "Algol 60" and "Algol 68".
But at some instance of time I read somewhere that "Algol"
would "now" refer to Algol 68, so I changed my habit.

Quite right. Algol 60 died, for all practical purposes,
half a century ago. Algol 68 may be a niche interest, but it is
still a nice language, and its [dwindling] band of adherents and practitioners still use it and prefer it to C and other more
recent languages.

I think it's a not only formally outstanding language; despite I've
never used it professionally since my first contact with it in the
early 1980's. (Though I still have a compiler on my private box to
play with it.)

But since [LD'O's] post shows that this may not (not yet?) be
common usage I'll be more specific in future. - Thanks for
the hint!

For how long? Does anyone still think that an unadorned
"Unix" must refer to 6th Edition [or earlier], "C" to K&R, "Fortran"
to Fortran IV, and so on? Clearly, there /are/ occasions when it is necessary to specify which version of a language/OS/computer/... is
being referred to, and there is often a change-over period of a few
years when an older version is still sufficiently current. But fifty
years is surely long enough to get used to the newer version!

Yes. - What I didn't know was whether that generic "Algol" naming
convention was already made around 1968 or maybe only much later.

But, WRT Algol 60 vs. Algol 68, these are quite different languages;
I wouldn't call the latter a new version. While some basic abstract
concepts from Algol 60 have certainly been considered in Algol 68
the whole design and specification process was done anew in Algol 68.
(The van Wijngaarden grammar also was some fundamental new approach.)
These languages can hardly be seen as "versions" of the same language.

Algol 60, OTOH, also had an own history and continued use after 1968;
to my knowledge it had been used in numerical mathematics and it was
(while per se quite terse a language) the base of Simula 67, an
extremely powerful language ahead of time (still).

But Algol 60, Simula, and also Algol 68 are all meaningless today, I
(sadly) dare to say. Maybe more than of "niche interest"? Can't tell.
Back these days they certainly were not hyped (as languages nowadays
are as part of the inventor's "marketing" activities). There's papers
existing that try to explain the/possible reasons for their fail to
become established.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

Andy Walker <anw@cuboid.co.uk> writes:

On 06/04/2024 17:57, Janis Papanagnou wrote:

I named it always explicitly as "Algol 60" and "Algol 68".
But at some instance of time I read somewhere that "Algol"
would "now" refer to Algol 68, so I changed my habit.

That doesn't match my experience.

Quite right. Algol 60 died, for all practical purposes,
half a century ago. Algol 68 may be a niche interest, but it is
still a nice language, and its [dwindling] band of adherents and practitioners still use it and prefer it to C and other more
recent languages.

I've never heard "Algol" by itself used to refer to Algol 68, which had
enough changes to be essentially a different language, and one which
didn't really replace Algol 60 (though it was clearly intended to).

<https://en.wikipedia.org/wiki/ALGOL> agrees.

The relative popularity of Algol 60 vs. 68 doesn't necessarily change
what "Algol" means.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sat, 6 Apr 2024 18:57:47 +0200, Janis Papanagnou wrote:

I named it always explicitly as "Algol 60" and "Algol 68". But at some instance of time I read somewhere that "Algol" would "now" refer to
Algol 68, so I changed my habit.

Sure, Algol 60 is way beyond a museum piece by now. But remember, that was
the one that spawned a great number of offshoots, namely the “Algol-like” language family--or really, superfamily. That included Pascal and its own offshoots.

Algol 68 was a bit less influential in terms of language features (I think
C “int”, “char”, “struct” and “union”, and the “long” and “short”
qualifiers came from there, and csh “if ... fi” as well), but it did seem to introduce a bunch of new terminology, some of which caught on, others
did not. See how many you can spot:

* “Elaboration” for the process of executing a program (including possibly
transforming from source form to an executable form)
* “Transput” instead of “input/output”
* “Heap” for an area in which memory may be dynamically allocated and
freed in no particular order
* “Overloading” for multiple context-dependent definitions of an operator
* “Name” instead of “pointer” or “address”
* “Mode” instead of “data type”
* “Coercion” for a type conversion
* “Cast” for an explicit type conversion
* “Void” for a construct yielding no value
* “Dereferencing” for following a pointer
* “Slice” for a subarray of an array
* “Pragmat” for compiler directive (I think “pragma” is more common
nowadays.)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 07.04.2024 00:57, Lawrence D'Oliveiro wrote:

Sure, Algol 60 is way beyond a museum piece by now. But remember, that was the one that spawned a great number of offshoots, namely the “Algol-like”
language family--or really, superfamily. That included Pascal and its own offshoots.

Indeed, it became the base of a huge tree of important programming
languages.

Algol 68 was a bit less influential in terms of language features

I like it more for its formal coherence than for specific features.

But of course it also has a lot of features; besides some mentioned
in your post, e.g., the generalized 'for' loop (that can even be
abbreviated for control structure subsets), but that we also find
(even in a more generalized version) already in Simula 67, BTW.

(I think
C “int”, “char”, “struct” and “union”, and the “long” and “short”
qualifiers came from there, and csh “if ... fi” as well), [...]

It was more a base for the Bourne shell family (and its successors,
including POSIX shell through ksh88). But yes, it influenced quite
some languages. And, yes, it was less influential than Algol 60.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On 07.04.2024 00:57, Lawrence D'Oliveiro wrote:

Algol 68 was a bit less influential in terms of language features [...]
See how many you can spot:

* “Elaboration” for the process of executing a program (including possibly
transforming from source form to an executable form)
* “Transput” instead of “input/output”

After all these decades it sounds still strange in my ears.

* “Heap” for an area in which memory may be dynamically allocated and
freed in no particular order
* “Overloading” for multiple context-dependent definitions of an operator * “Name” instead of “pointer” or “address”

Well, we had function parameters called "by name" before.

And we have 'REF' for references. (Also seen in Simula 67.)

* “Mode” instead of “data type”
* “Coercion” for a type conversion
* “Cast” for an explicit type conversion
* “Void” for a construct yielding no value

This is an interesting thing in Algol 68 if you study the
details!

As the "type" of statements it makes function definitions
or the mentioned conditionals (statements and expressions)
a coherent concept.

* “Dereferencing” for following a pointer
* “Slice” for a subarray of an array
* “Pragmat” for compiler directive (I think “pragma” is more common
nowadays.)

And maybe printf() and the op:= set of operators, and more.

I also find its collateral abilities very interesting. But I
seem to recall that not every compiler supports that.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sat, 6 Apr 2024 08:58:45 -0000 (UTC), Muttley wrote:

Lisp overloads them as block markers which simply makes the code more confusing, not less.

That’s because there is no fundamental difference between “blocks” and whatever else it is you think those Lisp parentheses are used for.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sun, 7 Apr 2024 01:47:13 +0200, Janis Papanagnou wrote:

On 07.04.2024 00:57, Lawrence D'Oliveiro wrote:

* “Name” instead of “pointer” or “address”

Well, we had function parameters called "by name" before.

Those were actually “thunks”. An early draft Algol 68 spec kept them on in the form of “proceduring” coercions, but these were dropped in the revised report.

See also <https://en.wikipedia.org/wiki/Jensen%27s_device>.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

In comp.unix.shell Johanne Fairchild <jfairchild@tudado.org> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

At one time, we distinguished between “scripting” languages and
“programming” languages. [...] But there is one distinction that I
think is still relevant, and that is the one between shell/command
languages and programming languages.

[...]

Consider looking at a shell language like a domain-specific programming language. A shell is a programming language made specifically for
running programs. When you write a shell line, you're specifying the arguments of execve(2). In other words, a shell is a programming
language made to prepare the memory to be consumed by the system in a specific way---execve(2).

It certainly encourages the writing of small modular tools. The
downside is the loss of performance because of disk access for trivial
things like 'nfiles=$(ls | wc -l)'. I suspect disk access times where
one of the reasons for the development of perl in the early 90s.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.misc

On Sun, 07 Apr 2024 00:01:43 +0000, Javier wrote:

The downside is the loss of performance because of disk access for
trivial things like 'nfiles=$(ls | wc -l)'.

Well, you could save one process creation by writing
“nfiles=$(echo * | wc -l)” instead. But that would still not be strictly correct.

I suspect disk access times where
one of the reasons for the development of perl in the early 90s.

Shells were somewhat less powerful in those days. I would describe the
genesis of Perl as “awk on steroids”. Its big party trick was regular expressions. And I guess combining that with more sophisticated data- structuring capabilities.
--- Synchronet 3.20a-Linux NewsLink 1.114