Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #401688 > unrolled thread

c needs this sign

Back to article view | Back to comp.lang.c

Contents

  c needs this sign fir <profesor.fir@gmail.com> - 2026-09-07 15:53 +0200
    Re: c needs this sign David LaRue <huey.dll@tampabay.rr.com> - 2026-09-07 19:21 +0000
      Re: c needs this sign Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 01:10 +0200
        Re: c needs this sign Dan Purgert <dan@djph.net> - 2026-09-07 23:13 +0000
          Re: c needs this sign Lane W <cactus_DAC@yahoo.com> - 2026-09-07 17:26 -0600
        Re: c needs this sign David Brown <david.brown@hesbynett.no> - 2026-09-08 10:40 +0200
          Re: c needs this sign Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:49 +0200
            Re: c needs this sign David Brown <david.brown@hesbynett.no> - 2026-09-09 13:21 +0200
              Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-09 13:33 +0200
              Support of Unicode characters in various places (was Re: c needs this sign) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 21:37 +0200
                Re: Support of Unicode characters in various places (was Re: c needs this sign) David Brown <david.brown@hesbynett.no> - 2026-09-10 09:01 +0200
                  Re: Support of Unicode characters in various places (was Re: c needs this sign) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 23:13 +0200
                    Re: Support of Unicode characters in various places (was Re: c needs this sign) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 14:54 -0700
                      Re: Support of Unicode characters in various places (was Re: c needs this sign) scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 22:17 +0000
                        Re: Support of Unicode characters in various places (was Re: c needs this sign) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 15:48 -0700
                          Re: Support of Unicode characters in various places (was Re: c needs this sign) bart <bc@freeuk.com> - 2026-09-11 10:51 +0100
                            Re: Support of Unicode characters in various places (was Re: c needs this sign) David Brown <david.brown@hesbynett.no> - 2026-09-11 12:49 +0200
                            Re: Support of Unicode characters in various places (was Re: c needs this sign) scott@slp53.sl.home (Scott Lurndal) - 2026-09-11 16:28 +0000
                      Re: Support of Unicode characters in various places (was Re: c needs this sign) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 02:03 +0200
                        Re: Support of Unicode characters in various places (was Re: c needs this sign) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 17:13 -0700
                          Re: Support of Unicode characters in various places (was Re: c needs this sign) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 02:24 +0200
                          Re: Support of Unicode characters in various places (was Re: c needs this sign) David Brown <david.brown@hesbynett.no> - 2026-09-11 09:42 +0200
            Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-09 23:59 +0200
              Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 00:04 +0200
                Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 00:16 +0200
                  Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 00:30 +0200
                Re: c needs this sign bart <bc@freeuk.com> - 2026-09-09 23:44 +0100
                  Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 00:55 +0200
                    Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 01:09 +0200
                      Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 01:21 +0200
                        Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 01:36 +0200
                          Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 01:45 +0200
                  Re: c needs this sign Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-15 07:23 +0000
        Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 11:56 +0200
          Re: c needs this sign bart <bc@freeuk.com> - 2026-09-08 11:14 +0100
            Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 12:28 +0200
            Re: c needs this sign Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 03:54 -0700
              Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 13:13 +0200
              = vs. == (again!) (Was: c needs this sign) gazelle@shell.xmission.com (Kenny McCormack) - 2026-09-08 14:39 +0000
                Re: = vs. == (again!) (Was: c needs this sign) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 23:36 -0700
              Re: c needs this sign Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:13 +0200
            Re: c needs this sign Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 00:29 +0000
              Re: c needs this sign "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 13:42 -0700
        Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 15:12 +0200
    Re: c needs this sign Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-08 03:33 +0000
      Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 12:02 +0200
        Re: c needs this sign Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 00:27 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#401931 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

On 2026-09-11 02:13, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>> (BTW, in my youth I had specified some detailed semantics (and
>> connotations) for the textual multiplication of '?' and '!' up
>> to a length of 3 - it had not been common to express more than
>> expressible with the single signs. I considered it worthy since
>> the expressive power of plain '!' and '?' wasn't sufficient for
>> the finer tones.)
> 
> Really???  Tell me more!!!

Yeah, these two are the simple ones; plain amplifications, IMO.
It's getting more interesting in the difference of mixed forms.
But, honestly, I don't recall the details any more. Back these
days I had no computer and the pencil-and-paper-storage-device
I used has long decayed, I fear.

> ⸘⸘⸘Or maybe not‽‽‽

Better not. (Not here.) :-)

Janis

[toc] | [prev] | [next] | [standalone]

#401935 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

On 11/09/2026 02:13, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>> (BTW, in my youth I had specified some detailed semantics (and
>> connotations) for the textual multiplication of '?' and '!' up
>> to a length of 3 - it had not been common to express more than
>> expressible with the single signs. I considered it worthy since
>> the expressive power of plain '!' and '?' wasn't sufficient for
>> the finer tones.)
> 
> Really???  Tell me more!!!
> 
> ⸘⸘⸘Or maybe not‽‽‽
> 

PHP has =, ==, and === as different operators, as well as ??.  Maybe the 
??? and !!! are not as unrealistic as they sound !!!

[toc] | [prev] | [next] | [standalone]

#401845

Janis Papanagnou pisze:

> Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
> use ':=' as usual. The Unicode symbol adds nothing and costs a lot!
> 

this one is in fact quite nice, and practically could be used as is imo

char* txt ≔ "skjnskjns";
char* txt = "skjnskjns";

its maybe even better looking than oryginal = but this probably depends 
on font..but from this mentioned it seem the best as for now


a ≔ b=3  //would mean assign true to a if b=3

a=b≔3 //this would mean assign b to 3  andcheck if a=3


hovver im not quite convinced if thise logical 'hypothesis'
should be cast to arithmetic (maybe yes maybe not i dont know)

if hypothesis not casted it could mean that if would no need oparators 
at all maybe just syntax

hypothesis statement

like

a<4 print "ssasa"

0<x<size x ≔ rand()

[toc] | [prev] | [next] | [standalone]

#401846

fir pisze:
> Janis Papanagnou pisze:
> 
>> Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
>> use ':=' as usual. The Unicode symbol adds nothing and costs a lot!
>>
> 
> this one is in fact quite nice, and practically could be used as is imo
> 
> char* txt ≔ "skjnskjns";
> char* txt = "skjnskjns";
> 
> its maybe even better looking than oryginal = but this probably depends 
> on font..but from this mentioned it seem the best as for now
> 
> 
> a ≔ b=3  //would mean assign true to a if b=3
> 
> a=b≔3 //this would mean assign b to 3  andcheck if a=3
> 
> 
> hovver im not quite convinced if thise logical 'hypothesis'
> should be cast to arithmetic (maybe yes maybe not i dont know)
> 
> if hypothesis not casted it could mean that if would no need oparators 
> at all maybe just syntax
> 
> hypothesis statement
> 
> like
> 
> a<4 print "ssasa"
> 
> 0<x<size x ≔ rand()
> 
> 
> 
> 

overally good one

i may announce

AS FOR NOW ≔ IS A WINNER (applause)

[toc] | [prev] | [next] | [standalone]

#401848

fir pisze:
> fir pisze:
>> Janis Papanagnou pisze:
>>
>>> Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
>>> use ':=' as usual. The Unicode symbol adds nothing and costs a lot!
>>>
>>
>> this one is in fact quite nice, and practically could be used as is imo
>>
>> char* txt ≔ "skjnskjns";
>> char* txt = "skjnskjns";
>>
>> its maybe even better looking than oryginal = but this probably 
>> depends on font..but from this mentioned it seem the best as for now
>>
>>
>> a ≔ b=3  //would mean assign true to a if b=3
>>
>> a=b≔3 //this would mean assign b to 3  andcheck if a=3
>>
>>
>> hovver im not quite convinced if thise logical 'hypothesis'
>> should be cast to arithmetic (maybe yes maybe not i dont know)
>>
>> if hypothesis not casted it could mean that if would no need oparators 
>> at all maybe just syntax
>>
>> hypothesis statement
>>
>> like
>>
>> a<4 print "ssasa"
>>
>> 0<x<size x ≔ rand()
>>
>>
>>
>>
> 
> overally good one
> 
> i may announce
> 
> AS FOR NOW ≔ IS A WINNER (applause)
> 

as to how to use it on windows there ias a program auto hotkey (3 MB)

some may instal it, make create new autohotkey script on desktop (text 
file with .ahk extension)

put this inside this text file

^=::SendText("≔")


run it by clicking on it and then this script is run in try area and 
each control + = generates ≔

≔≔slksklns≔≔sjnskj≔≔≔sskskjsn


so practically its not so hard to map unicode on keyboard imo

[toc] | [prev] | [next] | [standalone]

#401851

fir pisze:
> fir pisze:
>> fir pisze:
>>> Janis Papanagnou pisze:
>>>
>>>> Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
>>>> use ':=' as usual. The Unicode symbol adds nothing and costs a lot!
>>>>
>>>
>>> this one is in fact quite nice, and practically could be used as is imo
>>>
>>> char* txt ≔ "skjnskjns";
>>> char* txt = "skjnskjns";
>>>
>>> its maybe even better looking than oryginal = but this probably 
>>> depends on font..but from this mentioned it seem the best as for now
>>>
>>>
>>> a ≔ b=3  //would mean assign true to a if b=3
>>>
>>> a=b≔3 //this would mean assign b to 3  andcheck if a=3
>>>
>>>
>>> hovver im not quite convinced if thise logical 'hypothesis'
>>> should be cast to arithmetic (maybe yes maybe not i dont know)
>>>
>>> if hypothesis not casted it could mean that if would no need 
>>> oparators at all maybe just syntax
>>>
>>> hypothesis statement
>>>
>>> like
>>>
>>> a<4 print "ssasa"
>>>
>>> 0<x<size x ≔ rand()
>>>
>>>
>>>
>>>
>>
>> overally good one
>>
>> i may announce
>>
>> AS FOR NOW ≔ IS A WINNER (applause)
>>
> 
> as to how to use it on windows there ias a program auto hotkey (3 MB)
> 
> some may instal it, make create new autohotkey script on desktop (text 
> file with .ahk extension)
> 
> put this inside this text file
> 
> ^=::SendText("≔")
> 
> 
> run it by clicking on it and then this script is run in try area and 
> each control + = generates ≔
> 
> ≔≔slksklns≔≔sjnskj≔≔≔sskskjsn
> 
> 
> so practically its not so hard to map unicode on keyboard imo
> 
> 

can be also used to map c keywords


!f::SendText("float ")
!i::SendText("int ")
!r::SendText("return ")
!v::SendText("void ")
!c::SendText("char ")
!i::SendText("for(int i=0; i<100; i++) ")


hero for alts flt+f makes float and so on...
control+c control+v as copy paste seem to have priority
so it not showed but alst seem work with no problem
it may maybe block this menu shortcuts in window but this shortcuts are 
useles for me

[toc] | [prev] | [next] | [standalone]

#401854

On 09/09/2026 23:04, fir wrote:
> fir pisze:
>> Janis Papanagnou pisze:
>>
>>> Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
>>> use ':=' as usual. The Unicode symbol adds nothing and costs a lot!
>>>
>>
>> this one is in fact quite nice, and practically could be used as is imo
>>
>> char* txt ≔ "skjnskjns";
>> char* txt = "skjnskjns";
>>
>> its maybe even better looking than oryginal = but this probably 
>> depends on font..but from this mentioned it seem the best as for now
>>
>>
>> a ≔ b=3  //would mean assign true to a if b=3
>>
>> a=b≔3 //this would mean assign b to 3  andcheck if a=3
>>
>>
>> hovver im not quite convinced if thise logical 'hypothesis'
>> should be cast to arithmetic (maybe yes maybe not i dont know)
>>
>> if hypothesis not casted it could mean that if would no need oparators 
>> at all maybe just syntax
>>
>> hypothesis statement
>>
>> like
>>
>> a<4 print "ssasa"
>>
>> 0<x<size x ≔ rand()
>>
>>
>>
>>
> 
> overally good one
> 
> i may announce
> 
> AS FOR NOW ≔ IS A WINNER (applause)
> 

So, what happens now?

Do you implement this in your enhanced version of C, or in a new 
language (hard)?

Or persuade someone else to add it to C or some other mainstream 
language (magnitudes harder)?

Personally I find it near impossible to see, and near impossible to 
type. Still, I added it to my language (which already uses :=) to see 
how it works:

     a := 10
     b ≔ 20
     c := 30

It does work, but I have to use Notepad to view it, and even there I 
don't know how to type it: I pasted it from here.

Visibility is slightly better in Notepad than in Thunderbird, but not by 
much.

[toc] | [prev] | [next] | [standalone]

#401856

bart pisze:
> On 09/09/2026 23:04, fir wrote:
>> fir pisze:
>>> Janis Papanagnou pisze:
>>>
>>>> Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
>>>> use ':=' as usual. The Unicode symbol adds nothing and costs a lot!
>>>>
>>>
>>> this one is in fact quite nice, and practically could be used as is imo
>>>
>>> char* txt ≔ "skjnskjns";
>>> char* txt = "skjnskjns";
>>>
>>> its maybe even better looking than oryginal = but this probably 
>>> depends on font..but from this mentioned it seem the best as for now
>>>
>>>
>>> a ≔ b=3  //would mean assign true to a if b=3
>>>
>>> a=b≔3 //this would mean assign b to 3  andcheck if a=3
>>>
>>>
>>> hovver im not quite convinced if thise logical 'hypothesis'
>>> should be cast to arithmetic (maybe yes maybe not i dont know)
>>>
>>> if hypothesis not casted it could mean that if would no need 
>>> oparators at all maybe just syntax
>>>
>>> hypothesis statement
>>>
>>> like
>>>
>>> a<4 print "ssasa"
>>>
>>> 0<x<size x ≔ rand()
>>>
>>>
>>>
>>>
>>
>> overally good one
>>
>> i may announce
>>
>> AS FOR NOW ≔ IS A WINNER (applause)
>>
> 
> So, what happens now?
> 
> Do you implement this in your enhanced version of C, or in a new 
> language (hard)?
> 
> Or persuade someone else to add it to C or some other mainstream 
> language (magnitudes harder)?
> 
> Personally I find it near impossible to see, and near impossible to 
> type. Still, I added it to my language (which already uses :=) to see 
> how it works:
> 
>      a := 10
>      b ≔ 20
>      c := 30
> 
> It does work, but I have to use Notepad to view it, and even there I 
> don't know how to type it: I pasted it from here.
> 
> Visibility is slightly better in Notepad than in Thunderbird, but not by 
> much.
> 


what happans? from all this considered as for all that i see this one
seems best


as to adding i dont know last years i dont write my compiler,
as to imposing also no but i just make a conclusion ;c

as to typing install auto hot key 2 and you may create new script
paste it

^=::SendText("≔")


as a contest of this script and then control+= will gnerate this

as to visibility i think its only dependant on which font you use
for example notepad uses consolas and in this font its look quite good 
for me (as i said imo better than oryginal = )

[toc] | [prev] | [next] | [standalone]

#401858

fir pisze:
> bart pisze:
>> On 09/09/2026 23:04, fir wrote:
>>> fir pisze:
>>>> Janis Papanagnou pisze:
>>>>
>>>>> Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
>>>>> use ':=' as usual. The Unicode symbol adds nothing and costs a lot!
>>>>>
>>>>
>>>> this one is in fact quite nice, and practically could be used as is imo
>>>>
>>>> char* txt ≔ "skjnskjns";
>>>> char* txt = "skjnskjns";
>>>>
>>>> its maybe even better looking than oryginal = but this probably 
>>>> depends on font..but from this mentioned it seem the best as for now
>>>>
>>>>
>>>> a ≔ b=3  //would mean assign true to a if b=3
>>>>
>>>> a=b≔3 //this would mean assign b to 3  andcheck if a=3
>>>>
>>>>
>>>> hovver im not quite convinced if thise logical 'hypothesis'
>>>> should be cast to arithmetic (maybe yes maybe not i dont know)
>>>>
>>>> if hypothesis not casted it could mean that if would no need 
>>>> oparators at all maybe just syntax
>>>>
>>>> hypothesis statement
>>>>
>>>> like
>>>>
>>>> a<4 print "ssasa"
>>>>
>>>> 0<x<size x ≔ rand()
>>>>
>>>>
>>>>
>>>>
>>>
>>> overally good one
>>>
>>> i may announce
>>>
>>> AS FOR NOW ≔ IS A WINNER (applause)
>>>
>>
>> So, what happens now?
>>
>> Do you implement this in your enhanced version of C, or in a new 
>> language (hard)?
>>
>> Or persuade someone else to add it to C or some other mainstream 
>> language (magnitudes harder)?
>>
>> Personally I find it near impossible to see, and near impossible to 
>> type. Still, I added it to my language (which already uses :=) to see 
>> how it works:
>>
>>      a := 10
>>      b ≔ 20
>>      c := 30
>>
>  (...)
> as to visibility i think its only dependant on which font you use
> for example notepad uses consolas and in this font its look quite good 
> for me (as i said imo better than oryginal = )
> 
> 

it may be matter of taste , becouse if you like c := 30 you seem to have 
different taste than i ;c becouse for me its not standable

for this two in c = and == the set ≔ and = is much better

but as i said it very much must depend on font i guess

(i wouldnt also consider ≔ as a final choice for assigment but for now
as for replace in traditional c is best i seen as for the moment

i myself condider in fact two langueges one is slightly improved c 
(close to traditional c)  and one is maybe yet more radically improved c 
and in the second i could maybe search for something more futuristic as 
assigment, i dont know yet

but for traditional i may repeat  ≔ =  much better than = == andmuch 
better than := =

[toc] | [prev] | [next] | [standalone]

#401859

fir pisze:>>>>
 >>>> AS FOR NOW ≔ IS A WINNER (applause)
 >>>>
 >>>
this applaus above i said a bit ironically/distancebecouse its a tiny 
thing, hovever it was long time to
think about this "= ==" problem ;c

imo to get to conclusions you need some steps and for
me some step was noticing equality must be =
(i forgot at the moment sadly by what ocasion i noticed it)
(maybe i will recall later, coz i know there was soem occasion)
if so assigment must be something other byt preferably not much distant 
to = maybe just slightly better - this user janis posted this sign and i 
checked it looks ok so as for now imo its the best set as for the moment

[toc] | [prev] | [next] | [standalone]

#401862

fir pisze:
> fir pisze:>>>>
>  >>>> AS FOR NOW ≔ IS A WINNER (applause)
>  >>>>
>  >>>
> this applaus above i said a bit ironically/distancebecouse its a tiny 
> thing, hovever it was long time to
> think about this "= ==" problem ;c
> 
> imo to get to conclusions you need some steps and for
> me some step was noticing equality must be =
> (i forgot at the moment sadly by what ocasion i noticed it)
> (maybe i will recall later, coz i know there was soem occasion)
> if so assigment must be something other byt preferably not much distant 
> to = maybe just slightly better - this user janis posted this sign and i 
> checked it looks ok so as for now imo its the best set as for the moment


i dont know if that was the case (probbaly no) when i noticed tah single 
& is mucch better than &&

dog & cat has some meaning and dog && cat is so much bad as a==2

may also not e that | as or is also not much fortunate imo

this | look good as some operator for vector elements 1|2|3 or lists 
maybe, here looks great x|y = foo a|b|c so meybe it should be used 
instead of , in part of cases but not ofr "or"

not sure if for all "," cases but maybe only some for example
if foo takes 3 arguments

foo a b c

thse arguments will not create vector byt maybe more like ad hoc 
structure and \ should be maybe reserved for plain vectors

foo x|y - woud mean take a structure-vector of say two ints where
foo x y maybe take int and int as loose arguments

maybe that is good way to think

if so or neds another sign maybe \ is closed for or

a\b\d   //a or b or c

[toc] | [prev] | [next] | [standalone]

#401863

fir pisze:
> fir pisze:
>> fir pisze:>>>>
>>  >>>> AS FOR NOW ≔ IS A WINNER (applause)
>>  >>>>
>>  >>>
>> this applaus above i said a bit ironically/distancebecouse its a tiny 
>> thing, hovever it was long time to
>> think about this "= ==" problem ;c
>>
>> imo to get to conclusions you need some steps and for
>> me some step was noticing equality must be =
>> (i forgot at the moment sadly by what ocasion i noticed it)
>> (maybe i will recall later, coz i know there was soem occasion)
>> if so assigment must be something other byt preferably not much 
>> distant to = maybe just slightly better - this user janis posted this 
>> sign and i checked it looks ok so as for now imo its the best set as 
>> for the moment
> 
> 
> i dont know if that was the case (probbaly no) when i noticed tah single 
> & is mucch better than &&
> 
> dog & cat has some meaning and dog && cat is so much bad as a==2
> 
> may also not e that | as or is also not much fortunate imo
> 
> this | look good as some operator for vector elements 1|2|3 or lists 
> maybe, here looks great x|y = foo a|b|c so meybe it should be used 
> instead of , in part of cases but not ofr "or"
> 
> not sure if for all "," cases but maybe only some for example
> if foo takes 3 arguments
> 
> foo a b c
> 
> thse arguments will not create vector byt maybe more like ad hoc 
> structure and \ should be maybe reserved for plain vectors
> 
> foo x|y - woud mean take a structure-vector of say two ints where
> foo x y maybe take int and int as loose arguments
> 
> maybe that is good way to think
> 
> if so or neds another sign maybe \ is closed for or
> 
> a\b\d   //a or b or c
> 
> 
well maybe in fact a|3|2 may be a structure where a 3 2 represent 3 values

im not sure how it can be fit in c semantics maybe foo 1|2|3
should pass one pointer to 1|2|3 structure where foo 1 2 3 whould pass 3
values (not sure though bcouse passing one pointer could evetually show 
to be more eficien than soem syntax would end in being unused thus wasted

[toc] | [prev] | [next] | [standalone]

#402090

On Wed, 9 Sep 2026 23:44:48 +0100, bart wrote:

> It does work, but I have to use Notepad to view it

Aren’t you using an OS (Windows NT) which was just about the first to
embrace Unicode right into its core APIs, back in 1993?

The fact that it still doesn’t make it easy for you to work natively
with Unicode text ... just a teentsy weentsy bit of an irony there,
don’t you think?

[toc] | [prev] | [next] | [standalone]

#401711

Janis Papanagnou pisze:
> On 2026-09-07 21:21, David LaRue wrote:
>> fir <profesor.fir@gmail.com> wrote in news:117mfle$3aage$1@dont-email.me:
>>
>>> im not sure if in usenet message i am able to draw it but maybe put it
>>> in some editor that has font where chars are same size
>>>
>>> .................
>>> .................
>>> .................
>>> ..*************..
>>> ..*************..
>>> .................
>>> .................
>>> ..*************..
>>> ..*************..
>>> ..**.............
>>> ..**.............
>>> .................
>>>
>>>
>>> it is like = but with some small line, suggestin it is for assign not 
>>> for
>>> equality,,, asci dont have it more worse im not sure if even unicode has
>>> it and this is shocking
> 
> I'm lacking context why you need that, for what you need that, what it
> is supposed to mean - differentiate assignment from equality; is that
> what you tried to express? - and why it's non-existence is "shocking".
> 


i make some deductions about C (im not sure if i can it deduction here 
but it is thinking with yeald to quite grounded conclusions (i find it 
almost scientific - in some way)

some time ago (not even so long it was probably like i was lats time 
visiting this group) i concluded that if(a==3) is wrong and it seems
one and only proper way here is   if(a=3) it means = may be for 
comparison, not for assigment

THUS you need something for assigment and from traditional reasons it 
should be (probably ) close to = and more like in direction to <- but 
not so far (being in traditionalist spirit here)

THUS i think it should be something like i drawed here and its realy 
WEIRD there is no so sign in ascii/unicode as if some think  this kind 
of char suggests itself

the link you give found something like that

a⥫2

its close but = ⥫ what i need should be more like = and this small 
addon/tail also should be slightly more visible..though  this "Leftwards 
harpoon with barb down below long dash" (0x296b) in fact is not totally 
teriible
but probably depending on font.. in editor i use now notepad++ and 
lucida console it not renders





> To find characters by a (hand-painted) glyph you can use this service:
> https://shapecatcher.com/
> 
> If you dislike C's '==' for equality, and '=' for assignment, so much
> that you continue your whining and get even mentally shocked I affirm
> the previously given suggestion to just switch language (and newsgroup).
> 
> (There's many other languages that made (IMO) better choices than "C"
> concerning these operators/operations. Often there's ':=' used for the
> assignment and '=' for equality. Or there's context dependent parsing
> and interpretation of the '=' symbol.)
> 
> It's your choice.
> 
> Janis
> 
> BTW, I see that in Unicode there seems to be "Colon equals" '≔'
> (Unicode hexadecimal: 0x2254, In block: Mathematical Operators),
> which resembles the common two-character assignment symbol ':=',
> but depending on the font it's hard to recognize. - And it's not
> common or guaranteed that languages support Unicode characters,
> let alone as part of the basic language definition.
> 
>>>
>>
>> C doesn't use that character.  Adapt to whatever language you want to 
>> use.
>>
>> You might look at a Forth system and see if you can define the meaning of
>> that symbol to do what you want.  Forth allows you to do things like 
>> that.
> 

[toc] | [prev] | [next] | [standalone]

#401713

On 08/09/2026 10:56, fir wrote:
> Janis Papanagnou pisze:
>> On 2026-09-07 21:21, David LaRue wrote:
>>> fir <profesor.fir@gmail.com> wrote in news:117mfle$3aage$1@dont- 
>>> email.me:
>>>
>>>> im not sure if in usenet message i am able to draw it but maybe put it
>>>> in some editor that has font where chars are same size
>>>>
>>>> .................
>>>> .................
>>>> .................
>>>> ..*************..
>>>> ..*************..
>>>> .................
>>>> .................
>>>> ..*************..
>>>> ..*************..
>>>> ..**.............
>>>> ..**.............
>>>> .................
>>>>
>>>>
>>>> it is like = but with some small line, suggestin it is for assign 
>>>> not for
>>>> equality,,, asci dont have it more worse im not sure if even unicode 
>>>> has
>>>> it and this is shocking
>>
>> I'm lacking context why you need that, for what you need that, what it
>> is supposed to mean - differentiate assignment from equality; is that
>> what you tried to express? - and why it's non-existence is "shocking".
>>
> 
> 
> i make some deductions about C (im not sure if i can it deduction here 
> but it is thinking with yeald to quite grounded conclusions (i find it 
> almost scientific - in some way)
> 
> some time ago (not even so long it was probably like i was lats time 
> visiting this group) i concluded that if(a==3) is wrong and it seems
> one and only proper way here is   if(a=3) it means = may be for 
> comparison, not for assigment

It IS wrong in my view, but the fact is that most languages now use '=' 
for assignment, and those using C-like syntax use '==' for equality.

C is obviously never going to change, but some languages do still use 
'=' for equality, and for assignment they might use any of:

   :=
   <-
   ->
   =       (when assignments are not allowed in expression)

A few might use a quite different syntax (eg. Lisp or COBOL).

Using an obscure, hard to see and hard to type symbol like ⥫ is not 
practical.

(I use '=' for equality, ':=' for runtime assignment, but I also use '=' 
for compile-time assignments and identities, since there is no ambiguity.)

Of course this might all be irrelevant in a couple more years when 
everyone uses tools to write code for them.

[toc] | [prev] | [next] | [standalone]

#401714

bart pisze:
> On 08/09/2026 10:56, fir wrote:
>> Janis Papanagnou pisze:
>>> On 2026-09-07 21:21, David LaRue wrote:
>>>> fir <profesor.fir@gmail.com> wrote in news:117mfle$3aage$1@dont- 
>>>> email.me:
>>>>
>>>>> im not sure if in usenet message i am able to draw it but maybe put it
>>>>> in some editor that has font where chars are same size
>>>>>
>>>>> .................
>>>>> .................
>>>>> .................
>>>>> ..*************..
>>>>> ..*************..
>>>>> .................
>>>>> .................
>>>>> ..*************..
>>>>> ..*************..
>>>>> ..**.............
>>>>> ..**.............
>>>>> .................
>>>>>
>>>>>
>>>>> it is like = but with some small line, suggestin it is for assign 
>>>>> not for
>>>>> equality,,, asci dont have it more worse im not sure if even 
>>>>> unicode has
>>>>> it and this is shocking
>>>
>>> I'm lacking context why you need that, for what you need that, what it
>>> is supposed to mean - differentiate assignment from equality; is that
>>> what you tried to express? - and why it's non-existence is "shocking".
>>>
>>
>>
>> i make some deductions about C (im not sure if i can it deduction here 
>> but it is thinking with yeald to quite grounded conclusions (i find it 
>> almost scientific - in some way)
>>
>> some time ago (not even so long it was probably like i was lats time 
>> visiting this group) i concluded that if(a==3) is wrong and it seems
>> one and only proper way here is   if(a=3) it means = may be for 
>> comparison, not for assigment
> 
> It IS wrong in my view, but the fact is that most languages now use '=' 
> for assignment, and those using C-like syntax use '==' for equality.
> 
> C is obviously never going to change, but some languages do still use 
> '=' for equality, and for assignment they might use any of:
> 
>    :=
>    <-
>    ->
>    =       (when assignments are not allowed in expression)
> 
> A few might use a quite different syntax (eg. Lisp or COBOL).
> 
> Using an obscure, hard to see and hard to type symbol like ⥫ is not 
> practical.
> 
> (I use '=' for equality, ':=' for runtime assignment, but I also use '=' 
> for compile-time assignments and identities, since there is no ambiguity.)
> 
> Of course this might all be irrelevant in a couple more years when 
> everyone uses tools to write code for them.


well of course when i say on c here i mix two separate cases

1) one is whan can be in fact changed in c (like the list of annoances 
was in thic category, becouse there also are possible addons to c but it 
would change it so much it wouldnt be quite c so this would be in second 
category)


2) the one that is based on C ideas but the conclusions deduced from c 
ideas would make practically different language


the new sign i talk eventually even could be added maybe to old c
but indeed unlikely..so maybe what i say here is around the second 
category (it is on c ideas)


AS i said i personally think old c should not change and what thic c 
comitee is doing is probably mostly wrong..i think though they should
even revert some changes back - but some of this annoyances i mentioned 
they really could add to c (like this seeing down symbols and ad hoc 
enum tags especially - or at least allow 64 bit tags ('dEf3effe' etc) )

SO I MIX THIS ABOVE TWO CATEGORIES but it would be inpractical to each 
time talk clearly on which category im talking, so i skip it as
some my himself guess what would be practical in old ca nad what not


as to non practicality imo in new co some could in fact do some 
remapping of keywoard and add some new chars like in control+key or 
alt+key becouse overally you need more chars for operators in new modern 
language imo

obviously there could be no compromises in new language ;c

[toc] | [prev] | [next] | [standalone]

#401715

bart <bc@freeuk.com> writes:
[...]
> Using an obscure, hard to see and hard to type symbol like ⥫ is not
> practical.

Agreed.  (That's U+296B, LEFTWARDS HARPOON WITH BARB DOWN BELOW LONG DASH).

fir doesn't write coherently enough to know what he's suggesting,
but there is some validity to the complaint that C's uses of "="
for assignment can be confusing.  But this will not change in any
language called "C" (or "C++", for that matter).

If I were creating a new language, I might use ":=" for assignment
and "==" for comparison.  I'd use "==" rather than "=" only to
cater to programmers accustomed to C and the languages it influences.
And I'd discuss that language elsewhere.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#401718

Keith Thompson pisze:
> bart <bc@freeuk.com> writes:
> [...]
>> Using an obscure, hard to see and hard to type symbol like ⥫ is not
>> practical.
> 
> Agreed.  (That's U+296B, LEFTWARDS HARPOON WITH BARB DOWN BELOW LONG DASH).
> 
> fir doesn't write coherently enough to know what he's suggesting,
> but there is some validity to the complaint that C's uses of "="
> for assignment can be confusing.  But this will not change in any
> language called "C" (or "C++", for that matter).
> 
> If I were creating a new language, I might use ":=" for assignment
> and "==" for comparison.  I'd use "==" rather than "=" only to
> cater to programmers accustomed to C and the languages it influences.
> And I'd discuss that language elsewhere.
> 

you would but im not "standard freak"..c is abous standard bout also 
about c ideas (if ther real quality od c becouse i agree some may have 
inferior ideas which they only glue to c to get an attention)..
its also about c programming, c culture and so on

for me if there were two goups , ona about standard and aone anout ideas 
the one about standard would be wuite dead for me (i maybe wrote there 
once a few years, ) and this one about good ideas quite alive ;c

[toc] | [prev] | [next] | [standalone]

#401730 — = vs. == (again!) (Was: c needs this sign)

In article <117ophj$3il1$1@kst.eternal-september.org>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
...
>If I were creating a new language, I might use ":=" for assignment
>and "==" for comparison.  I'd use "==" rather than "=" only to
>cater to programmers accustomed to C and the languages it influences.
>And I'd discuss that language elsewhere.

Note that another way to solve this problem is simply to not allow
assignments to be expressions.  This has been suggested at various times in
the past on this newsgroup.

The fact that assignments are expressions is one of the nifty features of C
(and C-like) language(s) and allows for nifty, clever, compact code that is
dazzling to the eye (and confusing to the newbie).  A double win.

But if you require assignments to be parsed as statements rather than as
expressions, then you can use = for both operations.  E.g.,

    if (a = b)

has to mean compare a and b, since it can't be an assignment.

BASIC is an example of such a language.

-- 
Politics is show business for ugly people.

Sports is politics for stupid people.

[toc] | [prev] | [next] | [standalone]

#403177 — Re: = vs. == (again!) (Was: c needs this sign)

gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <117ophj$3il1$1@kst.eternal-september.org>,
> Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
> ...
>
>> If I were creating a new language, I might use ":=" for assignment
>> and "==" for comparison.  I'd use "==" rather than "=" only to
>> cater to programmers accustomed to C and the languages it influences.
>> And I'd discuss that language elsewhere.
>
> Note that another way to solve this problem is simply to not allow
> assignments to be expressions.  This has been suggested at various
> times in the past on this newsgroup.
>
> The fact that assignments are expressions is one of the nifty
> features of C (and C-like) language(s) and allows for nifty,
> clever, compact code that is dazzling to the eye (and confusing
> to the newbie).  [...]

They also can be used in ways that are straightforward, not hard
to understand, and not confusing to new programmers.  Like most
aspects of programming languages, using assignment expressions
effectively requires a certain amount of taste and good judgment.
If every potentially confusing language feature were thrown out
there would be almost nothing left.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web