Recent

Author Topic: Multi-paradigm languages  (Read 2748 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Multi-paradigm languages
« on: April 07, 2021, 11:36:49 am »
I wonder whether I could float a general question about programming style etc., hoping to obtain comments from people with more of a "computer science" background than I have.

The teaching/research language Leda http://web.engr.oregonstate.edu/~budd/Books/leda/info/ https://github.com/Henry/Leda implements imperative, object-oriented, functional and logic programming styles with a Pascal-like foundation. The author is well-respected and has written books on Smalltalk, APL and other language implementations.

The derivative Cleda https://ir.library.oregonstate.edu/concern/parent/cz30pv05m/file_sets/np193b42g reimplements the logic paradigm as a relational paradigm, and adds constraint logic programming.

My suspicion is that to a very large extent Object Pascal could use functions with strongly-typed parameters of different types (polymorphic functions?) to achieve the same results, and if it were possible to define additional operators (i.e. as well as redefining existing ones) the programming style could be made very similar.

The Cleda paper includes this when describing shortcomings in Leda's implementation:

Quote
2.5.1... The keyword suspend is used to define a clause. It acts like the return statement, namely, it terminates the enclosed function, but it does not discard the stack frame, which are used later upon backtracking.

The keyword rel is used instead of var. If the actual parameter for a rel formal parameter is a variable, the reference to the variable is passed as the argument. Otherwise, a new variable is created, it gets the value of the actual parameter, and the reference to the new variable is passed as the argument. Thus, constants as well as variables can be passed as reference variables.

The keyword fail causes backtracking. The execution returns to the latest choice point, a sequence of the suspend statements.

Is that effectively describing something which would (or at least could) be implemented as a closure in more recent languages?

Can (the FPC dialect of) Object Pascal cope with something like

Code: Pascal  [Select][+][-]
  1. function unify(var mother: Tname; child: Tname): boolean;
  2. ...
  3. function unify(const mother: Tname; child: Tname): boolean;
  4.  

and if so is it possible to guarantee that the compiler will always check the suitability of the first of those before settling for the second?

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

glorfin

  • Full Member
  • ***
  • Posts: 148
  • LMath supporter
Re: Multi-paradigm languages
« Reply #1 on: April 07, 2021, 04:45:26 pm »
I understand that most important part is this:
Quote
It acts like the return statement, namely, it terminates the enclosed function, but it does not discard the stack frame, which are used later upon backtracking.
, and this is not easily implemented.

As for your question, well, you could use always typed constants, which are in fact initialized variables, and pass them always as var (or constref, if you do not want them to be modified by your function). Thus, you avoid necessity to have overloaded functions which differ only by const or var definitions.
By the way, I don't think it is a wonderful language design. More implicit conversions and polymorphic behavior, more difficult is to understand how program work and especially why does not it work.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Multi-paradigm languages
« Reply #2 on: April 07, 2021, 04:58:17 pm »
...and this is not easily implemented.

The paper later explains that activation information is held on the heap. I /think/ it's equivalent to a closure in modern terminology.

Quote
As for your question, well, you could use always typed constants, which are in fact initialized variables, and pass them always as var (or constref, if you do not want them to be modified by your function). Thus, you avoid necessity to have overloaded functions which differ only by const or var definitions.
By the way, I don't think it is a wonderful language design. More implicit conversions and polymorphic behavior, more difficult is to understand how program work and especially why does not it work.

OTOH I was considering how the same sort of thing could be done in the context of FPC, and strong typing with polymorphic parameterisation is one of Object Pascal's selling points (IMO).

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

glorfin

  • Full Member
  • ***
  • Posts: 148
  • LMath supporter
Re: Multi-paradigm languages
« Reply #3 on: April 07, 2021, 05:11:56 pm »
Yes, overloading functions in general is nice, like it is implemented in FPC, when you can have function with the same name but different formal parameters. Like:

function max(X,Y:real):real;
function max(X,Y:integer):integer;
function max(array of real):real;

But here you always know what happens. In contrast, when you have function which can treat your parameters sometimes as a variable, and sometimes as a constant, you do not immediately see what happens in this particular case. And this becomes even more tricky when you call the function from another function, like:

function Inner(rel A:integer):integer;
begin
....
end;

function Outer(rel A:integer):integer;
begin
  Result := inner(A);
end;

It may be note easy to backtrack what is A and will it be treated as a variable or constant.
Everything has its price, and implementing more polymorphic and implicit behavior, we loose clarity and make language more prone to errors.

Well, yes, I am almost as conservative as N. Wirth himself :)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Multi-paradigm languages
« Reply #4 on: April 07, 2021, 05:17:29 pm »
when you have function which can treat your parameters sometimes as a variable, and sometimes as a constant, you do not immediately see what happens in this particular case.

Hence my wondering about whether the order in which similarly-named functions were examined was guaranteed.

I think it's probably /not/ guaranteed, since I don't recall seeing any discussion of the compiler complaining if the order of declaration in the interface and implementation parts differed (if the order was guaranteed, it would be reasonable to expect that these had to be the same).

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

glorfin

  • Full Member
  • ***
  • Posts: 148
  • LMath supporter
Re: Multi-paradigm languages
« Reply #5 on: April 07, 2021, 05:23:53 pm »
Well, my own recent experience (see https://forum.lazarus.freepascal.org/index.php/topic,53986.0.html) shows that it is defined by oreder of declarations. Most probably, if they are declared in different units, then functions from the unit which is mentioned in uses clause earlier, is searched first.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Multi-paradigm languages
« Reply #6 on: April 07, 2021, 05:42:05 pm »
Well, my own recent experience (see https://forum.lazarus.freepascal.org/index.php/topic,53986.0.html) shows that it is defined by oreder of declarations. Most probably, if they are declared in different units, then functions from the unit which is mentioned in uses clause earlier, is searched first.

"uses" is definitely significant in imports and unit initialisation sequences, otherwise the conventional strictures about putting cmem and heaptrc first wouldn't work.

I was thinking about the case where same-named functions were defined adjacent to each other in the same unit... or for that matter same-named methods in the same class.

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

glorfin

  • Full Member
  • ***
  • Posts: 148
  • LMath supporter
Re: Multi-paradigm languages
« Reply #7 on: April 07, 2021, 06:12:32 pm »
In case of functions in the same unit - see experiment which I describe in post cited, first declared, first found by compiler.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Multi-paradigm languages
« Reply #8 on: April 08, 2021, 09:20:59 am »
Which was agreed to be a bug, i.e. unintentional. I don't know whether there is compiler policy for the ordering.

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: 5446
  • Compiler Developer
Re: Multi-paradigm languages
« Reply #9 on: April 08, 2021, 09:24:14 am »
Well, my own recent experience (see https://forum.lazarus.freepascal.org/index.php/topic,53986.0.html) shows that it is defined by oreder of declarations. Most probably, if they are declared in different units, then functions from the unit which is mentioned in uses clause earlier, is searched first.

No, the lookup for identifiers in other units is right to left (and if you're in the implementation section then first the uses-clause of that and then the interface one).

Which was agreed to be a bug, i.e. unintentional. I don't know whether there is compiler policy for the ordering.

There is no documented order for routines as by definition there shouldn't be ambiguous situations. However the implementation has a preference, but as it's an implementation detail it should not be relied upon.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Multi-paradigm languages
« Reply #10 on: April 08, 2021, 09:40:56 am »
There is no documented order for routines as by definition there shouldn't be ambiguous situations. However the implementation has a preference, but as it's an implementation detail it should not be relied upon.

Thanks for that. So it shouldn't be relied upon as a language feature which would allow something more complex to be built on top of FPC. But it is presumably consistent in the context of a language implementation, so could be tested during program initialisation.

Which I suppose leaves open the possibility of a program which could test the behaviour of the current FPC implementation and generate appropriately-ordered declarations (please assume that is somewhere between a rhetorical question and a thought experiment, rather than something I propose to do :-)

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: 5446
  • Compiler Developer
Re: Multi-paradigm languages
« Reply #11 on: April 08, 2021, 01:42:13 pm »
Which I suppose leaves open the possibility of a program which could test the behaviour of the current FPC implementation and generate appropriately-ordered declarations (please assume that is somewhere between a rhetorical question and a thought experiment, rather than something I propose to do :-)

Sounds like what configure does in the C world with testing the C compiler and the environment and then configuring the project for it :P

Fun fact: I only saw that you had written me a PM about this two hours after I had replied here :P

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Multi-paradigm languages
« Reply #12 on: April 08, 2021, 02:00:16 pm »
Which I suppose leaves open the possibility of a program which could test the behaviour of the current FPC implementation and generate appropriately-ordered declarations (please assume that is somewhere between a rhetorical question and a thought experiment, rather than something I propose to do :-)

Sounds like what configure does in the C world with testing the C compiler and the environment and then configuring the project for it :P

Or a makefile... I think the Lazarus .lpi could probably cope with it. I /might/ have a quick play with this, since I realise I've got some experimental coroutine-like code which would be useful.

Quote
Fun fact: I only saw that you had written me a PM about this two hours after I had replied here :P

:-) I was obviously interested in knowing the "ex cathedra" situation.

Mark
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