Recent

Author Topic: Immutable data types  (Read 9416 times)

Bogen85

  • Hero Member
  • *****
  • Posts: 595
Re: Immutable data types
« Reply #60 on: October 04, 2022, 04:55:21 pm »
So what's the difference between a typed constant and a var?

It's stored differently in the executable? Is faster? Is cool?

const parameters to functions and procedures are still local of course, unlike const in the declaration section.

Thaddy

  • Hero Member
  • *****
  • Posts: 14162
  • Probably until I exterminate Putin.
Re: Immutable data types
« Reply #61 on: October 04, 2022, 05:21:07 pm »
NO. That depends on J-/+. If {J+} is the case they are not stored local, but global, with the provision they are in local SCOPE.
Specialize a type, not a var.

Bogen85

  • Hero Member
  • *****
  • Posts: 595
Re: Immutable data types
« Reply #62 on: October 04, 2022, 05:39:53 pm »
NO. That depends on J-/+. If {J+} is the case they are not stored local, but global, with the provision they are in local SCOPE.

Are you saying that in an argument list
Code: Pascal  [Select][+][-]
  1. procedure some_proc (const a: integer; constref b: someRecordType);
that a and b are not always local to some_proc?

Of course the constref parameter as part of the caller's scope as well as far as access).
« Last Edit: October 04, 2022, 05:43:09 pm by Bogen85 »

Bogen85

  • Hero Member
  • *****
  • Posts: 595
Re: Immutable data types
« Reply #63 on: October 04, 2022, 05:54:44 pm »
NO. That depends on J-/+. If {J+} is the case they are not stored local, but global, with the provision they are in local SCOPE.

https://wiki.freepascal.org/$writableConst

I'm not referring to the const declaration section after the parameter list, which what {$J} seems to be for.

I'm talking about these: https://www.freepascal.org/docs-html/ref/refsu67.html
"In addition to variable parameters and value parameters Free Pascal also supports Constant parameters"
"Specifying a parameter as Constant is giving the compiler a hint that the contents of the parameter will not be changed by the called routine."

It would make little sense for those to be global or static.

« Last Edit: October 04, 2022, 06:01:21 pm by Bogen85 »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: Immutable data types
« Reply #64 on: October 04, 2022, 06:10:48 pm »
However i believe that XE3+ record helpers was abomination anyway. They failed to design proper changes to the compiler and to the type system, so they started to apply what were "ugly hacks for retroactively modifying with closed-source software" to the very foundaiton of RTL.

The opposite is accepting every suggested expansion, a disease that FPC suffers from. Everything in language design is a matter of balance. Quite often between usability in production and design purity

And the usability can be subdivided into various user classes (corporate vs SME)
« Last Edit: October 04, 2022, 06:20:51 pm by marcov »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: Immutable data types
« Reply #65 on: October 04, 2022, 06:22:50 pm »
So at the very least it's possible to say that there's precedent for having the IDE and compiler detect inconsistencies (and for LARTing students until they appreciate that the tools are trying to help rather than hinder).

Or you could see it as a case against using production tools for teaching.

We were pestered with Hatley-Pirbhai top down development (iirc partially because Phillips Medical heavily used it). Good exercise, but as methodology highly specialized, and pretty useless in daily practice where specs are rarely so fixed and up front.

In reality, the chance is higher that my boss tells me to send a customer something, and it turns out the specification process for what to send hasn't even started, and the intake was just the customer venting about his problems without much analysis.
« Last Edit: October 04, 2022, 06:28:31 pm by marcov »

circular

  • Hero Member
  • *****
  • Posts: 4181
    • Personal webpage
Re: Immutable data types
« Reply #66 on: October 05, 2022, 04:23:36 am »
const parameters to functions and procedures are still local of course, unlike const in the declaration section.
The names are local indeed. I suppose the location of the value can depend though if it is passed by reference or not (this is decided by the compiler or if you use constref keyword). If it is in fact a reference, it is like using the var keyword while avoiding to modify it.
Conscience is the debugger of the mind

circular

  • Hero Member
  • *****
  • Posts: 4181
    • Personal webpage
Re: Immutable data types
« Reply #67 on: October 05, 2022, 04:27:42 am »
If declared in a function it's persistent across function invocations. As such it behaves like a global variable but with limited scope.
So it is like the static keyword in C. Or the class var keywords in Pascal classes. I suppose we could call it function var ?
Conscience is the debugger of the mind

Bogen85

  • Hero Member
  • *****
  • Posts: 595
Re: Immutable data types
« Reply #68 on: October 05, 2022, 04:38:51 am »
const parameters to functions and procedures are still local of course, unlike const in the declaration section.
The names are local indeed. I suppose the location of the value can depend though if it is passed by reference or not (this is decided by the compiler or if you use constref keyword). If it is in fact a reference, it is like using the var keyword while avoiding to modify it.

Agreed. However, there is still "some" compile time enforcement with constref, as with const (with all the caveats already discussed).

Many would consider "some" compile time better than none (as I do), especially with the understanding of how the enforcement could be bypassed, so that this should not be considered the only thing to rely on when dealing with concurrency situations (and possibly some reentrancy situations as well).
« Last Edit: October 05, 2022, 04:43:45 am by Bogen85 »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Immutable data types
« Reply #69 on: October 05, 2022, 08:45:43 am »
So it is like the static keyword in C. Or the class var keywords in Pascal classes. I suppose we could call it function var ?

Generally speaking it would be referred to elsewhere in the industry as static. It's a slight extension of ALGOL own variables, since while typed they didn't have an initialiser.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: Immutable data types
« Reply #70 on: October 05, 2022, 08:55:47 am »
Borland Pascal allowed to write structured constants. Keep in mind that it was originally a 16-bit real mode compiler, and probably not as rigid due to memory limitations.

8-bit: it was in v3. "A typed constant may be used exactly like a variable of the same type".

I've got nothing against the concept, but continued use of the name in modes that don't claim to be 100% Borland-compatible is indefensible.

The concept doesn't differ between the modes and it needs some name. So it can just as well have the name from where it originated from: “typed constants”.

NO. That depends on J-/+. If {J+} is the case they are not stored local, but global, with the provision they are in local SCOPE.

const parameters are not governed by this switch.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Immutable data types
« Reply #71 on: October 05, 2022, 09:20:59 am »
If I want an immutable value, I use a read-only property. But considering this discussion, it seems that I don't get it. So why doesn't that work?

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Immutable data types
« Reply #72 on: October 05, 2022, 09:39:10 am »
If I want an immutable value, I use a read-only property. But considering this discussion, it seems that I don't get it. So why doesn't that work?

It's a comparatively new industry term, and represents a variable which may be written to (precisely) once.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Immutable data types
« Reply #73 on: October 05, 2022, 09:51:57 am »
It's a comparatively new industry term, and represents a variable which may be written to (precisely) once.

MarkMLl
Yes, I know. From functional languages, but different.

Like querying a read-only database: you can only create new values by mutating old ones. Like, a view with one or more calculated fields that reference other fields. Or, like Lisp.

Generally, if you have a read-only property, you set it once, in the constructor. The constructor has a formula to calculate it from other values. Once.

Sounds like the same thing to me.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: Immutable data types
« Reply #74 on: October 05, 2022, 09:57:57 am »
Yes, I know. From functional languages, but different.

Like querying a read-only database: you can only create new values by mutating old ones. Like, a view with one or more calculated fields that reference other fields. Or, like Lisp.

Generally, if you have a read-only property, you set it once, in the constructor. The constructor has a formula to calculate it from other values. Once.

Sounds like the same thing to me.

(Shrug) it's computersciency crap. However, I'd highlight the particular case of (the pointer to) (the object representing) a form as implemented by Lazarus: creation and initialisation are distinct, and should be allowed to happen once only.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018