If I recall correctly (it's been a while) a good way is to use Ada fixed-length strings wherever you can, and use something like Dmitry Kazakov's UTF-8 library in other places. People often use unbounded strings in places they don't need to instead of declaring a fixed-length string when it's needed.
Nice to see somebody's still using Ada. I gave up on it for new projects because of the lack of infrastructure and 3rd party libraries. It seems that half of comp.lang.ada consists of professionals from the aerospace and embedded systems industry and the other half are crackpots who want to create a Caesar cipher plus spam. It always looked like a weird community to me (but that has indirectly to do with how Adacore conduct their business).
> It always looked like a weird community to me (but that has indirectly to do with how Adacore conduct their business).
I don't know the community (or communities), but yeah, Adacore looks like a special beast. I saw a few discussions on their damn stringS, and lately a bit of discussion on array literals I believe, which left be rather sceptical.
I tried to use one of their languages, Parasail, and I couldn't. I tried to compile it, and failed, even after correcting a few layer of mistakes. Then I tried to use the binary, and only half of the proposed binary tools worked ; and I couldn't figure out how to use the working half to build/run a source file located outside of the compiler/interpreter archive tree...
And that was a version number 8.x, published after over 10 years of development... I just don't get it; I don't get how you can just dump something like that; I don't get how you haven't fixed problems known for years or that you'd encounter for sure if you only bothered to try to make a clean install on a fresh machine instead of dumping your working copy. Even getting the package was a pain for me, because it was hosted on a Google Drive (you don't even know it when you click because it is hidden behind a link shortener service! why? don't ask me), and none of the 3 browsers on my computer will display that damn site correctly, I had to fetch the package from another computer. Why can't they simply put their package on their webserver? It's not like it's ever going to be popular and generate lots of traffic with its single 50Mo zip :-)
I mean, I have zero love for the modern trends in development and methodology I meet a bit everywhere and which occupy a lot of threads and are often praised here, but this... this is extremely on the other end of the spectrum. It's like coming back to the bad practices of the DOS days (not even the good ones).
To be fair, Parasail is absolutely not a major focus for Adacore. I'm also pretty sure it's a personal project they picked up from a hire - but maybe don't quote me on that. I suspect it would end up 'odd' almost no matter which company had ended up picking it up.
That said, this is absolutely the kind of thing I kind of expect from Adacore. It's actually been getting better, but for a long time they didn't really care too much about this kind of stuff. A few folks at Adacore have picked up the cause recently though and things have been improving. But unfortunately cruft often doesn't go away so easily.
Interestingly I tried ParaSail just a few days ago.
Downloaded the src,
Followed instructions to make and the second attempt worked. (I got an error message about Gtk package linking, there is an option all-no-gtk or so for make and then it worked). This even on my Pinebook Pro with ARM processor on Armbian.
So if someone wants to try ParaSail, an interesting approach to have implicit (and explicit) parallelism in a programming language which also tries to be small (as in amount of language definitions and special cases) and readable language I would suggest to try.
I don't think I've ever seen anybody else suggest using fixed-length strings in place of unbounded strings. I don't think I'd suggest that either. It's like suggesting C++ folks use c-strings in favor of std::string if they can. Unless dynamic memory is a problem, why care?
I have only heard good things about Dmity Kazakov's library though, so if you need UTF-8 stuff, that would probably be the way to go.
I think, there are that same many ways to use Ada strings as C/C++. Ada and UTF-8 works very nice out of the box, it doesn't need any 3rd parties libraries (at least I never needed them and I use both each day :)).
Out of curiosity, what do you mean by "lack of infrastructure"? About 3rd party libraries, that's true, Ada is far behind more popular languages but due to it nice binding capabilities it is not a problem to use C or C++ libraries in the Ada projects.
About comp.lang.ada I can say too much, I don't spend much time there. To be honest I stopped using Usenet many years ago. Many people who can help you with Ada related problems are on Stack Overflow, Reddit or Gitter too. I think list here: https://github.com/ohenley/awesome-ada#Community is the best place to start to ask for help.
And about the language popularity: as for someone who is inside it, probably it looks for me too optimistic. :) But I think in the last few months Ada got a second (small, but second) chance.
Ada has made a pretty mess with strings. In the same family of languages, Pascal reached a similar mess. Early decisions which seemed nice and clever, but quickly turned out to be way too limitative, so they piled a series of other strings types upon it, each of them introducing small incompatibilities with others, or being somewhat clunky in a different way. That's something you often meet in the Pascal and Ada worlds (strings being archetypal of the phenomenon): stuff that was thought to be clean/nice/smooth/safe/practical but turned out differently, and various extensions not very well thought which don't integrate very well or destroy the cleanness of the original design.
C strings, no matter how much people have complained about along decades (often quoting Pascal as a good counter-example!), were simple and versatile and thus could stand all usages without a change in the base principle (so other string types never took off).
> C strings, no matter how much people have complained about along decades (often quoting Pascal as a good counter-example!),
Because Pascal is a good counter-example to the awfulness of C strings.
I need to point to you that any strings in C is a potential buffer overflow. You can't use a string in C without introducing a potential security risk you will have to thoroughly check for. Ada gives you compile-time guaranties.
> C strings, no matter how much people have complained about along decades (often quoting Pascal as a good counter-example!), were simple and versatile and thus could stand all usages without a change in the base principle (so other string types never took off).
C strings are not so much versatile that they are not actually strings (as usual in C). They are raw byte arrays (in so much as you can C arrays arrays) with a special termination code and UTF-8 took care of staying compatible with this representation.
Why do you think I am not aware of those points? Those complaints have been made a million times. Yes, C is not a memory safe language and you may run into trouble if you don't use stdlib string functions properly or hand-manage characters without paying attention to the termination and the reserved space, we know it.
I am talking about the mess of the evolution of strings in the Pascal family. There was, and there isn't any such mess in the C world. That's a fact that cannot be disputed. Of course it is because C strings are extremely simple, and as such didn't have to suffer the superiorly intelligent design of Pascal strings and their original limitation to 256 characters and their incompatible indexing with arrays.
You can't seriously keep on talking about the "terrible design" of C-strings when you put Ada and Pascal in front of it. Any other language, yes. Not Pascal and Ada.
These are the string types in Pascal: Array of Char, PChar, String, ShortString, AnsiString, WideString, UnicodeString. I probably forget a few, and then there are aliases which may or may not be the alias of this or that other type depending on compilation. Compatibility and automatic conversions between those vary. There are many ways to shoot yourself in the foot with those. Some have remained 1-based indexed to keep indexing compatibility with original strings despite the fact that it doesn't make sense any more (there wasn't a good option to pick: either you were consistent with original strings or you were consistent with other arrays and the new string implementation). Some are 0-based to interact with real world.
In Ada, you have a bit fewer types (String, Bounded_String, Unbounded_String, I'll spare you the Wide_ versions), but manipulation is more difficult than in Pascal (and conversions are of course the Ada way : heavily verbose). Not sure if it is still the case, but there wasn't the same display of functions provided for each string type, so you'd convert and convert and convert. And even Unbounded_String is often not versatile enough.
I'm really not fond of string handling in Ada, but I can't imagine seriously arguing that C-strings are better.
Ada strings can be a pain to work with - but that's basically just my problem. And I haven't found it to be all that terrible, actually. Use unbounded strings. Don't mix fully-specified string types. There's even some fairly common styles for shorthands, like the unary '+' for unbounded conversions.
It's not great, but it's pretty fine. I don't do so much string manipulation that it's a huge deal. Most all problems will be caught at compile time. Things like the OP are pretty much all taken care of by simply not mixing fully specified string types.
And even if you do do it, the worst that'll happen is an exception. That's it. Meanwhile, try misusing a C-string. If you don't get to enjoy trying to track down that problem from all the strange problems it causes, somebody else will be glad to gleefully use it to exploit your program.
Ada strings are annoying to you, but they won't cause massive problems - either for you or your users. You cannot say the same for C-strings. I'll take a bit of easily solved bother over trying to debug buffer overruns or massive security problems.
> You can't seriously keep on talking about the "terrible design" of C-strings when you put Ada and Pascal in front of it.
Of course I can. I have used Ada strings extensively. As long as you don't mix bounded and unbounded strings too much (unbounded should be avoided anyway) it's mostly fine.
> Yes, C is not a memory safe language and you may run into trouble if you don't use stdlib string functions properly or hand-manage characters without paying attention to the termination and the reserved space, we know it.
As far as I'm concerned, that automatically puts C as pretty much the worst you can do regarding strings handling. Even the most misguided attempt to improve on that should be (and have been) an improvement.
> C strings, no matter how much people have complained about along decades (often quoting Pascal as a good counter-example!), were simple and versatile and thus could stand all usages without a change in the base principle (so other string types never took off).
Except that there are no string type in C. So talking about C strings is a bit disingenuous. And C has the exact same problems as Ada where people implement their own flavor of string libraries and functions all the time, all incompatible.
What a lot of people don't understand is the reason that Ada has so many string-types, and the answer is pretty simple: usage.
Fixed: The simple string-as-an-array approach.
Bounded: The maximum, but variable-size approach; analogous to many database string-field data-definitions.
Unbounded: The variable-at-runtime approach.
You can generally use the Fixed form for your operations, thanks to the String-array being unbounded, and having functions returning your perfectly-sized results.
My biggest issue with the Strings packages are the [[Wide_]Wide_]String hierarchy: I would have much rather had this be a set of instantiated generics with the appropriate parameters (eg passing in a CHARACTER type and UPPERCASE/LOWERCASE functions, etc)... but doing that would have required redesigning the STRINGS package back at the Ada95 era.
17 comments
[ 5.0 ms ] story [ 65.0 ms ] threadNice to see somebody's still using Ada. I gave up on it for new projects because of the lack of infrastructure and 3rd party libraries. It seems that half of comp.lang.ada consists of professionals from the aerospace and embedded systems industry and the other half are crackpots who want to create a Caesar cipher plus spam. It always looked like a weird community to me (but that has indirectly to do with how Adacore conduct their business).
I don't know the community (or communities), but yeah, Adacore looks like a special beast. I saw a few discussions on their damn stringS, and lately a bit of discussion on array literals I believe, which left be rather sceptical.
I tried to use one of their languages, Parasail, and I couldn't. I tried to compile it, and failed, even after correcting a few layer of mistakes. Then I tried to use the binary, and only half of the proposed binary tools worked ; and I couldn't figure out how to use the working half to build/run a source file located outside of the compiler/interpreter archive tree...
And that was a version number 8.x, published after over 10 years of development... I just don't get it; I don't get how you can just dump something like that; I don't get how you haven't fixed problems known for years or that you'd encounter for sure if you only bothered to try to make a clean install on a fresh machine instead of dumping your working copy. Even getting the package was a pain for me, because it was hosted on a Google Drive (you don't even know it when you click because it is hidden behind a link shortener service! why? don't ask me), and none of the 3 browsers on my computer will display that damn site correctly, I had to fetch the package from another computer. Why can't they simply put their package on their webserver? It's not like it's ever going to be popular and generate lots of traffic with its single 50Mo zip :-)
I mean, I have zero love for the modern trends in development and methodology I meet a bit everywhere and which occupy a lot of threads and are often praised here, but this... this is extremely on the other end of the spectrum. It's like coming back to the bad practices of the DOS days (not even the good ones).
That said, this is absolutely the kind of thing I kind of expect from Adacore. It's actually been getting better, but for a long time they didn't really care too much about this kind of stuff. A few folks at Adacore have picked up the cause recently though and things have been improving. But unfortunately cruft often doesn't go away so easily.
ParaSail author was already working on it before being hired by Ada Core.
So if someone wants to try ParaSail, an interesting approach to have implicit (and explicit) parallelism in a programming language which also tries to be small (as in amount of language definitions and special cases) and readable language I would suggest to try.
Brand new discussion room here: https://gitter.im/parasail-lang/community (Gitter / Matrix )
I have only heard good things about Dmity Kazakov's library though, so if you need UTF-8 stuff, that would probably be the way to go.
https://alire.ada.dev/
Out of curiosity, what do you mean by "lack of infrastructure"? About 3rd party libraries, that's true, Ada is far behind more popular languages but due to it nice binding capabilities it is not a problem to use C or C++ libraries in the Ada projects.
About comp.lang.ada I can say too much, I don't spend much time there. To be honest I stopped using Usenet many years ago. Many people who can help you with Ada related problems are on Stack Overflow, Reddit or Gitter too. I think list here: https://github.com/ohenley/awesome-ada#Community is the best place to start to ask for help.
And about the language popularity: as for someone who is inside it, probably it looks for me too optimistic. :) But I think in the last few months Ada got a second (small, but second) chance.
C strings, no matter how much people have complained about along decades (often quoting Pascal as a good counter-example!), were simple and versatile and thus could stand all usages without a change in the base principle (so other string types never took off).
Because Pascal is a good counter-example to the awfulness of C strings.
I need to point to you that any strings in C is a potential buffer overflow. You can't use a string in C without introducing a potential security risk you will have to thoroughly check for. Ada gives you compile-time guaranties.
> C strings, no matter how much people have complained about along decades (often quoting Pascal as a good counter-example!), were simple and versatile and thus could stand all usages without a change in the base principle (so other string types never took off).
C strings are not so much versatile that they are not actually strings (as usual in C). They are raw byte arrays (in so much as you can C arrays arrays) with a special termination code and UTF-8 took care of staying compatible with this representation.
I am talking about the mess of the evolution of strings in the Pascal family. There was, and there isn't any such mess in the C world. That's a fact that cannot be disputed. Of course it is because C strings are extremely simple, and as such didn't have to suffer the superiorly intelligent design of Pascal strings and their original limitation to 256 characters and their incompatible indexing with arrays.
You can't seriously keep on talking about the "terrible design" of C-strings when you put Ada and Pascal in front of it. Any other language, yes. Not Pascal and Ada.
These are the string types in Pascal: Array of Char, PChar, String, ShortString, AnsiString, WideString, UnicodeString. I probably forget a few, and then there are aliases which may or may not be the alias of this or that other type depending on compilation. Compatibility and automatic conversions between those vary. There are many ways to shoot yourself in the foot with those. Some have remained 1-based indexed to keep indexing compatibility with original strings despite the fact that it doesn't make sense any more (there wasn't a good option to pick: either you were consistent with original strings or you were consistent with other arrays and the new string implementation). Some are 0-based to interact with real world.
In Ada, you have a bit fewer types (String, Bounded_String, Unbounded_String, I'll spare you the Wide_ versions), but manipulation is more difficult than in Pascal (and conversions are of course the Ada way : heavily verbose). Not sure if it is still the case, but there wasn't the same display of functions provided for each string type, so you'd convert and convert and convert. And even Unbounded_String is often not versatile enough.
Ada strings can be a pain to work with - but that's basically just my problem. And I haven't found it to be all that terrible, actually. Use unbounded strings. Don't mix fully-specified string types. There's even some fairly common styles for shorthands, like the unary '+' for unbounded conversions.
It's not great, but it's pretty fine. I don't do so much string manipulation that it's a huge deal. Most all problems will be caught at compile time. Things like the OP are pretty much all taken care of by simply not mixing fully specified string types.
And even if you do do it, the worst that'll happen is an exception. That's it. Meanwhile, try misusing a C-string. If you don't get to enjoy trying to track down that problem from all the strange problems it causes, somebody else will be glad to gleefully use it to exploit your program.
Ada strings are annoying to you, but they won't cause massive problems - either for you or your users. You cannot say the same for C-strings. I'll take a bit of easily solved bother over trying to debug buffer overruns or massive security problems.
Of course I can. I have used Ada strings extensively. As long as you don't mix bounded and unbounded strings too much (unbounded should be avoided anyway) it's mostly fine.
> Yes, C is not a memory safe language and you may run into trouble if you don't use stdlib string functions properly or hand-manage characters without paying attention to the termination and the reserved space, we know it.
As far as I'm concerned, that automatically puts C as pretty much the worst you can do regarding strings handling. Even the most misguided attempt to improve on that should be (and have been) an improvement.
Except that there are no string type in C. So talking about C strings is a bit disingenuous. And C has the exact same problems as Ada where people implement their own flavor of string libraries and functions all the time, all incompatible.
Fixed: The simple string-as-an-array approach. Bounded: The maximum, but variable-size approach; analogous to many database string-field data-definitions. Unbounded: The variable-at-runtime approach.
You can generally use the Fixed form for your operations, thanks to the String-array being unbounded, and having functions returning your perfectly-sized results.
My biggest issue with the Strings packages are the [[Wide_]Wide_]String hierarchy: I would have much rather had this be a set of instantiated generics with the appropriate parameters (eg passing in a CHARACTER type and UPPERCASE/LOWERCASE functions, etc)... but doing that would have required redesigning the STRINGS package back at the Ada95 era.