Re: [ANN] List_Image v0.2.0

[Lionel Draghi <lionel.draghi@gmail.com>]

Le vendredi 2 février 2018 01:02:08 UTC+1, Randy Brukardt a écrit :
> "Lionel Draghi"... wrote in message 
> ...
> >You missed my point, I don't want to limit vendors possibilities to Windows 
> >and Unix.
> >Defining a function, and let vendors specify what is returned on each 
> >platform would
> >be an acceptable choice (and almost as easy to implement than the useless 
> >System_Name).
> 
> What would such a function return on OpenVMS, which does not use a character 
> to mark New_Line??
> 
>                           Randy.

Randy, your're asking my compiler vendor opinion, I'll give it to you! :-) 

It's implementation defined! :-)
In the current version of my compiler on OpenVMS, the function returns "", and that it. 
But in the next version, I'll be smarter : I will return CRLF : if the goal is to scan a string where you have yourself inserted the sequence, and then call Put_Line when the sequence is met, it will works better :-). 
Obviously, users should be warned that string that already contains that sequence will be akwardly cut : i'll put it bold in the doc!
 
But seriously, that's an acceptable side effect, considering that most Ada users will never face it.  

----8<---- end of my compiler vendors carreer :-)

I am aware that there is no silver bullet at this level, because we are trying to manipulate multiple lines within a single String : "fatal conceptual constraint error will be raised here!".

The only good solution would be that my Image function returns, not a String, but a list of String, with no line terminator at all, and that generic parameters that are Strings also becomes list of String.

I have to check by trying to specify such an alternate generic, but I expect it will add a lot of complexity for a problem that rarely arise.
Interresting, never te less, and it smells good my favorite fragrance : "conceptual integrity" by Ada.

And what would be the type of that list, that should be simple, efficient and unbounded, sparkable, etc. Look's like we need a "Text" abstraction here (*).
And also another Signature package... 
Seem's to be a fun challenge, I'm on it! :-)

(*) After all, we have a Text_IO package since the origin of Ada, it's time to define what is a Text!