PARAMETERS, LOCAL DATA & CREATE STATEMENT #124

dgarroDC · 2019-06-21T06:24:04Z

This resolves #113. Currently only LOCAL DATA section is implemented for now, I'll implement PARAMETERS later, you can review and test the code in the meantime.

Example:

DATA:
  x is number
PROCEDURE:
  sub-procedure foo
    LOCAL DATA:
      i is number
    PROCEDURE:
      incr i
      display "FOO " i crlf
  end sub-procedure
  sub-procedure bar
    LOCAL DATA:
      i is text
    PROCEDURE:
       join i and "-" in i
      display "BAR " i crlf
  end sub-procedure
  for x from 0 to 10 step 1 do
    call foo
    call bar
  repeat

Output:

FOO 1
BAR -
FOO 2
BAR --
FOO 3
BAR ---
FOO 4
BAR ----
FOO 5
BAR -----
FOO 6
BAR ------
FOO 7
BAR -------
FOO 8
BAR --------
FOO 9
BAR ---------
FOO 10
BAR ----------

All the variable declaration statements where merged to only one if to reduce duplicated code.

We store in which subprocedure a variable was declared and when we expect some variable we search it in the current subprocedure and main variables. The function variable_type handles this.

To keep the variable values persistent, we fix the C++ identifier based on the subprocedure (for example, LVAR_SUBPR_FOO_VAR_I) and declare it as a global variable.

The PROCEDURE: label is optional if the subprocedure only has procedure statements. This was implemented with the in_procedure_section function.

…unction and current_subprocedure variable

dgarroDC · 2019-06-22T05:41:50Z

PARAMETERS implemented! Now you can declare parameters in your subprocedure (following this syntax). They are passed by reference, so if you modify a parameter, the variable used in CALL changes its value too (but you can pass literals too!). This allow you to do cool stuff, like returning results in variables.

Lartu · 2019-06-22T06:31:13Z

This is wonderful! I'm going to test it asap! Thank you!!

dgarroDC · 2019-06-22T07:37:13Z

I changed the LOCAL DATA variables so they are no longer persistent, each invocation of a SUB-PROCEDURE will have its own variable (if you call it recursively this helps). I think that persistent variables weren't useful and I understand that maybe it was more "LDPLic" in a way, but I think usability is a priority here.

Lartu · 2019-06-22T08:21:41Z

I've been testing this PR for the last hour and I just love it. I do LOVE it. This is an absolute game changer, this makes the language so much useful, so much richer, I even started writing a true standard library with this. I can't stress enough how much this makes the language better. Just like when @dvkt implemented C++ Extensions, this has taken LDPL a big leap ahead and I cannot stress how much I thank you. Contributions like these are what made LDPL what it is today and I cannot be thankful enough for all the work this community has put into my little toy language, not so toy nor little anymore. It's truly a moving thing.

When you consider this PR is done, just go ahead and merge it. I'll go create a new repository for the LDPL Standard Library and start preparing everything for the next LDPL release. It was going to be LDPL 3.0.6, but an add-on this big deserves a major version increase, so I'd say let's go ahead and call it LDPL 3.1.0. Just like when we leaped from LDPL 2.2.0 to 3.0.0 with C++ Extensions.

Again, your work is wonderful and I thank you very, very much for your amazing contribution.

dgarroDC · 2019-06-22T09:10:26Z

Thank you for your kind words, this make me really happy!

I added a new statement to take advantage of these new powerful sub-procedures:

CREATE STATEMENT <TEXT> EXECUTING <SUB-PROCEDURE name>

(this keywords can change, they are just the first thing that came to me)

The TEXT is the statement patter, specifying the parameters with '$'. The sub-procedure must be already declared when CREATE STATEMENT is used. After you execute it, you can use the newly created statement, it just calls the sub-procedure with the parameters you pass (they follow the same order as the sub-procedure parameters declaration).

Example:

PROCEDURE:

sub-procedure say_hi
    parameters:
        name is text
    procedure:
        display "Hi " name "!" crlf
end sub-procedure

create statement "GREET $" executing say_hi

greet "LDPL"

I think that this would be cool for libraries, what do you think?

Lartu · 2019-06-22T09:29:49Z

Naaaaaaaaaaaah I cannot believe this! This is wonderful! Amazing! @dvkt this is the macro thing we were looking for! This is amazing, Damián, you are incredible. Thank you very, very, very, very, very much for this! Incredible!

This would be wonderful for libraries, I guess now the Standard Library must be rewritten! Haha! Really something, will get to it tomorrow! Thank you again!!

arielf212 · 2019-06-22T12:54:08Z

ok, this is awesome!
honestly not even kidding! the statement thing is a game changer!

arielf212 · 2019-06-22T13:21:35Z

oh also @Lartu I think that this might be a good time to remind r/programmingLanguages that we exist :P
it might be a good idea to post about this new macro system.

Lartu · 2019-06-23T01:12:38Z

oh also @Lartu I think that this might be a good time to remind r/programmingLanguages that we exist :P it might be a good idea to post about this new macro system.

Yes! This would be wonderful. Once we release 3.1.0 we should go rub it in their faces (? haha

Types are always correct when add_call_code is called from a custom statement (this is checked by line_like)

Lartu · 2019-06-25T03:40:33Z

If I create a new statement with the word IS in it, the compiler tells me that I have a Variable declaration outside DATA, PARAMETERS or LOCAL DATA section. Should we maybe check for created statements before we check for the default statements?

Lartu · 2019-06-25T03:42:55Z

Also I cannot create statements with spaces in them anymore 😞 (for instance, CHECK COMMAND LINE ARGUMENTS).

dgarroDC · 2019-06-25T04:15:52Z

Sorry about that, this is fixed now! If you pass an invalid type to IS now it continues checking for others statements instead of treating it always like a variable declaration.

Lartu · 2019-06-26T03:06:30Z

Sorry about that, this is fixed now! If you pass an invalid type to IS now it continues checking for others statements instead of treating it always like a variable declaration.

Wonderful, thank you! Thank you for this awesome contribution!!

dgarroDC added 5 commits June 21, 2019 01:24

All variable declaration statements in one if

4d254e4

section_state with more values (not used yet), in_procedure_section f…

e64a37a

…unction and current_subprocedure variable

LOCAL DATA section

888b7b9

Fixed bug in fix_identifier local_prefix

9d51b0f

PARAMETERS section

e4eb49a

dgarroDC changed the title ~~LOCAL DATA~~ PARAMETERS & LOCAL DATA Jun 22, 2019

Allow passing literals parameters

ab60af8

dgarroDC added 2 commits June 22, 2019 04:28

Added missing open_subprocedure_code call (when entering LOCAL DATA)

81a3b6a

LOCAL DATA is no longer persistent

e71ae77

dgarroDC added 2 commits June 22, 2019 05:54

Fix bug opening subprocedure code

ef2ba48

CREATE STATEMENT statement

764e492

Lartu mentioned this pull request Jun 22, 2019

LDPL Standard Library #126

Closed

dgarroDC added 2 commits June 22, 2019 17:46

Allow local variables named like global ones

c71011e

CREATE STATEMENT keywords validation (at least one and [A-Z ]+)

8ee82dd

dgarroDC added 2 commits June 23, 2019 19:25

Moved parameter types check from add_call_code to CALL statement

b35bdb0

Types are always correct when add_call_code is called from a custom statement (this is checked by line_like)

Check for invalid parameter token

9d84038

dgarroDC changed the title ~~PARAMETERS & LOCAL DATA~~ PARAMETERS, LOCAL DATA & CREATE STATEMENT Jun 25, 2019

dgarroDC added 2 commits June 25, 2019 01:02

Fixed bug about statements with spaces

afe46dc

Fix bug about statements with IS keyword

9811065

dgarroDC added 2 commits June 25, 2019 01:24

Don't declare variables with extra type tokens

439597c

Literal number parameter variables are really declared now

abf50be

dgarroDC marked this pull request as ready for review June 26, 2019 00:55

dgarroDC merged commit a452695 into Lartu:master Jun 26, 2019

dgarroDC deleted the local-data branch June 29, 2019 00:23

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PARAMETERS, LOCAL DATA & CREATE STATEMENT #124

PARAMETERS, LOCAL DATA & CREATE STATEMENT #124

dgarroDC commented Jun 21, 2019 •

edited by Lartu

Loading

dgarroDC commented Jun 22, 2019 •

edited

Loading

Lartu commented Jun 22, 2019

dgarroDC commented Jun 22, 2019

Lartu commented Jun 22, 2019

dgarroDC commented Jun 22, 2019

Lartu commented Jun 22, 2019

arielf212 commented Jun 22, 2019

arielf212 commented Jun 22, 2019

Lartu commented Jun 23, 2019

Lartu commented Jun 25, 2019

Lartu commented Jun 25, 2019 •

edited

Loading

dgarroDC commented Jun 25, 2019

Lartu commented Jun 26, 2019

PARAMETERS, LOCAL DATA & CREATE STATEMENT #124

PARAMETERS, LOCAL DATA & CREATE STATEMENT #124

Conversation

dgarroDC commented Jun 21, 2019 • edited by Lartu Loading

dgarroDC commented Jun 22, 2019 • edited Loading

Lartu commented Jun 22, 2019

dgarroDC commented Jun 22, 2019

Lartu commented Jun 22, 2019

dgarroDC commented Jun 22, 2019

Lartu commented Jun 22, 2019

arielf212 commented Jun 22, 2019

arielf212 commented Jun 22, 2019

Lartu commented Jun 23, 2019

Lartu commented Jun 25, 2019

Lartu commented Jun 25, 2019 • edited Loading

dgarroDC commented Jun 25, 2019

Lartu commented Jun 26, 2019

dgarroDC commented Jun 21, 2019 •

edited by Lartu

Loading

dgarroDC commented Jun 22, 2019 •

edited

Loading

Lartu commented Jun 25, 2019 •

edited

Loading