Disallow use of '$' when it isn't part of a variable name

[MachineCode]

I would get a step futher and allow '$' as the part of a procedure names, if it's returning a Strings! But I guess this is not going to come.

You can already do that! Just use either "Procedure.s MyProc()" or "Procedure$ MyProc()".

[Demivec]

I would get a step futher and allow '$' as the part of a procedure names, if it's returning a Strings! But I guess this is not going to come.

You can already do that! Just use either "Procedure.s MyProc()" or "Procedure$ MyProc()".

Your suggestion is incorrect. The '$' doesn't become part of the name, if it did then 'Procedure$ MyProc()' would require you to use 'MyProc$()' when calling the procedure.

That was the point of my feature request to disallow specifying '$' as a type because it doesn't become part of the actual name of a variable or procedure.

[MachineCode]

Your suggestion is incorrect.

I misunderstood what was being asked. My bad.

[NicknameFJ]

(...) it doesn't become part of the actual name of a variable (...)

Hello Demivec,

it is part of the variable name:

You can use

Code: Select all

This.s = "Test"
debug This

and it will show "Test" because This.s and This is the same variable.

But you can not use

Code: Select all

That$ = "Test"
debug That

it will show nothing (ok it shows 0, the value of the intaeger variable) because That$ and That is not the same variable.

Look here (from the german offline help file - sorry for german in the forum)

Schreibweise von String-Variablen: es ist möglich, '$' als letztes Zeichen eines Variablennamens zu verwenden, um die Variable als String zu kennzeichnen. Auf diesem Weg können Sie 'a$' und 'a.s' als zwei unterschiedliche String-Variablen verwenden. Bitte beachten Sie, dass das '$' zum Variablennamen gehört und immer hinzugefügt werden muss, während das '.s' nur beim ersten Deklarieren der String-Variable benötigt wird.

NicknameFJ

[Demivec]

it is part of the variable name

@NicknameFJ: This was the reason for my request.

From what I understood, using '$' as the last character of a variable name made it a string and it was required that it be included each time the variable was used (as part of the name).

The language allows for a type to be specified as '$' without the '$' being attached to a variable (or procedure) name. That just seems to be a little confusing with regard to making the syntax more consistent.

I know the simple solution is to simply not use it and I never have. It still seems strange that it would be permitted.

It seems Fred doesn't favor the idea of making any changes in this regard so I guess it will hang around as a quirky part of the language. There are other quirks still lingering as well, one of these is allowing pointers to have a native type specified instead of a structure (i.e. *ptr.w, *ptr.s, or even *ptr$ ).

[Fred]

There are other quirks still lingering as well, one of these is allowing pointers to have a native type specified instead of a structure (i.e. *ptr.w, *ptr.s, or even *ptr$ ).

This one will be removed in the next version.

[Demivec]

There are other quirks still lingering as well, one of these is allowing pointers to have a native type specified instead of a structure (i.e. *ptr.w, *ptr.s, or even *ptr$ ).

This one will be removed in the next version.

I'm glad to hear that. Thanks for the heads up.

[skywalk]

There are other quirks still lingering as well, one of these is allowing pointers to have a native type specified instead of a structure (i.e. *ptr.w, *ptr.s, or even *ptr$ ).

This one will be removed in the next version.

Hi Fred,
Do you mean only the *ptr.s or *p.s will be removed?
Please don't change the remaining native data type decorations, *ptr.d, *ptr.u, etc.
I have many many Prototypes that would need changing otherwise.
And these are very helpful to keep code lines short and meaningful for documentation.

Code: Select all

Prototype PtrNoInfo(*p)                 ;<-- OK but not helpful with documentation
Prototype PtrToNativeD(*p.d)            ;<-- OK and helps identify parameter type
Prototype PtrToStrucDouble(*p.Double)   ;<-- OK but much more to type and makes for really long lines :(
Procedure PtrNoInfo(*p)
  PokeD(*p,2 * PeekD(*p))
EndProcedure

Procedure PtrToNativeD(*p.d)
  PokeD(*p,2 * PeekD(*p))
EndProcedure

Procedure PtrToStrucDouble(*p.Double)
  ;PokeD(*p,2 * PeekD(*p))
  *p\d * 2                              ;<-- Alternative use
EndProcedure

Define.d x
Define *pp.PtrNoInfo = @PtrNoInfo()
Define *p.d = @x                        ;<-- OK, and less typing than *p.Double
;Define *p.Double = @x                  ;<-- OK
;Define *p.Byte = @x                    ;<-- Also works, but not helpful with documentation
Debug "-- Using PtrNoInfo(*p) --"
x = #PI
Debug "x = " + StrD(x,2)
PtrNoInfo(*p)
Debug "x = " + StrD(x,2)
Debug "-- Using PtrToNativeD(*p.d) --"
x = #PI
Debug "x = " + StrD(x,2)
PtrToNativeD(*p)
Debug "x = " + StrD(x,2)
Debug "-- Using PtrToStrucDouble(*p.Double) --"
x = #PI
Debug "x = " + StrD(x,2)
PtrToStrucDouble(*p)
Debug "x = " + StrD(x,2)
Debug "-- Using Prototype *pp.PtrNoInfo(*p) --"
x = #PI
Debug "x = " + StrD(x,2)
*pp(@x)
Debug "x = " + StrD(x,2)

[luis]

*p.d, *p.i, *p.f, etc. never meant something.
*p and any of the above pointers are all the same, a pointer to some memory address containing something not specified.

The need to keep them because they were used for self documenting purposes sounds a little weak to me, compared to their unreasonable existence in the first place. They have no use in the language.

*p.Double is something different, it's a pointer to a structure and makes sense, since you can access its field.

[Danilo]

It could be turned into a feature, just map the PureBasic basic types to the corresponding structures internally:
*p.a -> *p.Ascii
*p.c -> *p.Character
*p.i -> *p.Integer

This is most intuitive for many starters. 'var.i' is a basic type, '*p.i' is a pointer to basic type.
At the same time, if turned into a feature, it is readable and intuitive, shorter to write, and compatible to old versions.


The other thing:

Code: Select all

Procedure GetTitle$()
EndProcedure

would be nice, IMO. It says it returns a string and becomes part of the name (you have to always use GetTitle$() with the '$').
But for this point, it could be late to change it now because PB's string functions don't use it (Trim()/Trim$() etc..), which could be confusing.

[skywalk]

Hi luis,
I see no reason to complicate lives with this proposed change

Code: Select all

; FROM C
;;FN_ERROR _A_FUNC somedllfunction(FN_HANDLE handle,u32 nPts,f32 xdata[],f32 ydata[],f64 *res1,f64 *res2);
; TO PB
; 1 - preferred
PrototypeC.l somedllfunction(handle.l, nPts.i, *xdata.f,    *ydata.f,    *res1.d,     *res2.d)
; 2
PrototypeC.l somedllfunction(handle.l, nPts.i, *xdata,      *ydata,      *res1,       *res2)
; 3  -- Not sure if this one actually works for the *xdata pointing to an array of Float?
PrototypeC.l somedllfunction(handle.l, nPts.i, *xdata.Float,*ydata.Float,*res1.Double,*res2.Double)

All 3 PrototypeC definitions work, but I rely on AutoComplete to show me the various intended pointer data types and to not say it with dozens more characters. (

[netmaestro]

I rely on AutoComplete to show me the various intended pointer data types and to not say it with dozens more characters. (

Good point. Pointers qualified with unstructured native datatypes are meaningless and the fact that the compiler doesn't forbid them is a source of confusion, especially for someone trying to get a grip on the language. I'll be thrilled when Fred disallows them, I've always thought it should be done.

I think the mapping idea where '*ptr.l' would compile to '*ptr.Long' would be a mistake. 'l' is not the name of that structure and there are enough ways to get confused in coding without introducing another one.

[skywalk]

Yeah, I'm not too sure what Fred meant?
I think he will disallow *ptr.s or *ptr$ and I agree that is a good thing.
The decorated *ptr.i,*ptr.l,*ptr.w,etc. are in no way a hindrance or source of bugs and should NOT be disallowed.
Otherwise, I have to change a lot of code and lose AutoComplete self-documentation or worse be forced to add bogus commenting. Can't say it enough, please do no harm.

[netmaestro]

*ptr.i,*ptr.l,*ptr.w,etc. are in no way a hindrance

But what good do they do? Without a structure they are useless and a source of confusion because coders at earlier stages of learning will look at that and think it actually does something.

[skywalk]

Hi netmaestro,
I think I've said several times that *p.d is waaayyyy shorter than typing *p.Double.
And if I have 6 or more parameters in a long function call, it gets ridiculous with no line continuation.

Did you run my example code above?
;Define *p.d = @x ;<-- OK, and less typing than *p.Double
;Define *p.Double = @x ;<-- OK
Define *p.Byte = @x ;<-- Also works, but not helpful with documentation

Defining *p.Byte behaved identically? How is that for confusing?

If there is no speed improvement or bug fix involved in this pursuit, then it is only harmful to legacy code and a larger source of confusion. I cannot see the logic as presented.