Parsers Specification thoughts during implementation

Ideas for ADC may be presented here for others to review and point out flaws or further improve the idea.
Forum rules
If you have an account on the wiki, remember to update the ADC Proposals page for new ideas.

http://dcbase.org/wiki/ADC_Proposals_list
poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: Parsers Specification thoughts during implementation

Post by poy » 31 Mar 2010, 14:42

udoprog wrote:Named vs Positional parameters are too disambiguous to be parsed and validated in a formal (context-unaware) manner.
is there any reason you would actually do that? parsing a message always involves its context, and when being aware of it, the spec clearly states which parameters are compulsory in each message description.

the general definition in the beginning is probably just to give the global idea that positional params come before named ones, but it is left to each message definition to specify how their parameters should be parsed.

udoprog
Newbie
Posts: 5
Joined: 30 Mar 2010, 22:11

Re: Parsers Specification thoughts during implementation

Post by udoprog » 31 Mar 2010, 17:18

I have the following protocol proposition to make.
  • Remove positional parameters completely
  • Redefine named parameters as <type>:<key>:<value>
type: a three letter simple_alpha declaration of the type
key: a two letter, simple_alpha and simple_alphanum declaration of the parameter name.
value: an escape sequence

For details, example implementation, and updated grammar, see; http://github.com/udoprog/python-adc/tree/type-test

These are some of the strong points for having a type system like this:
  • This would greatly simplify low-level code, since messages can be decoded and type converted early in the application stack, errors and type problems are less likely to propagate into the application logic.
  • Library authors for any language can convert the different types to native (or custom types) when applicable, the conversion will be transparent to the application layer which will never be affected by minor protocol changes.
  • Types can easily be extended in future definitions, since the parsers takes the value as an escape sequence (basically; anything), and the type/key are fixed values.
Radical changes, but luck favours the bold ;) .

andyhhp
Junior Member
Posts: 30
Joined: 18 Feb 2010, 17:44
Location: England

Re: Parsers Specification thoughts during implementation

Post by andyhhp » 01 Apr 2010, 15:31

Hmm - Interesting idea.

I have to say that I quite like the proposal, even if I am unsure whether it is wise to alter the syntax that dramatically. Then again, considering some of the other proposed ideas for ADC/2.0, it might be quite possible

One point, on gitit you say INT has to match the grammar " '1' [0-9]*"
Why does an integer have to start with a 1? What if I want to send the number 2? What is wrong with the grammar "[0-9]+"?

About python being slow at base32 transformations, what does it matter? If you are looking for speed in a program then you write in C/C++, not in a scripting language which is going to be slow anyway. I am not saying that using a scripting language is bad - i am saying that speed is not a valid argument in this case. Even base32 in a scripting language is plenty fast enough for these purposes on modern computers :P

~Andrew

udoprog
Newbie
Posts: 5
Joined: 30 Mar 2010, 22:11

Re: Parsers Specification thoughts during implementation

Post by udoprog » 01 Apr 2010, 20:16

andyhhp wrote:One point, on gitit you say INT has to match the grammar " '1' [0-9]*"
Why does an integer have to start with a 1? What if I want to send the number 2? What is wrong with the grammar "[0-9]+"?
I quite agree with you, i was pressed for time when writing the README and it's far from finished.

The syntax for an integer should be something like: ('+'|'-')? [0-9]+ (ignore leading zeroes), or as a decimal; ('+'|'-')? ([0-9]+ '.' [0-9]+)

I will be revisiting the document after easter.

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: Parsers Specification thoughts during implementation

Post by darkKlor » 02 Apr 2010, 02:16

It's nice to see people discussing the protocol.. it's been a bit quiet on here for a few months. I might ask that one of the moderators setup a wiki page to propose and discuss ideas towards ADC/2.0, similar to how we have the Proposed Extensions page.

Toast

Re: Parsers Specification thoughts during implementation

Post by Toast » 02 Apr 2010, 13:40

drakklor: should u have access to the wiki to do that yourself ? or did i forgot to give you an acc ?

andyhhp
Junior Member
Posts: 30
Joined: 18 Feb 2010, 17:44
Location: England

Re: Parsers Specification thoughts during implementation

Post by andyhhp » 02 Apr 2010, 14:12

How about:

INT ::= -?(0|[1-9][0-9]*)

which is an optional minus sign to indicate negative followed by either a zero or a non-zero didgt (to prevent sending leading zeroes) followed by any number of digits. IT is a slightly messy grammar but allows for sending positive and negative numbers, allows for 0 to be sent but prevents sending numbers with leading zeroes.

If the leading zero problem is not considered importent, we could just go with the grammar INT ::= -?[0-9]+

As for floating point numbers,

FLO ::= -?[0-9]+.[0-9]+((e|E)-?[1-9][0-9]*)?

This allows for negative numbes and optional exponentials which might be able to represent a number in a far more compact form than purely with [0-9]+.[0-9]+

~Andrew

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: Parsers Specification thoughts during implementation

Post by darkKlor » 03 Apr 2010, 03:32

@Toast: Yeah I went in and tried, but nah seems I never got around to asking you for an account.

Toast

Re: Parsers Specification thoughts during implementation

Post by Toast » 03 Apr 2010, 09:17

All done now details are sent to you

Locked