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.

Scott Lurndal <scott@slp53.sl.home> wrote at 16:09 this Tuesday (GMT):
> John Ames <commodorejohn@gmail.com> writes:
>>On Tue, 2 Apr 2024 15:30:09 -0000 (UTC)
>>candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
>>wrote:
>>
>>> It still protects writing to memory outside that buffer, right?
>>> [snip]
>>
>>"Protecting memory" doesn't mean "no page fault," though, just that it
>>won't scribble all over some other process's memory.
>
> The regions each side of the stack are marked not-present. This supports
> automatic stack expansion, within the resource limit for the stack on
> one side, and will produce a SIGSEGV or SIGBUS on the other end.
>
>
>> But I am curious
>>how universally various freenix distributions these days just let the
>>application segfault vs. using that as a cue to allocate additional
>>stack space; a quick test with WSL (Debian somethingorother) runs that
>>test without complaint, but I don't have a genuine *nix box to hand to
>>try it with.
>
> All linux will allocate space, up to the stack resource limit.

Interesting.
--
user <candycane> is generated from /dev/urandom

In article <87plv762zt.fsf@tudado.org>,
Johanne Fairchild <jfairchild@tudado.org> wrote:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:
>>
>>> reading that indentation.
>>
>> If indentation is good, more indentation should be better.
>
>Too much of a good thing is a bad thing.

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

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

--

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

- Thomas 'PointedEars' Lahn -

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?

On 2024-04-02 20:59, Scott Lurndal wrote:
> gazelle@shell.xmission.com (Kenny McCormack) writes:
>> In article <87plv762zt.fsf@tudado.org>,
>> Johanne Fairchild <jfairchild@tudado.org> wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Mon, 01 Apr 2024 21:26:19 -0300, Johanne Fairchild wrote:
>>>>
>>>>> reading that indentation.
>>>>
>>>> If indentation is good, more indentation should be better.
>>>
>>> Too much of a good thing is a bad thing.
>>
>> By definition. Because the definition of "too much" implies having crossed
>> into the zone of being a bad thing.
>>
>> I would like to argue that there are things that there is no such thing as
>> too much of, but I can't think of any examples off hand.
>
> Money?

Inflation.

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

In article <UzYON.154262$TSTa.122307@fx47.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
....
>>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?

Think of all those lottery winners whose lives got totally screwed up by
money.

I'm of the opinion that if I did win the lottery (which I don't play, so
there's no chance of this happening), I'd keep a million or two to live on
(comfortably) and give the rest away (in one fell swoop) to some good
charity. I wouldn't tell anyone about it.

The hard part, in this day and age where everything is a scam, would be
finding an actually good/deserving charity.

--

Prayer has no place in the public schools, just like facts
have no place in organized religion.
-- Superintendent Chalmers