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.
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
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
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.
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:
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
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.
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
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.
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.
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.
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?
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.
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.
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?
As a counter point, good luck writing a device driver in lisp.
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.
The terminology will continue to be used, but the distinction does not matter, except from a speed of processing difference.
Program text is initially text.[*] During parsing (either in
an interpreted or in a compiled language) you split the text
in tokens.
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.)
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.
TCL is a language that might be considered half-way between your
categories here.
The distinctions between script and programming languages made sense when they were first introduced. [...]
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, 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”;
in a programming language, you have the assumption that
“everything is a program construct until indicated otherwise”.
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 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?
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).
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”.
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.
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!
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.
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.
And the entire construct needs to be processed before the shell can
begin to execute it. Misspelling "done" prevents the whole thing from running.
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.
"for" is not just a command. It's a keyword, part of the shell language syntax.
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
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.
"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.
Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:Of course. :) But we both know what that means. It's abstract because
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!
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.
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?
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
I'm not being obtuse. There is no hard dividing line between scripts and programs - as I said, its shades of grey.
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."
You're just being deliberately obtuse, not to mention snippy with the >scissors.
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.
[...]
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.
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
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.
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.
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.
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?
Johanne Fairchild <jfairchild@tudado.org> wrote or quoted: >>ram@zedat.fu-berlin.de (Stefan Ram) writes:
Johanne Fairchild <jfairchild@tudado.org> wrote or quoted: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.
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!
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.
It didn't really take off very well, but certainly people have written
device drivers in Forth.
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.
"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).
So what is 'for i in a ; do ... ; done' then in your world?
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.
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.
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.
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.
(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))))))))))
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.
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.
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.
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.
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.
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."
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.
Ugh. No wonder the language fell out of fashion. Looks like some kind of hacked up Basic.
Scripting languages handle the memory for you.
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]; }
... the stack, which may or may not even *be* a true
hardware stack (depending on the architecture,) ...
reading that indentation.
Readability of the flow of control matters. God knows whats going on with
all those nested statements.
Why is it important that there be a distinction between "scripting" and "non-scripting" languages at all?
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.
You don't seem to much of a Lisp writer. Lisp writers have no problem >reading that 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
Why is it important that there be a distinction between "scripting"
and "non-scripting" languages at all?
( 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 )))))))))
On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:
reading that indentation.
If indentation is good, more indentation should be better.
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.
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.
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
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.
On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:
reading that indentation.
If indentation is good, more indentation should be better.
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.
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.
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.
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?
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?
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 that same logic, if water is good, more water should be better. Tell
that to someone who is drowning.
... she was following a recommendation that she drink 8 glasses of water
a day "for her health".
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.
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
How about just writing Python code the way pretty much everyone else
writes Python code?
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?
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.
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).
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:It’s bloody horrible Python even when wrapped correctly. I think
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.
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).
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
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 theNo, Perl's conditional expressions use the same syntax as C's.
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.
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 <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’ve been familiar with both for years and I think the Python version is >awful; in particular the ordering is a bizarre choice.
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.
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;
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.
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.
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;
On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:
This is where indentation helps. E.g.Indentation generally helps.
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
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).
Here are the two forms supported by Algol ...
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.
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.
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.
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.
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
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.Indentation generally helps.
a =
b ?
c ? d : e
: f ?
g ? h : i
: j;
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").
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
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
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;
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.
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").
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 [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!
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!
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.
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”
* “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.)
Lisp overloads them as block markers which simply makes the code more confusing, not less.
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.
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), [...]
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).
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.
But, WRT Algol 60 vs. Algol 68, these are quite different languages;
I wouldn't call the latter a new version.
Algol 60, OTOH, also had an own history and continued use after 1968;
to my knowledge it had been used in numerical mathematics [...].
But Algol 60, Simula, and also Algol 68 are all meaningless today, I
(sadly) dare to say.
On 06.04.2024 20:32, Andy Walker wrote:
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.
I can see no argument for saying that [“Algol”], by default, refers to A60.
If acknowledging the existence of female developers makes you
uncomfortable, you're just going to have to learn to deal with that
yourself. I'm not going to adjust my language to cater to your
insecurities.
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.
I agree; OTOH, WG2.1 accepted A68 as the "new" Algol. The
instant question here was what an unadorned "Algol" means, and while
I can see an argument for saying that it shouldn't happen, I can see
no argument for saying that it, by default, refers to A60.
But Algol 60, Simula, and also Algol 68 are all meaningless today, I
(sadly) dare to say.
You're probably right. But A68G is still a nice language. It
creaks in places, and it's not suitable for everything [what is?]. But
it serves all my programming needs. It has the advantage, in practice,
over C that all the common programming blunders -- use of uninitialised variables, array accesses out of bounds, numerical overflow, dereferencing null pointers, memory leaks and consequences thereof, the things that
cause most of the security holes -- are picked up either by the compiler
or at run-time before they can do any damage. I expect there are modern languages that also do that, but at my age it's not worth learning a new language when the old one works perfectly well.
On Sun, 07 Apr 2024 06:04:16 -0400
Alan Bawden <alan@csail.mit.edu> wrote:
If acknowledging the existence of female developers makes you
uncomfortable, you're just going to have to learn to deal with that
yourself. I'm not going to adjust my language to cater to your
insecurities.
If my insecurities you mean acknowledging reality then fine. The thing about people like you is (and I don't believe the 50% thing, sorry) is that you would never use a male pronoun if talking about nurses or pre school teachers who are heavily biased towards women.
Even in the 21st century, articles like <https://seattlewebsitedevelopers.medium.com/algol-the-language-that-influenced-the-future-cfec9a3e2a4c>
can say
Generally called ALGOL 60, ALGOL had three major updates ...
On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
On Sun, 07 Apr 2024 06:04:16 -0400
Alan Bawden <alan@csail.mit.edu> wrote:
If acknowledging the existence of female developers makes you
uncomfortable, you're just going to have to learn to deal with that
yourself. I'm not going to adjust my language to cater to your
insecurities.
If my insecurities you mean acknowledging reality then fine. The thing about >> people like you is (and I don't believe the 50% thing, sorry) is that you
would never use a male pronoun if talking about nurses or pre school teachers
who are heavily biased towards women.
What makes you so sure about that? Are you assuming that because /you/
are sexist, everyone else is?
On Sun, 07 Apr 2024 00:01:43 +0000
Javier <invalid@invalid.invalid> wrote:
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.
You really want either built-ins for a lot of basic commands, or a good scheme for caching commonly-used executables. AmigaDOS (a TriPOS
derivative) made it pretty trivial to set up a RAM disk and add that to
the search path, which made a big difference in performance since
almost nothing was built-in. Wouldn't be hard to do in *nix-land,
either, but it's an open question whether you'd gain anything over
modern generalized disk caching.
On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
On Sun, 07 Apr 2024 06:04:16 -0400
Alan Bawden <alan@csail.mit.edu> wrote:
If acknowledging the existence of female developers makes you
uncomfortable, you're just going to have to learn to deal with that
yourself. I'm not going to adjust my language to cater to your
insecurities.
If my insecurities you mean acknowledging reality then fine. The thing about
people like you is (and I don't believe the 50% thing, sorry) is that you >>> would never use a male pronoun if talking about nurses or pre school teachers
who are heavily biased towards women.
What makes you so sure about that? Are you assuming that because /you/
are sexist, everyone else is?
An immediate fallacious ad hominem no doubt in order to prop up whatever straw men follow.
... compulsively indenting and
splitting across lines can get out of hand, too. It seems to me that a
lot of people in this age of "cinematic" aspect ratios and super-sized displays in personal computing forget that eye-travel isn't free, and spreading information across maximal space can make it *harder* to keep
track of context.
Hmm, wonder why hardly anyone outside academia used the language even back in the day, never mind now....
Also, I suspect HD caching and the increase in HD speed was one of the reasons for the fall in popularity of Perl for writing small system automation tasks that could be done with just shell. But there were
another reasons, like the disapearance of diversity in the Unix OS
ecosystem.
Perl made easy to write portable scripts that could run on propietary
Unixen that came with slight incompatibilities in the command line tools (IRIX/Solaris/HP-UX/AIX, etc.)
There it is again: “maximal space”. The “space” is there to be used. Code may be one-dimensional, but you have a two-dimensional screen to
display it, why not make use of that, if it makes a complex structure clearer?
Another example:
def fill_in_depreciations(tax_year) :
"(re)inserts depreciation entries for the specified tax year," \
" based on currently-entered assets."
sql.cursor.execute \
(
"delete from payments where kind = %s and tax_year = %s",
["D", tax_year]
)
for \
entry \
in \
get_each_record \
On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
What makes you so sure about that? Are you assuming that because /you/ >>>are sexist, everyone else is?
An immediate fallacious ad hominem no doubt in order to prop up whatever
straw men follow.
You wrote, "people like you ... would never use a male pronoun if
talking about nurses", written by you, is already ad hominem;
it's a direct accusation of hypocrisy, rather than focusing on the
argument content.
If you can't handle the ad-hominem ball returned to your court,
don't serve it!
On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
What makes you so sure about that? Are you assuming that because /you/ >>>>are sexist, everyone else is?
An immediate fallacious ad hominem no doubt in order to prop up whatever >>> straw men follow.
You wrote, "people like you ... would never use a male pronoun if
talking about nurses", written by you, is already ad hominem;
it's a direct accusation of hypocrisy, rather than focusing on the
argument content.
Mine was correct in general, yours shows you don't understand the difference between sexism and realism.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
There it is again: “maximal space”. The “space” is there to be used. >> Code may be one-dimensional, but you have a two-dimensional screen to
display it, why not make use of that, if it makes a complex structure
clearer?
Like I said: eye-travel. If the same amount of information is spread
out over a larger space, there comes a point where it's actually *more*
work to read, and it eventually becomes harder for the brain to keep
track of the relevant context as a result; the "flow" is broken.
On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
If you can't handle the ad-hominem ball returned to your court,
don't serve it!
In tennis spectators don't generally jump onto the court and return the ball.
John Ames <commodorejohn@gmail.com> writes:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
There it is again: “maximal space”. The “space” is there to be used.
Code may be one-dimensional, but you have a two-dimensional screen to
display it, why not make use of that, if it makes a complex structure
clearer?
Like I said: eye-travel. If the same amount of information is spread
out over a larger space, there comes a point where it's actually *more*
work to read, and it eventually becomes harder for the brain to keep
track of the relevant context as a result; the "flow" is broken.
Also, the more it’s spread out, the less of it you can get on one
screen, and the resulting need for paging makes the medium-scale
structure a lot less clear.
John Ames <commodorejohn@gmail.com> writes:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
There it is again: “maximal space”. The “space” is there to be used.
Code may be one-dimensional, but you have a two-dimensional screen to
display it, why not make use of that, if it makes a complex structure
clearer?
Like I said: eye-travel. If the same amount of information is spread
out over a larger space, there comes a point where it's actually *more*
work to read, and it eventually becomes harder for the brain to keep
track of the relevant context as a result; the "flow" is broken.
Also, the more it’s spread out, the less of it you can get on one
screen, and the resulting need for paging makes the medium-scale
structure a lot less clear.
Comments to say when your loop or functions end is another big red flag
that the layout is bad.
On Tue, 9 Apr 2024 10:11:09 +0200, David Brown wrote:
Comments to say when your loop or functions end is another big red flag
that the layout is bad.
Without #end comments: how easy is it to tell which lines belong to
the inner function, and which to the outer?
Muttley@dastardlyhq.com writes:
On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
What makes you so sure about that? Are you assuming that because /you/ >>>>>are sexist, everyone else is?
An immediate fallacious ad hominem no doubt in order to prop up whatever >>>> straw men follow.
You wrote, "people like you ... would never use a male pronoun if
talking about nurses", written by you, is already ad hominem;
it's a direct accusation of hypocrisy, rather than focusing on the >>>argument content.
Mine was correct in general
Only in your worldview.
FWIW, at the local A&E, the split is about 50-50.
On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
What makes you so sure about that? Are you assuming that because /you/ >>>>are sexist, everyone else is?
An immediate fallacious ad hominem no doubt in order to prop up whatever >>> straw men follow.
You wrote, "people like you ... would never use a male pronoun if
talking about nurses", written by you, is already ad hominem;
it's a direct accusation of hypocrisy, rather than focusing on the
argument content.
Mine was correct in general
On Tue, 09 Apr 2024 15:01:46 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
On Mon, 8 Apr 2024 19:32:21 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-04-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote: >>>>> On Mon, 8 Apr 2024 14:35:48 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 08/04/2024 09:47, Muttley@dastardlyhq.com wrote:
What makes you so sure about that? Are you assuming that because /you/ >>>>>>are sexist, everyone else is?
An immediate fallacious ad hominem no doubt in order to prop up whatever >>>>> straw men follow.
You wrote, "people like you ... would never use a male pronoun if >>>>talking about nurses", written by you, is already ad hominem;
it's a direct accusation of hypocrisy, rather than focusing on the >>>>argument content.
Mine was correct in general
Only in your worldview.
FWIW, at the local A&E, the split is about 50-50.
What local A&E? Here in the UK the vast majority of nurses are female whereas >with doctors its a more even mix.
On Tue, 9 Apr 2024 15:09:01 -0000 (UTC)
Muttley@dastardlyhq.com wrote:
Mine was correct in general
Only in your worldview.
FWIW, at the local A&E, the split is about 50-50.
What local A&E? Here in the UK the vast majority of nurses are female
whereas with doctors its a more even mix.
"I was actually correct in a broadly objective sense, if you discount >attestations to the contrary because I don't feel they match my
specific experience" is a *special* breed of argument :|
On 09.04.2024 09:47, Richard Kettlewell wrote:
John Ames <commodorejohn@gmail.com> writes:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
There it is again: “maximal space”. The “space” is there to be used.
Code may be one-dimensional, but you have a two-dimensional screen to
display it, why not make use of that, if it makes a complex structure
clearer?
Like I said: eye-travel. If the same amount of information is spread
out over a larger space, there comes a point where it's actually *more*
work to read, and it eventually becomes harder for the brain to keep
track of the relevant context as a result; the "flow" is broken.
Also, the more it’s spread out, the less of it you can get on one
screen, and the resulting need for paging makes the medium-scale
structure a lot less clear.
Add structuring code (e.g. using functions) to manage complexity
and make it possible to keep entities in appropriate sizes.
You could try doing what almost every other Python programmer does - use smaller functions and drop the silly line continuations.
On Tue, 9 Apr 2024 15:22:25 +0200, David Brown wrote:
You could try doing what almost every other Python programmer does - use
smaller functions and drop the silly line continuations.
Fine. Try that with the example I gave.
On 07.04.2024 23:05, Lawrence D'Oliveiro wrote:
Even in the 21st century, articles likeAn extremely badly written article in *all* aspects (form, content,
<https:// [... snipped, to avoid giving it more publicity -- ANW]
facts, quality, etc.).
Muttley@dastardlyhq.com writes:
[...]
ITYM "he" would allow HIMself.
I am looking forward with great eagerness to this subthread dying out,
and I encourage everyone to help make that happen.
On 08/04/2024 13:53, Janis Papanagnou wrote:
On 07.04.2024 23:05, Lawrence D'Oliveiro wrote:
Even in the 21st century, articles likeAn extremely badly written article in *all* aspects (form, content,
<https:// [... snipped, to avoid giving it more publicity -- ANW]
facts, quality, etc.).
Agreed. I think it is a prime candidate for the worst serious supposedly-scientific web page I've ever seen.
If it was written by a
12yo with access to ChatGPT, that would not surprise me.
It has two
indirect redeeming features:
-- It pointed me at "https://opensource.com/article/20/6/algol68",
which /is/ worth reading.
-- Its list of the A60 committee members prompted me to check, and I
found, somewhat to my surprise, that one of them, Mike Woodger,
who I worked with briefly nearly 50 years ago, is still alive, aged
101. Having recently seen a couple of new scientific papers by F. G.
Smith, the former Astronomer Royal, aged 100, perhaps we are entering
a new era of golden oldies? Richard Guy made it to 103, and was still
working past his century. I know of a fair number of nonagenarians,
not least Tom Lehrer [96 yesterday], but [mostly] not whether they are
still active.
[ Friedrich L. Bauer ] - He died 9 years ago at age of 91.
Two weeks ago would have been his centenary!
Janis
I don't worry about that anymore. My bash scripts run blazing fast
in my laptop with an SSD.
I guess it was an issue at the time Perl
appeared (1987), although TBH I didn't experience it myself, since at
that time I wasn't a Unix user.
Also, I suspect HD caching and the increase in HD speed was one of the reasons for the fall in popularity of Perl for writing small system automation tasks that could be done with just shell. But there were
another reasons, like the disapearance of diversity in the Unix OS ecosystem. Perl made easy to write portable scripts that could run on propietary Unixen that came with slight incompatibilities in the command line tools (IRIX/Solaris/HP-UX/AIX, etc.)
Perhaps somebody here who uses (or used to use) Perl for system
automation tasks can tell us more about their personal reasons
for prefering (or used to prefer) Perl over shell.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
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.
If that saves a process, it's because echo is builtin.
But it will set
$nfiles to 1 (unless you happen to have files with newlines in their
names). Both skip hidden files, which may or may not be what you want.
[...]
Python:
There should be one - and preferably only one - obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
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.Indentation generally helps.
a =
b ?
c ? d : e
: f ?
g ? h : i
: j;
Let me give it a try to find how I would indent that!
b?
c? d: e:
f?
g? h: i:
j;
Better:
a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;
Equivalent Lisp, for comparison:
(setf a (cond (b (if c d e))
(f (if g h i))
(t j)))
Equivalent Lisp, for comparison:
(setf a (cond (b (if c d e))
(f (if g h i))
(t j)))
You can’t avoid the parentheses, but this, too, can be improved:
(setf a
(cond
(b
(if c d e)
)
(f
(if g h i)
)
(t
j
)
) ; cond
)
On 2024-08-06, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Equivalent Lisp, for comparison:
(setf a (cond (b (if c d e))
(f (if g h i))
(t j)))
You can’t avoid the parentheses, but this, too, can be improved:
(setf a
(cond
(b
(if c d e)
)
(f
(if g h i)
)
(t
j
)
) ; cond
)
Nobody is ever going to follow your idio(syncra)tic coding preferences
for Lisp, that wouldn't pass code review in any Lisp shop, and result in >patches being rejected in a FOSS setting.
On Tue, 6 Aug 2024 08:04:35 -0000 (UTC), Sebastian wrote:
Better:
a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;
Better still (fewer confusing parentheses):
a =
b ?
c ? d : e
: f ?
g ? h : i
: j;
Equivalent Lisp, for comparison:
(setf a (cond (b (if c d e))
(f (if g h i))
(t j)))
You can’t avoid the parentheses, but this, too, can be improved:
(setf a
(cond
(b
(if c d e)
)
(f
(if g h i)
)
(t
j
)
) ; cond
)
On Thu, 08 Aug 2024 17:25:54 +0200, Andreas Eder wrote:
Sorry, but that is not an improvement but rather an abomination.
Aw, diddums.
Sorry, but that is not an improvement but rather an abomination.
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
a =
b ?
c ? d : e
: f ?
g ? h : i
: j;
I find this more confusing than the parentheses.
On Tue, 6 Aug 2024 08:04:35 -0000 (UTC), Sebastian wrote:
Better:
a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;
Better still (fewer confusing parentheses):
a =
b ?
c ? d : e
: f ?
g ? h : i
: j;
Equivalent Lisp, for comparison:
(setf a (cond (b (if c d e))
(f (if g h i))
(t j)))
You can?t avoid the parentheses, but this, too, can be improved:
(setf a
(cond
(b
(if c d e)
)
(f
(if g h i)
)
(t
j
)
) ; cond
)
On Sun, 25 Aug 2024 07:32:26 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
a =
b ?
c ? d : e
: f ?
g ? h : i
: j;
I find this more confusing than the parentheses.
Not accustomed to looking at source code in 2D? You have to feel your way from symbol to symbol like brackets, rather than being able to see overall shapes?
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 25 Aug 2024 07:32:26 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
a =
b ?
c ? d : e
: f ?
g ? h : i
: j;
I find this more confusing than the parentheses.
Not accustomed to looking at source code in 2D? You have to feel your
way from symbol to symbol like brackets, rather than being able to see
overall shapes?
Says the guy who finds a few brackets so confusing that he
Black-formatted a snippet of Lisp code.
On Mon, 26 Aug 2024 16:13:33 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 25 Aug 2024 07:32:26 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Says the guy who finds a few brackets so confusing that he
Black-formatted a snippet of Lisp code.
I use the same principles in all my code. (And I have no idea about
this ?Black? thing. I just do my thing.)
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
(And I have no idea about this “Black” thing. I just do my thing.)
Black is a [bla bla bla]
On Tue, 27 Aug 2024 03:15:16 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
(And I have no idea about this “Black” thing. I just do my thing.)
Black is a [bla bla bla]
*Yawn*
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 27 Aug 2024 03:15:16 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
(And I have no idea about this “Black” thing. I just do my thing.)
Black is a [bla bla bla]
*Yawn*
The guy was kindly and politely sharing information with you.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 27 Aug 2024 19:56:50 -0300, Johanne Fairchild wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 27 Aug 2024 03:15:16 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >>>>>>
(And I have no idea about this “Black” thing. I just do my thing.) >>>>>Black is a [bla bla bla]
*Yawn*
The guy was kindly and politely sharing information with you.
Didn’t ask, didn’t know, didn’t care.
Knock yourself out. You have the freedom to disdain.
On Tue, 27 Aug 2024 19:56:50 -0300, Johanne Fairchild wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Tue, 27 Aug 2024 03:15:16 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Black is a [bla bla bla]
(And I have no idea about this “Black” thing. I just do my thing.) >>>>
*Yawn*
The guy was kindly and politely sharing information with you.
Didn’t ask, didn’t know, didn’t care.
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Mon, 26 Aug 2024 16:13:33 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 25 Aug 2024 07:32:26 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Says the guy who finds a few brackets so confusing that he
Black-formatted a snippet of Lisp code.
I use the same principles in all my code. (And I have no idea about
this ?Black? thing. I just do my thing.)
Black is a Python program that formats Python code
almost exactly the way you formatted that snippet of Lisp
code. It's just as ugly in Python as it is in Lisp. Black
spreads by convincing organizations to mandate its use. It's
utterly non-configurable on purpose, in order to guarantee
that eventually, all Python code is made to be as ugly
and unreadable as possible.
On Wed, 7 Aug 2024 13:43:10 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> boringly babbled:
On 2024-08-06, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Equivalent Lisp, for comparison:
(setf a (cond (b (if c d e))
(f (if g h i))
(t j)))
You can’t avoid the parentheses, but this, too, can be improved:
(setf a
(cond
(b
(if c d e)
)
(f
(if g h i)
)
(t
j
)
) ; cond
)
Nobody is ever going to follow your idio(syncra)tic coding preferences
for Lisp, that wouldn't pass code review in any Lisp shop, and result in >>patches being rejected in a FOSS setting.
I'm not a Lisp dev, but the original looks far more readable to me.
His definition of improvement seems to be obfuscation.
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.
Perl is more awk+sed+sh in a single language. Basically the killer of
the Unix philophy in late 90's/early 00's, and for the good.
Check Emacs' eshell where you can mix pseudo-sh code with Elisp
On Mon, 30 Sep 2024 20:04:54 -0000 (UTC), Bozo User wrote:responds>:
Perl is more awk+sed+sh in a single language. Basically the killer of
the Unix philophy in late 90's/early 00's, and for the good.
That’s what Rob Pike said <https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-
Q: “Given the nature of current operating systems and applications,
do you think the idea of "one tool doing one job well" has been
abandoned?”
A: “Those days are dead and gone and the eulogy was delivered by
Perl.”
But I’m not sure I agree. Those small, specialized tools always required large, monolithic pieces under them to operate: the shell itself for
shell scripts, the X server for GUI apps, the kernel itself for
everything. So while the coming of Perl has changed some things,
it has not made a difference to the modularity of the Unix way.
On Mon, 30 Sep 2024 20:04:53 -0000 (UTC), Bozo User wrote:
Check Emacs' eshell where you can mix pseudo-sh code with Elisp
Can you give examples that either support or refute my claim?
With eshell you can do sh like commands and put elisp (literal lisp
code) inside a loop:
https://howardism.org/Technical/Emacs/eshell-why.html
El Mon, 30 Sep 2024 21:04:24 -0000 (UTC), Lawrence D'Oliveiro escribió:
On Mon, 30 Sep 2024 20:04:54 -0000 (UTC), Bozo User wrote:
Perl is more awk+sed+sh in a single language. Basically the killer of
the Unix philophy in late 90's/early 00's, and for the good.
That’s what Rob Pike said
<https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike- >responds>:
Q: “Given the nature of current operating systems and applications,
do you think the idea of "one tool doing one job well" has been
abandoned?”
A: “Those days are dead and gone and the eulogy was delivered by
Perl.”
But I’m not sure I agree. Those small, specialized tools always required >> large, monolithic pieces under them to operate: the shell itself for
shell scripts, the X server for GUI apps, the kernel itself for
everything. So while the coming of Perl has changed some things,
it has not made a difference to the modularity of the Unix way.
The shell could be changed as just a command launcher with no
conditionals, while perl doing all the hard work.
On X11/X.org, X11 was never very "Unix like" by itself.
On Tue, 1 Oct 2024 20:18:28 -0000 (UTC)
usuario <anthk@disroot.org> boring babbled:
El Mon, 30 Sep 2024 21:04:24 -0000 (UTC), Lawrence D'Oliveiro escribió:
On Mon, 30 Sep 2024 20:04:54 -0000 (UTC), Bozo User wrote:
Perl is more awk+sed+sh in a single language. Basically the killer of
the Unix philophy in late 90's/early 00's, and for the good.
That’s what Rob Pike said
<https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike- >>responds>:
Q: “Given the nature of current operating systems and
applications,
do you think the idea of "one tool doing one job well" has been
abandoned?”
A: “Those days are dead and gone and the eulogy was delivered by
Perl.”
But I’m not sure I agree. Those small, specialized tools always
required large, monolithic pieces under them to operate: the shell
itself for shell scripts, the X server for GUI apps, the kernel itself
for everything. So while the coming of Perl has changed some things,
it has not made a difference to the modularity of the Unix way.
The shell could be changed as just a command launcher with no
conditionals, while perl doing all the hard work.
On X11/X.org, X11 was never very "Unix like" by itself.
An X server is about as minimal as you can have a graphics system and
still make it usable. I don't see how it could have been subdivided any further and still work.
El Wed, 2 Oct 2024 07:10:32 -0000 (UTC), Muttley escribió:
An X server is about as minimal as you can have a graphics system and
still make it usable. I don't see how it could have been subdivided any
further and still work.
Check out Blit under Unix V10 and Rio under plan9/9front for a much better >Unix-oriented (9front/plan9 it's basically Unix philosophy 2.0) approach.
On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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.
Perl is more awk+sed+sh in a single language. Basically the killer
of the Unix philophy in late 90's/early 00's, and for the good.
Bozo User <anthk@disroot.org> writes:
On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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.
Perl is more awk+sed+sh in a single language. Basically the killer
of the Unix philophy in late 90's/early 00's, and for the good.
Perl is a high-level programming language with a rich syntax¹, with
support for deterministic automatic memory management, functions as >first-class objects and message-based OO. It's also a virtual machine
for executing threaded code and a(n optimizing) compiler for translating
Perl code into the corresponding threaded code.
On Wed, 09 Oct 2024 22:25:05 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Bozo User <anthk@disroot.org> writes:
On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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.
Perl is more awk+sed+sh in a single language. Basically the killer
of the Unix philophy in late 90's/early 00's, and for the good.
Perl is a high-level programming language with a rich syntax¹, with >>support for deterministic automatic memory management, functions as >>first-class objects and message-based OO. It's also a virtual machine
for executing threaded code and a(n optimizing) compiler for translating >>Perl code into the corresponding threaded code.
Its syntax is also a horrific mess.
Its no surprise Perl has been ditched in favour of Python just about everywhere for new scripting projects.
Its syntax is also a horrific mess.
Which means precisely what?
Its no surprise Perl has been ditched in favour of Python just about
everywhere for new scripting projects.
"I say so and I'm an avid Phython fan?"
Not much of a reason.
On Thu, 10 Oct 2024 16:09:49 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Muttley@DastartdlyHQ.org writes:
Its syntax is also a horrific mess.
Which means precisely what?
Far too much pointless punctuation. An interpreter shouldn't need the vartype signified by $ or @ once its defined, it should already know.
And then there are semantically meaningful underscores (seriously?)
and random hacky keywords such as <STDIN>.
I could go on.
Muttley@DastartdlyHQ.org ignorantly rambled:
On Thu, 10 Oct 2024 16:09:49 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled: >>>Muttley@DastartdlyHQ.org writes:
Its syntax is also a horrific mess.
Which means precisely what?
Far too much pointless punctuation. An interpreter shouldn't need the vartype
signified by $ or @ once its defined, it should already know.
For the purpose of variable declaration, how's the interpeter going to
know the type of a variable without being told about it? Obviously, not
at all.
On 2024-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
Muttley@DastartdlyHQ.org ignorantly rambled:
On Thu, 10 Oct 2024 16:09:49 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled: >>>>Muttley@DastartdlyHQ.org writes:
Its syntax is also a horrific mess.
Which means precisely what?
Far too much pointless punctuation. An interpreter shouldn't need the vartype
signified by $ or @ once its defined, it should already know.
For the purpose of variable declaration, how's the interpeter going to
Interpreter? Perl has some kind of compiler in it, right?
know the type of a variable without being told about it? Obviously, not
at all.
But it's not exactly type, because $x means "scalar variable of any
type" whereas @x is an "array of any type".
That's quite useless for proper type checking and only causes noise,
due to having to be repeated.
Actually typed languages don't use sigils. How is that?
The type of a name is declared (or else inferred); references to that
name don't need to repeat that info.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
Thinks start to become complicated once references to complex objects
are involved. Eg,
@{$$a[0]}
is the array referred to by the first item of the array $a refers to and
${$$a[0]}[0]
which seriously starts to look like a trench fortification with
barbed-wire obstacles is a way to refer to the first element of this
array.
Muttley@DastartdlyHQ.org ignorantly rambled:
On Thu, 10 Oct 2024 16:09:49 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Muttley@DastartdlyHQ.org writes:
Its syntax is also a horrific mess.
Which means precisely what?
Far too much pointless punctuation. An interpreter shouldn't need the vartype
signified by $ or @ once its defined, it should already know.
For the purpose of variable declaration, how's the interpeter going to
know the type of a variable without being told about it? Obviously, not
at all.
Perl has three builtin types, scalars, arrays and hashes and
each is denoted by a single-letter prefix which effectively creates
three different variable namespaces, one for each type. That's often convenient, because the same name can be reused for a variable of a
different type, eg:
my ($data, @data, %data);
$data = rand(128);
@data = ($data, $data + 1);
%data = map { $_, 15 } @data;
it's also convenient to type and easy to read due to being concise.
Outside of declarations, $ and @ really denote access modes/ contexts,
with $ standing for "a thing" and @ for "a number of things", eg
$a[0]
is the first element of the array @a and
@a[-3 .. -1]
is a list composed of the three last elements of @a.
An interpreter shouldn't need the vartype signified by $ or @ once its defined, it should already know.
On Thu, 10 Oct 2024 16:09:49 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled: >>>Muttley@DastartdlyHQ.org writes:
Its syntax is also a horrific mess.
Which means precisely what?
Far too much pointless punctuation. An interpreter shouldn't need the vartype
signified by $ or @ once its defined, it should already know.
For the purpose of variable declaration, how's the interpeter going to
convenient, because the same name can be reused for a variable of a
different type, eg:
my ($data, @data, %data);
$data = rand(128);
@data = ($data, $data + 1);
%data = map { $_, 15 } @data;
it's also convenient to type and easy to read due to being concise.
and returns the next line read from this file handle. In list context,
it returns all lines in the file.
Eg, this a poor man's implementation of cat:
perl -e 'open($fh, $_) and print <$fh> for @ARGV'
Please don't enumerate everything else on this planet you also don't
really understand as that's probably going to become a huge list. ;-)
On 10/10/2024 17:55, Rainer Weikusat wrote:
Muttley@DastartdlyHQ.org ignorantly rambled:
On Thu, 10 Oct 2024 16:09:49 +0100For the purpose of variable declaration, how's the interpeter going
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Muttley@DastartdlyHQ.org writes:
Its syntax is also a horrific mess.
Which means precisely what?
Far too much pointless punctuation. An interpreter shouldn't need the vartype
signified by $ or @ once its defined, it should already know.
to
know the type of a variable without being told about it? Obviously, not
at all.
Perl has three builtin types, scalars, arrays and hashes and
each is denoted by a single-letter prefix which effectively creates
three different variable namespaces, one for each type. That's often
convenient, because the same name can be reused for a variable of a
different type, eg:
my ($data, @data, %data);
Why would you want to do this?
$data = rand(128);
@data = ($data, $data + 1);
%data = map { $_, 15 } @data;
it's also convenient to type and easy to read due to being concise.
Adding shifted punctuation at the start of every instance of a
variable? I don't call that convenient!
So, $ is scalar, @ is an array, and % is a hash?
Outside of declarations, $ and @ really denote access modes/ contexts,
with $ standing for "a thing" and @ for "a number of things", eg
$a[0]
is the first element of the array @a and
Now I'm already lost. 'a' is an array, but it's being used with $?
What would just this:
a[0]
mean by itself?
@a[-3 .. -1]
is a list composed of the three last elements of @a.
Sorry, these prefixes look utterly pointless to me. This stuff works perfectly well in other languages without them.
I can write a[i..j] in mine and I know that it yields a slice.
What would $a[-3 .. -1] mean?
What happens if you have an array of mixed scalars, arrays and hashes;
what prefix to use in front of a[i]?
On 2024-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
Muttley@DastartdlyHQ.org ignorantly rambled:
On Thu, 10 Oct 2024 16:09:49 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled: >>>>Muttley@DastartdlyHQ.org writes:
Its syntax is also a horrific mess.
Which means precisely what?
Far too much pointless punctuation. An interpreter shouldn't need the vartype
signified by $ or @ once its defined, it should already know.
For the purpose of variable declaration, how's the interpeter going to
Interpreter? Perl has some kind of compiler in it, right?
know the type of a variable without being told about it? Obviously, not
at all.
But it's not exactly type, because $x means "scalar variable of any
type" whereas @x is an "array of any type".
That's quite useless for proper type checking and only causes noise,
due to having to be repeated.
Actually typed languages don't use sigils. How is that?
The type of a name is declared (or else inferred); references to that
name don't need to repeat that info.
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Bart <bc@freeuk.com> writes:
Interpreter? Perl has some kind of compiler in it, right?
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler. However unlike the python interpreter its non interactive >making it an even less attractive option these days.
Bart <bc@freeuk.com> writes:
Interpreter? Perl has some kind of compiler in it, right?
The Perl compiler turns Perl source code into a set of (that's a
In article <vebffc$3n6jv$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Bart <bc@freeuk.com> writes:
Interpreter? Perl has some kind of compiler in it, right?
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler. However unlike the python interpreter its non interactive >>making it an even less attractive option these days.
That's a bad distinction. There have been "Load and Go"
compilers in the past that have compiled and linked a program
directly into memory and executed it immediately after
compilation. As I recall, the Waterloo FORTRAN compilers on the
IBM mainframe did, or could do, more or less this.
Saving to some sort of object image is not a necessary function
of a compiler.
In article <vebffc$3n6jv$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Bart <bc@freeuk.com> writes:
Interpreter? Perl has some kind of compiler in it, right?
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler. However unlike the python interpreter its non interactive >>making it an even less attractive option these days.
That's a bad distinction. There have been "Load and Go"
compilers in the past that have compiled and linked a program
directly into memory and executed it immediately after
compilation. As I recall, the Waterloo FORTRAN compilers on the
IBM mainframe did, or could do, more or less this.
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <vebffc$3n6jv$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>>On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Bart <bc@freeuk.com> writes:
Interpreter? Perl has some kind of compiler in it, right?
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter >>>not a compiler. However unlike the python interpreter its non interactive >>>making it an even less attractive option these days.
That's a bad distinction. There have been "Load and Go"
compilers in the past that have compiled and linked a program
directly into memory and executed it immediately after
compilation. As I recall, the Waterloo FORTRAN compilers on the
IBM mainframe did, or could do, more or less this.
Irrelevant. Lot of interpreters do partial compilation and the JVM does it
on the fly. A proper compiler writes a standalone binary file to disk.
Saving to some sort of object image is not a necessary function
of a compiler.
Yes it is.
On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Bart <bc@freeuk.com> writes:
Interpreter? Perl has some kind of compiler in it, right?
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler. However unlike the python interpreter its non interactive making it an even less attractive option these days.
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Eg, this a poor man's implementation of cat:
perl -e 'open($fh, $_) and print <$fh> for @ARGV'
Meanwhile in awk: { print }
On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net>:
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler.
In article <vebi0j$3nhvq$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>Irrelevant. Lot of interpreters do partial compilation and the JVM does it >>on the fly. A proper compiler writes a standalone binary file to disk.
Not generally, no. Most compilers these days generate object
code and then, as a separate step, a linker is invoked to
combine object files and library archives into an executable
binary.
By the way, when many people talk about a "standalone" binary,
they are referring to something directly executable on hardware,
without the benefit of an operating system. The Unix kernel is
an example of such a "standalone binary."
Most executable binaries are not standalone.
Saving to some sort of object image is not a necessary function
of a compiler.
Yes it is.
So you say, but that's not the commonly accepted definition.
Sorry.
On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Bart <bc@freeuk.com> writes:
Interpreter? Perl has some kind of compiler in it, right?
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler. However unlike the python interpreter its non interactive
making it an even less attractive option these days.
The perl debugger offers an interactive environment (with line editing support >if
the necessary packages/ modules are available). It can be invoked with a >suitable 'script argument' to use it without actually debugging
something, eg,
perl -de 0
On Fri, 11 Oct 2024 15:15:57 -0000 (UTC), Muttley wrote:
On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net>:
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler.
There are two parts: the interpreter interprets code generated by the compiler.
Remember, your CPU is an interpreter, too.
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <vebi0j$3nhvq$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>>Irrelevant. Lot of interpreters do partial compilation and the JVM does it >>>on the fly. A proper compiler writes a standalone binary file to disk.
Not generally, no. Most compilers these days generate object
code and then, as a separate step, a linker is invoked to
combine object files and library archives into an executable
binary.
Ok, the compiler toolchain then. Most people invoke it using a single command, >the rest is behind the scenes.
By the way, when many people talk about a "standalone" binary,
they are referring to something directly executable on hardware,
For many read a tiny minority.
without the benefit of an operating system. The Unix kernel is
an example of such a "standalone binary."
If you're going to nitpick then I'm afraid you're wrong. Almost all operating >systems require some kind of bootloader and/or BIOS combination to start them >up. You can't just point the CPU at the first byte of the binary and off it >goes particularly in the case of Linux where the kernel requires decompressing >first.
Most executable binaries are not standalone.
Standalone as you are well aware in the sense of doesn't require an interpreter
or VM to run on the OS and contains CPU machine code.
Saving to some sort of object image is not a necessary function
of a compiler.
Yes it is.
So you say, but that's not the commonly accepted definition.
Sorry.
Where do you get this commonly accepted definition from?
On Fri, 11 Oct 2024 20:58:26 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boring babbled:
On Fri, 11 Oct 2024 15:15:57 -0000 (UTC), Muttley wrote:
On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net>:
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter
not a compiler.
There are two parts: the interpreter interprets code generated by the compiler.
Code generated by a compiler does not require an interpreter.
In article <vedcjc$3mqn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>up. You can't just point the CPU at the first byte of the binary and off it >>goes particularly in the case of Linux where the kernel requires decompressing
first.
Again, not generally, no. Consider an embedded system where the
program to be executed on, say, a microcontroller is itself
statically linked at an absolute address and burned into a ROM,
with the program's entry point at the CPU's reset address. I
suppose that's not "standalone" if you count a ROM burner as
part of "loading" it.
Also, I mentioned Unix, not Linux. The two are different. The
Standalone as you are well aware in the sense of doesn't require an >interpreter
or VM to run on the OS and contains CPU machine code.
So what about a binary that is dynamically linked with a shared
object? That requires a runtime interpreter nee linker to bind
its constituent parts together before it's executable. And what
if it makes a system call? Then it's no longer "standalone", as
it necessarily relies on the operating system to perform part of
its function.
usually in userspace. Why do you think that a compiler that
generates bytecode for some virtual machine is any different
from a compiler that generates object code for some CPU?
You don't seem to be able to recognize that the compilation step
Where do you get this commonly accepted definition from?
*shrug* Tanenbaum; Silberschatz; Kaashoek; Roscoe; etc. Where
did you get your definition?
Muttley@dastardlyhq.com writes:
Standalone in the sense that the opcodes in the binary don't need to be >>transformed into something else before being loaded by the CPU.
That's a rather unique definition of 'standalone'.
On Sat, 12 Oct 2024 13:53:56 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <vedcjc$3mqn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>>up. You can't just point the CPU at the first byte of the binary and off it >>>goes particularly in the case of Linux where the kernel requires decompressing
first.
Again, not generally, no. Consider an embedded system where the
program to be executed on, say, a microcontroller is itself
statically linked at an absolute address and burned into a ROM,
Unlikely to be running *nix in that case.
So what about a binary that is dynamically linked with a shared
object? That requires a runtime interpreter nee linker to bind
its constituent parts together before it's executable. And what
if it makes a system call? Then it's no longer "standalone", as
it necessarily relies on the operating system to perform part of
its function.
Standalone in the sense that the opcodes in the binary don't need to be >transformed into something else before being loaded by the CPU.
On Sat, 12 Oct 2024 13:53:56 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) gabbled:
In article <vedcjc$3mqn$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>>up. You can't just point the CPU at the first byte of the binary and off it >>>goes particularly in the case of Linux where the kernel requires decompressing
first.
Again, not generally, no. Consider an embedded system where the
program to be executed on, say, a microcontroller is itself
statically linked at an absolute address and burned into a ROM,
Unlikely to be running *nix in that case.
with the program's entry point at the CPU's reset address. I
suppose that's not "standalone" if you count a ROM burner as
part of "loading" it.
Now you're just being silly.
Also, I mentioned Unix, not Linux. The two are different. The
Are they? Thats debatable these days. I'd say Linux is a lot closer to
the philosphy of BSD and SYS-V than MacOS which is a certified unix.
Standalone as you are well aware in the sense of doesn't require an >>interpreter
or VM to run on the OS and contains CPU machine code.
So what about a binary that is dynamically linked with a shared
object? That requires a runtime interpreter nee linker to bind
its constituent parts together before it's executable. And what
if it makes a system call? Then it's no longer "standalone", as
it necessarily relies on the operating system to perform part of
its function.
Standalone in the sense that the opcodes in the binary don't need to be >transformed into something else before being loaded by the CPU.
usually in userspace. Why do you think that a compiler that
generates bytecode for some virtual machine is any different
from a compiler that generates object code for some CPU?
I'd say its a grey area because it isn't full compilation is it, the p-code >still requires an interpreter before it'll run.
You don't seem to be able to recognize that the compilation step
Compiling is not the same as converting. Is a javascript to C converter a >compiler? By your definition it is.
Where do you get this commonly accepted definition from?
*shrug* Tanenbaum; Silberschatz; Kaashoek; Roscoe; etc. Where
did you get your definition?
Only heard of one of them so mostly irrelevant. Mine come from the name of >tools that compile code to a runnable binary.
Muttley@DastartdlyHQ.org writes:
On Wed, 09 Oct 2024 22:25:05 +0100 Rainer Weikusat
<rweikusat@talktalk.net> boring babbled:
Bozo User <anthk@disroot.org> writes:
On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 07 Apr 2024 00:01:43 +0000, Javier wrote:
Its syntax is also a horrific mess.Which means precisely what?
Indeed. As far as I know the term, an interpreter is something which
reads text from a file, parses it an checks it for syntax errors
and then executes the code as soon as enough of it has been gathered to
allow for execution of something, ie, a complete statement. This read,
check and parse, execute cycle is repeated until the program
terminates.
Muttley@DastartdlyHQ.org writes:
On Fri, 11 Oct 2024 20:58:26 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boring babbled:
On Fri, 11 Oct 2024 15:15:57 -0000 (UTC), Muttley wrote:
On Fri, 11 Oct 2024 15:47:06 +0100
Rainer Weikusat <rweikusat@talktalk.net>:
The Perl compiler turns Perl source code into a set of (that's a
Does it produce a standalone binary as output? No, so its an intepreter >>>> not a compiler.
There are two parts: the interpreter interprets code generated by the compiler.
Code generated by a compiler does not require an interpreter.
Indeed. As far as I know the term, an interpreter is something which
reads text from a file, parses it an checks it for syntax errors
and then executes the code as soon as enough of it has been gathered to
allow for execution of something, ie, a complete statement. This read,
check and parse, execute cycle is repeated until the program
terminates.
In contrast to this, a compiler reads the source code completely, parses
and checks it and then transforms it into some sort of "other
representation" which can be executed without dealing with the source
code (text) again.
Code generated by a compiler does not require an interpreter.
If you want to go down the reductio ad absurdum route then the electrons
are interpreters too.
with <87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com> Rainer
Weikusat wrote:
Muttley@DastartdlyHQ.org writes:
On Wed, 09 Oct 2024 22:25:05 +0100 Rainer Weikusat
<rweikusat@talktalk.net> boring babbled:
Bozo User <anthk@disroot.org> writes:
On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 07 Apr 2024 00:01:43 +0000, Javier wrote:
*CUT* [ 19 lines 6 levels deep]
Its syntax is also a horrific mess.Which means precisely what?
You're arguing with Unix Haters Handbook. You've already lost.
On 2024-10-12, Rainer Weikusat <rweikusat@talktalk.net> wrote:
Indeed. As far as I know the term, an interpreter is something which
reads text from a file, parses it an checks it for syntax errors
and then executes the code as soon as enough of it has been gathered to
allow for execution of something, ie, a complete statement. This read,
check and parse, execute cycle is repeated until the program
terminates.
I don't really want to participate in this discussion, but what
you're saying there is that all those 1980s home computer BASIC
interpreters, which read and tokenized a program before execution,
were actually compilers.
On Sat, 12 Oct 2024 08:42:17 -0000 (UTC), Muttley wrote:
Code generated by a compiler does not require an interpreter.
Something has to implement the rules of the “machine language”. This is >why we use the term “abstract machine”, to avoid having to distinguish >between “hardware” and “software”.
Think: modern CPUs typically have “microcode” and “firmware” >associated
with them. Are those “hardware” or “software”?
If you want to go down the reductio ad absurdum route then the electrons
are interpreters too.
<https://www.americanscientist.org/article/the-computational-universe> ><https://en.wikipedia.org/wiki/Digital_physics>
In article <vee2b1$6vup$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>Unlikely to be running *nix in that case.
We're discussing the concept of a "standalone binary"; you seem
to think that means a binary image emitted by a linker and meant
to run under a hosted environment, like an operating system. It
does not.
Now you're just being silly.
*shrug* Not my problem if you haven't dealt with many embedded
systems.
Are they? Thats debatable these days. I'd say Linux is a lot closer to
the philosphy of BSD and SYS-V than MacOS which is a certified unix.
Yes, they are.
Standalone in the sense that the opcodes in the binary don't need to be >>transformed into something else before being loaded by the CPU.
Yeah, no, that's not what anybody serious means when they say
that.
I'd say its a grey area because it isn't full compilation is it, the p-code >>still requires an interpreter before it'll run.
Nope.
Compiling is not the same as converting. Is a javascript to C converter a >>compiler? By your definition it is.
Yes, of course it is. So is the terminfo compiler, and any
number of other similar things. The first C++ compiler, cfront
emitted C code, not object code. Was it not a compiler?
Only heard of one of them so mostly irrelevant. Mine come from the name of >>tools that compile code to a runnable binary.
It's very odd that you seek to speak from a position of
authority when you don't even know who most of the major people
in the field are.
On Sat, 12 Oct 2024 16:39:20 +0000
Eric Pozharski <apple.universe@posteo.net> boring babbled:
[...]
You're arguing with Unix Haters Handbook. You've already lost.
ITYF the people who dislike Perl are the ones who actually like the unix
way of having simple daisychained tools instead of some lump of a language that does everything messily.
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <vee2b1$6vup$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>>Unlikely to be running *nix in that case.
We're discussing the concept of a "standalone binary"; you seem
to think that means a binary image emitted by a linker and meant
to run under a hosted environment, like an operating system. It
does not.
It can mean either. Essentially its a binary that contains directly runnable >CPU machine code. I'm not sure why you're having such a conceptual struggle >understanding this simple concept.
Now you're just being silly.
*shrug* Not my problem if you haven't dealt with many embedded
systems.
I could bore you with the number I've actually "dealt with" including >military hardware but whats the point.
You've probably programmed the
occasional PIC or arduino and think you're an expert.
Are they? Thats debatable these days. I'd say Linux is a lot closer to >>>the philosphy of BSD and SYS-V than MacOS which is a certified unix.
Yes, they are.
I disagree. Modern linux reminds me a lot of SunOS and HP-UX from back in
the day.
Not something that can be said for MacOS with its role-our-own
Apple specific way of doing pretty much everything.
Standalone in the sense that the opcodes in the binary don't need to be >>>transformed into something else before being loaded by the CPU.
Yeah, no, that's not what anybody serious means when they say
that.
Anybody serious presumably meaning you.
I'd say its a grey area because it isn't full compilation is it, the p-code >>>still requires an interpreter before it'll run.
Nope.
Really? So java bytecode will run direct on x86 or ARM will it? Please give >some links to this astounding discovery you've made.
Compiling is not the same as converting. Is a javascript to C converter a >>>compiler? By your definition it is.
Yes, of course it is. So is the terminfo compiler, and any
So in your mind google translate is a "compiler" for spoken languages is it?
number of other similar things. The first C++ compiler, cfront
emitted C code, not object code. Was it not a compiler?
No, it was a pre-compiler. Just like Oracles PRO*C/C++.
Only heard of one of them so mostly irrelevant. Mine come from the name of >>>tools that compile code to a runnable binary.
It's very odd that you seek to speak from a position of
authority when you don't even know who most of the major people
in the field are.
I know the important ones. You've dug out some obscure names from google
that probably only a few CS courses even mention never mind study the work of.
On Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <vee2b1$6vup$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote: >>>Unlikely to be running *nix in that case.
*shrug* Not my problem if you haven't dealt with many embedded
systems.
I could bore you with the number I've actually "dealt with" including >military hardware but whats the point. You've probably programmed the >occasional PIC or arduino and think you're an expert.
In article <vefvo0$k1mm$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
Really? So java bytecode will run direct on x86 or ARM will it? Please give >>some links to this astounding discovery you've made.
Um, ok. https://en.wikipedia.org/wiki/Jazelle
In article <vefvo0$k1mm$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>On Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
It can mean either. Essentially its a binary that contains directly runnable >>CPU machine code. I'm not sure why you're having such a conceptual struggle >>understanding this simple concept.
Oh, I understand what you mean; it's your choice of non-standard
terminology that I object to. Admittedly, Microsoft uses the
Or consider x86; most modern x86 processors are really dataflow
CPUs, and the x86 instruction encoding is just a bytecode that
is, in fact, interpreted by the real CPU under the hood. So
where does that fit on your little shrink-to-fit taxonomy? What
I could bore you with the number I've actually "dealt with" including >>military hardware but whats the point.
Weird appeals to experience, with vague and unsupported claims,
aren't terribly convincing.
You've probably programmed the
occasional PIC or arduino and think you're an expert.
Ok, Internet Guy.
I disagree. Modern linux reminds me a lot of SunOS and HP-UX from back in >>the day.
Then I can only guess that you never used either SunOS or HP-UX.
Anybody serious presumably meaning you.
Sorry, you've shown no evidence why I should believe your
assertions, and you've ignored directly disconfirming evidence
Really? So java bytecode will run direct on x86 or ARM will it? Please give >>some links to this astounding discovery you've made.
Um, ok. https://en.wikipedia.org/wiki/Jazelle
So in your mind google translate is a "compiler" for spoken languages is it?
To quote you above, "now you're just being silly."
No, it was a pre-compiler. Just like Oracles PRO*C/C++.
Nope.
I know the important ones. You've dug out some obscure names from google >>that probably only a few CS courses even mention never mind study the work of.
Ok, so you aren't familiar with the current state of the field
as far as systems go; fair enough.
Aho, Sethi, and Ullman: "Simply stated, a compiler is a program
that reads a program written in one language -- the _source_
language -- and translates it into an equivalent program in
another language -- the _target_ language."
So it would seem that your definition is not shared by those who
quite literally wrote the book on compilers.
Look, I get the desire to want to pin things down into neat
little categorical buckets, and if in one's own experience a
"compiler" has only ever meant GCC or perhaps clang (or maybe
Microsoft's compiler), then I can get where one is coming from.
But as usual, in its full generality, the world is just messier
than whatever conceptual boxes you've built up here.
Aho, Sethi, and Ullman: "Simply stated, a compiler is a program
that reads a program written in one language -- the _source_
language -- and translates it into an equivalent program in
another language -- the _target_ language."
Thats an opinion, not a fact.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <vefvo0$k1mm$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
Really? So java bytecode will run direct on x86 or ARM will it? Please give >>>some links to this astounding discovery you've made.
Um, ok. https://en.wikipedia.org/wiki/Jazelle
There was also a company a couple of decades ago that
built an entire processor designed to execute bytecode
directly - with a coprocessor to handle I/O.
IIRC, it was Azul. There were a number of others, including
Sun.
None of them panned out - JIT's ended up winning that battle.
Even ARM no longer includes Jazelle extensions in any of their
mainstream processors.
In article <vegmul$ne3v$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>So what is standard terminology then?
I've already explained this to you.
What happens inside the CPU is irrelevant. Its a black box as far as the >>rest of the machine is concerned. As I said in another post, it could be >>pixies with abacuses, doesn't matter.
So why do you think it's so important that the definition of a
CPU"? If, as you admit, what the CPU does is highly variable,
then why do you cling so hard to this meaningless distinction?
[lots of waffle snipped]
In other words, you discard anything that doesn't fit with your >preconceptions. Got it.
So its incomplete and has to revert to software for some opcodes. Great. >>FWIW Sun also had a java processor but you still can't run bytecode on >>normal hardware without a JVM.
Cool. So if I run a program targetting a newer version of an
ISA is run on an older machine, and that machine lacks a newer
instruction present in the program, and the CPU generates an
illegal instruction trap at runtime that the OS catches and
emulates on the program's behalf, the program was not compiled?
And again, what about an emulator for a CPU running on a
different CPU? I can boot 7th Edition Unix on a PDP-11
emulator on my workstation; does that mean that the 7the
edition C compiler wasn't a compiler?
Why, whats the difference? Your definition seems to be any program that can >>translate from one language to another.
If you can't see that yourself, then you're either ignorant or
obstinant. Take your pick.
Yes, they're entirely analoguous.
https://docs.oracle.com/cd/E11882_01/appdev.112/e10825/pc_02prc.htm
Nah, not really.
Who cares about the current state? Has nothing to do with this discussion.
In other words, "I don't have an argument, so I'll just lamely
try to define things until I'm right."
that a compiler is pretty much any program which translates from one thing to >>another.
No. It translates one computer _language_ to another computer
_language_. In the usual case, that's from a textual source
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <vefvo0$k1mm$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>>On Sat, 12 Oct 2024 16:36:26 -0000 (UTC)
It can mean either. Essentially its a binary that contains directly runnable >>>CPU machine code. I'm not sure why you're having such a conceptual struggle >>>understanding this simple concept.
Oh, I understand what you mean; it's your choice of non-standard >>terminology that I object to. Admittedly, Microsoft uses the
So what is standard terminology then?
Or consider x86; most modern x86 processors are really dataflow
CPUs, and the x86 instruction encoding is just a bytecode that
is, in fact, interpreted by the real CPU under the hood. So
where does that fit on your little shrink-to-fit taxonomy? What
What happens inside the CPU is irrelevant. Its a black box as far as the
rest of the machine is concerned. As I said in another post, it could be >pixies with abacuses, doesn't matter.
[lots of waffle snipped]
Then I can only guess that you never used either SunOS or HP-UX.
"I disagree with you so you must be lying". Whatever.
Sorry, you've shown no evidence why I should believe your
assertions, and you've ignored directly disconfirming evidence
Likewise.
Really? So java bytecode will run direct on x86 or ARM will it? Please give >>>some links to this astounding discovery you've made.
Um, ok. https://en.wikipedia.org/wiki/Jazelle
So its incomplete and has to revert to software for some opcodes. Great.
FWIW Sun also had a java processor but you still can't run bytecode on
normal hardware without a JVM.
So in your mind google translate is a "compiler" for spoken languages is it? >>To quote you above, "now you're just being silly."
Why, whats the difference? Your definition seems to be any program that can >translate from one language to another.
No, it was a pre-compiler. Just like Oracles PRO*C/C++.
Nope.
Yes, they're entirely analoguous.
https://docs.oracle.com/cd/E11882_01/appdev.112/e10825/pc_02prc.htm
I know the important ones. You've dug out some obscure names from google >>>that probably only a few CS courses even mention never mind study the work of.
Ok, so you aren't familiar with the current state of the field
as far as systems go; fair enough.
Who cares about the current state? Has nothing to do with this discussion.
Aho, Sethi, and Ullman: "Simply stated, a compiler is a program
that reads a program written in one language -- the _source_
language -- and translates it into an equivalent program in
another language -- the _target_ language."
Thats an opinion, not a fact.
So it would seem that your definition is not shared by those who
quite literally wrote the book on compilers.
Writing the book is not the same as writing the compilers.
Look, I get the desire to want to pin things down into neat
little categorical buckets, and if in one's own experience a
"compiler" has only ever meant GCC or perhaps clang (or maybe
Microsoft's compiler), then I can get where one is coming from.
You can add a couple of TI and MPLAB compilers into that list. And obviously >Arduinos , whatever its called. Been a while.
But as usual, in its full generality, the world is just messier
than whatever conceptual boxes you've built up here.
There's a difference between accepting there are shades of grey and asserting >that a compiler is pretty much any program which translates from one thing to >another.
On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
[...]
No. It translates one computer _language_ to another computer
_language_. In the usual case, that's from a textual source
Machine code isn't a language. Fallen at the first hurdle with that definition.
In article <QnROO.226037$EEm7.111715@fx16.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <vefvo0$k1mm$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
Really? So java bytecode will run direct on x86 or ARM will it? Please give
some links to this astounding discovery you've made.
Um, ok. https://en.wikipedia.org/wiki/Jazelle
There was also a company a couple of decades ago that
built an entire processor designed to execute bytecode
directly - with a coprocessor to handle I/O.
IIRC, it was Azul. There were a number of others, including
Sun.
None of them panned out - JIT's ended up winning that battle.
Even ARM no longer includes Jazelle extensions in any of their
mainstream processors.
Sure. But the fact that any of these were going concerns is an
existence proof that one _can_ take bytecodes targetted toward a
"virtual" machine and execute it on silicon,
making the
distinction a lot more fluid than might be naively assumed, in
turn exposing the silliness of this argument that centers around
this weirdly overly-rigid definition of what a "compiler" is.
Irrelevant. Lot of interpreters do partial compilation and the JVM does it
on the fly. A proper compiler writes a standalone binary file to disk.
On 2024-10-11, Muttley@DastartdlyHQ.org <Muttley@DastartdlyHQ.org> wrote:
Irrelevant. Lot of interpreters do partial compilation and the JVM does it >> on the fly. A proper compiler writes a standalone binary file to disk.
You might want to check those goalposts again. You can easily make a
"proper compiler" which just writes a canned interpreter executable to
disk, appending to it the program source code.
On 13/10/2024 16:52, Dan Cross wrote:
In article <QnROO.226037$EEm7.111715@fx16.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <vefvo0$k1mm$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
Really? So java bytecode will run direct on x86 or ARM will it? Please give
some links to this astounding discovery you've made.
Um, ok. https://en.wikipedia.org/wiki/Jazelle
There was also a company a couple of decades ago that
built an entire processor designed to execute bytecode
directly - with a coprocessor to handle I/O.
IIRC, it was Azul. There were a number of others, including
Sun.
None of them panned out - JIT's ended up winning that battle.
Even ARM no longer includes Jazelle extensions in any of their
mainstream processors.
Sure. But the fact that any of these were going concerns is an
existence proof that one _can_ take bytecodes targetted toward a
"virtual" machine and execute it on silicon,
making the
distinction a lot more fluid than might be naively assumed, in
turn exposing the silliness of this argument that centers around
this weirdly overly-rigid definition of what a "compiler" is.
I've implemented numerous compilers and interpreters over the last few >decades (and have dabbled in emulators).
To me the distinctions are clear enough because I have to work at the
sharp end!
I'm not sure why people want to try and be clever by blurring the roles
of compiler and interpreter; that's not helpful at all.
Sure, people can write emulators for machine code, which are a kind of >interpreter, or they can implement bytecode in hardware; so what?
That doesn't really affect what I do. Writing compiler backends for
actual CPUs is hard work. Generating bytecode is a lot simpler.
(Especially in my case as I've devised myself, another distinction.
Compilers usually target someone else's instruction set.)
If you want one more distinction, it is this: with my compiler, the
resultant binary is executed by a separate agency: the CPU. Or maybe the
OS loader will run it through an emulator.
With my interpreter, then *I* have to write the dispatch routines and
write code to implement all the instructions.
(My compilers generate an intermediate language, a kind of VM, which is
then processed further into native code.
But I have also tried interpreting that VM; it just runs 20 times slower
than native code. That's what interpreting usually means: slow programs.)
On 2024-10-12, Rainer Weikusat <rweikusat@talktalk.net> wrote:
Indeed. As far as I know the term, an interpreter is something which
reads text from a file, parses it an checks it for syntax errors
and then executes the code as soon as enough of it has been gathered to
allow for execution of something, ie, a complete statement. This read,
check and parse, execute cycle is repeated until the program
terminates.
I don't really want to participate in this discussion, but what
you're saying there is that all those 1980s home computer BASIC
interpreters, which read and tokenized a program before execution,
were actually compilers.
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <vegmul$ne3v$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>>So what is standard terminology then?
I've already explained this to you.
No you haven't. You explanation seems to be "anything that converts from one >language to another".
What happens inside the CPU is irrelevant. Its a black box as far as the >>>rest of the machine is concerned. As I said in another post, it could be >>>pixies with abacuses, doesn't matter.
So why do you think it's so important that the definition of a
Who said its important? Its just what most people think of as compilers.
CPU"? If, as you admit, what the CPU does is highly variable,
then why do you cling so hard to this meaningless distinction?
You're the one making a big fuss about it with pages of waffle to back up >your claim.
[lots of waffle snipped]
In other words, you discard anything that doesn't fit with your >>preconceptions. Got it.
No, I just have better things to do on a sunday than read all that. Keep
it to the point.
So its incomplete and has to revert to software for some opcodes. Great. >>>FWIW Sun also had a java processor but you still can't run bytecode on >>>normal hardware without a JVM.
Cool. So if I run a program targetting a newer version of an
ISA is run on an older machine, and that machine lacks a newer
instruction present in the program, and the CPU generates an
illegal instruction trap at runtime that the OS catches and
emulates on the program's behalf, the program was not compiled?
And again, what about an emulator for a CPU running on a
different CPU? I can boot 7th Edition Unix on a PDP-11
emulator on my workstation; does that mean that the 7the
edition C compiler wasn't a compiler?
Its all shades of grey. You seem to be getting very worked up about it.
As I said, most people consider a compiler as something that translates source >code to machine code and writes it to a file.
Why, whats the difference? Your definition seems to be any program that can >>>translate from one language to another.
If you can't see that yourself, then you're either ignorant or
obstinant. Take your pick.
So you can't argue the failure of your logic then. Noted.
Yes, they're entirely analoguous.
https://docs.oracle.com/cd/E11882_01/appdev.112/e10825/pc_02prc.htm
Nah, not really.
Oh nice counter arguement, you really sold your POV there.
Who cares about the current state? Has nothing to do with this discussion. >>In other words, "I don't have an argument, so I'll just lamely
try to define things until I'm right."
Im just defining things the way most people see it, not some ivory tower >academics. Anyway, lifes too short for the rest.
[tl;dr]
that a compiler is pretty much any program which translates from one thing to
another.
No. It translates one computer _language_ to another computer
_language_. In the usual case, that's from a textual source
Machine code isn't a language. Fallen at the first hurdle with that >definition.
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <vegmul$ne3v$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>>So what is standard terminology then?
I've already explained this to you.
No you haven't. You explanation seems to be "anything that converts from one >language to another".
What happens inside the CPU is irrelevant. Its a black box as far as the >>>rest of the machine is concerned. As I said in another post, it could be >>>pixies with abacuses, doesn't matter.
So why do you think it's so important that the definition of a
Who said its important? Its just what most people think of as compilers.
CPU"? If, as you admit, what the CPU does is highly variable,
then why do you cling so hard to this meaningless distinction?
You're the one making a big fuss about it with pages of waffle to back up >your claim.
So its incomplete and has to revert to software for some opcodes. Great. >>>FWIW Sun also had a java processor but you still can't run bytecode on >>>normal hardware without a JVM.
Cool. So if I run a program targetting a newer version of an
ISA is run on an older machine, and that machine lacks a newer
instruction present in the program, and the CPU generates an
illegal instruction trap at runtime that the OS catches and
emulates on the program's behalf, the program was not compiled?
And again, what about an emulator for a CPU running on a
different CPU? I can boot 7th Edition Unix on a PDP-11
emulator on my workstation; does that mean that the 7the
edition C compiler wasn't a compiler?
Its all shades of grey. You seem to be getting very worked up about it.
As I said, most people consider a compiler as something that translates source >code to machine code and writes it to a file.
[snip]
Who cares about the current state? Has nothing to do with this discussion. >>In other words, "I don't have an argument, so I'll just lamely
try to define things until I'm right."
Im just defining things the way most people see it, not some ivory tower >academics. Anyway, lifes too short for the rest.
Machine code isn't a language. Fallen at the first hurdle with that >definition.
On 2024-10-11, Muttley@DastartdlyHQ.org <Muttley@DastartdlyHQ.org> wrote:
Irrelevant. Lot of interpreters do partial compilation and the JVM does it >> on the fly. A proper compiler writes a standalone binary file to disk.
You might want to check those goalposts again. You can easily make a
"proper compiler" which just writes a canned interpreter executable to
disk, appending to it the program source code.
On Sat, 12 Oct 2024 21:25:17 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 12 Oct 2024 08:42:17 -0000 (UTC), Muttley boring babbled:
Code generated by a compiler does not require an interpreter.
Something has to implement the rules of the “machine language”. This is >>why we use the term “abstract machine”, to avoid having to distinguish >>between “hardware” and “software”.
Think: modern CPUs typically have “microcode” and “firmware” associated
with them. Are those “hardware” or “software”?
Who cares what happens inside the CPU hardware?
On Sat, 12 Oct 2024 16:39:20 +0000
Eric Pozharski <apple.universe@posteo.net> boring babbled:
with <87wmighu4i.fsf@doppelsaurus.mobileactivedefense.com> Rainer
Weikusat wrote:
Muttley@DastartdlyHQ.org writes:
On Wed, 09 Oct 2024 22:25:05 +0100 Rainer Weikusat
<rweikusat@talktalk.net> boring babbled:
Bozo User <anthk@disroot.org> writes:
On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 07 Apr 2024 00:01:43 +0000, Javier wrote:
*CUT* [ 19 lines 6 levels deep]
Its syntax is also a horrific mess.Which means precisely what?
You're arguing with Unix Haters Handbook. You've already lost.
ITYF the people who dislike Perl are the ones who actually like the unix
way of having simple daisychained tools instead of some lump of a language that does everything messily.
ITYF the people who dislike Perl are the ones who actually like the unix
way of having simple daisychained tools instead of some lump of a
language that does everything messily.
You explanation seems to be "anything that converts from one
language to another".
You know there's formal definitions for what constitutes languages.
What happens inside the CPU is irrelevant.
On Sun, 13 Oct 2024 18:28:32 +0200, Janis Papanagnou wrote:
You know there's formal definitions for what constitutes languages.
Not really. For example, some have preferred the term “notation” instead of “language”.
Regardless of what you call it, machine code still qualifies.
In article <vegs0o$nh5t$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
On 13/10/2024 16:52, Dan Cross wrote:
In article <QnROO.226037$EEm7.111715@fx16.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <vefvo0$k1mm$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
Really? So java bytecode will run direct on x86 or ARM will it? Please give
some links to this astounding discovery you've made.
Um, ok. https://en.wikipedia.org/wiki/Jazelle
There was also a company a couple of decades ago that
built an entire processor designed to execute bytecode
directly - with a coprocessor to handle I/O.
IIRC, it was Azul. There were a number of others, including
Sun.
None of them panned out - JIT's ended up winning that battle.
Even ARM no longer includes Jazelle extensions in any of their
mainstream processors.
Sure. But the fact that any of these were going concerns is an
existence proof that one _can_ take bytecodes targetted toward a
"virtual" machine and execute it on silicon,
making the
distinction a lot more fluid than might be naively assumed, in
turn exposing the silliness of this argument that centers around
this weirdly overly-rigid definition of what a "compiler" is.
I've implemented numerous compilers and interpreters over the last few
decades (and have dabbled in emulators).
To me the distinctions are clear enough because I have to work at the
sharp end!
I'm not sure why people want to try and be clever by blurring the roles
of compiler and interpreter; that's not helpful at all.
I'm not saying the two are the same; what I'm saying is that
this arbitrary criteria that a compiler must emit a fully
executable binary image is not just inadquate, but also wrong,
as it renders separate compilation impossible. I am further
saying that there are many different _types_ of compilers,
including specialized tools that don't emit machine language.
Sure, people can write emulators for machine code, which are a kind of
interpreter, or they can implement bytecode in hardware; so what?
That's exactly my point.
That doesn't really affect what I do. Writing compiler backends for
actual CPUs is hard work. Generating bytecode is a lot simpler.
That really depends on the bytecode, doesn't it? The JVM is a
complex beast;
MIPS or the unprivileged integer subset of RISC-Vare pretty simple in comparison.
(Especially in my case as I've devised myself, another distinction.
Compilers usually target someone else's instruction set.)
If you want one more distinction, it is this: with my compiler, the
resultant binary is executed by a separate agency: the CPU. Or maybe the
OS loader will run it through an emulator.
Python has a mode by which it will emit bytecode _files_, which
can be separately loaded and interpreted; it even has an
optimizing mode. Is that substantially different?
With my interpreter, then *I* have to write the dispatch routines and
write code to implement all the instructions.
Again, I don't think that anyone disputes that interpreters
exist. But insisting that they must take a particular shape is
just wrong.
(My compilers generate an intermediate language, a kind of VM, which is
then processed further into native code.
Then by the definition of this psuedonyminous guy I've been
responding to, your compiler is not a "proper compiler", no?
But I have also tried interpreting that VM; it just runs 20 times slower
than native code. That's what interpreting usually means: slow programs.)
Not necessarily. The JVM does pretty good, quite honestly.
On 13.10.2024 23:10, Lawrence D'Oliveiro wrote:
On Sun, 13 Oct 2024 18:28:32 +0200, Janis Papanagnou wrote:
You know there's formal definitions for what constitutes languages.
Not really. For example, some have preferred the term “notation”
instead of “language”.
A "notation" is not the same as a [formal (or informal)] "language".
(Frankly, I don't know where you're coming from ...
In article <vegqu5$o3ve$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
The people who create the field are the ones who get to make
the defintiions, not you.
Machine code isn't a language. Fallen at the first hurdle with that >>definition.
Oh really? Is that why they call it "machine language"? It's
even in the dictionary with "machine code" as a synonymn: >https://www.merriam-webster.com/dictionary/machine%20language
[ X-post list reduced ]
On 13.10.2024 18:02, Muttley@DastartdlyHQ.org wrote:
On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
[...]
No. It translates one computer _language_ to another computer
_language_. In the usual case, that's from a textual source
Machine code isn't a language. Fallen at the first hurdle with that
definition.
Careful (myself included); watch out for the glazed frost!
You know there's formal definitions for what constitutes languages.
At first glance I don't see why machine code wouldn't quality as a
language (either as some specific "mnemonic" representation, or as
a sequence of integral numbers or other "code" representations).
What's the problem, in your opinion, with considering machine code
as a language?
ITYF the people who dislike Perl are the ones who actually like the unix
way of having simple daisychained tools instead of some lump of a language >> that does everything messily.
Perl is a general-purpose programming language, just like C or Java (or >Python or Javascript or Rust or $whatnot). This means it can be used to >implement anything (with some practical limitation for anything) and not
that it "does everything".
The simple but flexible OO system, reliable automatic memory management
On Sun, 13 Oct 2024 21:33:56 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Muttley@DastartdlyHQ.org writes:
ITYF the people who dislike Perl are the ones who actually like the unix >>> way of having simple daisychained tools instead of some lump of a language >>> that does everything messily.
Perl is a general-purpose programming language, just like C or Java (or >>Python or Javascript or Rust or $whatnot). This means it can be used to >>implement anything (with some practical limitation for anything) and not >>that it "does everything".
I can be , but generally isn't. Its niche tends to be text processing of
some sort
On Mon, 14 Oct 2024 01:16:11 +0200, Janis Papanagnou wrote:
On 13.10.2024 23:10, Lawrence D'Oliveiro wrote:
On Sun, 13 Oct 2024 18:28:32 +0200, Janis Papanagnou wrote:
You know there's formal definitions for what constitutes languages.
Not really. For example, some have preferred the term “notation”
instead of “language”.
A "notation" is not the same as a [formal (or informal)] "language".
(Frankly, I don't know where you're coming from ...
<https://en.wikipedia.org/wiki/Programming_language>:
A programming language is a system of notation for writing computer
programs.
On Sun, 13 Oct 2024 18:28:32 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
[ X-post list reduced ]
On 13.10.2024 18:02, Muttley@DastartdlyHQ.org wrote:
On Sun, 13 Oct 2024 15:30:03 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
[...]
No. It translates one computer _language_ to another computer
_language_. In the usual case, that's from a textual source
Machine code isn't a language. Fallen at the first hurdle with that
definition.
Careful (myself included); watch out for the glazed frost!
You know there's formal definitions for what constitutes languages.
At first glance I don't see why machine code wouldn't quality as a
language (either as some specific "mnemonic" representation, or as
a sequence of integral numbers or other "code" representations).
What's the problem, in your opinion, with considering machine code
as a language?
A programming language is an abstraction of machine instructions that is readable by people.
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
Oh really? Is that why they call it "machine language"? It's
even in the dictionary with "machine code" as a synonymn: >>https://www.merriam-webster.com/dictionary/machine%20language
Its not a programming language.
On Mon, 14 Oct 2024 13:38:04 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <veiki1$14g6h$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>>On Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
Oh really? Is that why they call it "machine language"? It's
even in the dictionary with "machine code" as a synonymn: >>>>https://www.merriam-webster.com/dictionary/machine%20language
Its not a programming language.
That's news to those people who have, and sometimes still do,
write programs in it.
Really? So if its a language you'll be able to understand this then:
0011101011010101010001110101010010110110001110010100101001010100 >0101001010010010100101010111001010100110100111010101010101010101 >0001110100011101010001001010110011100010101001110010100101100010
Muttley@DastartdlyHQ.org writes:
On Sun, 13 Oct 2024 18:28:32 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
[ X-post list reduced ]
A programming language is an abstraction of machine instructions that is >>readable by people.
By that definition, PAL-D is a programming language.
Any assembler is a programming language, by that definition.
On Sun, 13 Oct 2024 18:28:32 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
[ X-post list reduced ]
A programming language is an abstraction of machine instructions that is >readable by people.
In article <veiki1$14g6h$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote: >>On Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
Oh really? Is that why they call it "machine language"? It's
even in the dictionary with "machine code" as a synonymn: >>>https://www.merriam-webster.com/dictionary/machine%20language
Its not a programming language.
That's news to those people who have, and sometimes still do,
write programs in it.
But that's not important. If we go back and look at what I
|No. It translates one computer _language_ to another computer
|_language_. In the usual case, that's from a textual source
Note that I said, "computer language", not "programming
language". Being a human-readable language is not a requirement
for a computer language.
Your claim that "machine language" is not a "language" is simply
not true. Your claim that a "proper" compiler must take the
shape you are pushing is also not true.
On Mon, 14 Oct 2024 11:38:29 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
The simple but flexible OO system, reliable automatic memory management
Then there's the whole 2 stage object creation with the "bless"
nonsense. Hacky.
Muttley@DastartdlyHQ.org writes:
On Mon, 14 Oct 2024 13:38:04 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <veiki1$14g6h$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
On Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
Oh really? Is that why they call it "machine language"? It's
even in the dictionary with "machine code" as a synonymn:
https://www.merriam-webster.com/dictionary/machine%20language
Its not a programming language.
That's news to those people who have, and sometimes still do,
write programs in it.
Really? So if its a language you'll be able to understand this then:
0011101011010101010001110101010010110110001110010100101001010100
0101001010010010100101010111001010100110100111010101010101010101
0001110100011101010001001010110011100010101001110010100101100010
I certainly understand this, even four decades later
94A605440C00010200010400000110
Your claim that "machine language" is not a "language" is simply
not true.
On Mon, 14 Oct 2024 11:38:29 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
The simple but flexible OO system, reliable automatic memory management
[...]
Then there's the whole 2 stage object creation with the "bless"
nonsense. Hacky.
I was planning to write a longer reply but killed it. You're obviously >argueing about something you reject for political reasons despite you're
not really familiar with it and you even 'argue' like a politician. That
is, you stick peiorative labels on stuff you don't like to emphasize how >really disagreeable you believe it to be. IMHO, such a method of >(pseudo-)discussing anything is completely pointless.
On Mon, 14 Oct 2024 13:38:04 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
In article <veiki1$14g6h$1@dont-email.me>, <Muttley@DastartdlyHQ.org> wrote:
On Sun, 13 Oct 2024 20:15:45 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
Oh really? Is that why they call it "machine language"? It's
even in the dictionary with "machine code" as a synonymn:
https://www.merriam-webster.com/dictionary/machine%20language
Its not a programming language.
That's news to those people who have, and sometimes still do,
write programs in it.
Really? So if its a language you'll be able to understand this then:
0011101011010101010001110101010010110110001110010100101001010100 0101001010010010100101010111001010100110100111010101010101010101 0001110100011101010001001010110011100010101001110010100101100010
On 14/10/2024 16:53, Scott Lurndal wrote:
Muttley@DastartdlyHQ.org writes:
Really? So if its a language you'll be able to understand this then:
0011101011010101010001110101010010110110001110010100101001010100
0101001010010010100101010111001010100110100111010101010101010101
0001110100011101010001001010110011100010101001110010100101100010
I certainly understand this, even four decades later
94A605440C00010200010400000110
In my early days of assembly programming on my ZX Spectrum, I would hand-assembly to machine code, and I knew at least a few of the codes by heart. (01 is "ld bc, #xxxx", 18 is "jr", c9 is "ret", etc.) So while
I rarely wrote machine code directly, it is certainly still a
programming language - it's a language you can write programs in.
cross@spitfire.i.gajendra.net (Dan Cross) boring babbled:
[snip]
|No. It translates one computer _language_ to another computer >>|_language_. In the usual case, that's from a textual source
Note that I said, "computer language", not "programming
language". Being a human-readable language is not a requirement
for a computer language.
Oh watch those goalpost moves with pedant set to 11. Presumably you
think the values of the address lines is a language too.
Your claim that "machine language" is not a "language" is simply
not true. Your claim that a "proper" compiler must take the
shape you are pushing is also not true.
If you say so.
Muttley@DastartdlyHQ.org writes:
On Sun, 13 Oct 2024 18:28:32 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
[ X-post list reduced ]
A programming language is an abstraction of machine instructions that is
readable by people.
By that definition, PAL-D is a programming language.
Any assembler is a programming language, by that definition.
A programming language is an abstraction of machine instructions that is readable by people.
On 14/10/2024 15:58, Scott Lurndal wrote:
Muttley@DastartdlyHQ.org writes:
On Sun, 13 Oct 2024 18:28:32 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
[ X-post list reduced ]
A programming language is an abstraction of machine instructions that is >>> readable by people.
By that definition, PAL-D is a programming language.
(I've no idea what PAL-D is in this context.)
Any assembler is a programming language, by that definition.
You mean 'assembly'? An assembler (in the sofware world) is usually a
program that translates textual assembly code.
'Compiler' isn't a programming language (although no doubt someone here
will dredge up some obscure language with exactly that name just to
prove me wrong).
On 14/10/2024 15:58, Scott Lurndal wrote:
Muttley@DastartdlyHQ.org writes:
On Sun, 13 Oct 2024 18:28:32 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
[ X-post list reduced ]
A programming language is an abstraction of machine instructions that is >>> readable by people.
By that definition, PAL-D is a programming language.
(I've no idea what PAL-D is in this context.)
On Wed, 09 Oct 2024 22:25:05 +0100
Rainer Weikusat <rweikusat@talktalk.net> boring babbled:
Bozo User <anthk@disroot.org> writes:
On 2024-04-07, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
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.
Perl is more awk+sed+sh in a single language. Basically the killer
of the Unix philophy in late 90's/early 00's, and for the good.
Perl is a high-level programming language with a rich syntax??, with >>support for deterministic automatic memory management, functions as >>first-class objects and message-based OO. It's also a virtual machine
for executing threaded code and a(n optimizing) compiler for translating >>Perl code into the corresponding threaded code.
Its syntax is also a horrific mess. Larry took the worst parts of C and shell syntax and mashed them together. Its no surprise Perl has been ditched in favour of Python just about everywhere for new scripting projects. And while I hate Pythons meangingful whitespace nonsense, I'd use it in preference
to Perl any day.
In comp.unix.programmer Muttley@dastartdlyhq.org wrote:
syntax and mashed them together. Its no surprise Perl has been ditched in
favour of Python just about everywhere for new scripting projects. And while >> I hate Pythons meangingful whitespace nonsense, I'd use it in preference
to Perl any day.
I think you've identified the one language that Python is better than.
On Mon, 11 Nov 2024 07:31:13 -0000 (UTC)
Sebastian <sebastian@here.com.invalid> boring babbled:
In comp.unix.programmer Muttley@dastartdlyhq.org wrote:
syntax and mashed them together. Its no surprise Perl has been ditched in >>> favour of Python just about everywhere for new scripting projects. And while
I hate Pythons meangingful whitespace nonsense, I'd use it in preference >>> to Perl any day.
I think you've identified the one language that Python is better than.
Yes, Python does have a lot of cons as a language. But its syntax lets newbies get up to speed quickly and there are a lot of libraries. However its dog slow and inefficient and I'm amazed its used as a key language for AI development - not traditionally a newbie coder area - when in that application
speed really is essential. Yes it generally calls libraries written in C/C++ but then why not just write the higher level code in C++ too?
Muttley@DastartdlyHQ.org writes:
On Mon, 11 Nov 2024 07:31:13 -0000 (UTC)
Sebastian <sebastian@here.com.invalid> boring babbled:
In comp.unix.programmer Muttley@dastartdlyhq.org wrote:
syntax and mashed them together. Its no surprise Perl has been ditched in >>>> favour of Python just about everywhere for new scripting projects. And >while
I hate Pythons meangingful whitespace nonsense, I'd use it in preference >>>> to Perl any day.
I think you've identified the one language that Python is better than.
Yes, Python does have a lot of cons as a language. But its syntax lets
newbies get up to speed quickly and there are a lot of libraries. However its
dog slow and inefficient and I'm amazed its used as a key language for AI
development - not traditionally a newbie coder area - when in that >application
speed really is essential. Yes it generally calls libraries written in C/C++ >> but then why not just write the higher level code in C++ too?
You'd have to give up the REPL, for instance.
Yes it generally calls libraries written in C/C++
but then why not just write the higher level code in C++ too?
In comp.unix.programmer Muttley@dastartdlyhq.org wrote:
[Perl’s] syntax is also a horrific mess. Larry took the worst parts of
C and shell syntax and mashed them together.
I think you've identified the one language that Python is better than.
Yes, Python does have a lot of cons as a language. But its syntax lets newbies get up to speed quickly
and there are a lot of libraries. However its
dog slow and inefficient and I'm amazed its used as a key language for AI
development - not traditionally a newbie coder area - when in that application
speed really is essential. Yes it generally calls libraries written in C/C++ but then why not just write the higher level code in C++ too?
On Mon, 11 Nov 2024 07:31:13 -0000 (UTC), Sebastian wrote:
In comp.unix.programmer Muttley@dastartdlyhq.org wrote:
[Perl’s] syntax is also a horrific mess. Larry took the worst parts of >>> C and shell syntax and mashed them together.
I think you've identified the one language that Python is better than.
In terms of the modern era of high-level programming, Perl was the breakthrough language. Before Perl, BASIC was considered to be an example
of a language with “good” string handling. After Perl, BASIC looked old and clunky indeed.
Perl was the language that made regular expressions sexy. Because it made them easy to use.
On 11.11.2024 11:06, Muttley@DastartdlyHQ.org wrote:
and there are a lot of libraries. However its
dog slow and inefficient and I'm amazed its used as a key language for AI
(and not only there; it's ubiquitous, it seems)
development - not traditionally a newbie coder area - when in that >application
speed really is essential. Yes it generally calls libraries written in C/C++ >> but then why not just write the higher level code in C++ too?
Because of its simpler syntax and less syntactical ballast compared
to C++?
On Tue, 12 Nov 2024 10:14:20 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
On 11.11.2024 11:06, Muttley@DastartdlyHQ.org wrote:
[ Q: why some prefer Python over C++ ]
Because of its simpler syntax and less syntactical ballast compared
to C++?
When you're dealing with something as complicated and frankly ineffable as
an AI model I doubt syntactic quirks of the programming language matter that much in comparison.
Surely you'd want the fastest implementation possible and
in this case it would be C++.
On 12.11.2024 10:21, Muttley@DastartdlyHQ.org wrote:
On Tue, 12 Nov 2024 10:14:20 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
On 11.11.2024 11:06, Muttley@DastartdlyHQ.org wrote:
[ Q: why some prefer Python over C++ ]
Because of its simpler syntax and less syntactical ballast compared
to C++?
When you're dealing with something as complicated and frankly ineffable as >> an AI model I doubt syntactic quirks of the programming language matter that >> much in comparison.
Oh, I would look at it differently; in whatever application domain I
program I want a syntactic clear and well defined language.
Surely you'd want the fastest implementation possible and
in this case it would be C++.
Speed is one factor (to me), and expressiveness or "modeling power"
(OO) is another one. I also appreciate consistently defined languages
and quality of error catching and usefulness of diagnostic messages.
(There's some more factors, but...)
In which case I'd go with a statically typed language like C++ every time ahead of a dynamic one like python.
C++ is undeniably powerful, but I think the majority would agree now that
its syntax has become an unwieldy mess.
On 12.11.2024 10:53, Muttley@DastartdlyHQ.org wrote:
C++ is undeniably powerful, but I think the majority would agree now that
its syntax has become an unwieldy mess.
Yes. And recent standards made it yet worse - When I saw it the
first time I couldn't believe that this would be possible. ;-)
On 12.11.2024 10:53, Muttley@DastartdlyHQ.org wrote:
In which case I'd go with a statically typed language like C++ every time
ahead of a dynamic one like python.
Definitely!
I'm using untyped languages (like Awk) for scripting, though, but
not for code of considerable scale.
Incidentally, on of my children recently spoke about their setups;
they use Fortran with old libraries (hydrodynamic earth processes),
have the higher level tasks implemented in C++, and they do the
"job control" of the simulation tasks with Python. - A multi-tier architecture. - That sounds not unreasonable to me. (But they had
built their system based on existing software, so it might have
been a different decision if they'd have built it from scratch.)
Perl was the language that made regular expressions sexy. Because it made
them easy to use.
For those of us who used regexps in Unix from the beginning it's not
that shiny as you want us to buy it; Unix was supporting Chomsky-3
Regular Expressions with a syntax that is still used in contemporary languages. Perl supports some nice syntactic shortcuts, but also
patterns that exceed Chomsky-3's; too bad if one doesn't know these differences and any complexity degradation that may be bought with it.
More interesting to me is the fascinating fact that on some non-Unix platforms it took decades before regexps got (slooooowly) introduced
(even in its simplest form).
On Tue, 12 Nov 2024 10:14:20 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
Because of its simpler syntax and less syntactical ballast compared
to C++?
When you're dealing with something as complicated and frankly ineffable as
an AI model I doubt syntactic quirks of the programming language matter that much in comparison. Surely you'd want the fastest implementation possible and in this case it would be C++.
But the app also had an embedded scripting language, which had access to
the app's environment and users' data.
On 11.11.2024 22:24, Lawrence D'Oliveiro wrote:
Perl was the language that made regular expressions sexy. Because it
made them easy to use.
... Unix was supporting Chomsky-3
Regular Expressions with a syntax that is still used in contemporary languages.
On Tue, 12 Nov 2024 14:50:26 +0000, Bart wrote:
But the app also had an embedded scripting language, which had access to
the app's environment and users' data.
Did you invent your own scripting language? Nowadays you would use
something ready-made, like Lua, Guile or even Python.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
By Chomsky-3 you mean a grammar of type 3 in the Chomsky hierarchy? And
that would be ``regular'' language, recognizable by a finite-state
automaton? If not, could you elaborate on the terminology?
"Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
"Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Lawrence> Perl was the language that made regular expressions
Lawrence> sexy. Because it made them easy to use.
I'm often reminded of this as I've been coding very little in Perl these days, and a lot more in languages like Dart, where the regex feels like
a clumsy bolt-on rather than a proper first-class citizen.
"Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Lawrence> Perl was the language that made regular expressions
Lawrence> sexy. Because it made them easy to use.
I'm often reminded of this as I've been coding very little in Perl these >days, and a lot more in languages like Dart, where the regex feels like
a clumsy bolt-on rather than a proper first-class citizen.
On Tue, 19 Nov 2024 18:43:48 -0800
merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
I'm often reminded of this as I've been coding very little in Perl these
days, and a lot more in languages like Dart, where the regex feels like
a clumsy bolt-on rather than a proper first-class citizen.
Regex itself is clumsy beyond simple search and replace patterns. A lot of stuff I've seen done in regex would have better done procedurally at the expense of slightly more code but a LOT more readability. Also given its effectively a compact language with its own grammar and syntax IMO it should not be the core part of any language as it can lead to a syntatic mess, which is what often happens with Perl.
On 20.11.2024 09:21, Muttley@DastartdlyHQ.org wrote:
On Tue, 19 Nov 2024 18:43:48 -0800
merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
I'm often reminded of this as I've been coding very little in Perl these >>> days, and a lot more in languages like Dart, where the regex feels like
a clumsy bolt-on rather than a proper first-class citizen.
Regex itself is clumsy beyond simple search and replace patterns. A lot of >> stuff I've seen done in regex would have better done procedurally at the
expense of slightly more code but a LOT more readability. Also given its
effectively a compact language with its own grammar and syntax IMO it should >> not be the core part of any language as it can lead to a syntatic mess, >which
is what often happens with Perl.
I wouldn't look at it that way. I've seen Regexps as part of languages >usually in well defined syntactical contexts. For example, like strings
are enclosed in "...", Regexps could be seen within /.../ delimiters.
GNU Awk (in recent versions) went towards first class "strongly typed" >Regexps which are then denoted by the @/.../ syntax.
I'm curious what you mean by Regexps presented in a "procedural" form.
Can you give some examples?
In practice, given that a Regexp conforms to a FSA, any Regexp can be >precompiled and used multiple times. The thing I had used in Java - it
then operate on that same object. (Since there's still typical Regexp
syntax involved I suppose that is not what you meant by "procedural"?)
On 11/20/2024 2:21 AM, Muttley@DastartdlyHQ.org wrote:
On Tue, 19 Nov 2024 18:43:48 -0800
merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
"Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Lawrence> Perl was the language that made regular expressions
Lawrence> sexy. Because it made them easy to use.
I'm often reminded of this as I've been coding very little in Perl these >>> days, and a lot more in languages like Dart, where the regex feels like
a clumsy bolt-on rather than a proper first-class citizen.
Regex itself is clumsy beyond simple search and replace patterns. A lot of >> stuff I've seen done in regex would have better done procedurally at the
expense of slightly more code but a LOT more readability.
Definitely. The most relevant statement about regexps is this:
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
Obviously regexps are very useful and commonplace but if you find you
have to use some online site or other tools to help you write/understand
one or just generally need more than a couple of minutes to
write/understand it then it's time to back off and figure out a better
way to write your code for the sake of whoever has to read it 6 months
later (and usually for robustness too as it's hard to be sure all rainy
day cases are handled correctly in a lengthy and/or complicated regexp).
merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
"Lawrence" == Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Lawrence> Perl was the language that made regular expressions
Lawrence> sexy. Because it made them easy to use.
I'm often reminded of this as I've been coding very little in Perl these >>days, and a lot more in languages like Dart, where the regex feels like
a clumsy bolt-on rather than a proper first-class citizen.
Regex itself is clumsy beyond simple search and replace patterns. A lot of stuff I've seen done in regex would have better done procedurally at the expense of slightly more code but a LOT more readability. Also given its effectively a compact language with its own grammar and syntax IMO it should not be the core part of any language as it can lead to a syntatic mess, which is what often happens with Perl.
On Wed, 20 Nov 2024 11:51:11 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> boring babbled:
On 20.11.2024 09:21, Muttley@DastartdlyHQ.org wrote:
On Tue, 19 Nov 2024 18:43:48 -0800which
merlyn@stonehenge.com (Randal L. Schwartz) boring babbled:
I'm often reminded of this as I've been coding very little in Perl these >>>> days, and a lot more in languages like Dart, where the regex feels like >>>> a clumsy bolt-on rather than a proper first-class citizen.
Regex itself is clumsy beyond simple search and replace patterns. A lot of >>> stuff I've seen done in regex would have better done procedurally at the >>> expense of slightly more code but a LOT more readability. Also given its >>> effectively a compact language with its own grammar and syntax IMO it should
not be the core part of any language as it can lead to a syntatic mess,
is what often happens with Perl.
I wouldn't look at it that way. I've seen Regexps as part of languages
usually in well defined syntactical contexts. For example, like strings
are enclosed in "...", Regexps could be seen within /.../ delimiters.
GNU Awk (in recent versions) went towards first class "strongly typed"
Regexps which are then denoted by the @/.../ syntax.
I'm curious what you mean by Regexps presented in a "procedural" form.
Can you give some examples?
Anything that can be done in regex can obviously also be done procedurally. At the point regex expression become unwieldy - usually when substitution variables raise their heads - I prefer procedural code as its also often easier to debug.
In practice, given that a Regexp conforms to a FSA, any Regexp can be
precompiled and used multiple times. The thing I had used in Java - it
Precompiled regex is no more efficient than precompiled anything , its all just assembler at the bottom.
then operate on that same object. (Since there's still typical Regexp
syntax involved I suppose that is not what you meant by "procedural"?)
If you don't know the different between declarative syntax like regex and procedural syntax then there's not much point continuing this discussion.
Definitely. The most relevant statement about regexps is this:
Some people, when confronted with a problem, think "I know, I'll use
regular expressions." Now they have two problems.
Obviously regexps are very useful and commonplace but if you find you
have to use some online site or other tools to help you write/understand
one or just generally need more than a couple of minutes to
write/understand it then it's time to back off and figure out a better
way to write your code for the sake of whoever has to read it 6 months
later (and usually for robustness too as it's hard to be sure all rainy
day cases are handled correctly in a lengthy and/or complicated regexp).
On 20.11.2024 12:30, Muttley@DastartdlyHQ.org wrote:
Anything that can be done in regex can obviously also be done procedurally. >> At the point regex expression become unwieldy - usually when substitution
variables raise their heads - I prefer procedural code as its also often
easier to debug.
You haven't even tried to honestly answer my (serious) question.
With your statement above and your hostility below, it rather seems
With your statement above and your hostility below, it rather seems
If you think my reply was hostile then I suggest you go find a safe space
and cuddle your teddy bear snowflake.
Personally I think that writing bulky procedural stuff for something
like [0-9]+ can only be much worse, and that further abbreviations
like \d+ are the better direction to go if targeting a good interface.
YMMV.
Edge cases are regex achilles heal, eg an expression that only accounted
for 1 -> N chars, not 0 -> N, or matches in the middle but not at the
ends.
[...]
With your statement above and your hostility below, it rather seems
If you think my reply was hostile then I suggest you go find a safe space
and cuddle your teddy bear snowflake.
There's surely no reason why anyone could ever think you were inclined
to substitute verbal aggression for arguments.
On Wed, 20 Nov 2024 12:27:54 -0000 (UTC), Muttley wrote:
Edge cases are regex achilles heal, eg an expression that only accounted
for 1 -> N chars, not 0 -> N, or matches in the middle but not at the
ends.
That’s what “^” and “$” are for.
On Wed, 20 Nov 2024 17:54:22 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
There's surely no reason why anyone could ever think you were inclined
to substitute verbal aggression for arguments.
I mean, it's his whole thing - why would he stop now?
"Rainer" == Rainer Weikusat <rweikusat@talktalk.net> writes:
On Wed, 20 Nov 2024 17:54:22 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
There's surely no reason why anyone could ever think you were inclined
to substitute verbal aggression for arguments.
I mean, it's his whole thing - why would he stop now?
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Personally I think that writing bulky procedural stuff for something
like [0-9]+ can only be much worse, and that further abbreviations
like \d+ are the better direction to go if targeting a good interface.
YMMV.
Assuming that p is a pointer to the current position in a string, e is a >pointer to the end of it (ie, point just past the last byte) and -
that's important - both are pointers to unsigned quantities, the 'bulky'
C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a
general-purpose automaton programmed to recognize the same pattern
(which might not matter most of the time, but sometimes, it does).
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Personally I think that writing bulky procedural stuff for something
like [0-9]+ can only be much worse, and that further abbreviations
like \d+ are the better direction to go if targeting a good interface.
YMMV.
Assuming that p is a pointer to the current position in a string, e is a >>pointer to the end of it (ie, point just past the last byte) and -
that's important - both are pointers to unsigned quantities, the 'bulky'
C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a >>general-purpose automaton programmed to recognize the same pattern
(which might not matter most of the time, but sometimes, it does).
It's also not exactly right. `[0-9]+` would match one or more
characters; this possibly matches 0 (ie, if `p` pointed to
something that wasn't a digit).
In article <20241120100347.00005f10@gmail.com>,
John Ames <commodorejohn@gmail.com> wrote:
On Wed, 20 Nov 2024 17:54:22 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
There's surely no reason why anyone could ever think you were inclined
to substitute verbal aggression for arguments.
I mean, it's his whole thing - why would he stop now?
This is the guy who didn't know what a compiler is, right?
Rainer> ¹ I used to use a JSON parser written in OO-Perl which made"Rainer" == Rainer Weikusat <rweikusat@talktalk.net> writes:
Rainer> extensive use of regexes for that. I've recently replaced that Rainer> with a C/XS version which - while slightly larger (617 vs 410
Rainer> lines of text) - is over a hundred times faster and conceptually Rainer> simpler at the same time.
I wonder if that was my famous "JSON parser in a single regex" from https://www.perlmonks.org/?node_id=995856, or from one of the two CPAN modules that incorporated it.
On 20.11.2024 09:21, Muttley@DastartdlyHQ.org wrote:
Regex itself is clumsy beyond simple search and replace patterns. A lot of >> stuff I've seen done in regex would have better done procedurally at the
expense of slightly more code but a LOT more readability. Also given its
effectively a compact language with its own grammar and syntax IMO it should >> not be the core part of any language as it can lead to a syntatic mess, which
is what often happens with Perl.
I wouldn't look at it that way. I've seen Regexps as part of languages usually in well defined syntactical contexts. For example, like strings
are enclosed in "...", Regexps could be seen within /.../ delimiters.
GNU Awk (in recent versions) went towards first class "strongly typed" Regexps which are then denoted by the @/.../ syntax.
I'm curious what you mean by Regexps presented in a "procedural" form.
Can you give some examples?
On Wed, 20 Nov 2024 21:43:41 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boring babbled:
On Wed, 20 Nov 2024 12:27:54 -0000 (UTC), Muttley wrote:
Edge cases are regex achilles heal, eg an expression that only
accounted for 1 -> N chars, not 0 -> N, or matches in the middle but
not at the ends.
That’s what “^” and “$” are for.
Yes, but people forget about those (literal) edge cases.
On 2024-11-20, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
I'm curious what you mean by Regexps presented in a "procedural" form.
Can you give some examples?
Here is an example: using a regex match to capture a C comment /* ... */
in Lex compared to just recognizing the start sequence /* and handling
the discarding of the comment in the action.
Without non-greedy repetition matching, the regex for a C comment is
quite obtuse. The procedural handling is straightforward: read
characters until you see a * immediately followed by a /.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
Personally I think that writing bulky procedural stuff for something
like [0-9]+ can only be much worse, and that further abbreviations
like \d+ are the better direction to go if targeting a good interface.
YMMV.
Assuming that p is a pointer to the current position in a string, e is a pointer to the end of it (ie, point just past the last byte) and -
that's important - both are pointers to unsigned quantities, the 'bulky'
C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a
general-purpose automaton programmed to recognize the same pattern
(which might not matter most of the time, but sometimes, it does).
[...]
In the wild, you see regexes being used for all sorts of stupid stuff,
like checking whether numeric input is in a certain range, rather than converting it to a number and doing an arithmetic check.
On Thu, 21 Nov 2024 08:15:41 -0000 (UTC), Muttley wrote:
On Wed, 20 Nov 2024 21:43:41 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> boring babbled:
[...]
That’s what “^” and “$” are for.
Yes, but people forget about those (literal) edge cases.
Those of us who are accustomed to using regexes do not.
Another handy one is “\b” for word boundaries.
On 20.11.2024 18:50, Rainer Weikusat wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
Personally I think that writing bulky procedural stuff for something
like [0-9]+ can only be much worse, and that further abbreviations
like \d+ are the better direction to go if targeting a good interface.
YMMV.
Assuming that p is a pointer to the current position in a string, e is a
pointer to the end of it (ie, point just past the last byte) and -
that's important - both are pointers to unsigned quantities, the 'bulky'
C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a
general-purpose automaton programmed to recognize the same pattern
(which might not matter most of the time, but sometimes, it does).
Okay, I see where you're coming from (and especially in that simple
case).
Personally (and YMMV), even here in this simple case I think that
using pointers is not better but worse - and anyway isn't [in this
form] available in most languages;
in other cases (and languages)
such constructs get yet more clumsy, and for my not very complex
example - /[0-9]+(ABC)?x*foo/ - even a "catastrophe" concerning
readability, error-proneness, and maintainability.
If that is what the other poster meant I'm fine with your answer;
there's no need to even consider abandoning regular expressions
in favor of explicitly codified parsing.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Personally I think that writing bulky procedural stuff for something
like [0-9]+ can only be much worse, and that further abbreviations
like \d+ are the better direction to go if targeting a good interface. >>>> YMMV.
Assuming that p is a pointer to the current position in a string, e is a >>>pointer to the end of it (ie, point just past the last byte) and -
that's important - both are pointers to unsigned quantities, the 'bulky' >>>C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a >>>general-purpose automaton programmed to recognize the same pattern
(which might not matter most of the time, but sometimes, it does).
It's also not exactly right. `[0-9]+` would match one or more
characters; this possibly matches 0 (ie, if `p` pointed to
something that wasn't a digit).
The regex won't match any digits if there aren't any. In this case, the
match will fail. I didn't include the code for handling that because it >seemed pretty pointless for the example.
Something which would match [0-9]+ in its first argument (if any) would
be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
Rainer Weikusat <rweikusat@talktalk.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Personally I think that writing bulky procedural stuff for something >>>>> like [0-9]+ can only be much worse, and that further abbreviations
like \d+ are the better direction to go if targeting a good interface. >>>>> YMMV.
Assuming that p is a pointer to the current position in a string, e is a >>>>pointer to the end of it (ie, point just past the last byte) and - >>>>that's important - both are pointers to unsigned quantities, the 'bulky' >>>>C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a >>>>general-purpose automaton programmed to recognize the same pattern >>>>(which might not matter most of the time, but sometimes, it does).
It's also not exactly right. `[0-9]+` would match one or more
characters; this possibly matches 0 (ie, if `p` pointed to
something that wasn't a digit).
The regex won't match any digits if there aren't any. In this case, the >>match will fail. I didn't include the code for handling that because it >>seemed pretty pointless for the example.
That's rather the point though, isn't it? The program snippet
(modulo the promotion to signed int via the "usual arithmetic
conversions" before the subtraction and comparison giving you
unexpected values; nothing to do with whether `char` is signed
or not) is a snippet that advances a pointer while it points to
a digit, starting at the current pointer position; that is, it
just increments a pointer over a run of digits.
But that's not the same as a regex matcher, which has a semantic
notion of success or failure. I could run your snippet against
a string such as, say, "ZZZZZZ" and it would "succeed" just as
it would against an empty string or a string of one or more
digits.
By the way, something that _would_ match `^[0-9]+$` might be:
Rainer Weikusat <rweikusat@talktalk.net> writes:
[...]
Something which would match [0-9]+ in its first argument (if any) would
be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
This needs to be
while (c = *p, c && c - '0' > 9) ++p
In article <87zflrs1ti.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Rainer Weikusat <rweikusat@talktalk.net> writes:
[...]
Something which would match [0-9]+ in its first argument (if any) would
be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
This needs to be
while (c = *p, c && c - '0' > 9) ++p
No, that's still wrong. Try actually running it.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <87zflrs1ti.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Rainer Weikusat <rweikusat@talktalk.net> writes:
[...]
Something which would match [0-9]+ in its first argument (if any) would >>>> be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
This needs to be
while (c = *p, c && c - '0' > 9) ++p
No, that's still wrong. Try actually running it.
If you know something that's wrong with that, why not write it instead
of utilizing the claim for pointless (and wrong) snide remarks?
cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
[snip]
It's also not exactly right. `[0-9]+` would match one or more
characters; this possibly matches 0 (ie, if `p` pointed to
something that wasn't a digit).
The regex won't match any digits if there aren't any. In this case, the >>>match will fail. I didn't include the code for handling that because it >>>seemed pretty pointless for the example.
That's rather the point though, isn't it? The program snippet
(modulo the promotion to signed int via the "usual arithmetic
conversions" before the subtraction and comparison giving you
unexpected values; nothing to do with whether `char` is signed
or not) is a snippet that advances a pointer while it points to
a digit, starting at the current pointer position; that is, it
just increments a pointer over a run of digits.
That's the core part of matching someting equivalent to the regex [0-9]+
and the only part of it is which is at least remotely interesting.
But that's not the same as a regex matcher, which has a semantic
notion of success or failure. I could run your snippet against
a string such as, say, "ZZZZZZ" and it would "succeed" just as
it would against an empty string or a string of one or more
digits.
Why do you believe that p being equivalent to the starting position
would be considered a "successful match", considering that this
obviously doesn't make any sense?
[...]
By the way, something that _would_ match `^[0-9]+$` might be:
[too much code]
Something which would match [0-9]+ in its first argument (if any) would
be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to
the problem of recognizing a digit.
In article <87v7wfrx26.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote: >>cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <87zflrs1ti.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Rainer Weikusat <rweikusat@talktalk.net> writes:
[...]
Something which would match [0-9]+ in its first argument (if any) would >>>>> be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
This needs to be
while (c = *p, c && c - '0' > 9) ++p
No, that's still wrong. Try actually running it.
If you know something that's wrong with that, why not write it instead
of utilizing the claim for pointless (and wrong) snide remarks?
I did, at length, in my other post.
Rainer Weikusat <rweikusat@talktalk.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote: >>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
[snip]
It's also not exactly right. `[0-9]+` would match one or more
characters; this possibly matches 0 (ie, if `p` pointed to
something that wasn't a digit).
The regex won't match any digits if there aren't any. In this case, the >>>>match will fail. I didn't include the code for handling that because it >>>>seemed pretty pointless for the example.
That's rather the point though, isn't it? The program snippet
(modulo the promotion to signed int via the "usual arithmetic
conversions" before the subtraction and comparison giving you
unexpected values; nothing to do with whether `char` is signed
or not) is a snippet that advances a pointer while it points to
a digit, starting at the current pointer position; that is, it
just increments a pointer over a run of digits.
That's the core part of matching someting equivalent to the regex [0-9]+ >>and the only part of it is which is at least remotely interesting.
Not really, no. The interesting thing in this case appears to
be knowing whether or not the match succeeded, but you omited
that part.
But that's not the same as a regex matcher, which has a semantic
notion of success or failure. I could run your snippet against
a string such as, say, "ZZZZZZ" and it would "succeed" just as
it would against an empty string or a string of one or more
digits.
Why do you believe that p being equivalent to the starting position
would be considered a "successful match", considering that this
obviously doesn't make any sense?
Because absent any surrounding context, there's no indication
that the source is even saved.
Something which would match [0-9]+ in its first argument (if any) would
be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to
the problem of recognizing a digit.
This is wrong in many ways. Did you actually test that program?
First of all, why `"string.h"` and not `<string.h>`? Ok, that's
not technically an error, but it's certainly unconventional, and
raises questions that are ultimately a distraction.
Second, suppose that `argc==0` (yes, this can happen under
POSIX).
Third, the loop: why `> 10`? Don't you mean `< 10`? You are
trying to match digits, not non-digits.
Fourth, you exit with failure (`exit(1)`) if `!p` *and* if `!c`
at the end, but `!c` there means you've reached the end of the
string; which should be success.
Something which would match [0-9]+ in its first argument (if any) would >>>be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to >>>the problem of recognizing a digit.
This is wrong in many ways. Did you actually test that program?
First of all, why `"string.h"` and not `<string.h>`? Ok, that's
not technically an error, but it's certainly unconventional, and
raises questions that are ultimately a distraction.
Such as your paragraph above.
Second, suppose that `argc==0` (yes, this can happen under
POSIX).
It can happen in case of some piece of functionally hostile software >intentionally creating such a situation. Tangential, irrelevant
point. If you break it, you get to keep the parts.
Third, the loop: why `> 10`? Don't you mean `< 10`? You are
trying to match digits, not non-digits.
Mistake I made. The opposite of < 10 is > 9.
Fourth, you exit with failure (`exit(1)`) if `!p` *and* if `!c`
at the end, but `!c` there means you've reached the end of the
string; which should be success.
Mistake you made: [0-9]+ matches if there's at least one digit in the
string. That's why the loop terminates once one was found. In this case,
c cannot be 0.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Personally I think that writing bulky procedural stuff for something >>>>>> like [0-9]+ can only be much worse, and that further abbreviations >>>>>> like \d+ are the better direction to go if targeting a good interface. >>>>>> YMMV.
Assuming that p is a pointer to the current position in a string, e is a >>>>>pointer to the end of it (ie, point just past the last byte) and - >>>>>that's important - both are pointers to unsigned quantities, the 'bulky' >>>>>C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a >>>>>general-purpose automaton programmed to recognize the same pattern >>>>>(which might not matter most of the time, but sometimes, it does).
It's also not exactly right. `[0-9]+` would match one or more
characters; this possibly matches 0 (ie, if `p` pointed to
something that wasn't a digit).
The regex won't match any digits if there aren't any. In this case, the >>>match will fail. I didn't include the code for handling that because it >>>seemed pretty pointless for the example.
That's rather the point though, isn't it? The program snippet
(modulo the promotion to signed int via the "usual arithmetic
conversions" before the subtraction and comparison giving you
unexpected values; nothing to do with whether `char` is signed
or not) is a snippet that advances a pointer while it points to
a digit, starting at the current pointer position; that is, it
just increments a pointer over a run of digits.
That's the core part of matching someting equivalent to the regex [0-9]+
and the only part of it is which is at least remotely interesting.
But that's not the same as a regex matcher, which has a semantic
notion of success or failure. I could run your snippet against
a string such as, say, "ZZZZZZ" and it would "succeed" just as
it would against an empty string or a string of one or more
digits.
Why do you believe that p being equivalent to the starting position
would be considered a "successful match", considering that this
obviously doesn't make any sense?
[...]
By the way, something that _would_ match `^[0-9]+$` might be:
[too much code]
Something which would match [0-9]+ in its first argument (if any) would
be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to
the problem of recognizing a digit.
On 21.11.2024 20:12, Kaz Kylheku wrote:
[...]
In the wild, you see regexes being used for all sorts of stupid stuff,
No one can prevent folks using features for stupid things. Yes.
On Thu, 21 Nov 2024 19:12:03 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> boring babbled:
On 2024-11-20, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
I'm curious what you mean by Regexps presented in a "procedural" form.
Can you give some examples?
Here is an example: using a regex match to capture a C comment /* ... */
in Lex compared to just recognizing the start sequence /* and handling
the discarding of the comment in the action.
Without non-greedy repetition matching, the regex for a C comment is
quite obtuse. The procedural handling is straightforward: read
characters until you see a * immediately followed by a /.
Its not that simple I'm afraid since comments can be commented out.
eg:
// int i; /*
int j;
/*
int k;
*/
++j;
A C99 and C++ compiler would see "int j" and compile it, a regex would
simply remove everything from the first /* to */.
Also the same probably applies to #ifdef's.
Rainer Weikusat <rweikusat@talktalk.net> writes: >>cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote: >>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Personally I think that writing bulky procedural stuff for something >>>>>>> like [0-9]+ can only be much worse, and that further abbreviations >>>>>>> like \d+ are the better direction to go if targeting a good interface. >>>>>>> YMMV.
Assuming that p is a pointer to the current position in a string, e is a >>>>>>pointer to the end of it (ie, point just past the last byte) and - >>>>>>that's important - both are pointers to unsigned quantities, the 'bulky' >>>>>>C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a >>>>>>general-purpose automaton programmed to recognize the same pattern >>>>>>(which might not matter most of the time, but sometimes, it does).
It's also not exactly right. `[0-9]+` would match one or more
characters; this possibly matches 0 (ie, if `p` pointed to
something that wasn't a digit).
The regex won't match any digits if there aren't any. In this case, the >>>>match will fail. I didn't include the code for handling that because it >>>>seemed pretty pointless for the example.
That's rather the point though, isn't it? The program snippet
(modulo the promotion to signed int via the "usual arithmetic
conversions" before the subtraction and comparison giving you
unexpected values; nothing to do with whether `char` is signed
or not) is a snippet that advances a pointer while it points to
a digit, starting at the current pointer position; that is, it
just increments a pointer over a run of digits.
That's the core part of matching someting equivalent to the regex [0-9]+ >>and the only part of it is which is at least remotely interesting.
But that's not the same as a regex matcher, which has a semantic
notion of success or failure. I could run your snippet against
a string such as, say, "ZZZZZZ" and it would "succeed" just as
it would against an empty string or a string of one or more
digits.
Why do you believe that p being equivalent to the starting position
would be considered a "successful match", considering that this
obviously doesn't make any sense?
[...]
By the way, something that _would_ match `^[0-9]+$` might be:
[too much code]
Something which would match [0-9]+ in its first argument (if any) would
be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to
the problem of recognizing a digit.
Personally, I'd use:
$ cat /tmp/a.c
#include <stdint.h>
#include <string.h>
int
main(int argc, const char **argv)
{
char *cp;
uint64_t value;
if (argc < 2) return 1;
value = strtoull(argv[1], &cp, 10);
if ((cp == argv[1])
|| (*cp != '\0')) {
return 1;
}
return 0;
}
$ cc -o /tmp/a /tmp/a.c
$ /tmp/a 13254
$ echo $?
0
$ /tmp/a 23v23
$ echo $?
1
scott@slp53.sl.home (Scott Lurndal) writes:
Rainer Weikusat <rweikusat@talktalk.net> writes: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote: >>>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:It's also not exactly right. `[0-9]+` would match one or more
[...]
Personally I think that writing bulky procedural stuff for something >>>>>>>> like [0-9]+ can only be much worse, and that further abbreviations >>>>>>>> like \d+ are the better direction to go if targeting a good interface. >>>>>>>> YMMV.
Assuming that p is a pointer to the current position in a string, e is a >>>>>>>pointer to the end of it (ie, point just past the last byte) and - >>>>>>>that's important - both are pointers to unsigned quantities, the 'bulky' >>>>>>>C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a >>>>>>>general-purpose automaton programmed to recognize the same pattern >>>>>>>(which might not matter most of the time, but sometimes, it does). >>>>>>
characters; this possibly matches 0 (ie, if `p` pointed to
something that wasn't a digit).
The regex won't match any digits if there aren't any. In this case, the >>>>>match will fail. I didn't include the code for handling that because it >>>>>seemed pretty pointless for the example.
That's rather the point though, isn't it? The program snippet
(modulo the promotion to signed int via the "usual arithmetic
conversions" before the subtraction and comparison giving you
unexpected values; nothing to do with whether `char` is signed
or not) is a snippet that advances a pointer while it points to
a digit, starting at the current pointer position; that is, it
just increments a pointer over a run of digits.
That's the core part of matching someting equivalent to the regex [0-9]+ >>>and the only part of it is which is at least remotely interesting.
But that's not the same as a regex matcher, which has a semantic
notion of success or failure. I could run your snippet against
a string such as, say, "ZZZZZZ" and it would "succeed" just as
it would against an empty string or a string of one or more
digits.
Why do you believe that p being equivalent to the starting position
would be considered a "successful match", considering that this
obviously doesn't make any sense?
[...]
By the way, something that _would_ match `^[0-9]+$` might be:
[too much code]
Something which would match [0-9]+ in its first argument (if any) would >>>be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to >>>the problem of recognizing a digit.
Personally, I'd use:
Albeit this is limited to strings of digits that sum to less than >ULONG_MAX...
$ cat /tmp/a.c
#include <stdint.h>
#include <string.h>
int
main(int argc, const char **argv)
{
char *cp;
uint64_t value;
if (argc < 2) return 1;
value = strtoull(argv[1], &cp, 10);
if ((cp == argv[1])
|| (*cp != '\0')) {
return 1;
}
return 0;
}
$ cc -o /tmp/a /tmp/a.c
$ /tmp/a 13254
$ echo $?
0
$ /tmp/a 23v23
$ echo $?
1
In any event, this seems simpler than what you posted:
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char *argv[])
{
if (argc != 2) {
fprintf(stderr, "Usage: matchd <str>\n");
return EXIT_FAILURE;
}
for (const char *p = argv[1]; *p != '\0'; p++)
if ('0' <= *p && *p <= '9')
return EXIT_SUCCESS;
return EXIT_FAILURE;
}
Rainer Weikusat <rweikusat@talktalk.net> writes:
Something which would match [0-9]+ in its first argument (if any) would
be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to
the problem of recognizing a digit.
Personally, I'd use:
$ cat /tmp/a.c
#include <stdint.h>
#include <string.h>
int
main(int argc, const char **argv)
{
char *cp;
uint64_t value;
if (argc < 2) return 1;
value = strtoull(argv[1], &cp, 10);
if ((cp == argv[1])
|| (*cp != '\0')) {
return 1;
}
return 0;
}
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
In any event, this seems simpler than what you posted:
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char *argv[])
{
if (argc != 2) {
fprintf(stderr, "Usage: matchd <str>\n");
return EXIT_FAILURE;
}
for (const char *p = argv[1]; *p != '\0'; p++)
if ('0' <= *p && *p <= '9')
return EXIT_SUCCESS;
return EXIT_FAILURE;
}
It's not only 4 lines longer but in just about every individual aspect >syntactically more complicated and more messy and functionally more
clumsy.
This is particularly noticable in the loop
for (const char *p = argv[1]; *p != '\0'; p++)
if ('0' <= *p && *p <= '9')
return EXIT_SUCCESS;
the loop header containing a spuriously qualified variable declaration,
the loop body and half of the termination condition.
The other half then
follows as special-case in the otherwise useless loop body.
It looks like a copy of my code which each individual bit redesigned
under the guiding principle of "Can we make this more complicated?", eg,
char **argv
declares an array of pointers
(as each pointer in C points to an array)
and
char *argv[]
accomplishes exactly the same but uses both more characters and more >different kinds of characters.
scott@slp53.sl.home (Scott Lurndal) writes:
Rainer Weikusat <rweikusat@talktalk.net> writes:
[...]
Something which would match [0-9]+ in its first argument (if any) would >>>be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to >>>the problem of recognizing a digit.
Personally, I'd use:
$ cat /tmp/a.c
#include <stdint.h>
#include <string.h>
int
main(int argc, const char **argv)
{
char *cp;
uint64_t value;
if (argc < 2) return 1;
value = strtoull(argv[1], &cp, 10);
if ((cp == argv[1])
|| (*cp != '\0')) {
return 1;
}
return 0;
}
This will accept a string of digits whose numerical value is <=
ULLONG_MAX, ie, it's basically ^[0-9]+$ with unobvious length and
content limits.
return !strstr(argv[1], "0123456789");
would be a better approximation,
just a much more complicated algorithm
than necessary. Even in strictly conforming ISO-C "digitness" of a
character can be determined by a simple calculation instead of some kind
of search loop.
On 2024-11-22, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 21.11.2024 20:12, Kaz Kylheku wrote:
[...]
In the wild, you see regexes being used for all sorts of stupid stuff,
No one can prevent folks using features for stupid things. Yes.
But the thing is that "modern" regular expressions (Perl regex and its progeny) have features that are designed to exclusively cater to these
folks.
Rainer Weikusat <rweikusat@talktalk.net> wrote:
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
In any event, this seems simpler than what you posted:
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char *argv[])
{
if (argc != 2) {
fprintf(stderr, "Usage: matchd <str>\n");
return EXIT_FAILURE;
}
for (const char *p = argv[1]; *p != '\0'; p++)
if ('0' <= *p && *p <= '9')
return EXIT_SUCCESS;
return EXIT_FAILURE;
}
It's not only 4 lines longer but in just about every individual aspect >>syntactically more complicated and more messy and functionally more
clumsy.
That's a lot of opinion, and not particularly well-founded
opinion at that, given that your code was incorrect to begin
with.
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 20.11.2024 18:50, Rainer Weikusat wrote:
[...]
while (p < e && *p - '0' < 10) ++p;
That's not too bad. And it's really a hell lot faster than a
general-purpose automaton programmed to recognize the same pattern
(which might not matter most of the time, but sometimes, it does).
Okay, I see where you're coming from (and especially in that simple
case).
Personally (and YMMV), even here in this simple case I think that
using pointers is not better but worse - and anyway isn't [in this
form] available in most languages;
That's a question of using the proper tool for the job. In C, that's
pointer and pointer arithmetic because it's the simplest way to express something like this.
in other cases (and languages)
such constructs get yet more clumsy, and for my not very complex
example - /[0-9]+(ABC)?x*foo/ - even a "catastrophe" concerning
readability, error-proneness, and maintainability.
Procedural code for matching strings constructed in this way is
certainly much simpler¹ than the equally procedural code for a
programmable automaton capable of interpreting regexes.
Your statement
is basically "If we assume that the code interpreting regexes doesn't
exist, regexes need much less code than something equivalent which does exist." Without this assumption, the picture becomes a different one altogether.
[...]
In article <87cyinrt5s.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
Rainer Weikusat <rweikusat@talktalk.net> writes:
[...]
Something which would match [0-9]+ in its first argument (if any) would >>>>be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to >>>>the problem of recognizing a digit.
Personally, I'd use:
$ cat /tmp/a.c
#include <stdint.h>
#include <string.h>
int
main(int argc, const char **argv)
{
char *cp;
uint64_t value;
if (argc < 2) return 1;
value = strtoull(argv[1], &cp, 10);
if ((cp == argv[1])
|| (*cp != '\0')) {
return 1;
}
return 0;
}
This will accept a string of digits whose numerical value is <=
ULLONG_MAX, ie, it's basically ^[0-9]+$ with unobvious length and
content limits.
He acknowledged this already.
return !strstr(argv[1], "0123456789");
would be a better approximation,
No it wouldn't. That's not even close. `strstr` looks for an
instance of its second argument in its first, not an instance of
any character in it's second argument in its first. Perhaps you
meant something with `strspn` or similar. E.g.,
const char *p = argv[1] + strspn(argv[1], "0123456789");
return *p != '\0';
cross@spitfire.i.gajendra.net (Dan Cross) writes:
Rainer Weikusat <rweikusat@talktalk.net> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
In any event, this seems simpler than what you posted:
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char *argv[])
{
if (argc != 2) {
fprintf(stderr, "Usage: matchd <str>\n");
return EXIT_FAILURE;
}
for (const char *p = argv[1]; *p != '\0'; p++)
if ('0' <= *p && *p <= '9')
return EXIT_SUCCESS;
return EXIT_FAILURE;
}
It's not only 4 lines longer but in just about every individual aspect >>>syntactically more complicated and more messy and functionally more >>>clumsy.
That's a lot of opinion, and not particularly well-founded
opinion at that, given that your code was incorrect to begin
with.
That's not at all an opinion but an observation. My opinion on this is
that this is either a poor man's attempt at winning an obfuscation
context or - simpler - exemplary bad code.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <87cyinrt5s.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
Rainer Weikusat <rweikusat@talktalk.net> writes:
[...]
Something which would match [0-9]+ in its first argument (if any) would >>>>>be:
#include "string.h"
#include "stdlib.h"
int main(int argc, char **argv)
{
char *p;
unsigned c;
p = argv[1];
if (!p) exit(1);
while (c = *p, c && c - '0' > 10) ++p;
if (!c) exit(1);
return 0;
}
but that's 14 lines of text, 13 of which have absolutely no relation to >>>>>the problem of recognizing a digit.
Personally, I'd use:
$ cat /tmp/a.c
#include <stdint.h>
#include <string.h>
int
main(int argc, const char **argv)
{
char *cp;
uint64_t value;
if (argc < 2) return 1;
value = strtoull(argv[1], &cp, 10);
if ((cp == argv[1])
|| (*cp != '\0')) {
return 1;
}
return 0;
}
This will accept a string of digits whose numerical value is <= >>>ULLONG_MAX, ie, it's basically ^[0-9]+$ with unobvious length and
content limits.
He acknowledged this already.
return !strstr(argv[1], "0123456789");
would be a better approximation,
No it wouldn't. That's not even close. `strstr` looks for an
instance of its second argument in its first, not an instance of
any character in it's second argument in its first. Perhaps you
meant something with `strspn` or similar. E.g.,
const char *p = argv[1] + strspn(argv[1], "0123456789");
return *p != '\0';
My bad.
On 21.11.2024 23:05, Lawrence D'Oliveiro wrote:
Another handy one is “\b” for word boundaries.
I prefer \< and \> (that are quite commonly used) for such structural
things ...
On 2024-11-22, Muttley@DastartdlyHQ.org <Muttley@DastartdlyHQ.org> wrote:
Its not that simple I'm afraid since comments can be commented out.
Umm, no.
eg:
// int i; /*
This /* sequence is inside a // comment, and so the machinery that
recognizes /* as the start of a comment would never see it.
A C99 and C++ compiler would see "int j" and compile it, a regex would
simply remove everything from the first /* to */.
No, it won't, because that's not how regexes are used in a lexical
Also the same probably applies to #ifdef's.
Lexically analyzing C requires implementing the translation phases
as described in the standard. There are preprocessor phases which
delimit the input into preprocessor tokens (pp-tokens). Comments
are stripped in preprocessing. But logical lines (backslash
continuations) are recognized below comments; i.e. this is one
comment:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Personally I think that writing bulky procedural stuff for
something like [0-9]+ can only be much worse, and that further
abbreviations like \d+ are the better direction to go if targeting
a good interface. YMMV.
Assuming that p is a pointer to the current position in a string, e
is a pointer to the end of it (ie, point just past the last byte)
and - that's important - both are pointers to unsigned quantities,
the 'bulky' C equivalent of [0-9]+ is
while (p < e && *p - '0' < 10) ++p;
Here is an example: using a regex match to capture a C comment /* ... */
in Lex compared to just recognizing the start sequence /* and handling
the discarding of the comment in the action.
Without non-greedy repetition matching, the regex for a C comment is
quite obtuse. The procedural handling is straightforward: read
characters until you see a * immediately followed by a /.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 36:27:17 |
| Calls: | 10,392 |
| Calls today: | 3 |
| Files: | 14,064 |
| Messages: | 6,417,153 |