On 21/01/2024 16:24, David Brown wrote:
> On 21/01/2024 03:44, Malcolm McLean wrote:
>> On 20/01/2024 23:02, bart wrote:
>>> On 20/01/2024 22:37, Malcolm McLean wrote:
>>>> On 20/01/2024 21:37, Lawrence D'Oliveiro wrote:
>>>>> On Sat, 20 Jan 2024 11:19:57 +0000, Malcolm McLean wrote:
>>>>>
>>>>>> But no-one has yet come up with an occasion where they implemented a
>>>>>> variadic function by choice, for code which they controlled ...
>>>>>
>>>>> But the people who created these libraries we mentioned certainly did.
>>>>  >
>>>> I was wrong. As was pointed out eslewhere. Kaz gave some examples.
>>>> But his first was of usage.
>>>>
>>>> Of course someone must have taken the decision that the call to
>>>> evoke an external process would take a variable list of arguments
>>>> rather than a single string. However In find that, of thousands of
>>>> functions in my code base, not a single one is variadic except a few
>>>> interfaces to vsprintf.
>>>
>>>
>>> Variadic functions were likely added to implement *printf functions,
>>> since the language didn't want to make special provision just for those.
>>>
>>> Then a number of people decided to make use of the feature, although
>>> less often than you might expect.
>>>
>>> But it is not a desirable feature for general use as it is not
>>> type-safe.
>>>
>>> The other thing is, calling a variadic function is a lot easier than
>>> writing the body of one. That will likely put many off.
>>>
>>> I wouldn't be able to do it without looking up some examples.
>>>
>> I have occasionally passed the wrong type to printf. Usually a long
>> integer to %d. But I can't recall an occasion where the problem wasn't
>> quickly fixed. Xcode gives a warning for mismatched format string
>> parameters, but of course it can't do that for roll your own.
>
> Of course you can.
>
> XCode uses clang, IIUIC, and both gcc and clang have extensions
> (attributes) for checking printf and scanf style strings and the
> variadic parameters.  They only work with compile-time known format
> strings, understandably enough, but are fine for making your own checked
> functions for logging, debug prints, or whatever.
>
> That doesn't help for other types of variadic functions, however, and
> you they are never as type-safe as functions with full non-variadic
> prototypes.
>
>> The other thing is passing a raw pointer to %p instead of casting to
>> void *. Technically this is an error, but %p is only really useful for
>> temporary debug code, so it's just pointless typing to out the cast in.
>>
>> Variardic functions are implemented with macros and it's a bit hard to
>> work out what is going on. But it's not that hard. I don't think it's
>> a good reason for avoiding them. On the other hand, I implemented a
>> C++ variable length template expansion to produce a "simple JSON"
>> which is in effect a varidaic function with type information. But
>> whilst I implemented it myself, I can't remember exactly how it is
>> supposed to work or what the syntax means.
>>
>
> Variadic templates in C++ are typesafe, which is a big improvement over C.
>
>
A small improvement.

If you have type safety, it can be easier to know how to call the
function, because the system can help you by suggesting variables of the
right type and rejecting variables of the wrong type. And because the
type is often documentation about what the parameter means.

Then of course you can always create a bug by passing a varibale of the
wrong type.

But it's not a big improvement because, if you call a function at all,
you have to know what parameters it takes and what they mean anyway. And
whilst it does eliminate a bug, it's unlikely to be a dangerous bug, it
will usually be manifested very early and likely caught. So not the type
of thing that is likely to much effect on delivery time or quality of
the final product. However of course that won't always be the case,
especially if a long integer with all high bits zero happens to have the
same observable effect as the correct short integer or similar.

So there's a small advantage, but not a gamechanger.

My simpleJSON is variadic C++. But of course if you pass
"Nemployees",10.5, it will just create a JSON structure with a real
field value 10.5.

-- .
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Sun, 21 Jan 2024 21:43:13 +0000, bart wrote:

> On 21/01/2024 21:29, Lawrence D'Oliveiro wrote:
>> On Sun, 21 Jan 2024 13:27:30 +0000, bart wrote:
>>
>>> That is, the user-code in Python doesn't directly call 'stack_calc'.
>>> This means that there is no real need for the C function to be
variadic.
>>>
>>> It could take a single pointer to any arbitrary C data structure that
>>> can represent your sample expression. Or maybe two pointers to
parallel
>>> arrays. Or ...
>>
>> ... and be just as type-unsafe as the variadic option.
>
> No, it wouldn't.

Go on, then. Show us a typesafe alternative to printf, using your idea.

On 21/01/2024 23:51, Lawrence D'Oliveiro wrote:
> On Sun, 21 Jan 2024 21:43:13 +0000, bart wrote:
>
>> On 21/01/2024 21:29, Lawrence D'Oliveiro wrote:
>>> On Sun, 21 Jan 2024 13:27:30 +0000, bart wrote:
>>>
>>>> That is, the user-code in Python doesn't directly call 'stack_calc'.
>>>> This means that there is no real need for the C function to be
> variadic.
>>>>
>>>> It could take a single pointer to any arbitrary C data structure that
>>>> can represent your sample expression. Or maybe two pointers to
> parallel
>>>> arrays. Or ...
>>>
>>> ... and be just as type-unsafe as the variadic option.
>>
>> No, it wouldn't.
>
> Go on, then. Show us a typesafe alternative to printf, using your idea.

I said your example didn't need the C function to be variadic. The point
of variadic is to be legally able to write, in C:

f(a) or f(a,b,c,d)

But your C function wasn't called from C, it isn't called from Python
user code. From inside your special function, I think it's called as
'func(*all_args)'.

It could easily be made to work with a non-variadic C function. But my
call to f() above either has to use a variadic function, or 'f' needs to
be declared with no parameter list:

void f(T, ...); // variadic
void f(); // unchecked arguments

Both are unsafe.

On Mon, 22 Jan 2024 00:09:08 +0000, bart wrote:

> On 21/01/2024 23:51, Lawrence D'Oliveiro wrote:
>> On Sun, 21 Jan 2024 21:43:13 +0000, bart wrote:
>>
>>> On 21/01/2024 21:29, Lawrence D'Oliveiro wrote:
>>>> On Sun, 21 Jan 2024 13:27:30 +0000, bart wrote:
>>>>
>>>>> That is, the user-code in Python doesn't directly call 'stack_calc'.
>>>>> This means that there is no real need for the C function to be
>> variadic.
>>>>>
>>>>> It could take a single pointer to any arbitrary C data structure
>>>>> that can represent your sample expression. Or maybe two pointers to
>> parallel
>>>>> arrays. Or ...
>>>>
>>>> ... and be just as type-unsafe as the variadic option.
>>>
>>> No, it wouldn't.
>>
>> Go on, then. Show us a typesafe alternative to printf, using your idea.
>
> I said your example didn't need the C function to be variadic.

You also denied that your alternative would be less type-unsafe.

On 21/01/2024 22:54, Malcolm McLean wrote:
> On 21/01/2024 16:24, David Brown wrote:
>> On 21/01/2024 03:44, Malcolm McLean wrote:

>>> Variardic functions are implemented with macros and it's a bit hard
>>> to work out what is going on. But it's not that hard. I don't think
>>> it's a good reason for avoiding them. On the other hand, I
>>> implemented a C++ variable length template expansion to produce a
>>> "simple JSON" which is in effect a varidaic function with type
>>> information. But whilst I implemented it myself, I can't remember
>>> exactly how it is supposed to work or what the syntax means.
>>>
>>
>> Variadic templates in C++ are typesafe, which is a big improvement
>> over C.
>>
>>
> A small improvement.
>
> If you have type safety, it can be easier to know how to call the
> function, because the system can help you by suggesting variables of the
> right type and rejecting variables of the wrong type. And because the
> type is often documentation about what the parameter means.
>

Type-safety means the compiler will reject arguments of the wrong type
for the function - or, alternatively, select (or generate) the correct
function for the type of the arguments. Either way, the function and
arguments match in type. Documentation has nothing to do with it.

> Then of course you can always create a bug by passing a varibale of the
> wrong type.

No, you can't - that's what type safety means. (Sure, you can - at
least in C and C++ - go out of your way with cast pointers, low-level
memory access, etc., to break type safety. No language can entirely
prevent the user writing intentionally dangerous code.)

>
> But it's not a big improvement because, if you call a function at all,
> you have to know what parameters it takes and what they mean anyway.

Yes, obviously. Type-safety means the language is safe in regard to
types. It doesn't stop other bugs.

> And
> whilst it does eliminate a bug, it's unlikely to be a dangerous bug, it
> will usually be manifested very early and likely caught.

Type-safety eliminates a huge class of bugs that could otherwise cause
all sorts of problems - some big, some small, some easily spotted and
some much more subtle. And it can be used as the basis for a lot more
safety features and checks if you want.

> So not the type
> of thing that is likely to much effect on delivery time or quality of
> the final product.

That is contrary to the experience of most high quality software
developers. There is a reason why few modern languages are weakly
typed. Strong typing does not stop all problems, nor is it necessary
for writing correct software, and using typing for safety can involve
writing more verbose code than otherwise necessary. But it is a major
tool towards writing good code, and having checks on the code quality.

> However of course that won't always be the case,
> especially if a long integer with all high bits zero happens to have the
> same observable effect as the correct short integer or similar.
>
> So there's a small advantage, but not a gamechanger.
>
> My simpleJSON is variadic C++. But of course if you pass
> "Nemployees",10.5, it will just create a JSON structure with a real
> field value 10.5.
>

On 22/01/2024 07:58, David Brown wrote:
> On 21/01/2024 22:54, Malcolm McLean wrote:
>>
> That is contrary to the experience of most high quality software
> developers.  There is a reason why few modern languages are weakly
> typed.  Strong typing does not stop all problems, nor is it necessary
> for writing correct software, and using typing for safety can involve
> writing more verbose code than otherwise necessary.  But it is a major
> tool towards writing good code, and having checks on the code quality.
>
No, it's because there is a benefit, and it is easy to write a computer
program which checks for type. So there is a point in doing it. Then
there's often a perception that because something can be done by the
computer, it is important and beneficial, because the people who write
the development system must know what they are doing, and if the
computer says so, it must be correct.

Computer projects fail because the complexity of the interactions
between the sub systems exceeds the capacity of the developers to
understand them. Overwhelmingly. Not because developers sometimes pass
variables of the wrong type to functions.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 22/01/2024 13:46, Malcolm McLean wrote:
> On 22/01/2024 07:58, David Brown wrote:
>> On 21/01/2024 22:54, Malcolm McLean wrote:
>>>
>> That is contrary to the experience of most high quality software
>> developers.  There is a reason why few modern languages are weakly
>> typed.  Strong typing does not stop all problems, nor is it necessary
>> for writing correct software, and using typing for safety can involve
>> writing more verbose code than otherwise necessary.  But it is a major
>> tool towards writing good code, and having checks on the code quality.
>>
> No, it's because there is a benefit, and it is easy to write a computer
> program which checks for type. So there is a point in doing it. Then
> there's often a perception that because something can be done by the
> computer, it is important and beneficial, because the people who write
> the development system must know what they are doing, and if the
> computer says so, it must be correct.
>
> Computer projects fail because the complexity of the interactions
> between the sub systems exceeds the capacity of the developers to
> understand them. Overwhelmingly. Not because developers sometimes pass
> variables of the wrong type to functions.

Software projects fail for countless different reasons. For many of the
possible reasons, computers can't help much. In cases where computers
(compilers, static analysis, run-time checkers, etc.) /can/ help, it
makes sense to use those features - it's more efficient, and usually
more accurate.

Strong typing is one of those cases - along with many other higher-level
language features.

(And no, it's not easy to make a language and tools that provide good
checking, a comfortable and productive language, and quality tools with
efficient compilation. It is, I believe, a good deal easier to make
languages and tools with very little type checking capabilities.)

On 2024-01-22, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Computer projects fail because the complexity of the interactions
> between the sub systems exceeds the capacity of the developers to
> understand them. Overwhelmingly. Not because developers sometimes pass
> variables of the wrong type to functions.

If passing wrong types to functions was not caught, either at compile
time, or at run time (as in dynamic languages) but simply resulted
in an object of one type being misused as another, then that would be
a huge source of bugs.

You can't tell whether wrong types are a source of bugs without working
in a typeless language.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 22/01/2024 19:44, Kaz Kylheku wrote:
> On 2024-01-22, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> Computer projects fail because the complexity of the interactions
>> between the sub systems exceeds the capacity of the developers to
>> understand them. Overwhelmingly. Not because developers sometimes pass
>> variables of the wrong type to functions.
>
> If passing wrong types to functions was not caught, either at compile
> time, or at run time (as in dynamic languages) but simply resulted
> in an object of one type being misused as another, then that would be
> a huge source of bugs.
>
> You can't tell whether wrong types are a source of bugs without working
> in a typeless language.
>
You can use variadic functions in C.

When you use your "cat" function, for example, do you find it a problem
that is you pass a variable that isn't a character pointer, the system
will reinterpret the bits as though they were a character pointer?

And catching at run time is a bug, just an easy bug to detect and correct.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 22/01/2024 12:58, David Brown wrote:
> On 22/01/2024 13:46, Malcolm McLean wrote:
>> On 22/01/2024 07:58, David Brown wrote:
>>> On 21/01/2024 22:54, Malcolm McLean wrote:
>>>>
>>> That is contrary to the experience of most high quality software
>>> developers.  There is a reason why few modern languages are weakly
>>> typed.  Strong typing does not stop all problems, nor is it necessary
>>> for writing correct software, and using typing for safety can involve
>>> writing more verbose code than otherwise necessary.  But it is a
>>> major tool towards writing good code, and having checks on the code
>>> quality.
>>>
>> No, it's because there is a benefit, and it is easy to write a
>> computer program which checks for type. So there is a point in doing
>> it. Then there's often a perception that because something can be done
>> by the computer, it is important and beneficial, because the people
>> who write the development system must know what they are doing, and if
>> the computer says so, it must be correct.
>>
>> Computer projects fail because the complexity of the interactions
>> between the sub systems exceeds the capacity of the developers to
>> understand them. Overwhelmingly. Not because developers sometimes pass
>> variables of the wrong type to functions.
>
> Software projects fail for countless different reasons.  For many of the
> possible reasons, computers can't help much.  In cases where computers
> (compilers, static analysis, run-time checkers, etc.) /can/ help, it
> makes sense to use those features - it's more efficient, and usually
> more accurate.
>
> Strong typing is one of those cases - along with many other higher-level
> language features.
>
> (And no, it's not easy to make a language and tools that provide good
> checking, a comfortable and productive language, and quality tools with
> efficient compilation.  It is, I believe, a good deal easier to make
> languages and tools with very little type checking capabilities.)
>
>
>
Have you tried to write a compiler or intepreter?

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Spiros Bousbouras wrote:

> On Sat, 20 Jan 2024 11:19:57 +0000 Malcolm McLean
> <malcolm.arthur.mclean@gmail.com> wrote:
>> But no-one has yet come up with an occasion where they implemented a
>> variadic function by choice, for code which they controlled, except for
>> printf style formatting. Either a hobby project or work code for which
>> they had ownership.
>
> I asked a similar question on this group many years ago. One example
> given was a function for concatenating strings which would accept as
> arguments a variable number of strings.

I've only ever done chained strcat calls, e.g.
strcat(strcat(strcat(something, "blah"), "whatever"), "nonsense").

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
“Hotel California” is completely literal and the Eagles are still trapped
there.

Malcolm McLean wrote:

> Who has actually used a variadic function for any purpose other than
> implementing printf-style format strings?

I'll admit to not having written many of them. But i _have_ written a lot
of variadic macros, though this has mostly been so as to prevent problems
with commas in arguments.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site

On Mon, 22 Jan 2024 23:25:22 -0000 (UTC), Blue-Maned_Hawk wrote:

> I've only ever done chained strcat calls, e.g.
> strcat(strcat(strcat(something, "blah"), "whatever"), "nonsense").

You’ve got to be kidding.

On 2024-01-22, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 22/01/2024 19:44, Kaz Kylheku wrote:
>> On 2024-01-22, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> Computer projects fail because the complexity of the interactions
>>> between the sub systems exceeds the capacity of the developers to
>>> understand them. Overwhelmingly. Not because developers sometimes pass
>>> variables of the wrong type to functions.
>>
>> If passing wrong types to functions was not caught, either at compile
>> time, or at run time (as in dynamic languages) but simply resulted
>> in an object of one type being misused as another, then that would be
>> a huge source of bugs.
>>
>> You can't tell whether wrong types are a source of bugs without working
>> in a typeless language.
>>
> You can use variadic functions in C.
>
> When you use your "cat" function, for example, do you find it a problem
> that is you pass a variable that isn't a character pointer, the system
> will reinterpret the bits as though they were a character pointer?

Yes?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 22/01/2024 23:25, Malcolm McLean wrote:
> On 22/01/2024 12:58, David Brown wrote:
>> On 22/01/2024 13:46, Malcolm McLean wrote:
>>> On 22/01/2024 07:58, David Brown wrote:
>>>> On 21/01/2024 22:54, Malcolm McLean wrote:
>>>>>
>>>> That is contrary to the experience of most high quality software
>>>> developers.  There is a reason why few modern languages are weakly
>>>> typed.  Strong typing does not stop all problems, nor is it
>>>> necessary for writing correct software, and using typing for safety
>>>> can involve writing more verbose code than otherwise necessary.  But
>>>> it is a major tool towards writing good code, and having checks on
>>>> the code quality.
>>>>
>>> No, it's because there is a benefit, and it is easy to write a
>>> computer program which checks for type. So there is a point in doing
>>> it. Then there's often a perception that because something can be
>>> done by the computer, it is important and beneficial, because the
>>> people who write the development system must know what they are
>>> doing, and if the computer says so, it must be correct.
>>>
>>> Computer projects fail because the complexity of the interactions
>>> between the sub systems exceeds the capacity of the developers to
>>> understand them. Overwhelmingly. Not because developers sometimes
>>> pass variables of the wrong type to functions.
>>
>> Software projects fail for countless different reasons.  For many of
>> the possible reasons, computers can't help much.  In cases where
>> computers (compilers, static analysis, run-time checkers, etc.) /can/
>> help, it makes sense to use those features - it's more efficient, and
>> usually more accurate.
>>
>> Strong typing is one of those cases - along with many other
>> higher-level language features.
>>
>> (And no, it's not easy to make a language and tools that provide good
>> checking, a comfortable and productive language, and quality tools
>> with efficient compilation.  It is, I believe, a good deal easier to
>> make languages and tools with very little type checking capabilities.)
>>
>>
>>
> Have you tried to write a compiler or intepreter?
>

No (except for tiny DSL's).

But I also have not tried to fly a plane, yet I know that some types of
plane are easier to fly than others.

On 23/01/2024 08:07, David Brown wrote:
> On 22/01/2024 23:25, Malcolm McLean wrote:
>> On 22/01/2024 12:58, David Brown wrote:
>>> On 22/01/2024 13:46, Malcolm McLean wrote:
>>>> On 22/01/2024 07:58, David Brown wrote:
>>>>> On 21/01/2024 22:54, Malcolm McLean wrote:
>>>>>>
>>>>> That is contrary to the experience of most high quality software
>>>>> developers.  There is a reason why few modern languages are weakly
>>>>> typed.  Strong typing does not stop all problems, nor is it
>>>>> necessary for writing correct software, and using typing for safety
>>>>> can involve writing more verbose code than otherwise necessary.
>>>>> But it is a major tool towards writing good code, and having checks
>>>>> on the code quality.
>>>>>
>>>> No, it's because there is a benefit, and it is easy to write a
>>>> computer program which checks for type. So there is a point in doing
>>>> it. Then there's often a perception that because something can be
>>>> done by the computer, it is important and beneficial, because the
>>>> people who write the development system must know what they are
>>>> doing, and if the computer says so, it must be correct.
>>>>
>>>> Computer projects fail because the complexity of the interactions
>>>> between the sub systems exceeds the capacity of the developers to
>>>> understand them. Overwhelmingly. Not because developers sometimes
>>>> pass variables of the wrong type to functions.
>>>
>>> Software projects fail for countless different reasons.  For many of
>>> the possible reasons, computers can't help much.  In cases where
>>> computers (compilers, static analysis, run-time checkers, etc.) /can/
>>> help, it makes sense to use those features - it's more efficient, and
>>> usually more accurate.
>>>
>>> Strong typing is one of those cases - along with many other
>>> higher-level language features.
>>>
>>> (And no, it's not easy to make a language and tools that provide good
>>> checking, a comfortable and productive language, and quality tools
>>> with efficient compilation.  It is, I believe, a good deal easier to
>>> make languages and tools with very little type checking capabilities.)
>>>
>>>
>>>
>> Have you tried to write a compiler or intepreter?
>>
>
> No (except for tiny DSL's).
>
> But I also have not tried to fly a plane, yet I know that some types of
> plane are easier to fly than others.
>
>
Bascially it's just a grammar rule, and you'll already have a flexible
grammar system because you need it for the rest of the compiler.
Technically it will be a "constraint" on the grammar as most grammars
can't express "function_call = function_name open_parentheses
variable_of_a_type_that_matches close_parentheses".

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 22/01/2024 23:36, Lawrence D'Oliveiro wrote:
> On Mon, 22 Jan 2024 23:25:22 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> I've only ever done chained strcat calls, e.g.
>> strcat(strcat(strcat(something, "blah"), "whatever"), "nonsense").
>
> You’ve got to be kidding.
>
That was why strcat retutns a pointer. It was how it was meant to be
used. But it never caught on.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 23/01/2024 09:30, Malcolm McLean wrote:
> On 22/01/2024 23:36, Lawrence D'Oliveiro wrote:
>> On Mon, 22 Jan 2024 23:25:22 -0000 (UTC), Blue-Maned_Hawk wrote:
>>
>>> I've only ever done chained strcat calls, e.g.
>>> strcat(strcat(strcat(something, "blah"), "whatever"), "nonsense").
>>
>> You’ve got to be kidding.
> >
> That was why strcat retutns a pointer. It was how it was meant to be
> used. But it never caught on.
>

I don't think that is a reasonable way to put it. Rather, say that
strcat and strcpy return their first argument because that was what the
library specifiers felt would be the most useful return value. One of
the possibilities it allows is chaining like this.

One possible reason why people don't use it - perhaps preferring to use
snprintf or non-standard functions for multiple concatenation - is that
a naïve implementation is unnecessarily inefficient. For such uses, it
would be far better if strcat and strcpy had returned a pointer to one
past the end of the resulting string, rather than duplicating the
initial pointer. (For other uses, maybe it is more convenient to have
the returns the way strcat and strcpy do.)

Some optimising compilers will do a better job, and will optimise such
nested strcat() calls for efficiency, making it a perfectly reasonable
construction if you are using something like gcc (or if efficiency is
not an issue).

On 23/01/2024 09:27, Malcolm McLean wrote:
> On 23/01/2024 08:07, David Brown wrote:
>> On 22/01/2024 23:25, Malcolm McLean wrote:
>>> On 22/01/2024 12:58, David Brown wrote:
>>>> On 22/01/2024 13:46, Malcolm McLean wrote:
>>>>> On 22/01/2024 07:58, David Brown wrote:
>>>>>> On 21/01/2024 22:54, Malcolm McLean wrote:
>>>>>>>
>>>>>> That is contrary to the experience of most high quality software
>>>>>> developers.  There is a reason why few modern languages are weakly
>>>>>> typed.  Strong typing does not stop all problems, nor is it
>>>>>> necessary for writing correct software, and using typing for
>>>>>> safety can involve writing more verbose code than otherwise
>>>>>> necessary. But it is a major tool towards writing good code, and
>>>>>> having checks on the code quality.
>>>>>>
>>>>> No, it's because there is a benefit, and it is easy to write a
>>>>> computer program which checks for type. So there is a point in
>>>>> doing it. Then there's often a perception that because something
>>>>> can be done by the computer, it is important and beneficial,
>>>>> because the people who write the development system must know what
>>>>> they are doing, and if the computer says so, it must be correct.
>>>>>
>>>>> Computer projects fail because the complexity of the interactions
>>>>> between the sub systems exceeds the capacity of the developers to
>>>>> understand them. Overwhelmingly. Not because developers sometimes
>>>>> pass variables of the wrong type to functions.
>>>>
>>>> Software projects fail for countless different reasons.  For many of
>>>> the possible reasons, computers can't help much.  In cases where
>>>> computers (compilers, static analysis, run-time checkers, etc.)
>>>> /can/ help, it makes sense to use those features - it's more
>>>> efficient, and usually more accurate.
>>>>
>>>> Strong typing is one of those cases - along with many other
>>>> higher-level language features.
>>>>
>>>> (And no, it's not easy to make a language and tools that provide
>>>> good checking, a comfortable and productive language, and quality
>>>> tools with efficient compilation.  It is, I believe, a good deal
>>>> easier to make languages and tools with very little type checking
>>>> capabilities.)
>>>>
>>>>
>>>>
>>> Have you tried to write a compiler or intepreter?
>>>
>>
>> No (except for tiny DSL's).
>>
>> But I also have not tried to fly a plane, yet I know that some types
>> of plane are easier to fly than others.
>>
>>
> Bascially it's just a grammar rule, and you'll already have a flexible
> grammar system because you need it for the rest of the compiler.
> Technically it will be a "constraint" on the grammar as most grammars
> can't express "function_call = function_name open_parentheses
> variable_of_a_type_that_matches close_parentheses".
>

That is not the difference between strong typing and weak typing, nor is
it all you need for a language to support good typing. But perhaps we
have lost track of exactly what we are talking about here, and are
thinking about different things, or at least different aspects of
typing. Let's leave it for now.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 22/01/2024 23:36, Lawrence D'Oliveiro wrote:
>> On Mon, 22 Jan 2024 23:25:22 -0000 (UTC), Blue-Maned_Hawk wrote:
>>
>>> I've only ever done chained strcat calls, e.g.
>>> strcat(strcat(strcat(something, "blah"), "whatever"), "nonsense").
>>
>> You’ve got to be kidding.
> >
>That was why strcat retutns a pointer. It was how it was meant to be
>used. But it never caught on.
>
For rather good reason. Too easy to overrun the size of the buffer.

Huge security hole.

On Tue, 23 Jan 2024 15:27:25 GMT, Scott Lurndal wrote:

> Huge security hole.

That was the point I was trying to make, but it seemed to go over
somebody’s head ...

bart wrote:

> But it is not a desirable feature for general use as it is not
> type-safe.

Data types are a social construct.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Very fred kindley!

Lawrence D'Oliveiro wrote:

> On Mon, 22 Jan 2024 23:25:22 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> I've only ever done chained strcat calls, e.g.
>> strcat(strcat(strcat(something, "blah"), "whatever"), "nonsense").
>
> You’ve got to be kidding.

I am not kidding. Here's an actual fragment of code where i used it to
format an array of backtrace symbols to be on one line each:

for (int i = 0; i < depth; ++i)
strcat(strcat(strcat(btstr, "\t"), btsyms[i]), "\n");

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Sip it, don't chug it!

Scott Lurndal wrote:

> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>On 22/01/2024 23:36, Lawrence D'Oliveiro wrote:
>>> On Mon, 22 Jan 2024 23:25:22 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> I've only ever done chained strcat calls, e.g.
>>>> strcat(strcat(strcat(something, "blah"), "whatever"), "nonsense").
>>>
>>> You’ve got to be kidding.
>> >
>>That was why strcat retutns a pointer. It was how it was meant to be
>>used. But it never caught on.
>>
> For rather good reason. Too easy to overrun the size of the buffer.
>
> Huge security hole.

strncat

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
In this case, some interesting physical effects would destroy it.

On Tue, 23 Jan 2024 22:28:03 -0000 (UTC), Blue-Maned_Hawk wrote:

> strncat

If you can figure out how to use it properly.