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

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

Pascal is usually compiled to machine code. UCSD Pascal with its
intermediate p-code was an atypical case.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

On 2024-03-30, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Fri, 29 Mar 2024 17:25:18 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>>Scripting is an activity, a use case, not a language.
>>>
>>> So if I write a program to for example process some files in a directory by
>>> your argument its a script whether I write it in shell, python, C++ or
>>> assembler.
>>
>>I also wrote: "Scripting refers to executing commands which are so high
>>level that they are entire applications or functional blocks within an
>>application."
>
> So if I write:
>
> int main()
> {
> system("ls | wc -l");
> return 0;
> }
>
> Thats a script?

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

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

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

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

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

>>You're just being deliberately obtuse, not to mention snippy with the
>>scissors.
>
> I'm not being obtuse. There is no hard dividing line between scripts and

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

> programs - as I said, its shades of grey.

Would you say, fifty shades?

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

On 29/03/2024 17:02, Muttley@dastardlyhq.com wrote:
> On Fri, 29 Mar 2024 08:44:54 -0700
> John Ames <commodorejohn@gmail.com> wrote:
>> On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
>> Muttley@dastardlyhq.com wrote:
>>
>>> My rule of thimb is that a scripting language is one whereby the
>>> source code can be run immediately by the interpreter, eg perl,
>>> python, regardless of what happens internally. A full fledged
>>> programming language is one that requires a compile/debug/link step
>>> first with the compiler and runtime (if required) being seperate. eg
>>> Java, C
>>
>> By *that* logic, even Lisp and Forth don't count as "full-fledged
>> programming languages" o_O Johanne's definition of a "scripting
>
> As a counter point, good luck writing a device driver in lisp. Forth maybe,
> no idea.
>

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

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

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

On 2024-03-30, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Fri, 29 Mar 2024 17:58:41 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> Were the mucky bits actually written in Lisp or was Lisp simply calling some
>>> routines written in assembler?
>>
>>Sorry, could you demarcate where exactly the goalposts are? Which mucky
>>bits?
>
> Oh I dunno, the parts that walk a kernel memory structure for example.

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

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

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

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

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

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

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

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

CCL is compiled; this just turns into a machine language function
poking at stack memory.

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

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:
>>ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:
>>>>A scripting language is a programming language made for a hypothetical
>>>>machine, not too different from a programming language made for a real
>>>>machine, one made of hardware.
>>>C is clearly a programming language, yet its specification
>>>says, "The semantic descriptions in this document describe
>>>the behavior of an abstract machine". And you cannot buy
>>> this abstract C machine as a piece of hardware anywhere!
>>Of course. :) But we both know what that means. It's abstract because
>>there are so many real machines for which this abstract one is an
>>abstraction of. And the real ones are the target of the language.
>
> If you want to see it this way ...
>
> But look at Pascal, Java, or Python. They are usually compiled
> into an intermediate code (called "p-code" in the case of
> Pascal) which is then interpreted (the interpreter is called
> "JVM" in the case of Java). Yet, we think of Pascal and Java
> as programming languages and of Python as a scripting language.

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

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

Muttley@dastardlyhq.com writes:
>On Fri, 29 Mar 2024 17:25:18 -0000 (UTC)
>Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>>Scripting is an activity, a use case, not a language.
>>>
>>> So if I write a program to for example process some files in a directory by
>>> your argument its a script whether I write it in shell, python, C++ or
>>> assembler.
>>
>>I also wrote: "Scripting refers to executing commands which are so high
>>level that they are entire applications or functional blocks within an
>>application."
>
>So if I write:
>
>int main()
>{
> system("ls | wc -l");
> return 0;
>}
>
>Thats a script? No? What if I use popen() or execve() then? Where do you
>draw the line?

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

On 2024-03-30, David Brown <david.brown@hesbynett.no> wrote:
><https://en.wikipedia.org/wiki/Open_Firmware>
>
> It didn't really take off very well, but certainly people have written
> device drivers in Forth.

Unfortunately, the device tree crap from Open Firmware took off.

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On 2024-03-29 02:14, Lawrence D'Oliveiro wrote:
>> At one time, we distinguished between “scripting” languages and
>> “programming” languages. To begin with, the “scripting” languages were
>> somehow more limited in functionality than full-fledged “programming”
>> languages. Or they were slower, because they were interpreted.
> [...]
>
> The key difference is that a program in a scripting language need not
> to be complete or known in order to be executed.
>
> The limitations and ugliness of scripting languages is determined by
> this requirement, but also easiness of use.

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

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

There are a lot of dividing lines (compiled to machine code vs. compiled
to byte code (on each execution or just once) vs. interpreted (perhaps
with JIT), interactive vs. batch, strong vs. weak typing, static
vs. dynamic typing, etc.). None of them are rigorously defined, and
none of them particularly need to be.

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

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

> VAX Pascal (1980) was compiled directly to VAX machine code, as was
> the Pascal compiler I wrote in the graduate compiler class.
>
> UCSD Pascal used p-code, and IIRC Borland picked up
> on that.

Borland's Turbo Pascal compiled to machine code.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

On 2024-03-30 22:28, Keith Thompson wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> On 2024-03-29 02:14, Lawrence D'Oliveiro wrote:
>>> At one time, we distinguished between “scripting” languages and
>>> “programming” languages. To begin with, the “scripting” languages were
>>> somehow more limited in functionality than full-fledged “programming”
>>> languages. Or they were slower, because they were interpreted.
>> [...]
>>
>> The key difference is that a program in a scripting language need not
>> to be complete or known in order to be executed.
>>
>> The limitations and ugliness of scripting languages is determined by
>> this requirement, but also easiness of use.
>
> Perl, Python, and Lua are all considered scripting languages, and for
> all of them a syntax error at the end of a script will prevent any of it
> from being executed. The distinction is that they're not optimized for
> interactive use, as shell languages are (though they all can be used
> interactively).

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

ls

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

rm foo.bar

After that I turn off the computer. My program is complete now.

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

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

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

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

Like I said, in a shell language, you have the assumption that “everything
is literal text until indicated otherwise”.

On Sat, 30 Mar 2024 18:10:36 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>On 2024-03-30, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>I also wrote: "Scripting refers to executing commands which are so high
>>>level that they are entire applications or functional blocks within an
>>>application."
>>
>> So if I write:
>>
>> int main()
>> {
>> system("ls | wc -l");
>> return 0;
>> }
>>
>> Thats a script?
>
>The "ls | wc -l" part is a script, passed off for execution to a
>language that mainly supports scripting.

So its not a script.

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

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

>> No? What if I use popen() or execve() then? Where do you
>> draw the line?
>
>If you use popen and execve, you're using more systems programming
>functional blocks that are not scripting commands.

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

>> I'm not being obtuse. There is no hard dividing line between scripts and
>
>Right now you're doubling down on obtusity, by my estimate.

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

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.

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.

Johanne Fairchild <jfairchild@tudado.org> wrote or quoted:
>A scripting language is a programming language made for a hypothetical
>machine, not too different from a programming language made for a real
>machine, one made of hardware.

I think of the type system:

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

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

Also, resource handling:

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

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 Fr 29 Mär 2024 at 17:20, Muttley@dastardlyhq.com wrote:

> On Fri, 29 Mar 2024 17:13:47 -0000 (UTC)
> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>On 2024-03-29, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Fri, 29 Mar 2024 08:44:54 -0700
>>> John Ames <commodorejohn@gmail.com> wrote:
>>>>On Fri, 29 Mar 2024 09:55:33 -0000 (UTC)
>>>>Muttley@dastardlyhq.com wrote:
>>>>
>>>>> My rule of thimb is that a scripting language is one whereby the
>>>>> source code can be run immediately by the interpreter, eg perl,
>>>>> python, regardless of what happens internally. A full fledged
>>>>> programming language is one that requires a compile/debug/link step
>>>>> first with the compiler and runtime (if required) being seperate. eg
>>>>> Java, C
>>>>
>>>>By *that* logic, even Lisp and Forth don't count as "full-fledged
>>>>programming languages" o_O Johanne's definition of a "scripting
>>>
>>> As a counter point, good luck writing a device driver in lisp.
>>
>>The Lisp machines had operating systems and device drivers written in
>>Lisp, interrupt-driven and all. Where do you perceive the difficulty?
>
> Were the mucky bits actually written in Lisp or was Lisp simply calling some
> routines written in assembler? In the same sense that Python doesn't actually
> "do" AI, its way too slow, the AI but is done in libraries written in C++ that
> Python simply calls.

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

'Andreas
--
ceterum censeo redmondinem esse delendam

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

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

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

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

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

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

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

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

On 2024-04-01, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Mon, 01 Apr 2024 06:49:48 -0300
> Johanne Fairchild <jfairchild@tudado.org> wrote:
>>Muttley@dastardlyhq.com writes:
>>
>>> On Sat, 30 Mar 2024 18:46:50 -0000 (UTC)
>>> Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>>>>(defun get-network-interface-list ()
>>>> (open-shared-library "iphlpapi.dll")
>>>> (let ((blk-size 65536) ;; crude!
>>>> (get-adapters-info (foreign-symbol-address "GetAdaptersInfo")))
>>>> (if get-adapters-info
>>>> (%stack-block ((blk blk-size))
>>>> (rlet ((len-inout #>ULONG blk-size))
>>>> (if (zerop (ff-call get-adapters-info :address blk
>>>> :address len-inout
>>>> #>DWORD))
>>>> (loop for ptr = blk then (pref ptr #>IP_ADAPTER_INFO.Next)
>>>> until (%null-ptr-p ptr)
>>>> collecting
>>>> (let ((alen (pref ptr #>IP_ADAPTER_INFO.AddressLength))
>>
>>>> (addr (pref ptr #>IP_ADAPTER_INFO.Address))
>>>> (aname (pref ptr #>IP_ADAPTER_INFO.AdapterName))
>>>> (descr (pref ptr #>IP_ADAPTER_INFO.Description))
>>>> (iplist (pref ptr
>>#>IP_ADAPTER_INFO.IpAddressList))
>>>>
>>>> (type (pref ptr #>IP_ADAPTER_INFO.Type)))
>>>> (list type
>>>> (loop for i below alen
>>>> collecting (%get-unsigned-byte addr i)
>>>> into mac-bytes
>>>> finally
>>>> (return (mac-bytes-to-string
>>mac-bytes)))
>>>>
>>>> (get-ip-address-list iplist)
>>>> (%get-cstring aname)
>>>> (%get-cstring descr))))))))))
>>>
>>> Ugh. No wonder the language fell out of fashion. Looks like some kind of
>>> hacked up Basic.
>>
>>Fashion and intelligence have never been very good friends.
>
> Readability of the flow of control matters. God knows whats going on with
> all those nested statements.

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

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

The whole thing is compiled into native code.

CCL's primitives for accessing the C stuff aren't pretty, but they are
helpful. It's nice that it has the parsed information about the struct
offsets, like #>IP_ADAPTER_INFO.AdapterName. I didn't have to define
that anywhere. I remember it was pretty easy to figure the primtiies
out from CCL's reference documentation. Easy to write, easy to read
a decade later.

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

John Ames <commodorejohn@gmail.com> writes:
>On 1 Apr 2024 14:16:33 GMT
>ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>
>> Scripting languages handle the memory for you. In a scripting
>> language, you cannot call "malloc" to obtain the obligation to
>> free this piece of memory exactly once in the future. They are
>> garbage collected.
>
>And while this is pretty true of scripting languages, it doesn't make
>for a good point-of-contrast with "non-scripting" languages; *piles* of
>them include support for automatic memory management, and some (outside
>of the C family) don't even include facilities for doing it "by hand."

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

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

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.