|
YES !!!!
and as in :
if (ch in [A..Z,0..9])
as it is in Pascal.
|
|
|
|
|
I make a static Hashset for that (C#).
|
|
|
|
|
That's cool. The build-in contains/subset functions are native and fast.
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
Well, yes, but ... In all the Pascals I have been in touch with, it is implemented as a bit map. A few orders of magnitude lighter, I guess.
There are several other Pascal features I certainly would welcome in C#. Such as decent enumerations, as a first class data type - not just symbolic names for integers, that cannot even be used as integers! In particular: The enum we are offered cannot even be used as an array index type.
Closely related: I would welcome Pascal style subrange types. Define a type Year = 1900..2050, and assigning a value outside this range to a variable of type Year is caught by the runtime system (or the compiler, if it can be determined statically).
Related to this: An array with index type Year, so valid index values run from 1900 to 2050.
To go a little beyond Pascal: I wish we had a mechanism for defining incompatible types: If I could define 'new type Speed = float;' and 'new type Volume = float;', variables of type Speed and Volume would be incompatible, and the compiler would give an error if you try to add them (without a proper operator definition for the two types, or an explicit cast).
|
|
|
|
|
Oh, well, yeah, for individual (ASCII) characters a bitmap or similar may be best. I was thinking of a more general technique.
Edit: As in making a Hashset and putting various (UNICODE) quote characters or whitespace characters in it to test against.
Yes, there are many things Pascal does which are handy. But I haven't used Pascal in decades, not since learning C.
modified 2-Feb-23 9:47am.
|
|
|
|
|
Pascal had bitmaps as a first class type ('SET OF'), with operations for inserting and removing elements, intersection / union / difference operators and membership tests. I guess that the C code I have written for doing the same things were at least as efficient as the Pascal compiler could have done it (it probably would have added a lot of range tests), but I certainly have often missed the syntactic simplicity of Pascal for such operations!
|
|
|
|
|
I am rusty in C/C++, but thought typedef would do that for you in C and C++.
Need a cast to assign between the typedefs even if they are both native float.
|
|
|
|
|
Convert it to a function
In(var1, param1,…)
Or throw some functor at it like
In(var1)(param1,… )
Is(var1).in(param1…)
Could be a lot slower, though.
|
|
|
|
|
honey the codewitch wrote: What languages, wishlists do you have for your favorite programming languages? My daily drivers are TypeScript/ECMAScript (JavaScript). Since JS is now governed by ECMA, having a committee behind it is a great thing for helping the language to continue to mature in a reasonable way. So, my wish has been answered.
But, if I had to pick a wish-list for this ecosystem, it's less to do with the language and more to do with the developers. Despite this ecosystem finally starting to grow up, there are 10,000 packages to clip your toenails, for instance, and 99% of them aren't worth much. And despite the efforts of the language itself growing, due to the enormous popularity of JavaScript, there are still a ton of folks who pretend to know the language but are just script kiddies.
For those wondering why I didn't say something like TypeScript to WASM compilation.... there's already a project that does that with a subset of TS suitable for this.
Jeremy Falcon
modified 1-Feb-23 12:06pm.
|
|
|
|
|
C# -- Multiple inheritance.
And a C-Preprocessor which is more flexible, for use with things other than vanilla C.
I've wanted this since doing PRO*C back in the 90s.
|
|
|
|
|
PIEBALDconsult wrote: C# -- Multiple inheritance.
If you want C++, you have it. There were good reasons for including multiple inheritance in C++ at the time, and equally good reasons why C# and Java did not include it.
PIEBALDconsult wrote: And a C-Preprocessor which is more flexible, for use with things other than vanilla C.
Personally, I consider the C preprocessor in its current form to be poorly engineered. Because its definitions are global, the inclusion of a header file can totally change the semantics of a module. Yes, it has its uses, but on any large project it requires a lot of coordination to avoid definition clashes etc.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I'd like to have a language/IDE that can sense my mind, interpret what I want to accomplish, and generate the code required to fulfill my wish. Is that really too much to ask, in this era of AI domination?
Will Rogers never met me.
|
|
|
|
|
In R: A function that returns the path to where the R script was loaded from.
|
|
|
|
|
Is that really a language feature? I suppose it could be useful, but it sounds more like a library/OS feature.
|
|
|
|
|
There are setwd(path) and getwd(path) functions for setting the working directory (i.e. the folder from which any relative path would be rooted) but there is no way of finding out from where a script was loaded. That makes it cumbersome to distribute R scripts as an assemblage (e.g. a zip file) of interconnected R scripts and data files. The user must be instructed to call setwd(path) in the beginning of the main script with the folder of her choice. The same goes for yourself when you move your assemblage of R files from one folder to another; you always need to update the setwd(path) statement as well.
|
|
|
|
|
Sure, I see the usefulness. But I see it as a library extension, not as a language extension.
|
|
|
|
|
Oh, now I get it. You are right.
|
|
|
|
|
Not at all my favorite language, but I do wish that JavaScript could handle associative arrays (not objects) in foreach loops where keys and values could be easily accessed for each item in the array, and so that it could be done recursively. The workarounds for this are making me bug-eyed.
|
|
|
|
|
Cpichols wrote: I do wish that JavaScript could handle associative arrays (not objects) in foreach loops where keys and values could be easily accessed for each item in the array Most times people blame the language when it's really due to them not studying the language.
const data = [];
data['a'] = 200;
data['b'] = 300;
for (const datum in data) {
console.info(`${datum}: ${data[datum]}`);
}
Cpichols wrote: and so that it could be done recursively No language I've ever used does recursive traversing of objects automatically in a loop. Why would JavaScript be more difficult to understand?
Jeremy Falcon
|
|
|
|
|
Loop enhancements:
First iteration statements executed in loop context.
An optional 'break code' added to a 'break', to indicate why a loop is prematurely terminated
'Handlers' that executes in the context of the loop, for each break code. 'finally', like in exception handling.
E.g.:
for (record r = head; r; r = r.next) {
initloop: {
int iterationCount = 0;
record trailer = null;
int accumulated = 0;
}
...
if (++iterationCount > limit) break : GivingUp;
...
if (r.key == desiredKey) break : RecordFound;
...
trailer = r;
accumulated += r.value;
exitbreak (GivingUp): {
Console.WriteLine("Possible circular list: " + head.listname;
Console.WriteLine("Giving up after " + iterationCount + " iterations");
}
exitbreak (RecordFound): {
if (trailer == null) head = r.next;
else trailer.next = r.next;
r.sumOfPreceding = accumulated;
}
exitloop: {
Console.Writeline(desiredKey + " not found among " + iterationCount + " records");
}
finally: {
<actions executed in loop context regardless of exit reason>
}
} This would keep all the action related to the loop as one syntactical unit. It would reduce variable clutter for reporting the loop termination, and termination actions would have access to variables relevant to the loop alone.
The above actions, expressed without these enhancements, would require a handful of (loop) global variables, and the semantics would be spread out before the loop, in the loop and after the loop, not as one syntactical unit. Alternately, the loop body would have several if/else levels of nesting and it would be difficult to identify the exit actions as such.
|
|
|
|
|
switch( x, y, z )
{
case 1, 2, 3:
break;
etc.
}
|
|
|
|
|
CHILL has that. Or maybe I should say "had" - I don't know if anyone at all are using CHILL nowadays. We (i.e. Norway) used to have half of our land line phones handled by switches programmed in CHILL (ITT System 12 switches) but the land line phone system was closed down last newyear. Now only mobile phones and IP phones are left.
Maybe CHILL is where you take your proposal from. You present a simplified view: CHILL offered both '*' for Don't Care and ELSE for All other values than those mentioned explicitly in other switch alternatives.
CHILL has a few other properties that goes into my language feature wish list. It is a pity that it never caught on as a general language, it is really well designed. But noone worked for it - not even the creators of the language (The initial C is for CCITT, 'CCITT HIgh Level Language'. CCITT changed name to ITU-T many years ago.). They saw it as a good language for programming phone switches, and didn't care to consider the language for any other use.
|
|
|
|
|
C:
defer that works just like Go's deferAnonymous functions that don't mark the stack executable[1], so that defer is actually useful.
Replace #define with lisp-like macros (now in Nim as well, I believe)Lots more, just don't have the time.
[1] Current methods to do nested functions using compiler-specific extensions mark the entire stack as executable.
|
|
|
|
|
Java really needs typedef.
It could easily be restricted to final classes. Implement it via erasure like other Java generics.
typedef String InvoiceId;
|
|
|
|
|
C:
- A standard (and simple) way to declare a parameter (or local variable) as not-nullable. Clang supports such an extension, as does gcc (but in a less clean way). It would be better to have a portable tag to do it defined in the language standards. Honestly, this should have been done in back in C99, and would have probably stopped many bugs over the last decade or two.
- Variable value bound declarations. So if a parameter is declared unsigned int , but really only has a meaningful range of 0-100 , it could flag it during compile time that it is an error. Probably more useful to set reasonable bounds on items which could cause integer overflows (or static buffer overflows when still used due to legacy code).. For example:
typedef struct
{
int id;
char name[20];
} myrecord_t;
myrecord_t * alloc_list(__bound__(0, 10000000) unsigned int size)
{
return malloc(size * sizeof(myrecord_t));
}
void safecaller(__bound__(1, 100000) unsigned int size)
{
myrecord_t * list = alloc_list(size);
}
void badcaller(unsigned int size)
{
myrecord_t * list = alloc_list(size);
}
|
|
|
|