Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use records to store captured value instead of hashmap #2

Open
thautwarm opened this issue Aug 31, 2018 · 12 comments
Open

use records to store captured value instead of hashmap #2

thautwarm opened this issue Aug 31, 2018 · 12 comments
Labels
enhancement New feature or request

Comments

@thautwarm
Copy link
Owner

thautwarm commented Aug 31, 2018

A ::= B as b C as c

We could create a type A to perform capturing:

type A = {
     mutable b : B option
     mutable c : C option
}

This might be much more efficient than current implementation.

@thautwarm
Copy link
Owner Author

kind of difficult without meta programming..

@ice1000
Copy link
Collaborator

ice1000 commented Aug 31, 2018

Is as a binary operator?

@ice1000 ice1000 added the enhancement New feature or request label Aug 31, 2018
@thautwarm
Copy link
Owner Author

@ice1000 It cannot be a binop for F#.
In BNF we can regard it as a valid binop.
A ::= b=B c=C is alternative if you think it not readable.

@ice1000
Copy link
Collaborator

ice1000 commented Aug 31, 2018

Discussed in #1 (seems that we've come up with the same idea! Time to get married)

@thautwarm
Copy link
Owner Author

no... I found it difficult for the lack of metaprogramming infrastructures in F#.

@thautwarm
Copy link
Owner Author

A feasible solution is, use discriminated union to represented all context type.

bnf:

A ::= b=B c=C

generated:

type A = {
   mutable b : B
   mutable c : C
}

type B = Token
type C = Token

type context = 
| A of  A

the parserc schema:

type 't parser = 
| Bind('t -> unit, 't parser)  # first of which is a setter

@ice1000
Copy link
Collaborator

ice1000 commented Aug 31, 2018

Why metaprogramming? Code generators never need metaprogramming, we can generate hard-coded stuffs. What are you concerning about?

@thautwarm
Copy link
Owner Author

@ice1000 I don't want to say anything about this. Actually I have many to complain about code generation.

However, without a definite and specific explanation you might not be satisfied. I don't really refuse this feature but until now there is no feasible design about it and I cannot implement it recently.

Currently we need code generation from BNF to F#, which contains many important functionalities when visiting BNF AST:

  • implement auto lexer generation from grammar(this technology is easy to me now for the existed parser analyzer)

  • implement module, which requires tremendous and tedious tasks. I have implemented it twice, each of which exactly drives me crazy:

       import std.common.[Indentifier, DoubleDuotedStr, JavaComment]
       import lang.scala.[*] 
       [F#] import MyModule.AST 
    
  • find a way to introduce "function"s like what you said in parsing guard as combinator #1 for implementing predicate combinator and rewrite combinator:

    A ::= b=B{predB} c=C{predC} -> A(b, c)
    

If new features are added, I'm afraid that if we could implement it in a near future...
We could hold this issue until there is a feasible design and a clarified workflow about the whole.

@thautwarm
Copy link
Owner Author

to implement module, we need

  • a mechanism about path resolving and corresponding implementation.
  • a scope could handle symbol resolving from separate modules.
  • others that I haven't been reminded of yet.

And if we want to generate BNF into separate F# scripts we have to concern about stuffs related to .NET build system(which is not a trivial task)...

So I suggest that we could firstly release a available version and persist adding more interesting features in the future.

@ice1000
Copy link
Collaborator

ice1000 commented Sep 1, 2018

module should be a part of bootstrap. I think I can help with this.

@thautwarm
Copy link
Owner Author

thautwarm commented Sep 2, 2018

@thautwarm
Copy link
Owner Author

I found this prevent dynamic left recursion handling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants