Guillaume <message@bottle.org> schrieb:

> 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.

I've played for a while with Modula-2, but never used Oberon.

The I/O was a pain: Having to call a separate function for each
item was simply to tiresome to type.

There are a few things that can be done with I/O:

a) Make it part of the language. This adds language complexity,
and was done for languages like Fortran or Pascal.

b) Make it part of the library, with formatted output statements
like printf(). This was originally done in C, led to things
like varargs and to strange behavior when people got the format
string wrong. Compilers nowadays check printf, so b) is now
usually a) in practice.

c) Make it part of a library and prescribe a single call for
each variable type. Cumbersome to use.

d) Add templates or generics to the language and use a generic
library.

e) Ignore I/O altogether, like Algol. The least preferable
method.

On Monday, December 27, 2021 at 3:05:20 PM UTC-6, Stephen Fuld wrote:
> On 12/27/2021 12:54 PM, Michael S wrote:
> > On Monday, December 27, 2021 at 10:12:22 PM UTC+2, Stephen Fuld wrote:
> >> On 12/27/2021 11:50 AM, Michael S wrote:
> >>> On Monday, December 27, 2021 at 7:10:56 PM UTC+2, Stephen Fuld wrote:
> >>>> On 12/27/2021 12:30 AM, Tim Rentsch wrote:
> >> snip
> >>>>> 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.
> >>>
> >>> I did and do spend significant portion of my time as sw developer in at least part of the above mentioned areas.
> >>> And my experience is that it's not a case.
> >>> I mean, both extraction from bit field to scalar and insertion of scalar into bit field are indeed not very rare.
> >>> But copying of one bit field into another is extremely rare.
> >> Oh, I agree with that. But once you have the "syntactical sugar" of
> >> pseudo functions for extraction and insertion, the copying is just there
> >> for free.
> >
> > But both for extraction to scalar and for insertion from scalar what Tim said is true - doing them with shifts and masks is easy and not error-prone.
> > Pay attention that "extraction to scalar" and "insertion from scalar" implies that the bit field is no wider than widest scalar [integer] data type of a given machine, which is already quite significant simplification.
> But if the starting bit number and length are variables, not explicit
> constants, you might want to have code that checks for "legality" of the
> values.
<
My 66000 HW looks at the values and raises an exception if the values are out of some
reasonable range.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On Monday, December 27, 2021 at 4:16:32 PM UTC-6, Thomas Koenig wrote:
> Guillaume <mes...@bottle.org> schrieb:
> > Le 27/12/2021 à 09:30, Tim Rentsch a écrit :
> >> 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? =)
> > (Yes, it's a mess, but it might not be politically correct to say this.)
> What C++ suffers from isn't feature creep. It's a feature stampede.
<
Here, Here

On 12/27/21 2:14 PM, Thomas Koenig wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>> Would you ban file I/O because there are lots of useful programs
>>> which only use standard input and standart output?
>>
>> Maybe the argument goes that file I/O should not be part of the
>> language, but part of the library ;-)
>
> That is not really the case for C anymore. The library is very
> much part of the language now, as you will discover if you try to
> use reserved names for anything else.
>
> Example:
>
> #include <stdio.h>
>
> double cos(double x)
> {
> return 3*x;
> }
>
> int main()
> {
> double a = -0.1;
> printf ("%f\n", 1+cos(-a));
> }
>
> What will this print, both with gcc and with clang?
>

This works fine with clang & gcc. cos is not a reserved word.

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? I am familiar with
his 1974 paper "Hints on Programming Language Design"
http://flint.cs.yale.edu/cs428/doc/HintsPL.pdf

There he says (among other things)

- The designer of a new feature should concentrate on one feature
at a time. ... He should make sure that his feature mitigates
some disadvantage or remedies some incompleteness of the language
without compromising any of its existing merits. ... He should
write a number of example programs, evaluating all the consequences
of using the feature, in comparison with its many alternatives. ...

- The language designer should be familiar with many alternative
features designed by others, and should have excellent judgement
in choosing the best and rejecting any that are mutually
inconsistent. He must be capable of reconciling, by good engineering
design, any remaining minor inconsistencies or overlaps between
separately designed features.

"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?!

On 12/27/2021 2:47 PM, MitchAlsup wrote:
> On Monday, December 27, 2021 at 4:16:32 PM UTC-6, Thomas Koenig wrote:
>> Guillaume <mes...@bottle.org> schrieb:
>>> Le 27/12/2021 à 09:30, Tim Rentsch a écrit :
>>>> 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? =)
>>> (Yes, it's a mess, but it might not be politically correct to say this.)
>> What C++ suffers from isn't feature creep. It's a feature stampede.
> <
> Here, Here

Thear, Thear?

Bakul Shah <bakul@iitbombay.org> schrieb:
> On 12/27/21 2:14 PM, Thomas Koenig wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>>> Would you ban file I/O because there are lots of useful programs
>>>> which only use standard input and standart output?
>>>
>>> Maybe the argument goes that file I/O should not be part of the
>>> language, but part of the library ;-)
>>
>> That is not really the case for C anymore. The library is very
>> much part of the language now, as you will discover if you try to
>> use reserved names for anything else.
>>
>> Example:
>>
>> #include <stdio.h>
>>
>> double cos(double x)
>> {
>> return 3*x;
>> }
>>
>> int main()
>> {
>> double a = -0.1;
>> printf ("%f\n", 1+cos(-a));
>> }
>>
>> What will this print, both with gcc and with clang?
>>
>
> This works fine with clang & gcc. cos is not a reserved word.

Sorry, wrong example. Here is one that does something unexpected,
at least to me:

#include <stdio.h>

double
FUNC (double x)
{ return x / 2 + x * x;
}

double
foo (double x)
{ return 1 - FUNC (-x);
}

int
main ()
{ printf ("%f\n", foo (1.2));
} $ gcc b.c && ./a.out
0.160000
$ gcc -DFUNC=sin b.c && ./a.out
3.040000

This is actually correct according to the C standard, because
sin is a reserved word if it has external linkage, even if
math.h is not included.

From this, I think it is safe to say that the C library is no
longer separate from the language.

Michael S wrote:
> On Monday, December 27, 2021 at 7:10:56 PM UTC+2, Stephen Fuld wrote:
>> On 12/27/2021 12:30 AM, Tim Rentsch wrote:
>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
>>>
>>>> On 12/22/2021 12:24 PM, Tim Rentsch wrote:
>>>>
>>>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
>>>>>
>>>>>> On 12/20/2021 10:21 AM, James Van Buskirk wrote:
>>>>>>
>>>>>>> "Stephen Fuld" wrote in message news:spqc1d$oio$1...@dont-email.me...
>>>>>>>
>>>>>>>> A compiler I used to use (it was for Fortran, but this
>>>>>>>> functionality is not Fortran specific) had a pseudo function named
>>>>>>>> "Bits". It looked like a function that accepted three arguments,
>>>>>>>> a variable name and a starting bit number and number of bits, both
>>>>>>>> of which could be a constant or an integer variable. One of its
>>>>>>>> unique properties is that it could also be used on the left hand
>>>>>>>> side of an assignment statement.
>>>>>>>>
>>>>>>>> This feature led to very clear, concise code, that the compiler
>>>>>>>> didn't have to go through a complex algorithms to recognize, and
>>>>>>>> would generate optimal, inline code. There was sort of a pragma
>>>>>>>> that could optionally generate checking code for out of range
>>>>>>>> combinations of length and starting bit number.
>>>>>>>>
>>>>>>>> So, for example, the source code to move two bits starting at bit
>>>>>>>> 3 of variable B to starting at bit 4 of variable A would be
>>>>>>>>
>>>>>>>> Bits (A, 2, 4) = Bits (B, 2, 3)
>>>>>>>>
>>>>>>>> I always liked this feature, and used it a fair amount.
>>>>>>>
>>>>>>> Compare
>>>>>>> https://gcc.gnu.org/onlinedocs/gfortran/IBITS.html#IBITS
>>>>>>> https://gcc.gnu.org/onlinedocs/gfortran/MVBITS.html#MVBITS
>>>>>>> which are both elemental.
>>>>>>
>>>>>> They seem essentially equivalent. It says that these came in with
>>>>>> Fortran 90. The compiler I was referring to had its roots in a
>>>>>> predecessor with a different name that dated back to at least the
>>>>>> early 1970s. I am glad the idea became standardized.
>>>>>>
>>>>>> I guess I should ask the question that given that C is probably used
>>>>>> for bit manipulation stuff at least as much as Fortran, how come the
>>>>>> C standard didn't pick up some equivalent?
>>>>>
>>>>> Not necessarily an answer but an observation: in C no new language
>>>>> feature is needed, because C has the C preprocessor. It isn't hard
>>>>> to write a macro that does the necessary shifting and masking (and
>>>>> these days compilers are mostly smart enough to recognize the common
>>>>> patterns and translate them efficiently and in machine-specific
>>>>> ways).
>>>>
>>>> While you are right, of course, about the preprocessor, I guess it
>>>> comes down to me having a different philosophy of language design,
>>>> than what Mitch expressed in his (sarcastic) comment.
>>>
>>> Sorry, I thought the question was why it hasn't been done, not
>>> why it should or shouldn't be done.
>>>
>>>>> Having a straightforward way to succinctly express the requirement
>>>>> is <ahem> Not 'C'.
>>>
>>> You are attributing to me something I didn't say. Please don't
>>> do that.
>> Sorry, I thought that it was clear that I was quoting Mitch, not you.
>>>> The problem with the preprocessor approach is that everyone will
>>>> code their own macro, possibly with different syntax, so I have to
>>>> learn what you did, then if I move to a different project, what they
>>>> did etc. That is the beauty of a standard. (Unless you are talking
>>>> about having the preprocessor macro standardized.)
>>>>
>>>> Compare with, for example, integer division. It is part of the
>>>> standard, even though fairly rarely used. If bit field extraction
>>>> and insertion are reasonably well used (and I am guessing they are -
>>>> at least as much as they are used in Fortran, though probably less
>>>> than division), then I feel they should be standardized to ease the
>>>> programmer's job.
>>>
>>> Manipulating bit fields can easily be synthesized using other
>>> existing operators. Division does not have that property.
>> I agree that division was a poorly chosen example. But synthesizing bit
>> fields can get fairly complex (variables for starting bit number and
>> length, potentially on both the source and the target, with checking to
>> insure the combinations of length and starting bit number are files are
>> legal). While you certainly can synthesize this, I would question
>> whether it is "easy", and, perhaps more importantly, easy for someone
>> else to comprehend and for you to debug, especially years later. Of
>> course, YMMV.
>>> 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.
>
> I did and do spend significant portion of my time as sw developer in at least part of the above mentioned areas.
> And my experience is that it's not a case.
> I mean, both extraction from bit field to scalar and insertion of scalar into bit field are indeed not very rare.
> But copying of one bit field into another is extremely rare.

I agree:

I have actually done this myself, but then always in the context of
variable bit extracts, merged into a target buffer reg. Yes, having
variable length bit extract and insert would have saved one or two
instructions from each half of this, but it had never been really
performance critical.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 12/28/21 12:27 AM, Thomas Koenig wrote:
> Bakul Shah <bakul@iitbombay.org> schrieb:
>> On 12/27/21 2:14 PM, Thomas Koenig wrote:
>>> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>>>> Would you ban file I/O because there are lots of useful programs
>>>>> which only use standard input and standart output?
>>>>
>>>> Maybe the argument goes that file I/O should not be part of the
>>>> language, but part of the library ;-)
>>>
>>> That is not really the case for C anymore. The library is very
>>> much part of the language now, as you will discover if you try to
>>> use reserved names for anything else.
>>>
>>> Example:
>>>
>>> #include <stdio.h>
>>>
>>> double cos(double x)
>>> {
>>> return 3*x;
>>> }
>>>
>>> int main()
>>> {
>>> double a = -0.1;
>>> printf ("%f\n", 1+cos(-a));
>>> }
>>>
>>> What will this print, both with gcc and with clang?
>>>
>>
>> This works fine with clang & gcc. cos is not a reserved word.
>
> Sorry, wrong example. Here is one that does something unexpected,
> at least to me:
>
> #include <stdio.h>
>
> double
> FUNC (double x)
> {
> return x / 2 + x * x;
> }
>
> double
> foo (double x)
> {
> return 1 - FUNC (-x);
> }
>
> int
> main ()
> {
> printf ("%f\n", foo (1.2));
> }
> $ gcc b.c && ./a.out
> 0.160000
> $ gcc -DFUNC=sin b.c && ./a.out
> 3.040000
>
> This is actually correct according to the C standard, because
> sin is a reserved word if it has external linkage, even if
> math.h is not included.
>
> From this, I think it is safe to say that the C library is no
> longer separate from the language.

clang produces the 0.160000 for both cases. I tried reading
section 7.1.3 of n2731.pdf but I failed to grasp it.

On Mon, 27 Dec 2021 22:27:18 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

>Guillaume <message@bottle.org> schrieb:
>
>> 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.
>
>I've played for a while with Modula-2, but never used Oberon.
>
>The I/O was a pain: Having to call a separate function for each
>item was simply to tiresome to type.

Just about as annoying as C++ stream I/O <grin>.

Note: Modula 2 called everything "procedure", but most people here
(including me!) think in "function" ala C, so I will call things
functions.

What you have to recognize was that - excepting RawIO - all the I/O
functions worked with portable TEXT format.

This meant that you could take your data file to any machine and the
Modula 2 programs there would do ... almost said "the right thing" ...
something sensible with the file data.

But it also meant, e.g., that if the input was "-10" then
ReadCard(inal) would be an error, but ReadInt(eger) would be OK. Hence
different functions for different types.

RawIO was very much like using C: just Read or Write some buffer.
Modula 2 allowed any object to be passed as a (pointer to a)
SYSTEM.LOC [effectively 'byte'] array - which would give the function
access to the object's raw bits. Arrays were zero-based, but they
were pseudo-objects that could be queried for their length, so Read
and Write could never overrun the buffer due to a programmer error
passing the wrong size.

Although not standard, at least some implementations did provide the
moral equivalent of 'vararg', so with some effort it was possible to
cobble up something like printf and scanf for normal I/O and just use
them instead.

What I disliked most about Modula 2 was case sensitivity. I never
used Oberon, but I thought Modula 3 was much nicer than Modula 2.

YMMV,
George

On Sat, 25 Dec 2021 15:17:17 -0800, Bakul Shah <bakul@iitbombay.org>
wrote:

>Can any of the RnRS Schemes do reader macros?

None of the RnRS documents address reader macros ... but they don't
address many other real world concerns either.

A number of Scheme implementations do in fact offer reader macros.
'Racket', in particular, allows complete front-ending of the read
process so you can provide for any input syntax you desire.

Bakul Shah <bakul@iitbombay.org> schrieb:
> On 12/28/21 12:27 AM, Thomas Koenig wrote:

>> #include <stdio.h>
>>
>> double
>> FUNC (double x)
>> {
>> return x / 2 + x * x;
>> }
>>
>> double
>> foo (double x)
>> {
>> return 1 - FUNC (-x);
>> }
>>
>> int
>> main ()
>> {
>> printf ("%f\n", foo (1.2));
>> }
>> $ gcc b.c && ./a.out
>> 0.160000
>> $ gcc -DFUNC=sin b.c && ./a.out
>> 3.040000
>>
>> This is actually correct according to the C standard, because
>> sin is a reserved word if it has external linkage, even if
>> math.h is not included.
>>
>> From this, I think it is safe to say that the C library is no
>> longer separate from the language.
>
> clang produces the 0.160000 for both cases. I tried reading
> section 7.1.3 of n2731.pdf but I failed to grasp it.

The central sentence at least in n2176 is

# All identifiers with external linkage in any of the following
# subclauses (including the future library directions) and errno
# are always reserved for use as identifiers with external linkage.

and

# If the program declares or defines an identifier in a context in
# which it is reserved (other than as allowed by 7.1.4), or defines
# a reserved identifier as a macro name, the behavior is undefined.

The program above with -DFUNC=sin uses a reserved identifier,
resulting in undefined behavior.

In practice, gcc sees -sin(-x) and simplifies it to sin(x),
without a warning (which is a QoI issue).

Therefore, my argument that the C library is not separate from
the language itself, but has crept into the language proper in
via 7.1.3.

Le 29/12/2021 à 08:34, George Neuner a écrit :
> What I disliked most about Modula 2 was case sensitivity.

All modern languages I know of are case sensitive. (Except, I think ADA,
which you might think is not modern, although the latest revision of the
std is 2012.)

So what do you mean exactly? Yes, contrary to Pascal, Modula-2 was made
case sensitive. Same for all later iterations, like Oberon. Modula-3 as
well.

What many people find annoying are not the case sensitivity in itself
(which almost all modern languages have), but the uppercase keywords in
a case-sensitive language. So maybe that's what you mean. If so, the
same in all versions of Oberon and also in Modula-3.

> I never used Oberon, but I thought Modula 3 was much nicer than Modula 2.

Modula-2 in its latest revision was really not bad at all already. As
with most Wirthian languages, problem is, there were never many
compilers available. So the tooling was missing. (Exception with Pascal,
for which, even Wirth, when asked, has no clear explanation of why it
became successful while other languages did not...)

Modula-3 is really interesting. It's a wirthian language, but amended
for "industry" use by a committee of very competent people. You can find
the language report - I strongly suggest taking a look! The tooling was
also dearly missing at the time, but CM3 is knowing some kind of
revival: https://github.com/modula3/cm3

On 2021-12-29 21:18, Guillaume wrote:
> Le 29/12/2021 à 08:34, George Neuner a écrit :
>> What I disliked most about Modula 2 was case sensitivity.
>
> All modern languages I know of are case sensitive. (Except, I think ADA,
> which you might think is not modern, although the latest revision of the
> std is 2012.)

It is spelled "Ada", although you may think it silly for us Ada-fans to
insist on casing, as the language itself indeed is case-insensitive. It
is named after Ada Byron, so is not an acronym.

Next revision coming in 2022, as soon as the new standard is approved by
ISO higher levels.

> Modula-3 is really interesting. It's a wirthian language, but amended
> for "industry" use by a committee of very competent people.

Much the same can be said of Ada, but I'm not sure if Wirth approves of
the language -- a quick web search did not find any opinion.

On Wednesday, December 29, 2021 at 1:19:04 PM UTC-6, Guillaume wrote:
> Le 29/12/2021 à 08:34, George Neuner a écrit :
> > What I disliked most about Modula 2 was case sensitivity.
> All modern languages I know of are case sensitive. (Except, I think ADA,
> which you might think is not modern, although the latest revision of the
> std is 2012.)
>
> So what do you mean exactly? Yes, contrary to Pascal, Modula-2 was made
> case sensitive. Same for all later iterations, like Oberon. Modula-3 as
> well.
>
> What many people find annoying are not the case sensitivity in itself
> (which almost all modern languages have), but the uppercase keywords in
> a case-sensitive language.
<
a) this sounds like a couple of tweeks to an editor would fix the problem.
<
b) in C, we often have variable (a variable of local scope), b) VARIABLE (a macro
having to do with things of type variable, and c) Variable (a type used to create
instances of variable). So, we are quite use to name overloading. However, only
the Obfuscated_C-programmer uses spellings such as vARIABLE, VaRiAbLe,...
<
> So maybe that's what you mean. If so, the
> same in all versions of Oberon and also in Modula-3.
> > I never used Oberon, but I thought Modula 3 was much nicer than Modula 2.
> Modula-2 in its latest revision was really not bad at all already. As
> with most Wirthian languages, problem is, there were never many
> compilers available. So the tooling was missing. (Exception with Pascal,
> for which, even Wirth, when asked, has no clear explanation of why it
> became successful while other languages did not...)
>
> Modula-3 is really interesting. It's a wirthian language, but amended
> for "industry" use by a committee of very competent people. You can find
> the language report - I strongly suggest taking a look! The tooling was
> also dearly missing at the time, but CM3 is knowing some kind of
> revival: https://github.com/modula3/cm3

On 12/29/2021 1:59 PM, MitchAlsup wrote:
> On Wednesday, December 29, 2021 at 1:19:04 PM UTC-6, Guillaume wrote:
>> Le 29/12/2021 à 08:34, George Neuner a écrit :
>>> What I disliked most about Modula 2 was case sensitivity.
>> All modern languages I know of are case sensitive. (Except, I think ADA,
>> which you might think is not modern, although the latest revision of the
>> std is 2012.)
>>
>> So what do you mean exactly? Yes, contrary to Pascal, Modula-2 was made
>> case sensitive. Same for all later iterations, like Oberon. Modula-3 as
>> well.
>>
>> What many people find annoying are not the case sensitivity in itself
>> (which almost all modern languages have), but the uppercase keywords in
>> a case-sensitive language.
> <
> a) this sounds like a couple of tweeks to an editor would fix the problem.
> <
> b) in C, we often have variable (a variable of local scope), b) VARIABLE (a macro
> having to do with things of type variable, and c) Variable (a type used to create
> instances of variable). So, we are quite use to name overloading. However, only
> the Obfuscated_C-programmer uses spellings such as vARIABLE, VaRiAbLe,...

YouDontUseCamelForm?

On Wednesday, December 29, 2021 at 7:49:16 PM UTC-6, Ivan Godard wrote:
> On 12/29/2021 1:59 PM, MitchAlsup wrote:
> > On Wednesday, December 29, 2021 at 1:19:04 PM UTC-6, Guillaume wrote:
> >> Le 29/12/2021 à 08:34, George Neuner a écrit :
> >>> What I disliked most about Modula 2 was case sensitivity.
> >> All modern languages I know of are case sensitive. (Except, I think ADA,
> >> which you might think is not modern, although the latest revision of the
> >> std is 2012.)
> >>
> >> So what do you mean exactly? Yes, contrary to Pascal, Modula-2 was made
> >> case sensitive. Same for all later iterations, like Oberon. Modula-3 as
> >> well.
> >>
> >> What many people find annoying are not the case sensitivity in itself
> >> (which almost all modern languages have), but the uppercase keywords in
> >> a case-sensitive language.
> > <
> > a) this sounds like a couple of tweeks to an editor would fix the problem.
> > <
> > b) in C, we often have variable (a variable of local scope), b) VARIABLE (a macro
> > having to do with things of type variable, and c) Variable (a type used to create
> > instances of variable). So, we are quite use to name overloading. However, only
> > the Obfuscated_C-programmer uses spellings such as vARIABLE, VaRiAbLe,....
<
> YouDontUseCamelForm?
<
When I run out of other ways of expressing something, yes.
<
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........

Ivan Godard <ivan@millcomputing.com> schrieb:
> On 12/29/2021 1:59 PM, MitchAlsup wrote:
>> On Wednesday, December 29, 2021 at 1:19:04 PM UTC-6, Guillaume wrote:
>>> Le 29/12/2021 à 08:34, George Neuner a écrit :
>>>> What I disliked most about Modula 2 was case sensitivity.
>>> All modern languages I know of are case sensitive. (Except, I think ADA,
>>> which you might think is not modern, although the latest revision of the
>>> std is 2012.)
>>>
>>> So what do you mean exactly? Yes, contrary to Pascal, Modula-2 was made
>>> case sensitive. Same for all later iterations, like Oberon. Modula-3 as
>>> well.
>>>
>>> What many people find annoying are not the case sensitivity in itself
>>> (which almost all modern languages have), but the uppercase keywords in
>>> a case-sensitive language.
>> <
>> a) this sounds like a couple of tweeks to an editor would fix the problem.
>> <
>> b) in C, we often have variable (a variable of local scope), b) VARIABLE (a macro
>> having to do with things of type variable, and c) Variable (a type used to create
>> instances of variable). So, we are quite use to name overloading. However, only
>> the Obfuscated_C-programmer uses spellings such as vARIABLE, VaRiAbLe,...
>
> YouDontUseCamelForm?

I belive it's called OBNoxiousCapitalization.

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>Much the same can be said of Ada, but I'm not sure if Wirth approves of
>the language -- a quick web search did not find any opinion.

I dimly remember that he rejected Ada, in particular because of
exceptions, with words like "They don't know how to program". I don't
find this through web searches, though.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 30/12/21 03:25, MitchAlsup wrote:
> On Wednesday, December 29, 2021 at 7:49:16 PM UTC-6, Ivan Godard wrote:
>> On 12/29/2021 1:59 PM, MitchAlsup wrote:
>>> On Wednesday, December 29, 2021 at 1:19:04 PM UTC-6, Guillaume wrote:
>>>> Le 29/12/2021 à 08:34, George Neuner a écrit :
>>>>> What I disliked most about Modula 2 was case sensitivity.
>>>> All modern languages I know of are case sensitive. (Except, I think ADA,
>>>> which you might think is not modern, although the latest revision of the
>>>> std is 2012.)
>>>>
>>>> So what do you mean exactly? Yes, contrary to Pascal, Modula-2 was made
>>>> case sensitive. Same for all later iterations, like Oberon. Modula-3 as
>>>> well.
>>>>
>>>> What many people find annoying are not the case sensitivity in itself
>>>> (which almost all modern languages have), but the uppercase keywords in
>>>> a case-sensitive language.
>>> <
>>> a) this sounds like a couple of tweeks to an editor would fix the problem.
>>> <
>>> b) in C, we often have variable (a variable of local scope), b) VARIABLE (a macro
>>> having to do with things of type variable, and c) Variable (a type used to create
>>> instances of variable). So, we are quite use to name overloading. However, only
>>> the Obfuscated_C-programmer uses spellings such as vARIABLE, VaRiAbLe,...
> <
>> YouDontUseCamelForm?
> <
> When I run out of other ways of expressing something, yes.
> <
> 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.......

But not for the 8% of men and 0.1% of women that have some
form of colour blindness.

And then there's the strange optical illusions where the
apparent colour depends on the surrounding colour.

On 30/12/2021 11:40, Tom Gardner wrote:
> On 30/12/21 03:25, MitchAlsup wrote:
>> On Wednesday, December 29, 2021 at 7:49:16 PM UTC-6, Ivan Godard wrote:
>>> On 12/29/2021 1:59 PM, MitchAlsup wrote:
>>>> On Wednesday, December 29, 2021 at 1:19:04 PM UTC-6, Guillaume wrote:
>>>>> Le 29/12/2021 à 08:34, George Neuner a écrit :
>>>>>> What I disliked most about Modula 2 was case sensitivity.
>>>>> All modern languages I know of are case sensitive. (Except, I think
>>>>> ADA,
>>>>> which you might think is not modern, although the latest revision
>>>>> of the
>>>>> std is 2012.)
>>>>>
>>>>> So what do you mean exactly? Yes, contrary to Pascal, Modula-2 was
>>>>> made
>>>>> case sensitive. Same for all later iterations, like Oberon.
>>>>> Modula-3 as
>>>>> well.
>>>>>
>>>>> What many people find annoying are not the case sensitivity in itself
>>>>> (which almost all modern languages have), but the uppercase
>>>>> keywords in
>>>>> a case-sensitive language.
>>>> <
>>>> a) this sounds like a couple of tweeks to an editor would fix the
>>>> problem.
>>>> <
>>>> b) in C, we often have variable (a variable of local scope), b)
>>>> VARIABLE (a macro
>>>> having to do with things of type variable, and c) Variable (a type
>>>> used to create
>>>> instances of variable). So, we are quite use to name overloading.
>>>> However, only
>>>> the Obfuscated_C-programmer uses spellings such as vARIABLE,
>>>> VaRiAbLe,...
>> <
>>> YouDontUseCamelForm?
>> <
>> When I run out of other ways of expressing something, yes.
>> <
>> 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.......
>
> But not for the 8% of men and 0.1% of women that have some
> form of colour blindness.
>
> And then there's the strange optical illusions where the
> apparent colour depends on the surrounding colour.
>

colorForth, anyone?

On Thursday, 30 December 2021 at 12:06:27 UTC+1, David Brown wrote:

> colorForth, anyone?

David Brown is a fucking idiot and spammer: please ignore him.

*Spammer Alert*

Julio

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Wednesday, December 29, 2021 at 7:49:16 PM UTC-6, Ivan Godard wrote:

>> YouDontUseCamelForm?
><
> When I run out of other ways of expressing something, yes.
><
> 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.)

Using anything but plain ASCII for a programming language has
its dangers - comments can become malicious statements all of
a sudden...

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?

Stefan

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
> 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?

No, much worse.

I am referring to (TRIGGER WARNING) https://www.emojicode.org/ .