Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Whaddaya think?
Date: Mon, 17 Jun 2024 14:44:47 +0200
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <v4pb3v$lbo4$2@dont-email.me>
References: <666ded36$0$958$882e4bbb@reader.netnews.com>
 <20240616015649.000051a0@yahoo.com> <v4lm16$3s87h$4@dont-email.me>
 <v4lmso$3sl7n$1@dont-email.me> <877cep4j2i.fsf@nosuchdomain.example.com>
 <v4lqjc$3t9au$1@dont-email.me>
 <666f000a$1$1412891$882e4bbb@reader.netnews.com>
 <v4n1uh$40n6$1@dont-email.me> <v4n6ie$58k0$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 17 Jun 2024 14:44:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6eee6dfb82180fb756db1a7758fc4b5a";
	logging-data="700164"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX193PjNIit85GibLno++n0lEELV7w68NK2E="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:/ZQg/q6rCr2xoUqJ/UGau/J86gk=
Content-Language: en-GB
In-Reply-To: <v4n6ie$58k0$1@dont-email.me>
Bytes: 4059

On 16/06/2024 19:14, bart wrote:
> On 16/06/2024 16:56, David Brown wrote:
>> On 16/06/2024 17:09, DFS wrote:
>>> On 6/16/2024 12:44 AM, Janis Papanagnou wrote:
>>>> On 16.06.2024 06:17, Keith Thompson wrote:
>>>>>
>>>>> For the original problem, where the input consists of digits and
>>>>> whitespace, you could read a character at a time and accumulate the
>>>>> value of each number.  (You probably want to handle leading signs as
>>>>> well, which isn't difficult.)
>>>>
>>>> Yes. Been there, done that. Sometimes it's good enough to go back
>>>> to the roots if higher-level functions are imperfect or quirky.
>>>>
>>>>> That is admittedly reinventing the
>>>>> wheel, but the existing wheels aren't entirely round.  You still
>>>>> have to dynamically allocate the array of ints, assuming you need
>>>>> to store all of them rather than processing each value as it's read.
>>>>
>>>> A subclass of tasks can certainly process data on the fly but for
>>>> the general solution there should be a convenient way to handle it.
>>>>
>>>> I still prefer higher-level languages that take the burden from me.
>>>
>>> nums = []
>>> with open('data.txt','r') as f:
>>>      for nbr in f.read().split():
>>>          nums.append(int(nbr))
>>>      print(*sorted(nums))
>>>
>>
>> nums = sorted(map(int, open('data.txt', 'r').read().split()))
> 
> OK, a bit of a challenge for my scripting language. I managed this first:
> 
>    nums := sort(mapv(toval, splitstring(readstrfile("data.txt"))))
> 
> It needed a change to 'splitstring' to allow a default separator 
> consisting of white space of any length. And a one-line helper function 
> 'toval' since the usual candidates, special built-ins, were not valid 
> for 'mapv'.
> 

That's nice, but irrelevant - the OP can use the Python version if he 
decides writing the C version is not fun any more, but your language is 
useless to everyone but you.

> It also works like this:
> 
>    nums := readstrfile("data.txt") -> splitstring -> mapv(toval) -> sort
> 
> But only by chance since the 'piped' argument is the last one of 
> multi-parameter functions, rather than the first.
> 

A piping syntax is, IMHO, also a nice feature (though again the OP will 
have no direct use of your language).

Some people might like to do this all with shell pipes:

cat data.txt | xargs -n 1 | sort -n | xargs

That kind of thing can quickly get more awkward as the details change, 
such as if the data is separated by commas - by the time you have 
figured out the "awk" or "sed" commands needed, you'd be much faster 
with Python.