|
It was a few years ago and was basically transferring a daily snapshot of a banking system to a reporting/analysis tool with biztalk in the mix. System was totally unwieldy and got canned before it was completed. XML was never used again as a transfer medium.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
The "job" is undefined. I'm making an API.
Anyway, I'm not sure I'm going through with this bit.
Besides I have other stuff to work on that has taken precedence.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
For what it's worth, XML has been my preferred persistence format for a long time. It makes it relatively easy to manage arbitrary structure and schema changes, UNICODE, and so on. It also translates well to other programming environments and languages, given that support is fairly ubiquitous.
It's no longer "flavor of the month", but it has the advantage of... it works.
Software Zen: delete this;
|
|
|
|
|
Prolly stating the obvious, but can you package subelements as items in an array?
/ravi
|
|
|
|
|
they need names.
i could, but the resulting json isn't worth it
[ {a: b}, {c: d} , {e: f} ]
sucks, you know?
better to just use xml
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Use PostScript.
It's like a version of XML that hasn't had its bollocks lopped off.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
107. C question on expression container (4)
|
|
|
|
|
C ... question ... container
leads me to CASK, but
on expression
just leaves me confuzzled.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Well, you got it anyway 
'express' C + ask?
I mean, there's just so many synonyms for 'mix'
|
|
|
|
|
Oh my, so I know how to "hack" (using math basically) an LL(1) parser to allow for very expressive grammars.
I can describe it on a whiteboard, but I'll spare you the details, except to say it makes LL(1) competitive with LL(k) for any k value, as far as I know.
What does all that mean? It means a beautiful parser generator, that is very easy to use and extremely expressive.
Meh, I just want to share it with everyone, but you know how that goes. I'm sure you all have had something code-wise that has got you hot and bothered, too.
I'm debating about monetizing it. It's brilliant. Too brilliant for me to have designed it, and yet there it is. 
Gosh I just love this.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Quote: I'm debating about monetizing it. It's brilliant.
Sorry, but I think you are a little bit late. All you described in your posts is allreday available here: Niklaus Wirth[^]
Among others:
- Compiler Compiler
- EBNF Parser based on EBNF
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Actually it's not. Wirth shows you how to generate parsers, but not how to make LL(1) more expressive *without* bloating the parse tree <--- this is the part that isn't covered and doesn't seem to be implemented by offerings like Coco/R
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Quote: Wirth shows you how to generate parsers
Wirth showed exactly coco!
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Yeah, and Coco doesn't do what my thing does. Like I said.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
sorry, I'll explain. Coco/R can't use this grammar. It's too "ambiguous" (it's not ambiguous though, it's just not LL(1) deterministic)
grammar<start>=productions;
productions= productions production | production;
production=identifier ["<" attributes ">"] "=" expressions ";";
expressions= expressions "|" expression | expression;
symbol = literal | regex | identifier |
"(" expressions ")" |
"[" expressions "]" |
"{" expressions "}";
expression = symbols;
symbols= symbol symbols |;
attributes= attributes "," attribute | attribute;
attribute= identifier ["=" attrval];
attrval= literal | integer | identifier;
literal = '"([^"\\]|\\.)*"';
regex = '\'([^\'\\]|\\.)*\'';
identifier= '[A-Z_a-z][\-0-9A-Z_a-z]*';
integer='\-?[0-9]+';
whitespace<hidden>= '[ \v\f\t\r\n]';
lineComment<hidden>= '//[^\n]*';
blockComment<hidden,blockEnd="*/">="/*";
And even if it did left factor, which it doesn't seem to, it doesn't have a mechanism for collapsing factored non-terminals in the resulting parse tree
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Quote: it's just not LL(1)
I think it is the point!It is not context free...
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
The above grammar is context-free
A grammar can be context-free and not LL(1)
LL(k) grammars are of the CFG category, and all but one class ( LL(1)! ) are not LL(1)
My back of the napkin calculation puts that grammar at LL(2) (LL(k) for k=2 )
That's why it needed to be left-factored - to modify it to be LL(1) - my code does that.
normally that modifies the parse tree, but my code can do that transparently so the parse tree stays the same (no added non-terminal productions)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Ok, I think you know much more about this stuff than me. Please excuse the troubles 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
No worries. It's a real specialization.
The goal though, is clean grammars and clean parse trees + easy to use and efficient parsers.
So far, this does it all, and I've not gone past LL(1) in the actual parsing algorithm itself.
Trust me when I say, I think only one tool put out there *might* have done this before, and it wasn't a generator, just a parser.
And I can't be sure because it was commercial and they never told you what algo they used. They didn't have to because you could write whatever you want into it, like I did above - you didn't need to know. <--- and that's hard to achieve.
In fact, the attributed EBNF syntax I use was inspired by that tool - called Programmar. It's not around anymore, unfortunately.
Anyway, my tool gives you LL(1) without the hassle of LL(1)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: I'm debating about monetizing it. It's brilliant.
No! There's no greater glory than Github. Open source it. 
/ravi
|
|
|
|
|
I feel you, but also I am poor (at least by my region's standards), and while I'm fine with that, also helping with the bills wouldn't hurt.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Trust me - attempting to monetize an idea will steal all available cycles from you and cause you to have to deal with suits, who are an unpleasant and ignorant lot at best. Getting your name on Github will send more lucrative job offers to you than you will know what to deal with. Plus, it's nigh impossible to monetize something as hardcore as you're working on. Who do you expect your customers will be? And will they see the same value as you do? History will reveal that the most lucrative software endeavors haven't been technically challenging probems, but just good business ideas implemented at the right time. There's no money in algorithms - just glory. And that opens the door to opportunities that could pay well.
Have you tried talking to somebody at Google or FB about your idea? If it's as interesting and novel as you say it is (and I'm not knocking your solution - just being honest), you may not have to worry about money for the rest of your career.
Good luck and Godspeed. I hope you get to publish a paper at ACM and get the visibility you deserve. 
/ravi
|
|
|
|
|
I hear you but i think an expressive parser generator is something devs would want, if they need to parse a thing.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
OMG! This is just unbelievable!  
Good luck with whatever you go with!
|
|
|
|
|
While I'm left ANTLR behind a few years, I remember it was declared as LL(*), and uses EBNF to define the grammar...
It doesn't mean you have nothing new under your hand, but it may be hard to monetize such thing - maybe better to improve ANTRL or such...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
