Proposal for built-in string equate: $PERL

[Egbert Zijlema]

I met this problem last night. Had a function, returning a string. That string happened to be the end of both, a sentence and a line. So I needed to write a period plus a carriagereturn/linefeed. My 2 alternatives were:

CHR$(46) & $CRLF

or

CHR$(46, 13, 10)

This is very annoying when your output contains 10 or even more of such lines. Therefore I propose a new built-in string equate: $PERL (PEriod -Return - Linefeed) as a user-friendly alternative for CHR$(46, 13, 10).

[Michael Mattias]

Therefore I propose a new built-in string equate: $PERL (PEriod -Return - Linefeed) as a user-friendly alternative for CHR$(46, 13, 10).

??

$PERL = CHR$(46,13,10)

.. 
   PRINT #hFile, Z$; 
   PRINT #hFile, $PERL; 
...

????

MACRO PrintwithPerl (h, S)  =  PRINT #h, S & CHR$(46,13,10)

...
 PrintWithPerl (hfile, Z$)

(I must be missing something).

[Egbert Zijlema]

Of course, you can create it yourself. See, for instance, my renewed "Holidays code" in the Source Code Forum. But that's not what I mean. PBWin has built-in equates, such as $TAB, $CRLF etcetera (see: Helpfile, Programming Reference, Data Types, Constants, Built-in string equates). Well, I propose the Power Basic folks to add $PERL to that list.

[Michael Mattias]

Oh. I see.

Which is not the same as "I understand your need and second your suggestion" because I don't.

[Richard Angell]

The built-in string equates cover typical single character control codes. The exception being $CRLF, which is $CR + $LF equates. So I'd agree with Michael that the best route is defining your own equate or MACRO. Since PB supports program templates now this is pretty easy to add to your own special template which you would use to start a progam that needs that particular combination.

[Greg Turgeon]

Huh?

With 8.04/4.04, defining $PERL = CHR$(46,13,10) works just fine.

So we need yet another built-in string equate--why?

[Egbert Zijlema]

Okay, delete the existing ones.

With 8.04/4.04, defining $PERL = CHR$(46,13,10) works just fine. So we need yet another built-in string equate--why?

Why not? Defining $CRLF = CHR$(13, 10) would also work fine (if it weren't already present). And all the others would, I assume. So, if that is a reason to have no built-in string constants, I'd suggest to demolish the existing ones as well.

[Tonny Bjorn]

Egbert,

I want to join in here.

First of all "$PERL" is misleading as a name. I program in Perl as well and this equate name just makes me think in other directions. Anyway, that could be easily solved by changing the name.

$CRLF, $CR, $LF is commonly used equates in basically all aspects of programming where strings are involved. They give easily readable info on what is added/send/used. So they should of course be included. To be honest I have never (to date anyway) had the use for CHR$(46,13,10). And If i did I would follow one of Michael's suggestions.

Regards,
Tonny