Le 30/12/2021 à 15:52, Stefan Monnier a écrit :
> Thomas Koenig [2021-12-30 11:36:21] wrote:
>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>> Lately I have been thinking that using the same spelling, but using a different color
>>> scheme would work well. The text could be colored, the text could be wrapped in a
>>> box, the background could have one color and the text another. This multiplies by
>>> 50 (or so) the possibilities one could use the same spelling to accomplish.......
>> Or one could use Emojis. (Oh, wait, that has already been done.)
>
> Are you referring to https://stroustrup.com/whitespace98.pdf maybe?

"Whitespace overloading"...

I don't know if I want to laugh hysterically, or just facepalm. I think
both, but that may be challenging to do. Would be some kind of body
language overloading. =)

On Thursday, December 30, 2021 at 8:52:06 AM UTC-6, Stefan Monnier wrote:
> Thomas Koenig [2021-12-30 11:36:21] wrote:
> > MitchAlsup <Mitch...@aol.com> schrieb:
> >> Lately I have been thinking that using the same spelling, but using a different color
> >> scheme would work well. The text could be colored, the text could be wrapped in a
> >> box, the background could have one color and the text another. This multiplies by
> >> 50 (or so) the possibilities one could use the same spelling to accomplish.......
> > Or one could use Emojis. (Oh, wait, that has already been done.)
<
> Are you referring to https://stroustrup.com/whitespace98.pdf maybe?
<
No, I was describing how I write documentation with figures. Figure boxes (sometimes lines)
are given a color, then in the text, I surround the text with a box and color the background
of the text with the same color as in the figure. Makes it straightforward for the eye to go
to the figure and find what the word means.
>
>
> Stefan

On 12/30/2021 6:52 AM, Stefan Monnier wrote:
> Thomas Koenig [2021-12-30 11:36:21] wrote:
>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>> Lately I have been thinking that using the same spelling, but using a different color
>>> scheme would work well. The text could be colored, the text could be wrapped in a
>>> box, the background could have one color and the text another. This multiplies by
>>> 50 (or so) the possibilities one could use the same spelling to accomplish.......
>> Or one could use Emojis. (Oh, wait, that has already been done.)
>
> Are you referring to https://stroustrup.com/whitespace98.pdf maybe?

I expect he is referring to

https://esolangs.org/wiki/Emoji

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Bakul Shah <bakul@iitbombay.org> writes:

> On 12/27/21 12:30 AM, Tim Rentsch wrote:
>
>> Better to
>> follow the principle expressed by Tony Hoare: a language should
>> have only those features that are going to be used in every
>> program.
>
> Do you have a reference to where he said this?

Unfortunately I don't. During the 1970s I read a lot of computer
science literature, but I don't have any notes as to what, so it's
anyone's guess where it might have been. It is of course possible
that I am mis-remembering, but I don't think I am. To be clear, I
am not claiming that the wording is exact - for example, he might
have said "facilities" rather than "features". But I think the
spirit is right (that is, what I said matches the spirit of the
original). Also, it's possible that his comment is not something
I read but something I heard, because I did hear Hoare in person
on at least one occasion.

> I am familiar with his 1974 paper "Hints on Programming Language
> Design"

That paper is one I read during that time. It might be interesting
to read it again (thank you for the link).

> "only those features that are going to be used in every program"
> is a recipe for a totally stagnant language since how can you
> prove that every program will use a feature that does not yet exist?!

Hoare was writing in a different time. In those days people
expected that programming languges would be more or less static,
and not change much once they reached a certain point in their
design. I think that was a reasonable point of view at the time.
In more modern times, the question of how to evolve a programming
language is not any easy question, and there are some examples of
languages that have done rather poorly in that regard. Over in
comp.lang.c++ there is now discussion of a breaking change that
happened between C++17 and C++20, due to the introduction of the
so-called spaceship operator (<=>) and how it interacts with the
standard library. In any case the question of language evolution
was not meant to be included in the principle stated.

Thomas Koenig <tkoenig@netcologne.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
>> Better to
>> follow the principle expressed by Tony Hoare: a language should
>> have only those features that are going to be used in every
>> program.
>
> Taken literally, that is rather extreme.
>
> Would you ban file I/O because there are lots of useful programs
> which only use standard input and standart output?

Depends on what one considers the granularity of a "feature".
For the kind of language that C is, it seems reasonable to say
that <stdio.h> may be counted as a single feature.

Ivan Godard <ivan@millcomputing.com> writes:

> On 12/27/2021 12:46 AM, Tim Rentsch wrote:
>
>> Ivan Godard <ivan@millcomputing.com> writes:
>>
>>> On 12/24/2021 3:52 PM, Bakul Shah wrote:
>>>
>>>> On 12/24/21 1:29 PM, JimBrakefield wrote:
>>>>
>>>>> At my current level of understanding:
>>>>> An interesting feature of Zig is that instead of a macro or
>>>>> preprocessor the compiler
>>>>> will execute at compile time anything the can be computed at compile time
>>>>> (including type expressions). Thus the language itself is it's own
>>>>> preprocessor.
>>>>> And like the RTL languages, simplification and reduction is carried
>>>>> as far as possible.
>>>>
>>>> The "V" language also does this. But this is not the same as decent
>>>> macro processing. Scheme/CL macros allow you to abstract away details
>>>> very nicely but for that to work, there needs to a language syntax model
>>>> the macros can access. This is much simpler in S-expr languages since
>>>> the AST *is* the concrete syntax (more or less)!
>>>
>>> SmallTalk
>>
>> Let me remind you again: Smalltalk, not SmallTalk.
>>
>>> had the execution context accessible and mutable by the
>>> running program, including during translation.
>>
>> When code is running, yes. When code is being compiled, no.
>> It's been quite a few years since I used a Smalltalk system,
>> but most code was written and compiled using a conventional
>> compilation model, without any way to execute code as part
>> of the compilation process.
>
> Yes: most people use only the first order aspects of second order
> systems.

Are you missing the point here? What I am saying is that
Smalltalk does not provide second order capabilities during
compilation (aka translation). Of course people don't take
advantage of second order aspects when compiling/translating
Smalltalk code, because there are no second order aspects
available in those circumstances.

On 1/6/2022 11:15 PM, Tim Rentsch wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>
>> On 12/27/2021 12:46 AM, Tim Rentsch wrote:
>>
>>> Ivan Godard <ivan@millcomputing.com> writes:
>>>
>>>> On 12/24/2021 3:52 PM, Bakul Shah wrote:
>>>>
>>>>> On 12/24/21 1:29 PM, JimBrakefield wrote:
>>>>>
>>>>>> At my current level of understanding:
>>>>>> An interesting feature of Zig is that instead of a macro or
>>>>>> preprocessor the compiler
>>>>>> will execute at compile time anything the can be computed at compile time
>>>>>> (including type expressions). Thus the language itself is it's own
>>>>>> preprocessor.
>>>>>> And like the RTL languages, simplification and reduction is carried
>>>>>> as far as possible.
>>>>>
>>>>> The "V" language also does this. But this is not the same as decent
>>>>> macro processing. Scheme/CL macros allow you to abstract away details
>>>>> very nicely but for that to work, there needs to a language syntax model
>>>>> the macros can access. This is much simpler in S-expr languages since
>>>>> the AST *is* the concrete syntax (more or less)!
>>>>
>>>> SmallTalk
>>>
>>> Let me remind you again: Smalltalk, not SmallTalk.
>>>
>>>> had the execution context accessible and mutable by the
>>>> running program, including during translation.
>>>
>>> When code is running, yes. When code is being compiled, no.
>>> It's been quite a few years since I used a Smalltalk system,
>>> but most code was written and compiled using a conventional
>>> compilation model, without any way to execute code as part
>>> of the compilation process.
>>
>> Yes: most people use only the first order aspects of second order
>> systems.
>
> Are you missing the point here? What I am saying is that
> Smalltalk does not provide second order capabilities during
> compilation (aka translation). Of course people don't take
> advantage of second order aspects when compiling/translating
> Smalltalk code, because there are no second order aspects
> available in those circumstances.

There were second order facilities in the Smalltalk I once used. I'm not
surprised if later implementations discarded second order in favor of
faster first order.

Guillaume <message@bottle.org> writes:

> Le 27/12/2021 at 09:30, Tim Rentsch a ecrit:
>
>> The idea that feature X should be added to a language standard
>> just for the sake of commonality leads inexorably to a language
>> overloaded with features that are used only rarely.
>
> Yes. And isn't that what C++ exactly is? =)

Oh it isn't that. C++ is overloaded (no pun intended) with
features that people use all the time, often without realizing
that they are, and which have the property that they interact in
subtle and surprising ways. To make things even better, C++ has
what I think is the most poorly written reference manual I've
ever read. Astonishingly bad. AFAICT almost no one reads the
C++ standard any more, because unraveling what it says is too
difficult to reach any definitive conclusions about a question.

> (Yes, it's a mess, but it might not be politically correct to say
> this.)

IMO saying C++ is a mess is being too kind.

>> Better to follow the principle expressed by Tony Hoare: a language
>> should have only those features that are going to be used in every
>> program.
>
> Oh well. That statement is a bit extreme. But Hoare liked punch
> lines, and the point is still made. =)

I think whether it's extreme depends on how one understands what
it is meant to say. But based on Hoare's writing and also on
hearing him speak I think he meant it quite seriously (with a
disclaimer that I may have inadvertently changed the meaning
slightly by how I phrased it).

> (Yes, of course extreme. Let's take a trivial example. One can
> write entire programs that do not use a single division operator.
> Does that mean one should remove it from the language, because not
> every program uses it?)

First I don't think of division as an individual feature, but as
part of a larger-grained feature along the lines of "operations
on integer data types". If a language has "less than", does
that mean it doesn't need "greater than"? It seems silly to
have one and not the other, and I think one reason for that is
that the two operations both belong to a single conceptual
"feature".

On a larger scale, there needs be a shared understanding of what
constitutes the universe of programs. For almost any given
language construct, an adversary can concoct a program -- probably
even a useful program -- that does not use the given construct.
Does that mean the language should be stripped down to some sort
of minimalistic Turing-complete subset? Of course it doesn't.
In the statement of principle being discussed, "every program"
means every program in a (presumably large) universe of expected
programs, not every conceivable program.

> I prefer Wirth's "Make it as simple as possible, but not simpler"
> quote that can be found in the Oberon language specs. (And often
> attributed to Einstein.) Seemingly conveys the same idea, but in
> a more realistic, if slightly more abstract, form.

On the origin of the simple/no simpler quote, you might want to
read this:

https://quoteinvestigator.com/2011/05/13/einstein-simple/

On the subject of Wirth and Oberon, I know it may be sacrilege to
say this, but I'm not impressed with what Wirth did after Pascal.
The stuff in Modula was done better and earlier in the language
Mesa, and Wirth was familiar with Mesa before he developed Modula.

As for the simple/no simpler saying as a design principle, to me it
seems completely empty. It says nothing, a Rorschach test that
lets people see whatever they want to see. At one end we might say
a Turing machine is as simple as possible and cannot be simpler.
At the other end of the spectrum, I have heard people touting C++
invoke the "as simple as possible, but no simpler" mantra. Good
design requires balance between elements that provide capability
and restraint against the impulse to include too much. Note what
Fred Brooks says regarding "the second system effect" in his
well-known book The Mythical Man-Month.

On 1/8/2022 3:47 AM, Tim Rentsch wrote:
> Guillaume <message@bottle.org> writes:
>
>> Le 27/12/2021 at 09:30, Tim Rentsch a ecrit:
>>
>>> The idea that feature X should be added to a language standard
>>> just for the sake of commonality leads inexorably to a language
>>> overloaded with features that are used only rarely.
>>
>> Yes. And isn't that what C++ exactly is? =)
>
> Oh it isn't that. C++ is overloaded (no pun intended) with
> features that people use all the time, often without realizing
> that they are, and which have the property that they interact in
> subtle and surprising ways. To make things even better, C++ has
> what I think is the most poorly written reference manual I've
> ever read. Astonishingly bad. AFAICT almost no one reads the
> C++ standard any more, because unraveling what it says is too
> difficult to reach any definitive conclusions about a question.
>
>> (Yes, it's a mess, but it might not be politically correct to say
>> this.)
>
> IMO saying C++ is a mess is being too kind.
>
>>> Better to follow the principle expressed by Tony Hoare: a language
>>> should have only those features that are going to be used in every
>>> program.
>>
>> Oh well. That statement is a bit extreme. But Hoare liked punch
>> lines, and the point is still made. =)
>
> I think whether it's extreme depends on how one understands what
> it is meant to say. But based on Hoare's writing and also on
> hearing him speak I think he meant it quite seriously (with a
> disclaimer that I may have inadvertently changed the meaning
> slightly by how I phrased it).
>
>> (Yes, of course extreme. Let's take a trivial example. One can
>> write entire programs that do not use a single division operator.
>> Does that mean one should remove it from the language, because not
>> every program uses it?)
>
> First I don't think of division as an individual feature, but as
> part of a larger-grained feature along the lines of "operations
> on integer data types". If a language has "less than", does
> that mean it doesn't need "greater than"? It seems silly to
> have one and not the other, and I think one reason for that is
> that the two operations both belong to a single conceptual
> "feature".
>
> On a larger scale, there needs be a shared understanding of what
> constitutes the universe of programs. For almost any given
> language construct, an adversary can concoct a program -- probably
> even a useful program -- that does not use the given construct.
> Does that mean the language should be stripped down to some sort
> of minimalistic Turing-complete subset? Of course it doesn't.
> In the statement of principle being discussed, "every program"
> means every program in a (presumably large) universe of expected
> programs, not every conceivable program.
>
>> I prefer Wirth's "Make it as simple as possible, but not simpler"
>> quote that can be found in the Oberon language specs. (And often
>> attributed to Einstein.) Seemingly conveys the same idea, but in
>> a more realistic, if slightly more abstract, form.
>
> On the origin of the simple/no simpler quote, you might want to
> read this:
>
> https://quoteinvestigator.com/2011/05/13/einstein-simple/
>
> On the subject of Wirth and Oberon, I know it may be sacrilege to
> say this, but I'm not impressed with what Wirth did after Pascal.
> The stuff in Modula was done better and earlier in the language
> Mesa, and Wirth was familiar with Mesa before he developed Modula.

IMO, Wirth did by far his best work in PL360.

On Saturday, January 8, 2022 at 5:47:36 AM UTC-6, Tim Rentsch wrote:
> Guillaume <mes...@bottle.org> writes:
>
> > Le 27/12/2021 at 09:30, Tim Rentsch a ecrit:
> >
> >> The idea that feature X should be added to a language standard
> >> just for the sake of commonality leads inexorably to a language
> >> overloaded with features that are used only rarely.
> >
> > Yes. And isn't that what C++ exactly is? =)
>
> Oh it isn't that. C++ is overloaded (no pun intended) with
> features that people use all the time, often without realizing
> that they are, and which have the property that they interact in
> subtle and surprising ways. To make things even better, C++ has
> what I think is the most poorly written reference manual I've
> ever read. Astonishingly bad. AFAICT almost no one reads the
> C++ standard any more, because unraveling what it says is too
> difficult to reach any definitive conclusions about a question.
>
> > (Yes, it's a mess, but it might not be politically correct to say
> > this.)
>
> IMO saying C++ is a mess is being too kind.
> >> Better to follow the principle expressed by Tony Hoare: a language
> >> should have only those features that are going to be used in every
> >> program.
> >
> > Oh well. That statement is a bit extreme. But Hoare liked punch
> > lines, and the point is still made. =)
>
> I think whether it's extreme depends on how one understands what
> it is meant to say. But based on Hoare's writing and also on
> hearing him speak I think he meant it quite seriously (with a
> disclaimer that I may have inadvertently changed the meaning
> slightly by how I phrased it).
>
> > (Yes, of course extreme. Let's take a trivial example. One can
> > write entire programs that do not use a single division operator.
> > Does that mean one should remove it from the language, because not
> > every program uses it?)
>
> First I don't think of division as an individual feature, but as
> part of a larger-grained feature along the lines of "operations
> on integer data types". If a language has "less than", does
> that mean it doesn't need "greater than"? It seems silly to
> have one and not the other, and I think one reason for that is
> that the two operations both belong to a single conceptual
> "feature".
<
Add and Subtract are an arithmetic pair.
Multiply and divide are an arithmetic pair
Differentiate and Integrate are a functional pair.
Equality and Inequality are an arithmetic set.
These things come together or not at all in pairs.
<
>
> On a larger scale, there needs be a shared understanding of what
> constitutes the universe of programs. For almost any given
> language construct, an adversary can concoct a program -- probably
> even a useful program -- that does not use the given construct.
> Does that mean the language should be stripped down to some sort
> of minimalistic Turing-complete subset? Of course it doesn't.
> In the statement of principle being discussed, "every program"
> means every program in a (presumably large) universe of expected
> programs, not every conceivable program.
<
There are programs with a duty to watch is some other program has failed
and restart it when that happens.
This would require no multiply, Divide, maybe not even subtract,
certainly no floating point, and likely no pointer dereferencing,
and only 1 or 2 local variables and a character string.
<
I really don't think one wants a language "that small".
<
> > I prefer Wirth's "Make it as simple as possible, but not simpler"
> > quote that can be found in the Oberon language specs. (And often
> > attributed to Einstein.) Seemingly conveys the same idea, but in
> > a more realistic, if slightly more abstract, form.
> On the origin of the simple/no simpler quote, you might want to
> read this:
>
> https://quoteinvestigator.com/2011/05/13/einstein-simple/
>
> On the subject of Wirth and Oberon, I know it may be sacrilege to
> say this, but I'm not impressed with what Wirth did after Pascal.
> The stuff in Modula was done better and earlier in the language
> Mesa, and Wirth was familiar with Mesa before he developed Modula.
>
> As for the simple/no simpler saying as a design principle, to me it
> seems completely empty. It says nothing, a Rorschach test that
> lets people see whatever they want to see. At one end we might say
> a Turing machine is as simple as possible and cannot be simpler.
> At the other end of the spectrum, I have heard people touting C++
> invoke the "as simple as possible, but no simpler" mantra. Good
> design requires balance between elements that provide capability
> and restraint against the impulse to include too much. Note what
> Fred Brooks says regarding "the second system effect" in his
> well-known book The Mythical Man-Month.
<
What is not well known is that the designer/architect is not back to
the boldness and cleanness he was in his 1st attempt until attempt #4.

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

I have gone back and read through roughly a dozen of your
postings in this thread and on this general topic. I'm
using the following exchange as a representative example,
although my remarks below are meant as a general response
rather than a specific one.

>> Also there is the question of how often shift/masking bitfield
>> manipulation comes up. I have looked at a fair bit of C code
>> over the years and I just don't see this very often. Probably it
>> does occur routinely in some application areas, but certainly not
>> most of them.
>
> I may be wrong, but I expect it occurs in many "close to the metal"
> applications, such as embedded code and microcontrollers, OS code,
> graphics, etc. ISTM that these are the areas (especially OS) that C
> was designed for.

Looking through your recent writings in this general area, all I
see are statements of opinion and unsupported theories or
beliefs. Thus there appears to be no reason to take the various
comments seriously. When considering a proposal to extend a
standardized language, the burden of proof falls on whoever is
making the proposal. Even taken all together what you have said
here doesn't come close to meeting that burden. So if you want
to be taken seriously in future proposals, be prepared to offer
more than statements of opinion and unsupported theories or
beliefs.

MitchAlsup <MitchAlsup@aol.com> writes:

> On Saturday, January 8, 2022 at 5:47:36 AM UTC-6, Tim Rentsch wrote:
>
>> [...]
>>
>> On a larger scale, there needs be a shared understanding of what
>> constitutes the universe of programs. For almost any given
>> language construct, an adversary can concoct a program -- probably
>> even a useful program -- that does not use the given construct.
>> Does that mean the language should be stripped down to some sort
>> of minimalistic Turing-complete subset? Of course it doesn't.
>> In the statement of principle being discussed, "every program"
>> means every program in a (presumably large) universe of expected
>> programs, not every conceivable program.
>
> There are programs with a duty to watch is some other program has
> failed and restart it when that happens.
> This would require no multiply, Divide, maybe not even subtract,
> certainly no floating point, and likely no pointer dereferencing,
> and only 1 or 2 local variables and a character string. I really
> don't think one wants a language "that small".

I have already addressed this issue with my earlier comments.

Ivan Godard <ivan@millcomputing.com> writes:

>> Are you missing the point here? What I am saying is that
>> Smalltalk does not provide second order capabilities during
>> compilation (aka translation). Of course people don't take
>> advantage of second order aspects when compiling/translating
>> Smalltalk code, because there are no second order aspects
>> available in those circumstances.
>
> There were second order facilities in the Smalltalk I once used.
> I'm not surprised if later implementations discarded second order
> in favor of faster first order.

It would be nice if you could be more specific. I've used
several Smalltalks over a time span of roughly a dozen
years and none of them offered second order mechanisms
during compilation.

On 1/9/2022 6:49 AM, Tim Rentsch wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>
>>> Are you missing the point here? What I am saying is that
>>> Smalltalk does not provide second order capabilities during
>>> compilation (aka translation). Of course people don't take
>>> advantage of second order aspects when compiling/translating
>>> Smalltalk code, because there are no second order aspects
>>> available in those circumstances.
>>
>> There were second order facilities in the Smalltalk I once used.
>> I'm not surprised if later implementations discarded second order
>> in favor of faster first order.
>
> It would be nice if you could be more specific. I've used
> several Smalltalks over a time span of roughly a dozen
> years and none of them offered second order mechanisms
> during compilation.

I no longer remember which system it was. An interpreter, not a
compiler. Park Place Systems maybe?

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> MitchAlsup <MitchAlsup@aol.com> writes:
>
>> On Saturday, January 8, 2022 at 5:47:36 AM UTC-6, Tim Rentsch wrote:
>>
>>> [...]
>>>
>>> On a larger scale, there needs be a shared understanding of what
>>> constitutes the universe of programs. For almost any given
>>> language construct, an adversary can concoct a program -- probably
>>> even a useful program -- that does not use the given construct.
>>> Does that mean the language should be stripped down to some sort
>>> of minimalistic Turing-complete subset? Of course it doesn't.
>>> In the statement of principle being discussed, "every program"
>>> means every program in a (presumably large) universe of expected
>>> programs, not every conceivable program.
>>
>> There are programs with a duty to watch is some other program has
>> failed and restart it when that happens.
>> This would require no multiply, Divide, maybe not even subtract,
>> certainly no floating point, and likely no pointer dereferencing,
>> and only 1 or 2 local variables and a character string. I really
>> don't think one wants a language "that small".
>
> I have already addressed this issue with my earlier comments.

Where, specifically, did you address floating point?

It is certainly an expensive feature that is not needed by a lot
of systems programs:

$ ldd /bin/gzip
linux-vdso.so.1 (0x00007ffce5bd0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ece5a1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7ece89c000)
$ ldd /bin/ssh
linux-vdso.so.1 (0x00007ffe47fce000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fe6dacd2000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fe6da9fc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe6da9f6000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe6da9da000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fe6da9be000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fe6da971000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe6da77d000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fe6da6ed000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe6dade7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe6da6ca000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fe6da5ed000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fe6da5bc000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fe6da5b5000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fe6da5a4000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fe6da59d000)

Ivan Godard <ivan@millcomputing.com> writes:

> On 1/9/2022 6:49 AM, Tim Rentsch wrote:
>
>> Ivan Godard <ivan@millcomputing.com> writes:
>>
>>>> Are you missing the point here? What I am saying is that
>>>> Smalltalk does not provide second order capabilities during
>>>> compilation (aka translation). Of course people don't take
>>>> advantage of second order aspects when compiling/translating
>>>> Smalltalk code, because there are no second order aspects
>>>> available in those circumstances.
>>>
>>> There were second order facilities in the Smalltalk I once used.
>>> I'm not surprised if later implementations discarded second order
>>> in favor of faster first order.
>>
>> It would be nice if you could be more specific. I've used
>> several Smalltalks over a time span of roughly a dozen
>> years and none of them offered second order mechanisms
>> during compilation.
>
> I no longer remember which system it was. An interpreter, not a
> compiler. Park Place Systems maybe?

Both Smalltalk-76 and Smalltalk-80, which later became VisualWorks
of PPS, used a compilation model. Digitalk (or was it DigiTalk?)
Smalltalk also. There were several other Smalltalks, none of which
I ever used AFAIR. Granted, the compiler produced bytecodes that
were subsequently "executed" by the interpreter, similar to a JVM,
but still there was no code evaluation going on at compile time,
just compiling.