On 17/04/2024 21:19, John Ames wrote:
> On Wed, 17 Apr 2024 21:05:03 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> Another thing about Forth is that it gives C a run for its money in
>> potential for obfuscation :
>>
>> : 1 2 ;
>> 1 1 + .
>>
>> Redefine "1". That'll keep the reader on his/her toes!
>
> Redefinitions *stack,* too, so "foo" can mean multiple completely
> different things in different contexts depending on which definition
> was current at the time.
>
> : foo 2 * ;
> : double foo ;
> 3 foo .
>
> : foo 1 + ;
> 3 foo .
> 3 double .
>
> Genuine Forth-heads do staggering things (implementing OOP, etc.) with
> this; personally, it gives *me* the willies.
>

That's why mastering Forth takes a lot longer than just learning the
language!

I think that when finding the definition of a word, Forth just searches
back through the stack of definitions until it gets a hit. And if that
word definition uses other non-primitive words, it goes backwards from
where it currently is, looking only at definitions from before the
current word was defined. Is that right? And if so, can you do
"forward declarations", and mutual recursion somehow?

(I guess this is getting way off-topic for comp.unix.shell, and pretty
questionable for comp.unix.programmer - I don't know how much the
regulars there try to stay on-topic, or if they like threads like this.
I'll happily remove those groups from posts if there is objection to it,
but I don't want to cut out people who are interested if they want the
posts there.)

On Wed, 17 Apr 2024 21:52:06 +0200
David Brown <david.brown@hesbynett.no> wrote:

> I think that when finding the definition of a word, Forth just
> searches back through the stack of definitions until it gets a hit.
> And if that word definition uses other non-primitive words, it goes
> backwards from where it currently is, looking only at definitions
> from before the current word was defined. Is that right? And if so,
> can you do "forward declarations", and mutual recursion somehow?

That's my understanding, yes; essentially, it's a consequence of the
fact that definitions are stored as a list of pointers, and re-
definitions are simply appended to the dictionary without going back
through the rest of it to update any pointers to the prior definition.
A strange design choice, but they're consistent with it.

Forward declarations are possible using the CREATE ... DOES> construct,
which creates a definition that invokes a function pointer which can be
changed later. I dunno about mutual recursion, but it wouldn't shock me
if the same trick could be applied for that.

(And yes, if we ought to pare this back to comp.lang.misc we certainly
can.)

On Wed, 17 Apr 2024, John Ames wrote:

> On Wed, 17 Apr 2024 16:15:14 -0000 (UTC)
> Muttley@dastardlyhq.com wrote:
>
>>> (it means i am engaging in what is nominally a gesture of respect in
>>> a mocking way, so as to indicate that your pompous demands for
>>> respect are being deliberately ignored)
>>
>> Wasn't a demand for respect, just making a point about serious
>> applications and the languages used for them. Games arn't serious.
>
> Your definition of "serious applications" seems to coincide pretty
> substantially with "fields I, personally, have worked in," particularly
> since you've conveniently ignored the passel of non-game applications
> that have also been cited in order to focus on the one you feel most
> prepared to trivialize and discount in pursuance of your "argument."
> And in addition to habitually slagging on applications and tools you
> don't consider "serious" for no particular reason and with zero
> provocation, you name-call like a grade-schooler. So it's difficult
> *not* to parse your overall behavior as simian chest-thumping and
> expecting to be treated as Le Fromage Grande on the basis of standards
> conveniently set by yourself.
>
>> Have another go aspie.
>
> Case in point. But for the sake of argument, let's review:
>
> Person: "This thing exists."
> Muttley: "Nobody uses that."
> People: "Here's all these things that use that."
> Muttley: "Those don't count."
> People: "Come again?"
> Muttley: "They're not serious."
> People: "What's your definition of 'serious' here?"
> Muttley: "Things that I've worked on."
> People: "...Um."
> Muttley: "Also you're a poopiehead."

Sorry Muttley, I have to give this one to John. His argument is flawless
and spot on.

On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:

> Perl has had support for object-oriented programming (with multiple
> inheritance) for many years -- too many for me to remember.

Then why this new “class” thing in 5.38?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:
>> Perl has had support for object-oriented programming (with multiple
>> inheritance) for many years -- too many for me to remember.
>
> Then why this new “class” thing in 5.38?

It's explained reasonably well at the top of the "perldoc perlclass"
documentation in Perl 5.38:

History
Since Perl 5, support for objects revolved around the concept of
*blessing* references with a package name. Such reference could then be
used to call subroutines from the package it was blessed with (or any of
its parents). This system, while bare-bones, was flexible enough to
allow creation of multiple more advanced, community-driven systems for
object orientation.

Class feature is a core implementation of class syntax which is familiar
to what one would find in other programming languages. It isn't a
"bless" wrapper, but a completely new system built right into the perl
interpreter.

--
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 Wed, 17 Apr 2024 16:59:06 -0700, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:
>>>
>>> Perl has had support for object-oriented programming (with multiple
>>> inheritance) for many years -- too many for me to remember.
>>
>> Then why this new “class” thing in 5.38?
>
> It's explained reasonably well at the top of the "perldoc perlclass"
> documentation in Perl 5.38:

It says there is already supposed to be a mechanism for this, it doesn’t
explain why that isn’t good enough.

On 2024-04-17, John Ames <commodorejohn@gmail.com> wrote:
> On Wed, 17 Apr 2024 21:52:06 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> I think that when finding the definition of a word, Forth just
>> searches back through the stack of definitions until it gets a hit.
>> And if that word definition uses other non-primitive words, it goes
>> backwards from where it currently is, looking only at definitions
>> from before the current word was defined. Is that right? And if so,
>> can you do "forward declarations", and mutual recursion somehow?
>
> That's my understanding, yes; essentially, it's a consequence of the
> fact that definitions are stored as a list of pointers, and re-
> definitions are simply appended to the dictionary without going back
> through the rest of it to update any pointers to the prior definition.
> A strange design choice, but they're consistent with it.

I don't know at all whether Forth does this or not, but this design
choice allows the list to be restored to a prior state, whereby the
recent definitions are forgotten, and the old ones revealed again,
similarly to shadowed lexicals being revealed again upon the terminaton
of an inner scope.

It sounds reminiscent of the assoc list representation of the lexical
environment in a rudimentary Lisp interpreter.

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

On Wed, 17 Apr 2024 09:55:12 -0700
John Ames <commodorejohn@gmail.com> wrote:
>On Wed, 17 Apr 2024 16:15:14 -0000 (UTC)
>Muttley@dastardlyhq.com wrote:
>
>> >(it means i am engaging in what is nominally a gesture of respect in
>> >a mocking way, so as to indicate that your pompous demands for
>> >respect are being deliberately ignored)
>>
>> Wasn't a demand for respect, just making a point about serious
>> applications and the languages used for them. Games arn't serious.
>
>Your definition of "serious applications" seems to coincide pretty
>substantially with "fields I, personally, have worked in," particularly

There are plenty of fields I haven't worked in that I would also consider
serious eg agriculture, automotive, energy.

Games arn't on that list.

>provocation, you name-call like a grade-schooler. So it's difficult

I simply descended to the level that the argument had been brought to so
don't complain.

>Muttley: "Also you're a poopiehead."

Are you expecting to be taken seriously?

On Wed, 17 Apr 2024 23:05:34 +0200
D <nospam@example.net> wrote:
>Sorry Muttley, I have to give this one to John. His argument is flawless
>and spot on.

Says a sock puppet who's never posted before. Nice try John.

On Wed, 17 Apr 2024 08:05:23 -0700, John Ames wrote:

> *Syntactically* it's very simple, but explicit stack-orientation with
> reverse-Polish notation is a *very* different programming paradigm than
> practically everything else out there ...

The only really tricky part of stack-based programming is keeping track of
what’s on the stack.

I did some messing about with a reboot of PostScript which tried to add
some niceties, like stack guards and lexical binding. Here’s an example of
the sort of thing I was able to get working (“ddef” and “dstore” define
and assign to dynamically-bound variables, while “ldef” and “lstore”
correspondingly work on lexically-bound ones):

/Count 99 ddef

/metatry
{ % provides context for nonlocals
dup
/Name exch ldef
/Count 0 ldef
{ % actual proc
/Count dup lload 1 add lstore
/Count dup dload 1 add dstore
Name =
(local Count = ) print /Count lload =
(global Count = ) print /Count dload =
(whichever Count = ) print Count =
}
}
ddef

/try1 metatry ddef
/try2 metatry ddef

try1
try2
try1
try2

Output:

try1
local Count = 1
global Count = 100
whichever Count = 1
try2
local Count = 1
global Count = 101
whichever Count = 1
try1
local Count = 2
global Count = 102
whichever Count = 2
try2
local Count = 2
global Count = 103
whichever Count = 2

On 18/04/2024 06:18, Kaz Kylheku wrote:
> On 2024-04-17, John Ames <commodorejohn@gmail.com> wrote:
>> On Wed, 17 Apr 2024 21:52:06 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> I think that when finding the definition of a word, Forth just
>>> searches back through the stack of definitions until it gets a hit.
>>> And if that word definition uses other non-primitive words, it goes
>>> backwards from where it currently is, looking only at definitions
>>> from before the current word was defined. Is that right? And if so,
>>> can you do "forward declarations", and mutual recursion somehow?
>>
>> That's my understanding, yes; essentially, it's a consequence of the
>> fact that definitions are stored as a list of pointers, and re-
>> definitions are simply appended to the dictionary without going back
>> through the rest of it to update any pointers to the prior definition.
>> A strange design choice, but they're consistent with it.
>
> I don't know at all whether Forth does this or not, but this design
> choice allows the list to be restored to a prior state, whereby the
> recent definitions are forgotten, and the old ones revealed again,
> similarly to shadowed lexicals being revealed again upon the terminaton
> of an inner scope.
>

I suppose it also makes it a great deal easier to have small local
functions. Forth programming, as I understand it (I've only done very
small tests in Forth - I've never written a "real" program) generally
involves breaking code down into very small pieces. So your
implementation of "foo" might involve defining words like "get_next",
"double", "set_x", or whatever. (In Forth style these would probably be
shorter names, and perhaps include symbols.) Your implementation of
"bar" might want to re-use these same names but with different
definitions. With the list of pointers design of Forth, you can just
redefine these "local" words as you need to, and ignore any previous
definitions.

> It sounds reminiscent of the assoc list representation of the lexical
> environment in a rudimentary Lisp interpreter.
>

On Thu, 18 Apr 2024 10:30:49 +0200, David Brown wrote:

> With the list of pointers design of Forth, you can just
> redefine these "local" words as you need to, and ignore any previous
> definitions.

So, they reinvented local variables, and thought it was some great
innovation ...

On 18/04/2024 09:55, Lawrence D'Oliveiro wrote:
> On Wed, 17 Apr 2024 08:05:23 -0700, John Ames wrote:
>
>> *Syntactically* it's very simple, but explicit stack-orientation with
>> reverse-Polish notation is a *very* different programming paradigm than
>> practically everything else out there ...
>
> The only really tricky part of stack-based programming is keeping track of
> what’s on the stack.
>
> I did some messing about with a reboot of PostScript which tried to add
> some niceties, like stack guards and lexical binding. Here’s an example of
> the sort of thing I was able to get working (“ddef” and “dstore” define
> and assign to dynamically-bound variables, while “ldef” and “lstore”
> correspondingly work on lexically-bound ones):
>

I think I have only ever heard of one person who actually uses
PostScript for programming by hand, rather than as a print output
format. That is Don Lancaster, an electronics engineer who is a big fan
of "magic sines" (binary strings with low harmonics) and does all his
coding in PostScript. Anyone wanting to see a significant library of
PostScript code might be interested.

<https://www.tinaja.com/magsn01.shtml>

On Thu, 18 Apr 2024 10:37:47 +0200, David Brown wrote:

> I think I have only ever heard of one person who actually uses
> PostScript for programming by hand, rather than as a print output
> format. That is Don Lancaster ...

I know, I have seen his site.

The PostScript graphics model has long been superseded by worthy
successors, like Cairo. I did my own Python binding for Cairo
<https://gitlab.com/ldo/qahirah>, which adds things like vectors, matrices
and colours as first-class objects--beyond what Cairo itself, as a C-
language-based library, can do.

What I am interested in here is the PostScript language itself, and how it
can be modernized.

On Thu, 18 Apr 2024, Muttley@dastardlyhq.com wrote:

> On Wed, 17 Apr 2024 23:05:34 +0200
> D <nospam@example.net> wrote:
>> Sorry Muttley, I have to give this one to John. His argument is flawless
>> and spot on.
>
> Says a sock puppet who's never posted before. Nice try John.

Please keep the jokes coming. I find you most entertaining! =)

On 18/04/2024 10:36, Lawrence D'Oliveiro wrote:
> On Thu, 18 Apr 2024 10:30:49 +0200, David Brown wrote:
>
>> With the list of pointers design of Forth, you can just
>> redefine these "local" words as you need to, and ignore any previous
>> definitions.
>
> So, they reinvented local variables, and thought it was some great
> innovation ...

"word" in Forth terminology is more like "function" in common imperative
languages. (It is not exactly the same, since Forth "words" are much
more flexible - that is both a good thing and a bad thing.)

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

> I think I have only ever heard of one person who actually uses
> PostScript for programming by hand, rather than as a print output
> format.

I think I got a postscript program from Usenet or somewhere to print CD
covers once upon a time. Never used it though. I think the idea was to
edit track and artist names directly into the code and send it to a
printer.

The author may have been Jamie Zawinski but I'm not sure.

David Brown <david.brown@hesbynett.no> wrote at 09:30 this Wednesday (GMT):
> On 16/04/2024 16:49, Muttley@dastardlyhq.com wrote:
>> On Tue, 16 Apr 2024 10:58:49 -0000 (UTC)
>> Christian Weisgerber <naddy@mips.inka.de> wrote:
>>> the FreeBSD boot loader, another constrained environment. In the
>>> end Forth proved too unpopular, few people touched it, and it is
>>> being replaced with Lua now.
>>
>> So moving from one language hardly anyone uses to another that hardly anyone
>> uses. You can't deny the consistency.
>>
>
> Lots of people use Lua. It is very popular as a small scripting
> language, and as a language embedded in other programs - you only need
> two or three C source files linked into your code to make Lua available,
> and it's quite easy to expose C functions as Lua functions.
>
> It is extremely popular in gaming - including for player scripting in
> Minecraft.

Minecraft supports player scripting?
--
user <candycane> is generated from /dev/urandom

On Thu, 18 Apr 2024 11:28:38 +0200
D <nospam@example.net> wrote:
>On Thu, 18 Apr 2024, Muttley@dastardlyhq.com wrote:
>
>> On Wed, 17 Apr 2024 23:05:34 +0200
>> D <nospam@example.net> wrote:
>>> Sorry Muttley, I have to give this one to John. His argument is flawless
>>> and spot on.
>>
>> Says a sock puppet who's never posted before. Nice try John.
>
>Please keep the jokes coming. I find you most entertaining! =)

That hand up your arse must be getting annoying by now.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Wed, 17 Apr 2024 16:59:06 -0700, Keith Thompson wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>> On Wed, 17 Apr 2024 18:04:57 +0100, Ben Bacarisse wrote:
>>>>
>>>> Perl has had support for object-oriented programming (with multiple
>>>> inheritance) for many years -- too many for me to remember.
>>>
>>> Then why this new “class” thing in 5.38?
>>
>> It's explained reasonably well at the top of the "perldoc perlclass"
>> documentation in Perl 5.38:
>
> It says there is already supposed to be a mechanism for this, it doesn’t
> explain why that isn’t good enough.

There's a mechanism for method dispatch in class hierarcies. There's no
builtin support whatsoever for handling class instance data (or class
data, for that matter). This has certain advantages (everything a
reference refers to can be used as object, eg, file handles) and is
reasonably easy to provide for cases without multiple inheritance and
doable otherwise. OTOH, that absolutely not what people familiar with
other programming languages expect and also beyond what many of them can
wisely handle. Hence, a more dictatorial approach is probably expected
to improve things¹.

¹ Somewhat questionable when looking at another newer feature, namely,
subroutine signatures. It would be absolutely great if perl support real
function prototypes including checking function invocations for
correctness at compile time *and* *not* at runtime everytime a
function is called.

On Thu, 18 Apr 2024 07:33:14 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

> There are plenty of fields I haven't worked in that I would also
> consider serious eg agriculture, automotive, energy.
>
> Games arn't on that list.

Very well, then! That leaves us with the larger questions:

* By what logic do you argue that a language which is commonly used in
fields which are (by your own admission) "pretty big" but (in your
assessment) not "serious" is therefore "pretty irrelevant in most
language discussions?"
* What about all of the other non-game applications people have cited?
Are none of these "serious" by your standards?

> I simply descended to the level that the argument had been brought to
> so don't complain.

On the contrary, you've been the one dragging it down from the start;
the first to name-call, the first to accuse someone of being a sock-
puppet, the first to mock other people for having specialties you don't
consider "serious" - and, for that matter, the person who started this
off by talking pointless smack, as if anybody in comp.lang.misc cares
whether a language is considered "relevant" or "serious."

> >Muttley: "Also you're a poopiehead."
>
> Are you expecting to be taken seriously?

Were *you,* when you decided to start throwing around terms like
"aspie?" (2009 called, they want their insult back.)

On Thu, 18 Apr 2024, Muttley@dastardlyhq.com wrote:

> On Thu, 18 Apr 2024 11:28:38 +0200
> D <nospam@example.net> wrote:
>> On Thu, 18 Apr 2024, Muttley@dastardlyhq.com wrote:
>>
>>> On Wed, 17 Apr 2024 23:05:34 +0200
>>> D <nospam@example.net> wrote:
>>>> Sorry Muttley, I have to give this one to John. His argument is flawless
>>>> and spot on.
>>>
>>> Says a sock puppet who's never posted before. Nice try John.
>>
>> Please keep the jokes coming. I find you most entertaining! =)
>
> That hand up your arse must be getting annoying by now.

Keep em coming! =)

On 18/04/2024 17:10, candycanearter07 wrote:
> David Brown <david.brown@hesbynett.no> wrote at 09:30 this Wednesday (GMT):
>> On 16/04/2024 16:49, Muttley@dastardlyhq.com wrote:
>>> On Tue, 16 Apr 2024 10:58:49 -0000 (UTC)
>>> Christian Weisgerber <naddy@mips.inka.de> wrote:
>>>> the FreeBSD boot loader, another constrained environment. In the
>>>> end Forth proved too unpopular, few people touched it, and it is
>>>> being replaced with Lua now.
>>>
>>> So moving from one language hardly anyone uses to another that hardly anyone
>>> uses. You can't deny the consistency.
>>>
>>
>> Lots of people use Lua. It is very popular as a small scripting
>> language, and as a language embedded in other programs - you only need
>> two or three C source files linked into your code to make Lua available,
>> and it's quite easy to expose C functions as Lua functions.
>>
>> It is extremely popular in gaming - including for player scripting in
>> Minecraft.
>
>
> Minecraft supports player scripting?

I am no Minecraft expert. You might need an add-on, or special mode, or
something, to get access to Lua scripting.

On Thu, 18 Apr 2024 10:16:53 -0700
John Ames <commodorejohn@gmail.com> wrote:
>On Thu, 18 Apr 2024 07:33:14 -0000 (UTC)
>Muttley@dastardlyhq.com wrote:
>
>> There are plenty of fields I haven't worked in that I would also
>> consider serious eg agriculture, automotive, energy.
>>
>> Games arn't on that list.
>
>Very well, then! That leaves us with the larger questions:
>
>* By what logic do you argue that a language which is commonly used in
> fields which are (by your own admission) "pretty big" but (in your
> assessment) not "serious" is therefore "pretty irrelevant in most
> language discussions?"

The amount of code written in the language. I doubt game scripting amounts
to much in the scheme of things.

>* What about all of the other non-game applications people have cited?
> Are none of these "serious" by your standards?

Don't remember them tbh. A serious application IMO is something that
impacts society as a whole in that if it didn't exist we'd be in trouble
or something that benefits a persons ability to live their life.
If games vanishes some teenagers and kidults might get a bit annoyed for
a while before they went outside and played with a ball but society would
carry on as before.

>> Are you expecting to be taken seriously?
>
>Were *you,* when you decided to start throwing around terms like
>"aspie?" (2009 called, they want their insult back.)

Its a very relevant insult given these days every socially awkward moron
decides they're on the spectrum so they can have some kind of disadvantage
kudos.

On Thu, 18 Apr 2024 20:59:01 +0200
D <nospam@example.net> wrote:
>On Thu, 18 Apr 2024, Muttley@dastardlyhq.com wrote:
>
>> On Thu, 18 Apr 2024 11:28:38 +0200
>> D <nospam@example.net> wrote:
>>> On Thu, 18 Apr 2024, Muttley@dastardlyhq.com wrote:
>>>
>>>> On Wed, 17 Apr 2024 23:05:34 +0200
>>>> D <nospam@example.net> wrote:
>>>>> Sorry Muttley, I have to give this one to John. His argument is flawless
>>>>> and spot on.
>>>>
>>>> Says a sock puppet who's never posted before. Nice try John.
>>>
>>> Please keep the jokes coming. I find you most entertaining! =)
>>
>> That hand up your arse must be getting annoying by now.
>
>Keep em coming! =)

I suspect thats what you'll be doing at some point.