lexeme default vs. :default and :lexeme

[Ruslan Shvedov]

Just caught myself thinking that

:default ::= action => [name, values]
:lexeme default ::= latm => 1


looks like a bit more consistent (well, for some definitions of consistency
at least) syntax than the current

:default ::= action => [name, values]
lexeme default = latm => 1


:default ::= ... and :lexeme ~ ... are pseudo-rules, but lexeme default =
... is a statement. This is by design, so I'd appreciate any information
from those in the know.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: lexeme default vs. :default and :lexeme

[Jeffrey Kegler]

The "logic" goes like this.  Note the "=" instead of "::=".  This 
signals that the statement is not a rule, and is non-lexical -- it's 
location in the file does not matter.  Since it's not a rule, it does 
not take the form LHS ::= RHS2 ...


The initial colon was for pseudo-symbols.  Since the lexeme default 
statement is not a rule, it does not have a LHS, so what appears before 
the equal sign ("=") is not considered symbol, pseudo- or otherwise.


I am, frankly, less than 100% happy with this "logic" and my design 
choices, but there they are.


In an ironic way, it does show Marpa's strength.  Because it allows and 
exploits ambiguity, I can "unpaint myself out of the corner", by 
introducing new statements and syntax.  Languages based on other parsers 
cannot evolve in that way.


-- jeffrey

On 02/25/2014 08:25 AM, Ruslan Shvedov wrote:

Just caught myself thinking that

:default ::= action => [name, values]
:lexeme default ::= latm => 1


looks like a bit more consistent (well, for some definitions of 
consistency at least) syntax than the current


:default ::= action => [name, values]
lexeme default = latm => 1


:default ::= ... and :lexeme ~ ... are pseudo-rules, but lexeme 
default = ... is a statement. This is by design, so I'd appreciate any 
information from those in the know.

--
You received this message because you are subscribed to the Google 
Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to marpa-parser+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "marpa 
parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: lexeme default vs. :default and :lexeme

[Ruslan Shvedov]

Thanks for explaining.

The thing was I thought if SLIF DSL could benefit from less diverse/more
strict — (pseudo-)rule/adverbs only — syntax and model, where

lexeme default statement becomes :lexeme default ::= pseudo rule


inaccessible statement becomes an adverb of
:default and/or :lexeme default pseudo-rules, e.g.


:default action => [name, values] inaccessible => ok

and


named event statement — event ( 'name' | name ) = ( completed | nulled |
predicted ) *symbol* — becomes an adverb of the rule whose LHS *symbol* is,
e.g.

event subtext = completed 
event 'A[]' = nulled 
event '^a' = predicted A


become

subtext ::= ... event completed => subtext
 ::= ... event nulled => 'A[]'
A ::= ... event predicted => '^a'


Heretic as it is, but I thought I'd better braindump it. :)

What do you think?



On Tue, Feb 25, 2014 at 8:11 PM, Jeffrey Kegler <
jeffreykeg...@jeffreykegler.com> wrote:

>  The "logic" goes like this.  Note the "=" instead of "::=".  This
> signals that the statement is not a rule, and is non-lexical -- it's
> location in the file does not matter.  Since it's not a rule, it does not
> take the form LHS ::= RHS2 ...
>
> The initial colon was for pseudo-symbols.  Since the lexeme default
> statement is not a rule, it does not have a LHS, so what appears before the
> equal sign ("=") is not considered symbol, pseudo- or otherwise.
>
> I am, frankly, less than 100% happy with this "logic" and my design
> choices, but there they are.
>
> In an ironic way, it does show Marpa's strength.  Because it allows and
> exploits ambiguity, I can "unpaint myself out of the corner", by
> introducing new statements and syntax.  Languages based on other parsers
> cannot evolve in that way.
>
> -- jeffrey
>
>  On 02/25/2014 08:25 AM, Ruslan Shvedov wrote:
>
>  Just caught myself thinking that
>
>  :default ::= action => [name, values]
> :lexeme default ::= latm => 1
>
>
>  looks like a bit more consistent (well, for some definitions of
> consistency at least) syntax than the current
>
>   :default ::= action => [name, values]
>  lexeme default = latm => 1
>
>
>  :default ::= ... and :lexeme ~ ... are pseudo-rules, but lexeme default
> = ... is a statement. This is by design, so I'd appreciate any information
> from those in the know.
>  --
> You received this message because you are subscribed to the Google Groups
> "marpa parser" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to marpa-parser+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "marpa parser" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to marpa-parser+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: lexeme default vs. :default and :lexeme

[Jeffrey Kegler]

There's been talk of alternative interfaces to Libmarpa, and multiple 
interfaces are the real solution here.  In fact, the SLIF only exists 
because Peter Stuifzand decided my ways of interfacing Libmarpa in my 
public examples weren't good enough, and took it upon himself to write 
his own.   Once he'd done so, I saw that Peter was right -- and the SLIF 
is a direct descendant of Peter's interface.  [ Though any feature of it 
you don't like is probably my idea. :-) ]


-- jeffrey

On 02/25/2014 11:44 AM, Ruslan Shvedov wrote:

Thanks for explaining.

The thing was I thought if SLIF DSL could benefit from less 
diverse/more strict — (pseudo-)rule/adverbs only — syntax and model, where


lexeme default statement becomes :lexeme default ::= pseudo rule


inaccessible statement becomes an adverb of
:default and/or :lexeme default pseudo-rules, e.g. 



:default action => [name, values] inaccessible => ok

and


named event statement — event ( 'name' | name ) = ( completed |
nulled | predicted ) /symbol/ — becomes an adverb of the rule
whose LHS /symbol/ is, e.g.

event subtext = completed 
event 'A[]' = nulled 
event '^a' = predicted A


become

subtext ::= ... event completed => subtext
 ::= ... event nulled => 'A[]'
A ::= ... event predicted => '^a'


Heretic as it is, but I thought I'd better braindump it. :)

What do you think?



On Tue, Feb 25, 2014 at 8:11 PM, Jeffrey Kegler 
> wrote:


The "logic" goes like this. Note the "=" instead of "::=".  This
signals that the statement is not a rule, and is non-lexical --
it's location in the file does not matter.  Since it's not a rule,
it does not take the form LHS ::= RHS2 ...

The initial colon was for pseudo-symbols.  Since the lexeme
default statement is not a rule, it does not have a LHS, so what
appears before the equal sign ("=") is not considered symbol,
pseudo- or otherwise.

I am, frankly, less than 100% happy with this "logic" and my
design choices, but there they are.

In an ironic way, it does show Marpa's strength. Because it allows
and exploits ambiguity, I can "unpaint myself out of the corner",
by introducing new statements and syntax.  Languages based on
other parsers cannot evolve in that way.

-- jeffrey

On 02/25/2014 08:25 AM, Ruslan Shvedov wrote:

Just caught myself thinking that

:default ::= action => [name, values]
:lexeme default ::= latm => 1


looks like a bit more consistent (well, for some definitions of
consistency at least) syntax than the current

:default ::= action => [name, values]
lexeme default = latm => 1


:default ::= ... and :lexeme ~ ... are pseudo-rules, but lexeme
default = ... is a statement. This is by design, so I'd
appreciate any information from those in the know.
-- 
You received this message because you are subscribed to the

Google Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to marpa-parser+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google

Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to marpa-parser+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google 
Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to marpa-parser+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "marpa 
parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: lexeme default vs. :default and :lexeme

[Ruslan Shvedov]

Well, what can I say? Fair enough. :)


On Tue, Feb 25, 2014 at 10:10 PM, Jeffrey Kegler <
jeffreykeg...@jeffreykegler.com> wrote:

>  There's been talk of alternative interfaces to Libmarpa, and multiple
> interfaces are the real solution here.  In fact, the SLIF only exists
> because Peter Stuifzand decided my ways of interfacing Libmarpa in my
> public examples weren't good enough, and took it upon himself to write his
> own.   Once he'd done so, I saw that Peter was right -- and the SLIF is a
> direct descendant of Peter's interface.  [ Though any feature of it you
> don't like is probably my idea. :-) ]
>
> -- jeffrey
>
>
> On 02/25/2014 11:44 AM, Ruslan Shvedov wrote:
>
> Thanks for explaining.
>
>  The thing was I thought if SLIF DSL could benefit from less diverse/more
> strict — (pseudo-)rule/adverbs only — syntax and model, where
>
>  lexeme default statement becomes :lexeme default ::= pseudo rule
>
>
>  inaccessible statement becomes an adverb of
> :default and/or :lexeme default pseudo-rules, e.g.
>
>
>   :default action => [name, values] inaccessible => ok
>
>   and
>
>
>   named event statement — event ( 'name' | name ) = ( completed | nulled
> | predicted ) *symbol* — becomes an adverb of the rule whose LHS *symbol*is, 
> e.g.
>
>  event subtext = completed 
> event 'A[]' = nulled 
>  event '^a' = predicted A
>
>
>  become
>
>  subtext ::= ... event completed => subtext
>  ::= ... event nulled => 'A[]'
> A ::= ... event predicted => '^a'
>
>
>   Heretic as it is, but I thought I'd better braindump it. :)
>
>  What do you think?
>
>
>
> On Tue, Feb 25, 2014 at 8:11 PM, Jeffrey Kegler <
> jeffreykeg...@jeffreykegler.com> wrote:
>
>>  The "logic" goes like this.  Note the "=" instead of "::=".  This
>> signals that the statement is not a rule, and is non-lexical -- it's
>> location in the file does not matter.  Since it's not a rule, it does not
>> take the form LHS ::= RHS2 ...
>>
>> The initial colon was for pseudo-symbols.  Since the lexeme default
>> statement is not a rule, it does not have a LHS, so what appears before the
>> equal sign ("=") is not considered symbol, pseudo- or otherwise.
>>
>> I am, frankly, less than 100% happy with this "logic" and my design
>> choices, but there they are.
>>
>> In an ironic way, it does show Marpa's strength.  Because it allows and
>> exploits ambiguity, I can "unpaint myself out of the corner", by
>> introducing new statements and syntax.  Languages based on other parsers
>> cannot evolve in that way.
>>
>> -- jeffrey
>>
>>   On 02/25/2014 08:25 AM, Ruslan Shvedov wrote:
>>
>>   Just caught myself thinking that
>>
>>  :default ::= action => [name, values]
>> :lexeme default ::= latm => 1
>>
>>
>>  looks like a bit more consistent (well, for some definitions of
>> consistency at least) syntax than the current
>>
>>   :default ::= action => [name, values]
>>  lexeme default = latm => 1
>>
>>
>>  :default ::= ... and :lexeme ~ ... are pseudo-rules, but lexeme default
>> = ... is a statement. This is by design, so I'd appreciate any information
>> from those in the know.
>>   --
>> You received this message because you are subscribed to the Google Groups
>> "marpa parser" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to marpa-parser+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "marpa parser" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to marpa-parser+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "marpa parser" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to marpa-parser+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "marpa parser" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to marpa-parser+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Just uploaded a release candidate to CPAN: Marpa-R2 2.081_001

[Durand Jean-Damien]

Here is a gist showing how to inspect Marpa 
grammartogether with the new 
rule_name() and start_symbol_id() methods.
Great release candidate -;

Le lundi 24 février 2014 18:55:10 UTC+1, Jeffrey Kegler a écrit :
>
> I've just uploaded Marpa-R2 
> 2.081_001, 
> which is a release candidate.  Value added includes:
>
>- 
>- In the semantics, new array descriptor 
> elements:
>  
>"name", "symbol", "lhs". 
>- The ability to change the treatment of inaccessibble 
> symbols.
>  (Inaccessible 
>symbols are those which cannot be reached from the start symbol).
>- The SLIF's use of ambiiguity in its own DSL is now 
> documented
>.
>- Rules can now be named, using the "name" 
> adverb
>. 
>
> Since this is a release candidate, testing is especially appreciated.
>
> Thanks, jeffrey
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Just uploaded a release candidate to CPAN: Marpa-R2 2.081_001

[Durand Jean-Damien]

Here is a gist showing how to inspect Marpa 
grammar together 
with the new rule_name() and start_symbol_id() methods.
Great release candidate -;

Le lundi 24 février 2014 18:55:10 UTC+1, Jeffrey Kegler a écrit :
>
> I've just uploaded Marpa-R2 
> 2.081_001, 
> which is a release candidate.  Value added includes:
>
>- 
>- In the semantics, new array descriptor 
> elements:
>  
>"name", "symbol", "lhs". 
>- The ability to change the treatment of inaccessibble 
> symbols.
>  (Inaccessible 
>symbols are those which cannot be reached from the start symbol).
>- The SLIF's use of ambiiguity in its own DSL is now 
> documented
>.
>- Rules can now be named, using the "name" 
> adverb
>. 
>
> Since this is a release candidate, testing is especially appreciated.
>
> Thanks, jeffrey
>

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Just uploaded a release candidate to CPAN: Marpa-R2 2.081_001

[Ron Savage]

Thanx!

Also, I added a comment because I get the output in a different order.

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

A new blog post: Significant newlines? Or semicolons?

[Jeffrey Kegler]

I just posted a new piece to my blog 
.  My thought 
is to try doing a series which encourage people to think about designing 
their own new languages, in new ways, using techniques which were just 
not possible before.  This one starts out modestly, suggesting one 
solution to the debate about explicit statement termination versus 
significant whitespace:  Do not do either one.


-- jeffrey

--
You received this message because you are subscribed to the Google Groups "marpa 
parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: A new blog post: Significant newlines? Or semicolons?

[Paul Bennett]

On Feb 25, 2014 8:08 PM, "Jeffrey Kegler" 
wrote:
>
> Do not do either one.
>

I concur.

FWIW, I think my current version of Marpa.tmLanguage does rely on some
whitespace to figure out the highlighting rules, because it's easier to do
the regexes. I'll add it to The Big List Of Stuff To Fix. Oh, and that
reminds me: Marpa.tmPreferences is needed to help at least with Ctrl+/
commenting / uncommenting.

Belated thanks for the LATM options, btw. I get the feeling my SGML magic
wand is going to be a lot easier to build properly.

--
Paul

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: A new blog post: Significant newlines? Or semicolons?

[Jeffrey Kegler]

@Paul: While you're online, I've a question for you.  You spoke of a 
Python port at one time.  Did you have in mind Python 2 or 3?  -- jeffrey


On 02/25/2014 05:23 PM, Paul Bennett wrote:



On Feb 25, 2014 8:08 PM, "Jeffrey Kegler" 
> wrote:

>
> Do not do either one.
>

I concur.

FWIW, I think my current version of Marpa.tmLanguage does rely on some 
whitespace to figure out the highlighting rules, because it's easier 
to do the regexes. I'll add it to The Big List Of Stuff To Fix. Oh, 
and that reminds me: Marpa.tmPreferences is needed to help at least 
with Ctrl+/ commenting / uncommenting.


Belated thanks for the LATM options, btw. I get the feeling my SGML 
magic wand is going to be a lot easier to build properly.


--
Paul

--
You received this message because you are subscribed to the Google 
Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to marpa-parser+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google Groups "marpa 
parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: A new blog post: Significant newlines? Or semicolons?

[Paul Bennett]

On Feb 25, 2014 8:25 PM, "Jeffrey Kegler" 
wrote:
>
> @Paul: While you're online, I've a question for you.  You spoke of a
Python port at one time.  Did you have in mind Python 2 or 3?  -- jeffrey
>

My preference would be both / either / let-the-user-choose. Since (when I
pick the project back up) I'm going via SWIG, I hope the SWIGged stage will
be helpful to others, too.

I've got eleventy billion things on the boil right now, and Real Life keeps
intruding.

--
Paul

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.