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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Scripting languages handle the memory for you.

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

John Ames <commodorejohn@gmail.com> writes:
>On 1 Apr 2024 21:13:42 GMT
>ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>
>> This stack "management" is "limited" in C:
>
>True enough, although as noted that's an implementation issue as much
>as it is a limitation of the language spec. (I'm not sure how you could
>handle that in a way that's both robust and reasonably C-ish...)

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

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

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

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> John Ames <commodorejohn@gmail.com> wrote or quoted:
>>And, in fact, C actually does one specific bit of automatic memory
>>management itself - the stack, which may or may not even *be* a true
>>hardware stack (depending on the architecture,) and which is handled in
>>an entirely transparent fashion* by compiler-generated entry/exit code
>>generated by the compiler for each function.
>
> This stack "management" is "limited" in C:
>
> |Unfortunately, the notion of stack overflow is not mentioned
> |by the standard or the standard’s rationale at all. This is
> |very troublesome, as for most actual implementations stack
> |overflow is a real problem.
> ...
> |in a real C implementation, a call like f(10000000) will not
> |return 10000000, but instead will crash with a message like
> |"segmentation fault". Furthermore, stack overflow does not
> |necessarily have to result in a crash with a nice error
> |message, but might also overwrite non-stack parts of the
> |memory (possibly putting the address of virus code there).
> |Stack overflow even can occur without function calls. For
> |example, the program int main(void) { int a[10000000]; }
> ...
> "Subtleties of the ANSI/ISO C standard" (2012); Robbert
> Krebbers, Freek Wiedijk; Radboud University Nijmegen.

Available online at :

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1637.pdf

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

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

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

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

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

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

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

Particularly since the point of this thread is that there isn’t an
important one.

Muttley@dastardlyhq.com writes:

[...]

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

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

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.

No.

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

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

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:
>>
>>> reading that indentation.
>>
>> If indentation is good, more indentation should be better.
>
> No.

Don’t quote so deeply, then.

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:
>You don't seem to much of a Lisp writer. Lisp writers have no problem
>reading that indentation.

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

This is an example of LISP code:

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

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

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

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>( SETQ DIFF
> ( LAMBDA( X )
> ( COND
> ( ( ATOMP X )
> ( COND
> ( ( = X 'X )
> 1 )
> ( T
> 0 )))
> ( T
> ( COND
> ( ( =( CAR X )'SUM )
> ( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

In Python:

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

. An attempt at indentation:

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

. In a multiple-returns style:

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

.

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 4/1/24 15:42, Scott Lurndal wrote:
....
> Why is it important that there be a distinction between "scripting"
> and "non-scripting" languages at all?

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

On 4/1/24 20:57, Lawrence D'Oliveiro wrote:
> On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:
>
>> reading that indentation.
>
> If indentation is good, more indentation should be better.

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

Scott Lurndal <scott@slp53.sl.home> wrote at 22:40 this Monday (GMT):
> John Ames <commodorejohn@gmail.com> writes:
>>On 1 Apr 2024 21:13:42 GMT
>>ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>>
>>> This stack "management" is "limited" in C:
>>
>>True enough, although as noted that's an implementation issue as much
>>as it is a limitation of the language spec. (I'm not sure how you could
>>handle that in a way that's both robust and reasonably C-ish...)
>
> Modern (64-bit) linux systems leave large buffer zones (unmapped addresses)
> on either side of the stack; a stack overflow or underflow will
> immediately fault if the RLIMIT_STACK value is exceeded.

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

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.

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.

On 2024-04-02, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:
>>You don't seem to much of a Lisp writer. Lisp writers have no problem
>>reading that indentation.
>
> Well, there is the expression "write-only code", which shows
> that a good Lisp writer may not necessarily be a good reader.
>
> This is an example of LISP code:
>
> ( SETQ DIFF
> ( LAMBDA( X )
> ( COND
> ( ( ATOMP X )
> ( COND
> ( ( = X 'X )
> 1 )
> ( T
> 0 )))
> ( T
> ( COND
> ( ( =( CAR X )'SUM )
> ( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))
>
> . For someone who has not learned LISP, this is difficult to read,
> /not/ because of the indentation, but because the words used have no
> meaning for him. Without the indentation it would be harder to read.

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

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

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

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

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

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

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

when a cond clause consists of a single expression, then if that
expression is true, cond stops and yields that expression's value.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-04-02, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>>( SETQ DIFF
>> ( LAMBDA( X )
>> ( COND
>> ( ( ATOMP X )
>> ( COND
>> ( ( = X 'X )
>> 1 )
>> ( T
>> 0 )))
>> ( T
>> ( COND
>> ( ( =( CAR X )'SUM )
>> ( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))
>
> In Python:
>
> def diff( x ):
> return 1 if x == 'x' else 0 if type( x )is str
> else[ 'sum', diff( x[ 1 ]), diff( x[ 2 ])]
> if x[ 0 ]== 'sum' else None

n TXR Lisp:

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

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

If we compile 'dif we get unused variable warnings:

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

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

Otherwise we need more verbiage:

((@op . @args) (ignore args) (error ....))
...
(@else (ignore else) 0)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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.