On Wednesday, 16 September 2015 at 20:17:15 UTC, Stefan Koch wrote:
> On Monday, 14 September 2015 at 08:50:48 UTC, Bastiaan Veelo wrote:
>
>> Understanding the source of FancyPars is challenging because the core source, example vibe.d application source and supporting code, as well as generated lexer/parser code are all contained in the same directory and committed in the repository.
>
> Sorry about that.
> The Files that are really interesting are
> 1. fancy_grammar.d - contains helpers for working with the FancyParsGrammar Definition.
> 2. fancy_genPars.d - generates a function which parses the output form the generated lexer
> 3. fancy_genLex.d generates the lexer function.
> 4. fancy_genAST.d - generates the AST

Thanks. At first I thought that fancy_[ast|token|lexer|parser|printer].d were generated files because their content is so similar to the code produced in the vibe application. But on closer look I think it is the other way around: that the example grammar in vibe describes its own input format, and that the similarity in the produced output to said files is an illustration that it works the way it should. Am I close?

> The Syntax is inspired by D and Pegged.
> It is going to be extend though and you should consider it unstable.
> I will document it as it becomes more stable.

Wow that is great news! Not so abandoned after all :-)

> TransCompilers are what fancyPars is written for.
> please show me a few examples of your pascal gramamr.
> might be in pegged or EBNF or something similar.
>
> So I can see if there are idioms I should integrate in fp.

Please have a look in https://www.dropbox.com/sh/k0ewq4dkz0q009v/AADq5V6j5lPBfBkmpwIpkMq8a?dl=0

p2d.d is my dance with Pegged, containing a subset of the Extended Pascal grammar. It was only after typing close to 400 lines of grammar that I discovered left-recursions, which are commented out. These put a spanner in the works, but before that I felt this could go somewhere: even comments are translated.

There are many recursions in the complete grammar, for which you find the specification in the PDF. (This is the ANSI/IEEE standard; Extended Pascal became an ISO standard a year or so later, with identical text.) Note the alphabetical list of EBNF starting on page 129; the numbers in front refer to the corresponding section.

> Thanks for the interest.

Thanks for finding the time for this.

Bastiaan.

On Wednesday, 16 September 2015 at 21:25:40 UTC, Bastiaan Veelo wrote:

> Thanks. At first I thought that fancy_[ast|token|lexer|parser|printer].d were generated files because their content is so similar to the code produced in the vibe application. But on closer look I think it is the other way around: that the example grammar in vibe describes its own input format, and that the similarity in the produced output to said files is an illustration that it works the way it should. Am I close?

fancyPars has gone through a few iterations.
I used fancyPars to generate a parser for itself
and then fixed up the things that fancyPars cannot yet generate.

I eat my own dogfood!

Thanks for the pascal specs and your p2d.d
I will see what I can do about that.

On Wednesday, 16 September 2015 at 12:16:03 UTC, Bastiaan Veelo wrote:
>
> Sounds like you want to share this, but I can't find a licence. In case this turns out to be useful, we would need one :-)
>
> If you want I can prepare a PR for that, just let me know which licence to pick.
>
> Best,
> Bastiaan.

I am not sure.
The source should not be used in any product without my explicit permission.
However you may study it to get better in your understanding of dlang or parser technology

On Thursday, 17 September 2015 at 15:47:42 UTC, Stefan Koch wrote:
> On Wednesday, 16 September 2015 at 12:16:03 UTC, Bastiaan Veelo wrote:
>>
>> Sounds like you want to share this, but I can't find a licence. In case this turns out to be useful, we would need one :-)
>>
>> If you want I can prepare a PR for that, just let me know which licence to pick.
>>
>> Best,
>> Bastiaan.
>
> I am not sure.
> The source should not be used in any product without my explicit permission.
> However you may study it to get better in your understanding of dlang or parser technology

Yikes. Are you sure? Are you familiar with open source licensing?

On Thursday, 17 September 2015 at 16:02:14 UTC, John Colvin wrote:

> Yikes. Are you sure? Are you familiar with open source licensing?
I would be open to open-source the "base" of fp.
but keeping certin extentions for grammar analysis closed.

What license would you suggest for that.

On Thu, Sep 17, 2015 at 15:47:41 +0000, Stefan Koch via Digitalmars-d-announce wrote:
> I am not sure.
> The source should not be used in any product without my explicit
> permission.

FYI, that's not FOSS. Please consider using a LICENSE file which explicitly states that as the case. Github is already a minefield when it comes to licensing, please don't help make it worse :) .

--Ben

On Thursday, 17 September 2015 at 16:33:12 UTC, Stefan Koch wrote:
> On Thursday, 17 September 2015 at 16:02:14 UTC, John Colvin wrote:
>
>> Yikes. Are you sure? Are you familiar with open source licensing?
> I would be open to open-source the "base" of fp.
> but keeping certin extentions for grammar analysis closed.
>
> What license would you suggest for that.

Assuming you wrote it all, you can license the code in whatever way you want. See http://choosealicense.com for more info. You can even use multiple licenses, or different licenses for different parts of the code.

On Thursday, 17 September 2015 at 16:55:42 UTC, John Colvin wrote:

> Assuming you wrote it all, you can license the code in whatever way you want. See http://choosealicense.com for more info. You can even use multiple licenses, or different licenses for different parts of the code.

Hmm reading this. No license, is best for now.

@Bastian
  The FancyPars Grammar for pascal will look very very different from what you wrote.
  In FancyPars Grammars I worked very hard to avoid repetitions.
  FGPs do not just describe the language grammar. They are describing the AST-Structure.
  So just by reading the grammar a person working with the AST will know what is what and in which members-variables of the AST-Node which information is stored.
  I would recommed you open issues in the FancyPars-repo for stuff that is hard to understand.

On Thursday, 17 September 2015 at 20:32:59 UTC, Stefan Koch wrote:
> On Thursday, 17 September 2015 at 16:55:42 UTC, John Colvin wrote:
>
>> Assuming you wrote it all, you can license the code in whatever way you want. See http://choosealicense.com for more info. You can even use multiple licenses, or different licenses for different parts of the code.
>
> Hmm reading this. No license, is best for now.

Take your time, but without a license anyone cloning or forking your repo is in fact violating your copyright. It is not what most people expect on github, and I will have to delete my fork and local clone...

> @Bastiaan
>   The FancyPars Grammar for pascal will look very very different from what you wrote.
>   In FancyPars Grammars I worked very hard to avoid repetitions.
>   FGPs do not just describe the language grammar. They are describing the AST-Structure.
>   So just by reading the grammar a person working with the AST will know what is what and in which members-variables of the AST-Node which information is stored.

I can see the value of that when designing a grammar, or building a translator. In my case though the grammar was standardised a quarter of a century ago, and available in BNF. Redefining the complete language in FPG by hand would be interesting but time consuming and error prone -- not sure that would pay in the end. Maybe writing a BNF2FPG transcompiler would get me there faster...

But, without a license I am prohibited from experimenting with it. Even with permission for educational purposes or the like, which I think you have implied, I am not sure that I will be allowed to construct a transcompiler intended for the translation of proprietary source in the end.

I am afraid I can't afford the time to investigate the possibilities of FancyPars until legal uncertainties are resolved.

Maybe you could consider to make the core of FancyPars Open Source with one of the mainstream licenses, without further restrictions. The parts that you want to keep proprietary I would not publish at all. That way, if somebody else decides to write an analyser, he will not risk infringing the copyright of your closed source, because it is not publicly viewable.

Best,
Bastiaan.

On Thu, Sep 17, 2015 at 23:40:49 +0000, Bastiaan Veelo via Digitalmars-d-announce wrote:
> On Thursday, 17 September 2015 at 20:32:59 UTC, Stefan Koch wrote:
> > Hmm reading this. No license, is best for now.
> 
> Take your time, but without a license anyone cloning or forking your repo is in fact violating your copyright. It is not what most people expect on github, and I will have to delete my fork and local clone...

By using public repos, you explicitly allow anyone to view and fork your project. There are no implicit rights of *use* of that clone though.

--Ben