 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>> OK, so how do you do
>>
>> (\+|-)[0-9]+(\.[0-9]+)?(E(\+|-)?[0-9]{1,3})?
>>
>> in your parser language?
>
> OK, that's one big ol' complex regex, right there.
That's a pretty simple regex, actually.
>> (That is, optional sign, one or more digits, optional decimal point
>> followed by one or more digits, optional E followed by optional sign
>> followed by one to three digits.)
>
> If I've understood the spec correctly, it's
>
> do
> option (char '+' <|> char '-')
> many1 digit
> option (char '.')
> many1 digit
> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
Bzzzt. Sorry. That requires at least a 2-digit number.
> Enforcing that the exponent is less than or equal to 3 digits would be
> slightly more wordy. The obvious way is
>
> xs <- many1 digit
> if length xs > 3 then fail else return ()
>
> Notice that since this is written in a /real/ programming language and
> not a text string, we can do
>
> sign = char '+' <|> char '-'
>
> number = do
> option sign
> many1 digit
> option (char '.')
> many1 digit
> option (do char 'E'; option sign; many1 digit)
>
> and save a little typing.
You can do that with many regexp engines too. That's what I meant by
"trivial macros".
> You can also factor the task into smaller pieces:
Yeah, that's just a text substitution in the regexp expression.
> With a regex, on the other hand, you cannot even statically guarantee
> that a given string is even a syntactically valid regex.
Nonsense. How'd you get that?
If you mean you can't use a regexp to parse a regexp, well, yeah, so?
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
>> Nice straw man.
>
> Wasn't his problem that he didn't have a brain?
>
>> (And "foo*bar" still doesn't mean what you think it means
>> as a regex.)
>
> So, what, it means
>
> string "fo"
> many (char 'o')
> string "bar"
>
> Or am I reading this wrong?
* means 0 or more of the previous pattern, in this case, letter 'o'.
+ means 1 or more.
"fobar" is accepted. The correct pattern should be foo+bar or foo.*bar.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
>> OK, so how do you do
>>
>> (\+|-)[0-9]+(\.[0-9]+)?(E(\+|-)?[0-9]{1,3})?
>>
>> in your parser language?
>
> OK, that's one big ol' complex regex, right there.
I see you never looked at perl code.
>> (That is, optional sign, one or more digits, optional decimal point
>> followed by one or more digits, optional E followed by optional sign
>> followed by one to three digits.)
>
> If I've understood the spec correctly, it's
>
> do
> option (char '+' <|> char '-')
> many1 digit
> option (char '.')
> many1 digit
> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
so, besides the errors, are you satisfied to go the Lisp route and spell
out all functions rather than rely on specialized, more convenient
predefined syntax?
do you really believe spelling out "option (char '+' <|> char '-')" is
any worth as opposed to "(\+|-)"?
> Enforcing that the exponent is less than or equal to 3 digits would be
> slightly more wordy. The obvious way is
>
> xs <- many1 digit
> if length xs > 3 then fail else return ()
no, sorry. Truly overkill against "\d{3}".
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> xs <- many1 digit
> if length xs > 3 then fail else return ()
By the way, this also means you have backtracking, which means you have
exponential time and space requirements for your match rather than provably
linear time and constant space.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 escreveu:
> killer application for Unix", you don't expect some ugly archaic looking
> text-only interface...
>
> Yes, I've used SSH myself. It's quite neat that I can have an old 386
> laptop sitting in a cupboard somewhere and operate it basically as if I
> was sitting in front of it. On the other hand, would it be so hard to do
> so with a less primitive interface?
it's strange that I guy used to programming languages feels awkward
about a text interface. Plus, were you ever taught that one shouldn't
judge a book by its cover? Notepad in all its glorious graphical user
interface is much more featureless and rudimentar than vi on an old Unix
terminal.
There is power in words, they make spells and those magical enchantments
make things happen in the real world, like dispensing cash at your local
ATM.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I've always thought that manpages and the ugliest, lamest, most archaic
> thing ever, so I don't see that that's much of an advantage.
Oh, wait. Aren't you the one that goes on about LaTeX and Postscript? :-)
I'm not sure what you have against a text-based program for generating
typeset output.
> (On the other hand, today's reading suggests that troff is really
> designed to control phototypesetters - whatever those are - and not
> produce stuff on screen...)
Plus, they didn't produce stuff on screen. This is hardcopy land. Screens
were advanced stuff. :-)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmail com> wrote:
> Orchid XP v8 escreveu:
> > killer application for Unix", you don't expect some ugly archaic looking
> > text-only interface...
> >
> > Yes, I've used SSH myself. It's quite neat that I can have an old 386
> > laptop sitting in a cupboard somewhere and operate it basically as if I
> > was sitting in front of it. On the other hand, would it be so hard to do
> > so with a less primitive interface?
>
> it's strange that *a* guy used to programming languages feels awkward
> about a text interface. Plus, were you ever taught that one shouldn't
> judge a book by its cover? Notepad in all its glorious graphical user
> interface is much more featureless and *rudimentary* than vi on an old Unix
> terminal.
>
> There is power in words, they make spells and those magical enchantments
> make things happen in the real world, like dispensing cash at your local
> ATM.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> xs <- many1 digit
>> if length xs > 3 then fail else return ()
>
> By the way, this also means you have backtracking
No it doesn't.
Parsec doesn't backtrack by default; you have to explicitly request it
(which I haven't).
If there are more than three digits, the above parser fails, and no
other alternatives are tried (i.e., no backtracking).
(As an aside, there are other Haskell libraries that work similarly to
Parsec, but where backtracking is the default and turning it off is
explicit. Apparently this is more intuitive to work with...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> OK, that's one big ol' complex regex, right there.
>
> I see you never looked at perl code.
It's something I generally try to avoid, yeah. :-)
> do you really believe spelling out "option (char '+' <|> char '-')" is
> any worth as opposed to "(\+|-)"?
Um, *yes*. Why, do you think it doesn't have worth?
>> Enforcing that the exponent is less than or equal to 3 digits would be
>> slightly more wordy. The obvious way is
>>
>> xs <- many1 digit
>> if length xs > 3 then fail else return ()
>
> no, sorry. Truly overkill against "\d{3}".
So define a combinator for it:
manyN 0 _ = return []
manyN n p = do x <- p; xs <- manyN (n-1) p; return (x:xs)
And now, forever more, you can merely write
manyN 3 digit
Problem solved.
EDIT: Apparently this function is already predefined. I hadn't even
noticed. I could have just written "count 3 digit". In all the time I've
been writing parsers, I've never needed this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> (That is, optional sign, one or more digits, optional decimal point
>>> followed by one or more digits, optional E followed by optional sign
>>> followed by one to three digits.)
>>
>> If I've understood the spec correctly, it's
>>
>> do
>> option (char '+' <|> char '-')
>> many1 digit
>> option (char '.')
>> many1 digit
>> option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
>
> Bzzzt. Sorry. That requires at least a 2-digit number.
I don't follow. Where do you think by definition deviates from your spec?
>> Notice that since this is written in a /real/ programming language and
>> not a text string, we can do
>>
>> and save a little typing.
>
> You can do that with many regexp engines too. That's what I meant by
> "trivial macros".
I've never seen a system that can do that, but I guess that doesn't
prove a lot.
>> You can also factor the task into smaller pieces:
>
> Yeah, that's just a text substitution in the regexp expression.
Sure. Except without any guarantee of syntactic correctness.
>> With a regex, on the other hand, you cannot even statically guarantee
>> that a given string is even a syntactically valid regex.
>
> Nonsense. How'd you get that?
Not every string is a valid regex. You have to follow the syntax rules.
But this is not checked at compile-time (and usually /cannot/ be checked
at compile-time). So if you make a typo in your regex, you won't find
out until runtime.
If you start constructing regexs programmatically, your problems just
multiplied.
On the other hand, with a /real/ parser library, both of these grave
problems immediately vanish into thin air.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
