On 2021-10-23 17:44, Stefan Monnier wrote:
>> The upcoming new Ada standard, Ada 2022, adds standard libraries for
>> big-number arithmetic, both integer and real.
>
> Nitpick: you probably mean rationals or floating point, since reals are
> pretty hard to implement in a computer.

Yes, mathematically speaking; only the rational subset of the real
numbers can be used. I was using terminology from the Ada standard, sorry.

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 2021-10-23 16:36, Tim Rentsch wrote:
[...]
>> My impression is that signed integer operations (for the usual
>> arithmetic operators, and perhaps a few other) in Ada are defined
>> to produce exact results, of whatever size, and only when an
>> expression is assigned or used as an argument is the range
>> checked against the intended target. Is that right?
>
> No, if by "size" you mean the number of bits needed to represent the
> number. Run-time integer operations in Ada work as in any traditional
> compiled language: they use the HW operations, which usually generate
> n-bit results from n-bit operands, with overflow possible.

Okay, thank you.

Quadibloc <jsavard@ecn.ab.ca> writes:
>That isn't a solution. If the problem is to satisfy both sides,
>killing the branch of the language that satisfies one of them
>constitutes failure; one side is not satisfied.
>
>However, reality is more complex than that. The reality is
>that C99 and gcc are viewed by the dissatisfied side as
>just that "solution" as having happened already...

Actually, it seems to me that C++ is the solution for the nasal demon
worshippers. And once C compilers started to be written by C++
programmers, they applied the C++ view of how to deal with undefined
behaviour also to C.

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

According to Stefan Monnier <monnier@iro.umontreal.ca>:
>> It sounds like it is trying to map whole files rather than
>> managing moving windows onto mapped files or buffered IO.
>
>By and large Emacs only ever does "read a whole file into memory" and
>"write a whole file to disk". No `map`ping of any sort.

It doesn't do an mmap() with copy-on-write? That seems like an obvious optimization.

Same size issue, though, either it fits in the address space or it doesn't.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Ivan Godard <ivan@millcomputing.com> writes:

> On 10/19/2021 11:08 AM, Stephen Fuld wrote:
>
>> On 10/19/2021 9:20 AM, EricP wrote:
>>
>>> Ivan Godard wrote:
>>>
>>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>
>>>>> The only mechanism I can think of that can handle that kind of
>>>>> flexibility smoothly would be based on multiple language data
>>>>> types, and an ISA with separate instructions for each operation
>>>>> on each type.
>>>>
>>>> As for example:
>>>> enumWithTraits(intNumEnums, overflowCode,
>>>> excepting,
>>>> modulo,
>>>> saturating,
>>>> widening
>>>> );
>>>> available in every kind of operation that can overflow?
>>>
>>> I don't know what you mean.
>>>
>>> I mean that only the programmer knows their intent and since
>>> that intent changes and they need a way to express it.
>>> A one-size-fits-all approach isn't flexible enough.
>>>
>>> The compiler already handles overloading operators for different
>>> integral and float data types and sizes. This expands on that
>>> mechanism.
>>
>> I think the disconnect is the following. Ivan showed what
>> capabilities are/will be in the Mill hardware ISA. You talked
>> about what the programmer intends. The disconnect is that the
>> current C language doesn't provide a mechanism to "connect" the
>> two, at least in many cases. Several proposals have been made here
>> (pragmas, compile options, etc.), but none are apparently part of
>> the standard.
>>
>> I should note that at least a good part of these are specifiable in,
>> for example Ada. The very extensive type system in Ada is, IMO one
>> of its biggest strengths.
>
> Well put. Besides Ada, also consider C++ in which you can define
> classes saturatingShort, saturatingInt, etc and overload the
> operators to produce an intrinsic which in turn invokes a native
> instruction (Mill) or sequence (whatever). Writing the library is
> annoying, but using it is convenient and natural.

Let me offer a different perspective here. User-defined types
work well for situations where there is only one operand of an
"unusual" type, or where several operands are homogeneous in a
particular "unusual" type. A key aspect of the problem here is
not when all the operands have the same type but when they may
have different types. In many cases we want the choice of
trapping or wrapping or saturating to go with the operation, not
with the types of operands used. What should the result be in a
case where a trapping short and a wrapping int and a saturating
long are all added together? The combination of width on one
axis and choice of behavior rule on a different axis means a
non-linear number of types to define. To branch off a bit, now
add the aspect of units for different quantities. What should
happen if a saturating long inch is added to a saturating long
centimeter? User-defined types don't scale well when there are
multiple independent axes. Also there is the question of
understanding what the consequences are when different types are
combined. My experience doing this kind of thing in C++ leads me
to think figuring out the interactions along different axes would
be challenging, even just as a client of an existing set of
classes.

Possibly amusing footnote: what sort of thing should we get if
we divide a quantity having centimeter units by a quantity having
inch units? In at least one real-world application, the output
desired needs to be given in units of centimeters per foot.

On Saturday, October 23, 2021 at 3:44:42 PM UTC-5, Tim Rentsch wrote:
> Ivan Godard <iv...@millcomputing.com> writes:

> > Well put. Besides Ada, also consider C++ in which you can define
> > classes saturatingShort, saturatingInt, etc and overload the
> > operators to produce an intrinsic which in turn invokes a native
> > instruction (Mill) or sequence (whatever). Writing the library is
> > annoying, but using it is convenient and natural.
>
> Let me offer a different perspective here. User-defined types
> work well for situations where there is only one operand of an
> "unusual" type, or where several operands are homogeneous in a
> particular "unusual" type. A key aspect of the problem here is
> not when all the operands have the same type but when they may
> have different types. In many cases we want the choice of
> trapping or wrapping or saturating to go with the operation, not
> with the types of operands used. What should the result be in a
> case where a trapping short and a wrapping int and a saturating
> long are all added together?
<
If one adds an int and an int and assigns it to a long should the
int-add overflow or should the assignment to the long override
such overflow !! This is why it is the assignment container that
needs consideration, not the operands themselves. ADA got this
right.
<
< The combination of width on one
> axis and choice of behavior rule on a different axis means a
> non-linear number of types to define.
<
Done operation by operation one ends up with the Cartesian
product of {signedness}×{widths}×{modes}. Whereas the vast
majority of the time you actually want 2 instructions, not 64 !
<
Note: signedness can be 3 {signed, unsigned, and signless}
Also note: modes seems to be ever growing.....
<
< To branch off a bit, now
> add the aspect of units for different quantities. What should
> happen if a saturating long inch is added to a saturating long
> centimeter?
<
Why are measurements in integral type and not in fixed or floating
point type ?
<
< User-defined types don't scale well when there are
> multiple independent axes. Also there is the question of
> understanding what the consequences are when different types are
> combined.
<
This is generally accompanied by a large surprise factor.
<
< My experience doing this kind of thing in C++ leads me
> to think figuring out the interactions along different axes would
> be challenging, even just as a client of an existing set of
> classes.
<
Nancy Reagan: Just say no.
>
> Possibly amusing footnote: what sort of thing should we get if
> we divide a quantity having centimeter units by a quantity having
> inch units? In at least one real-world application, the output
> desired needs to be given in units of centimeters per foot.
<
The physicist in me just rolled over........................

[ Yeah, I know most of the rest is offtopic as well. ]

John Levine [2021-10-23 19:56:20] wrote:
> According to Stefan Monnier <monnier@iro.umontreal.ca>:
>>> It sounds like it is trying to map whole files rather than
>>> managing moving windows onto mapped files or buffered IO.
>>By and large Emacs only ever does "read a whole file into memory" and
>>"write a whole file to disk". No `map`ping of any sort.
> It doesn't do an mmap() with copy-on-write? That seems like an obvious optimization.

Making it applicable in a common case would require a lot of changes,
because in most cases we want to edit a file made of chars rather than
made of bytes, so there's a coding-system conversion taking place when
reading and when writing.

The time to read/write the actual bytes is usually drowned by other
things anyway.

> Same size issue, though, either it fits in the address space or it doesn't.

Yup.

Stefan

On 10/23/2021 1:44 PM, Tim Rentsch wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>
>> On 10/19/2021 11:08 AM, Stephen Fuld wrote:
>>
>>> On 10/19/2021 9:20 AM, EricP wrote:
>>>
>>>> Ivan Godard wrote:
>>>>
>>>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>>
>>>>>> The only mechanism I can think of that can handle that kind of
>>>>>> flexibility smoothly would be based on multiple language data
>>>>>> types, and an ISA with separate instructions for each operation
>>>>>> on each type.
>>>>>
>>>>> As for example:
>>>>> enumWithTraits(intNumEnums, overflowCode,
>>>>> excepting,
>>>>> modulo,
>>>>> saturating,
>>>>> widening
>>>>> );
>>>>> available in every kind of operation that can overflow?
>>>>
>>>> I don't know what you mean.
>>>>
>>>> I mean that only the programmer knows their intent and since
>>>> that intent changes and they need a way to express it.
>>>> A one-size-fits-all approach isn't flexible enough.
>>>>
>>>> The compiler already handles overloading operators for different
>>>> integral and float data types and sizes. This expands on that
>>>> mechanism.
>>>
>>> I think the disconnect is the following. Ivan showed what
>>> capabilities are/will be in the Mill hardware ISA. You talked
>>> about what the programmer intends. The disconnect is that the
>>> current C language doesn't provide a mechanism to "connect" the
>>> two, at least in many cases. Several proposals have been made here
>>> (pragmas, compile options, etc.), but none are apparently part of
>>> the standard.
>>>
>>> I should note that at least a good part of these are specifiable in,
>>> for example Ada. The very extensive type system in Ada is, IMO one
>>> of its biggest strengths.
>>
>> Well put. Besides Ada, also consider C++ in which you can define
>> classes saturatingShort, saturatingInt, etc and overload the
>> operators to produce an intrinsic which in turn invokes a native
>> instruction (Mill) or sequence (whatever). Writing the library is
>> annoying, but using it is convenient and natural.
>
> Let me offer a different perspective here. User-defined types
> work well for situations where there is only one operand of an
> "unusual" type, or where several operands are homogeneous in a
> particular "unusual" type. A key aspect of the problem here is
> not when all the operands have the same type but when they may
> have different types. In many cases we want the choice of
> trapping or wrapping or saturating to go with the operation, not
> with the types of operands used. What should the result be in a
> case where a trapping short and a wrapping int and a saturating
> long are all added together? The combination of width on one
> axis and choice of behavior rule on a different axis means a
> non-linear number of types to define. To branch off a bit, now
> add the aspect of units for different quantities. What should
> happen if a saturating long inch is added to a saturating long
> centimeter? User-defined types don't scale well when there are
> multiple independent axes. Also there is the question of
> understanding what the consequences are when different types are
> combined. My experience doing this kind of thing in C++ leads me
> to think figuring out the interactions along different axes would
> be challenging, even just as a client of an existing set of
> classes.
>
> Possibly amusing footnote: what sort of thing should we get if
> we divide a quantity having centimeter units by a quantity having
> inch units? In at least one real-world application, the output
> desired needs to be given in units of centimeters per foot.
>

The lit history is full of efforts to put units into the type systems.
They sure look plausible but don't work. Think of a NR sqrt routine.

As for your sum of sat+wrap+trunc, there's a simple solution: don't
pollute the types of the operations with the types of the arguments. Let
+ take arguments and produce results from Z, and then check when that is
assigned or passed to see if it conforms to the well defined and
unambiguous type of the destination. The rest is petty optimization.

Yes, Ada got it right, thank you. Yes, it was me, though unfortunately I
had to invent subtypes to get it past Ironman.

BGB <cr88192@gmail.com> writes:

> On 10/12/2021 10:31 AM, Tim Rentsch wrote:
>
>> George Neuner <gneuner2@comcast.net> writes:
>>
>> [...]
>>
>>> GCs for uncooperative languages (like C) do check potential
>>> pointers - i.e. properly aligned values - against the heap limits
>>> as a first step. But what the GC really needs to know is if a
>>> pointer refers to an actual allocated block. Determining /that/
>>> is a lot harder because the value must be range checked against
>>> every allocation, not just against the heap limits.
>>
>> It does take more development effort. It need not incur a
>> significantly larger run-time cost.
>
> Average-case cost for many GC designs is fairly low.
>
> One downside is the creation of delays or stalls.
>
> For example, if one has a mark/sweep collector, there is a visible
> (and potentially fairly obvious) stall whenever the GC runs. In a
> soft-real-time application (like a 3D game), it can get really
> annoying to have a game which periodically stalls.
>
> In harder real-time uses, these sorts of delays are unacceptable.
> [...]

Certainly it is true that many GC schemes can have large delays
at times, and that for some applications such delays are absolutely
unacceptable.

However, it is also true that some GC schemes have large delays
only very rarely (with much shorter delays being more common),
and also that some applications don't mind long delays at all as
long as the amortized cost is fairly low.

More generally, the kinds of arguments I see against using GC
tend to be pointing out that there are some situations where
using GC doesn't satisfy the requirements. And that's true:
some applications are so demanding and resource hungry that
they need a lot of care and specialized machinery to get done
whatever it is they need to get done, and trying to use GC
can get in the way of that.

Unfortunately the implicit argument that follows is that because
GC isn't good everywhere that it must not be good anywhere.
Obviously that's a bogus argument (which explains why it is
almost always implicit).

In truth GC works just fine for many or most application areas,
and the ratio is only getting bigger with time. I have used
large, long running, interactive environments that rely on GC
and whose performance is just fine over all time scales that
are directly perceptible to humans.

For developers, probably the biggest attraction of using GC (or
some other completely automatic memory management system) is
productivity gains for program development. Fewer lines of code
are needed, and a given amount of code gets written faster, when
the programming environment takes care of managing memory.
Provided the application area doesn't completely rule it out,
having GC available usually means a big win in program
development cost.

On Saturday, October 23, 2021 at 6:09:53 PM UTC-5, Tim Rentsch wrote:
> BGB <cr8...@gmail.com> writes:
>
> > On 10/12/2021 10:31 AM, Tim Rentsch wrote:
> >
> >> George Neuner <gneu...@comcast.net> writes:
> >>
> >> [...]
> >>
> >>> GCs for uncooperative languages (like C) do check potential
> >>> pointers - i.e. properly aligned values - against the heap limits
> >>> as a first step. But what the GC really needs to know is if a
> >>> pointer refers to an actual allocated block. Determining /that/
> >>> is a lot harder because the value must be range checked against
> >>> every allocation, not just against the heap limits.
> >>
> >> It does take more development effort. It need not incur a
> >> significantly larger run-time cost.
> >
> > Average-case cost for many GC designs is fairly low.
> >
> > One downside is the creation of delays or stalls.
> >
> > For example, if one has a mark/sweep collector, there is a visible
> > (and potentially fairly obvious) stall whenever the GC runs. In a
> > soft-real-time application (like a 3D game), it can get really
> > annoying to have a game which periodically stalls.
> >
> > In harder real-time uses, these sorts of delays are unacceptable.
> > [...]
>
> Certainly it is true that many GC schemes can have large delays
> at times, and that for some applications such delays are absolutely
> unacceptable.
>
> However, it is also true that some GC schemes have large delays
> only very rarely (with much shorter delays being more common),
> and also that some applications don't mind long delays at all as
> long as the amortized cost is fairly low.
>
> More generally, the kinds of arguments I see against using GC
> tend to be pointing out that there are some situations where
> using GC doesn't satisfy the requirements. And that's true:
> some applications are so demanding and resource hungry that
> they need a lot of care and specialized machinery to get done
> whatever it is they need to get done, and trying to use GC
> can get in the way of that.
>
> Unfortunately the implicit argument that follows is that because
> GC isn't good everywhere that it must not be good anywhere.
> Obviously that's a bogus argument (which explains why it is
> almost always implicit).
>
> In truth GC works just fine for many or most application areas,
<
The other truth is that most applications do not need any GC whatsoever.
{Where most means over 50%}
<
> and the ratio is only getting bigger with time. I have used
> large, long running, interactive environments that rely on GC
> and whose performance is just fine over all time scales that
> are directly perceptible to humans.
<
GC works perfectly when the application does not even need it.
>
> For developers, probably the biggest attraction of using GC (or
> some other completely automatic memory management system) is
> productivity gains for program development. Fewer lines of code
> are needed, and a given amount of code gets written faster, when
> the programming environment takes care of managing memory.
<
A "bar" friend was having problems with his mechanical free-ing of
data in business application; it was taking too much time {write,
debug, allocate, free}. I convinced him to fork off the sub-task and
allow the OS to clean up the memory without free-ing. Not only did
this work first time, and get rid of memory leaks, but it ran 30% faster
to boot.
<
> Provided the application area doesn't completely rule it out,
> having GC available usually means a big win in program
> development cost.

On Thu, 21 Oct 2021 03:06:56 -0500, BGB <cr88192@gmail.com> wrote:

>On 10/21/2021 12:16 AM, George Neuner wrote:
>
>> Same with schools - the idea to give every child a laptop or pad is
>> just wasteful. For roughly 2/3 what they are currently spending on
>> portables, school systems could put thin terminals at every desk and
>> give every student a small desk computer to use at home.
>>
>
>Do any schools actually do this?...
>
>Usual thing on the news is schools having issues with inability to pay
>teachers due to budget shortfalls and similar, inability to afford
>textbooks, ...

Unfortunately, at least in the U.S., there are quite a few school
systems that simply hand out devices, and many more that demand the
student purchase the device in order to attend. Often purchase
requirements are partially subsidized (with taxpayer money), but not
always.

Then it is expected that the student has Internet access from home.
For low income students, that isn't necessarily true, and then there
is a division between the haves who can work at home, and have nots
who can use their devices only at school, or in a library, or have to
find a place with free WiFi.

So then come the municipal scale projects to supply WiFi everywhere,
and government subsidies (in addition to their own fee structures for
ordinary customers) for ISPs to provide service to low income people
at little or no cost.

And, of course, since children can't be trusted with IT security,
these devices typically are not "general purpose" but rather are so
locked down that they barely qualify as "computers" ... it may look
like a Chromebook, but it's just an expensive Speak-n-Spell.

The primary beneficiaries of these programs are companies like Apple
and Google. It's debatable whether having a computer really will help
the average primary school student learn, and whether the benefit of
computers over books and pencils justifies the cost to the school
system, and to the taxpayers that support it.

How did any of us learn? I didn't even have a 4 function calculator
until I was in high school.

YMMV,
George

On 2021-10-23 23:44, Tim Rentsch wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>
>> On 10/19/2021 11:08 AM, Stephen Fuld wrote:
>>
>>> On 10/19/2021 9:20 AM, EricP wrote:
>>>
>>>> Ivan Godard wrote:
>>>>
>>>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>>
>>>>>> The only mechanism I can think of that can handle that kind of
>>>>>> flexibility smoothly would be based on multiple language data
>>>>>> types, and an ISA with separate instructions for each operation
>>>>>> on each type.
>>>>>
>>>>> As for example:
>>>>> enumWithTraits(intNumEnums, overflowCode,
>>>>> excepting,
>>>>> modulo,
>>>>> saturating,
>>>>> widening
>>>>> );
>>>>> available in every kind of operation that can overflow?
>>>>
>>>> I don't know what you mean.
>>>>
>>>> I mean that only the programmer knows their intent and since
>>>> that intent changes and they need a way to express it.
>>>> A one-size-fits-all approach isn't flexible enough.
>>>>
>>>> The compiler already handles overloading operators for different
>>>> integral and float data types and sizes. This expands on that
>>>> mechanism.
>>>
>>> I think the disconnect is the following. Ivan showed what
>>> capabilities are/will be in the Mill hardware ISA. You talked
>>> about what the programmer intends. The disconnect is that the
>>> current C language doesn't provide a mechanism to "connect" the
>>> two, at least in many cases. Several proposals have been made here
>>> (pragmas, compile options, etc.), but none are apparently part of
>>> the standard.
>>>
>>> I should note that at least a good part of these are specifiable in,
>>> for example Ada. The very extensive type system in Ada is, IMO one
>>> of its biggest strengths.
>>
>> Well put. Besides Ada, also consider C++ in which you can define
>> classes saturatingShort, saturatingInt, etc and overload the
>> operators to produce an intrinsic which in turn invokes a native
>> instruction (Mill) or sequence (whatever). Writing the library is
>> annoying, but using it is convenient and natural.
>
> Let me offer a different perspective here. User-defined types
> work well for situations where there is only one operand of an
> "unusual" type, or where several operands are homogeneous in a
> particular "unusual" type. A key aspect of the problem here is
> not when all the operands have the same type but when they may
> have different types.

In the Ada case, the idea (= spirit) is that you cannot combine
different types in that way -- for example, you cannot by default add a
signed integer to a modular integer. The programmer has to convert one
or both operands explicitly to compatible types, or (if this combination
of types is common) define an overriding operation for precisely this
combination of operand types (and this expected result type, which also
guides Ada overload resolution). I think C++ works in a similar way,
although there one can define implicit conversions too (which IMO would
be riskier than explicit ones).

> In many cases we want the choice of trapping or wrapping or
> saturating to go with the operation, not with the types of operands
> used.

In the Ada case, that is obtained by applying explicit type conversions
locally to the operands and/or result of the operation. I suppose the
same applies to C++ (except that result type is not a factor in overload
resolution in C++).

> What should the result be in a case where a trapping short and a
> wrapping int and a saturating long are all added together? The
> combination of width on one axis and choice of behavior rule on a
> different axis means a non-linear number of types to define.

In principle yes, but I doubt it would be a major practical problem in
any given program. Generics/templates can help here, too.

> To branch off a bit, now add the aspect of units for different
> quantities. What should happen if a saturating long inch is added to
> a saturating long centimeter?

I don't think there is a general programming-language solution for
managing different scales of measurement, but in some particular cases
user-defined types can help to avoid accidental confusion between units.

Ivan Godard <ivan@millcomputing.com> schrieb:

> The lit history is full of efforts to put units into the type systems.
> They sure look plausible but don't work. Think of a NR sqrt routine.

MathCad has got this right. It is not a compiled language,
but it certainly works. I use it a lot in my day job for simple
engineering calculations: You see the formulas, you immediately
see the output, you do input in units (like kg/h), you can convert
the output to units you want.

And, of course, it complains if you try to add or subtract
dimensions that do not match.

(Notice I said "dimensions" in the last sentence - adding an inch
to a meter is fine, because both get converted automatically,
but adding a meter to a second is an error. Nomenclature:
Length is a dimension, meter or inch are units, of length
in this case).

It even handles square roots of units and dimensions, which
are sometimes used, as characteristics of distillations colums,
for example.

It handles units and dimensions as floating point numbers.
For dimensions, using rational numbers would probably be better.

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:

> Possibly amusing footnote: what sort of thing should we get if
> we divide a quantity having centimeter units by a quantity having
> inch units?

Convert both to SI or some other convenient base system, then
do the calculation. The conversion should be done on
input/output.

> In at least one real-world application, the output
> desired needs to be given in units of centimeters per foot.

On output, multiply with the corresponding conversion factor.

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Friday, October 22, 2021 at 9:59:49 AM UTC-6, Thomas Koenig wrote:
>
>> Maybe there is a case to be made for using -INT_MAX -1 as an signed
>> integer NaN.
>
>> I would be surprised if people had not tried this before.
>
> I wouldn't be, since they could have tried something equivalent
> instead back when people were trying such bold options.
>
> That is: while what you suggest would add extra complexity to
> an ALU intended for operating on quantities represented in
> two's complement notation, alternative integer representations
> already have the needed complications present, thus allowing
> making... *minus zero*... into a signed integer NaN to be
> done "for free".
>
> So I think _that_ might have been tried, for either one's complement
> or sign-magnitude machines... eliminating the need to try the
> equivalent you suggest in two's complement.

Two's complement is being standardized at least for C++ now, but
you are, of course, right about the additional complications.

Ivan Godard <ivan@millcomputing.com> writes:
>The lit history is full of efforts to put units into the type systems.
>They sure look plausible but don't work. Think of a NR sqrt routine.

So maybe you cannot implement NR sqrt in such a type system, or need
to use an escape hatch. History is full of successful languages with
type systems that do not allow to implement some established algorithm
or data structure.

As an example, Java has references to objects, but not to variables.
This means that implementing tree updates is more complicated in Java
than in C (where you can take the address of a structure field and
pass it around) or Pascal (where the lack of first-class references
can be worked around with call-by-reference parameters).

Has this impeded the success of Java? No. Java provides a library
for dealing with container types (including trees), and most Java
programmers don't have to program tree updates themselves (outside of
programming courses).

Concerning units, they have not become a mainstream feature yet, maybe
because programming language designers deal more with abstract
mathematical objects than with physical ones.

But given the march of the static typechecking community towards more
and more elaborate type systems, it would not surprise me if one day a
language with units became mainstream, just like Java established
garbage collection as a mainstream feature.

BTW, what do you mean with "lit" in "lit history"?

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

On 10/23/2021 11:55 PM, George Neuner wrote:
> On Thu, 21 Oct 2021 03:06:56 -0500, BGB <cr88192@gmail.com> wrote:
>
>> On 10/21/2021 12:16 AM, George Neuner wrote:
>>
>>> Same with schools - the idea to give every child a laptop or pad is
>>> just wasteful. For roughly 2/3 what they are currently spending on
>>> portables, school systems could put thin terminals at every desk and
>>> give every student a small desk computer to use at home.
>>>
>>
>> Do any schools actually do this?...
>>
>> Usual thing on the news is schools having issues with inability to pay
>> teachers due to budget shortfalls and similar, inability to afford
>> textbooks, ...
>
> Unfortunately, at least in the U.S., there are quite a few school
> systems that simply hand out devices, and many more that demand the
> student purchase the device in order to attend. Often purchase
> requirements are partially subsidized (with taxpayer money), but not
> always.
>
> Then it is expected that the student has Internet access from home.
> For low income students, that isn't necessarily true, and then there
> is a division between the haves who can work at home, and have nots
> who can use their devices only at school, or in a library, or have to
> find a place with free WiFi.
>
> So then come the municipal scale projects to supply WiFi everywhere,
> and government subsidies (in addition to their own fee structures for
> ordinary customers) for ISPs to provide service to low income people
> at little or no cost.
>
> And, of course, since children can't be trusted with IT security,
> these devices typically are not "general purpose" but rather are so
> locked down that they barely qualify as "computers" ... it may look
> like a Chromebook, but it's just an expensive Speak-n-Spell.
>
> The primary beneficiaries of these programs are companies like Apple
> and Google. It's debatable whether having a computer really will help
> the average primary school student learn, and whether the benefit of
> computers over books and pencils justifies the cost to the school
> system, and to the taxpayers that support it.
>

Yeah...

Back when I was school-age, it was still mostly in the era of textbooks
and assignments being done on paper print-outs.

Computers were often around, typically as a row of desktop PCs along a
wall somewhere, but not typically used in normal class activities.

For me, this was true in elementary school as well, just back then they
were mostly running MS-DOS or sometimes Windows (Windows 3.11 and
Windows 95 were common). At this time, teachers ended up mostly just
letting me poke around on computers and write stuff in QBasic and
similar (from what I remember, unlike most of the other students, I was
mostly just sorta allowed to "do whatever" during these years).

I have a vague memory of at one point going off somewhere else where
they had me do some tests and similar. Don't remember, I think I talked
to some people, also have a vague (strange) memory of being asked to
assemble some 3D puzzles while in a room by myself behind a 1-way mirror.

After this, they just let me do whatever I felt like doing (which,
granted, was mostly just poking at QBasic on the computer...). Actually,
I think I also remember now they had sent me a few times (and I think
another person, who was female) to another smaller room with an adult
guy who I remember mostly talking about programming stuff (namely
Borland Pascal and similar; but I had more of a preference for C than
Pascal). I think the female was around for some of the other "do stuff
with computers" activities (but, I don't remember much else about her,
other than her personality being a little more harsh/abrasive than many
of the other kids; there were generally no other students present other
than us).

Also, in this room, there were some Macs, and a few of these computers
had magneto-optical drives (of the 130mm variety), or at least the ones
that had Turbo C and Pascal had the magneto-optical drives.

On my own time, I was mostly messing with Turbo C and TASM and similar
instead, and trying to make sense of the Wolf3D and Doom source.

My early years seem kinda weird when I think back on them.

Not that long after, my family moved to a different state, and I now
remember parents telling me not to tell anyone about any of this.

Typically (by HS):
Whiteboards were most commonly used;
Overhead projectors / transparencies were also common;
Sometimes also a TV on a cart with a VCR or DVD player;
Projectors connected up to a computer;
...

This was back in the era when laptops were a rare and expensive novelty.
Some people also had cellphones (of the flip-phone variety), but they
were the minority (most students did not have cellphones AFAIK).

Developments shortly after high-school were mostly:
Cheaper laptops;
The rise of smartphones;
CRT monitors getting steadily replaced with LCD monitors;
...

I had noted that depictions of school settings on TV usually showed
teachers using chalkboards (rather than whiteboards), with a general
absence of any computers.

Well, also differences:
It was much more densely packed vs TV depictions;
Lots more people in each class;
Lots more people in the halls;
...
It had guards walking the halls during class times:
They would generally go around with dogs on leashes, ...
One would need to show the guard their hall pass to go anywhere;
Also, they had metal gates they would close during class time;
...

So, some guards would walk dogs through the halls during class, and
others did not have dogs.

In the time between classes, there was also not generally any time to
socialize, generally ones' goal was more to get from one class to the
next before the bell rang (or, more like, certain sounds played over the
intercom). One couldn't take too long, or else they would be marked as
late. One generally had about 5 minutes to get from one class to the next.

Not actually sure what it is typically like now.

>
> How did any of us learn? I didn't even have a 4 function calculator
> until I was in high school.
>

I was in the era of the TI-83+ line...

It was also an era where some people had cable modems or DSL, and other
people were still using dial-up.

High-school for me was also in the transition period between Win98 and
Windows XP, but I was an oddball person running Windows 2000 as their
main OS.

Not long after high-school, I ended up switching over to XP-X64
(generally ran this until later switching over to Windows 7).

On 23/10/2021 15:56, Quadibloc wrote:
> On Friday, October 22, 2021 at 4:22:53 AM UTC-6, Ivan Godard wrote:
>
>> There is also the solution invented by Mssr. Guillotin.
>
> That isn't a solution. If the problem is to satisfy both sides,
> killing the branch of the language that satisfies one of them
> constitutes failure; one side is not satisfied.
>
> However, reality is more complex than that. The reality is
> that C99 and gcc are viewed by the dissatisfied side as
> just that "solution" as having happened already...
>
> and nothing is preventing them from taking the last version
> of gcc they liked, and maintaining it themselves. They could
> even issue a language standard for a language which they
> could call CC (for "Classic C") or something.

Actually, the gcc folks already did that for the "other side". They
added the "-fwrapv" flag, and the "-fno-strict-aliasing" flag, and the
"-fno-delete-null-pointer-checks" flag, and probably others. They added
these as aids to people who said "I know my code has UB, but this /used/
to work in a particular way - please help me avoid fixing the bugs in my
old code because that would be a huge task". That way everyone could,
in theory, be happy.

Of course, the people who said "the gcc developers are stupid evil
buggers who enjoy breaking other people's code and care only about the
speed of benchmarks" were not happy. They got gcc for free (without
having to maintain it), and they too could use the "-fwrapv" and
"-fno-strict-aliasing". Not only would their old broken code still
work, but they could now be sure that it would continue to work in the
future, albeit as non-portable code.

>
> My first thought was KRC, but that runs the risk of real
> individuals objecting to being associated with a
> retrogade movement.
>
> John Savard
>

On 23/10/2021 19:24, Anton Ertl wrote:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>> That isn't a solution. If the problem is to satisfy both sides,
>> killing the branch of the language that satisfies one of them
>> constitutes failure; one side is not satisfied.
>>
>> However, reality is more complex than that. The reality is
>> that C99 and gcc are viewed by the dissatisfied side as
>> just that "solution" as having happened already...
>
> Actually, it seems to me that C++ is the solution for the nasal demon
> worshippers. And once C compilers started to be written by C++
> programmers, they applied the C++ view of how to deal with undefined
> behaviour also to C.
>

C++ has some additional undefined behaviour to watch out for - for
example, type-punning unions are UB in C++ while being fully defined in C.

Most new code for gcc is written in C++, and has been for most of a
decade. As far as I know, clang/llvm has always been C++. But since I
have no idea what a "C++ view of UB" might be or how it might differ
from a "C view of UB", I can't tell if the change of implementation
language of gcc has had any effect here. I can't say I have noticed any
change.

But I can agree that C++ is a possible solution here - it is a solution
for people who want additional semantics for their coding when they are
not supported by the language itself. Neither C nor C++ give you any
defined behaviour for overflow of signed integer arithmetic - but you
could happily make a C++ class (or template library) that supports it.
Then use "wrapping<int>" instead of "int", and you have guaranteed
behaviour just as you want, portable to any C++ compiler and with the
same effect regardless of flags. Similarly, you can have
"aliasing_pointer<int>" instead of "int *".

(I'd be happy to see something along those lines added to the C++
standard library. It is, IME, rare to need such semantics - but it is
not unheard-of, and it would be nice to have them conveniently available
for those occasions.)

Anton Ertl wrote:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>> That isn't a solution. If the problem is to satisfy both sides,
>> killing the branch of the language that satisfies one of them
>> constitutes failure; one side is not satisfied.
>>
>> However, reality is more complex than that. The reality is
>> that C99 and gcc are viewed by the dissatisfied side as
>> just that "solution" as having happened already...
>
> Actually, it seems to me that C++ is the solution for the nasal demon
> worshippers. And once C compilers started to be written by C++
> programmers, they applied the C++ view of how to deal with undefined
> behaviour also to C.

So why aren't more people switching to Rust?

I took a look at RustCrypto, specifically how they handle bigint
operations, and I was extremely impressed: You get the exact same direct
access to both 64 and 128-bit signed and unsigned ints, and the
naive/natural way to express "(hi, lo) = a + ( b*c) + carry" works
as-is, and generates the same optimal code as you can get from clang
when compiling C(++).

I.e. the asm code (according to Godbolt) for that expression was

mov rax,b
mul c
add rax,a
adc rdx,0
add rax,carry
adc rdx,0

with all the variables in registers. This is less than 10 cycles/20
bytes and was applied inline in the bigint library. Since it was inlined
the 8

In Rust aliasing is even less of a problem than in Fortran afaik. :-)

Terje

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

kegs@provalid.com (Kent Dickey) writes:

> In article <87fstdumxd.fsf@hotmail.com>, <clamky@hotmail.com> wrote:
>
>> Might strike a cord with Anton and/or Mich
>>
>> https://www.yodaiken.com/2021/10/06/plos-2021-paper-how-iso-c-
>> became-unusable-for-operating-system-development/
>
> Let me summarize some of the arguments in a different way:
>
> 1) The ISO C standard leaves a large area of Undefined Behavior (UB).
> A C compiler that ignores UB in code it compiles is a valid
> compiler. But a C program containing any UB is always broken
> even if it seems to be working today. C compilers have grabbed
> the entire space--they reserve the right to release a new
> compiler that treats any UB as an optimization and change C code
> that was working to non-working, and provide no mechanism to
> warn that they are doing so, nor to provide the old behavior.
> The problem is new UB optimizations (detecting UB that compilers
> don't currently detect) which lead to new optimizations which
> will break more programs. It's possible every non-trivial C
> program accidentally touches some UB behavior. If everything
> is illegal, it's the laws which are wrong.
>
> 2) A C Standard should enable the C Standard Library to be written in
> fully conforming C (without triggering undefined behavior).
> Examples: malloc()/free(), etc. ISO C does not allow
> this due to undefined behavior inherent in some of the routines.
> This looks like a mistake in ISO C.
>
> 3) The ISO C standard is complex enough that very smart people can argue
> about basic points for weeks and not reach agreement. It's
> hard to agree on what even is UB. The ISO C Standard is 683 pages
> and costs $250USD. (Those "in the know" can get it for free).
> But any C program which accidentally uses UB behavior (despite
> -Wall, -Wextra, -fsanitize=undefined, etc. passing) is buggy and
> written by someone incompetent. It should not be necessary to
> be a C compiler writer to be able to write valid C code.

Notionally accepting that the summary accurately reflects what is
said in the paper (and thank you for writing it), a few responses.

On point (2), a standard library is and always has been a part of
a complete implementation. It's expected that code written as part
of a standard library will make use of private knowledge regarding
implementation-specific (and compiler-specific) behavior in order
to do its job. As far as "official C" is concerned, there has
never been an expectation that a standard library could be written
entirely in completely portable C.

That said, unfortunately it has become de facto accepted (and
moreso as time goes on) that compilers and standard libraries
(such as gcc and glibc) are separate components coming from
independent sources rather than part of one integrated whole.
However that perception is not the fault of the ISO C standard or
the people who write it.

On point (3), it's true that people argue (and continue to argue)
about some of the finer points of C semantics, but for the most
part these arguments concern esoterica that almost never occur
in ordinary C code. Also in some cases the "arguments" are the
result of what might be called willful misinterpretation on the
part of compiler implementors. Certainly there are some points
that need clarifying (and that should be done), but on the whole
the document is remarkably well-written for such a large and
complex subject.

On point (1), let me first consider the amount and kinds of
undefined behaviors, and second how to respond to the aggressive
optimizations that are becoming more common as time goes on.

First, the paper overstates the case for the ubiquity of different
kinds of undefined behaviors. There are, without doubt, a great
number of different kinds of undefined behaviors. But it is only
a relatively small number of particular undefined behaviors that
are causing problems with "perverse optimization". I haven't made
a systematic effort to determine actual numbers here, but I think
it's fair to say that the problematic cases boil down to a handful
or at most two, out of a list of many many more than that.

Now for the sixty four dollar question: what should be done to
address "the UB problem"? I propose a multi-pronged approach.

The first prong is undefined behavior that occurs at translation
time. These cases should be placed in a separate and more limited
category. At the very least implementations must be capable of
detecting such cases reliably and failing at compile time or link
time, and providing an option to developers to select that.

The second prong is runtime behaviors that are easily detectable,
as for example dereferencing a null pointer or shifting a negative
number. Implementations must provide options for giving such
operations well-defined semantics, including at the least ending
the program run immediately.

The third prong is signed overflow. This category is similar to
the last one but I mention it separately because I believe it
deserves more extensive treatment (although I will not now go
into what that might be).

The fourth prong is what the C standard calls effective type
rules, which have to do with aliasing, and which are present only
to allow possible optimizations. Implementations must provide a
standard way of simply disabling these undefined behaviors (like
what -fno-strict-aliasing does, but in a way that is part of the
language itself rather than being some sort of compiler add-on).

The fifth prong concerns constructs the C standard describes
implicitly rather than explicitly, which includes both behaviors
that are undefined "by reason of omission" and behaviors that are
unspecified and where the possible choices are not listed
explicitly. Implementations must provide an option that would
disallow inferences based on assumptions about how such cases
behave, even when the implementation "knows" how they will
behave (as for example cases of unspecified behavior).

The sixth prong concerns the remaining undefined behaviors, hard
cases such as dereferencing an out-of-bounds pointers. Here there
must be an option to treat such cases in much the same way as are
volatile accesses: the code must allow for the possibility of
unanticipated side effects, but the compiler cannot know or even
speculate about what these consequences might be. In effect the
code must be "compiled naively" when the option is selected. And
in particular when the option is on the compiler must never assume
that bad cases "cannot happen".

I realize that some of the above needs clarifying and also that
some of the ideas are controversial. My purpose is to start a
dialog (not necessarily one continuing in this newsgroup) and to
indicate a general direction of where I think the C standard
should be going. My thanks to everyone for your attention.

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:

[...]

> I realize that some of the above needs clarifying and also that
> some of the ideas are controversial. My purpose is to start a
> dialog (not necessarily one continuing in this newsgroup) and to
> indicate a general direction of where I think the C standard
> should be going. My thanks to everyone for your attention.

It will be extremely hard to get consensus on what you proposed
adopted into the current C standard. People who care about
the much-maligned optimization will not agree, and they include
compiler writers and maintainers.

What will not fly is the removal of such optimizatons from the
compilers middle and back ends. While I care marginally about
the speed of C code, I care very much about the speed of Fortran.
Some of the rules such as aliasing have been an undisputed part of
both FORTRAN and Fortran, and I (for one) would very much oppose
any attempt to dumb down my favorite language for the sake of C.

You (plural you, not especially you personally) could create a
document describing _exactly_ what your dialect should be, and
then you can submit patches to gcc and clang to create a switch
for such a compiler. Alternatively, you could create forks,
but that is probably not the best alternative.

Yes, this is a lot of work. It will also require some tact
and diplomacy, something that appears to be missing in
some of the arguments by the proponents of change.

In other words: People who want to change this need to put their
working hours where their mouth is.

On 10/24/2021 6:14 AM, Terje Mathisen wrote:
> Anton Ertl wrote:
>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>> That isn't a solution. If the problem is to satisfy both sides,
>>> killing the branch of the language that satisfies one of them
>>> constitutes failure; one side is not satisfied.
>>>
>>> However, reality is more complex than that. The reality is
>>> that C99 and gcc are viewed by the dissatisfied side as
>>> just that "solution" as having happened already...
>>
>> Actually, it seems to me that C++ is the solution for the nasal demon
>> worshippers.  And once C compilers started to be written by C++
>> programmers, they applied the C++ view of how to deal with undefined
>> behaviour also to C.
>
> So why aren't more people switching to Rust?

I think Rust usage is growing, but any change like that is very slow.

> I took a look at RustCrypto, specifically how they handle bigint
> operations, and I was extremely impressed: You get the exact same direct
> access to both 64 and 128-bit signed and unsigned ints, and the
> naive/natural way to express "(hi, lo) = a + ( b*c) + carry" works
> as-is, and generates the same optimal code as you can get from clang
> when compiling C(++).

Good to know. So . . . are you switching to Rust for general use? :-)

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

On 10/24/2021 1:06 AM, Anton Ertl wrote:
> Ivan Godard <ivan@millcomputing.com> writes:
>> The lit history is full of efforts to put units into the type systems.
>> They sure look plausible but don't work. Think of a NR sqrt routine.
>
> So maybe you cannot implement NR sqrt in such a type system, or need
> to use an escape hatch. History is full of successful languages with
> type systems that do not allow to implement some established algorithm
> or data structure.
>
> As an example, Java has references to objects, but not to variables.
> This means that implementing tree updates is more complicated in Java
> than in C (where you can take the address of a structure field and
> pass it around) or Pascal (where the lack of first-class references
> can be worked around with call-by-reference parameters).
>
> Has this impeded the success of Java? No. Java provides a library
> for dealing with container types (including trees), and most Java
> programmers don't have to program tree updates themselves (outside of
> programming courses).
>
> Concerning units, they have not become a mainstream feature yet, maybe
> because programming language designers deal more with abstract
> mathematical objects than with physical ones.
>
> But given the march of the static typechecking community towards more
> and more elaborate type systems, it would not surprise me if one day a
> language with units became mainstream, just like Java established
> garbage collection as a mainstream feature.
>
> BTW, what do you mean with "lit" in "lit history"?

"literature", i.e. the published papers etc. in the field.
>
> - anton
>

On 10/24/2021 2:23 AM, BGB wrote:
> On 10/23/2021 11:55 PM, George Neuner wrote:
>> On Thu, 21 Oct 2021 03:06:56 -0500, BGB <cr88192@gmail.com> wrote:
>>
>>> On 10/21/2021 12:16 AM, George Neuner wrote:
>>>
>>>> Same with schools - the idea to give every child a laptop or pad is
>>>> just wasteful. For roughly 2/3 what they are currently spending on
>>>> portables, school systems could put thin terminals at every desk and
>>>> give every student a small desk computer to use at home.
>>>>
>>>
>>> Do any schools actually do this?...
>>>
>>> Usual thing on the news is schools having issues with inability to pay
>>> teachers due to budget shortfalls and similar, inability to afford
>>> textbooks, ...
>>
>> Unfortunately, at least in the U.S., there are quite a few school
>> systems that simply hand out devices, and many more that demand the
>> student purchase the device in order to attend.  Often purchase
>> requirements are partially subsidized (with taxpayer money), but not
>> always.
>>
>> Then it is expected that the student has Internet access from home.
>> For low income students, that isn't necessarily true, and then there
>> is a division between the haves who can work at home, and have nots
>> who can use their devices only at school, or in a library, or have to
>> find a place with free WiFi.
>>
>> So then come the municipal scale projects to supply WiFi everywhere,
>> and government subsidies (in addition to their own fee structures for
>> ordinary customers) for ISPs to provide service to low income people
>> at little or no cost.
>>
>> And, of course, since children can't be trusted with IT security,
>> these devices typically are not "general purpose" but rather are so
>> locked down that they barely qualify as "computers" ... it may look
>> like a Chromebook, but it's just an expensive Speak-n-Spell.
>>
>> The primary beneficiaries of these programs are companies like Apple
>> and Google.  It's debatable whether having a computer really will help
>> the average primary school student learn, and whether the benefit of
>> computers over books and pencils justifies the cost to the school
>> system, and to the taxpayers that support it.
>>
>
> Yeah...
>
> Back when I was school-age, it was still mostly in the era of textbooks
> and assignments being done on paper print-outs.
>
> Computers were often around, typically as a row of desktop PCs along a
> wall somewhere, but not typically used in normal class activities.
>
>
> For me, this was true in elementary school as well, just back then they
> were mostly running MS-DOS or sometimes Windows (Windows 3.11 and
> Windows 95 were common). At this time, teachers ended up mostly just
> letting me poke around on computers and write stuff in QBasic and
> similar (from what I remember, unlike most of the other students, I was
> mostly just sorta allowed to "do whatever" during these years).
>
> I have a vague memory of at one point going off somewhere else where
> they had me do some tests and similar. Don't remember, I think I talked
> to some people, also have a vague (strange) memory of being asked to
> assemble some 3D puzzles while in a room by myself behind a 1-way mirror.
>
> After this, they just let me do whatever I felt like doing (which,
> granted, was mostly just poking at QBasic on the computer...). Actually,
> I think I also remember now they had sent me a few times (and I think
> another person, who was female) to another smaller room with an adult
> guy who I remember mostly talking about programming stuff (namely
> Borland Pascal and similar; but I had more of a preference for C than
> Pascal). I think the female was around for some of the other "do stuff
> with computers" activities (but, I don't remember much else about her,
> other than her personality being a little more harsh/abrasive than many
> of the other kids; there were generally no other students present other
> than us).
>
> Also, in this room, there were some Macs, and a few of these computers
> had magneto-optical drives (of the 130mm variety), or at least the ones
> that had Turbo C and Pascal had the magneto-optical drives.
>
> On my own time, I was mostly messing with Turbo C and TASM and similar
> instead, and trying to make sense of the Wolf3D and Doom source.
>
> My early years seem kinda weird when I think back on them.
>
>
> Not that long after, my family moved to a different state, and I now
> remember parents telling me not to tell anyone about any of this.
>
>
> Typically (by HS):
>   Whiteboards were most commonly used;
>   Overhead projectors / transparencies were also common;
>   Sometimes also a TV on a cart with a VCR or DVD player;
>   Projectors connected up to a computer;
>   ...
>
> This was back in the era when laptops were a rare and expensive novelty.
> Some people also had cellphones (of the flip-phone variety), but they
> were the minority (most students did not have cellphones AFAIK).
>
> Developments shortly after high-school were mostly:
>   Cheaper laptops;
>   The rise of smartphones;
>   CRT monitors getting steadily replaced with LCD monitors;
>   ...
>
>
> I had noted that depictions of school settings on TV usually showed
> teachers using chalkboards (rather than whiteboards), with a general
> absence of any computers.
>
> Well, also differences:
>   It was much more densely packed vs TV depictions;
>     Lots more people in each class;
>     Lots more people in the halls;
>     ...
>   It had guards walking the halls during class times:
>     They would generally go around with dogs on leashes, ...
>     One would need to show the guard their hall pass to go anywhere;
>     Also, they had metal gates they would close during class time;
>     ...
>
> So, some guards would walk dogs through the halls during class, and
> others did not have dogs.
>
> In the time between classes, there was also not generally any time to
> socialize, generally ones' goal was more to get from one class to the
> next before the bell rang (or, more like, certain sounds played over the
> intercom). One couldn't take too long, or else they would be marked as
> late. One generally had about 5 minutes to get from one class to the next.
>
>
> Not actually sure what it is typically like now.
>
>
>>
>> How did any of us learn?  I didn't even have a 4 function calculator
>> until I was in high school.
>>
>
> I was in the era of the TI-83+ line...
>
> It was also an era where some people had cable modems or DSL, and other
> people were still using dial-up.
>
> High-school for me was also in the transition period between Win98 and
> Windows XP, but I was an oddball person running Windows 2000 as their
> main OS.
>
> Not long after high-school, I ended up switching over to XP-X64
> (generally ran this until later switching over to Windows 7).
>
>

Young whippersnappers! In my entire educational career, such as it was
and what there was of it, no school or university I attended so much as
owned a computer.

Nor whiteboards either, now that I remember. They invented chalk in the
Jurassic, it should be good enough for computation!