 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/11/2010 08:28 PM, Darren New wrote:
> Invisible wrote:
>> The reason I put up with TeX, in spite of its innumerable and obvious
>> limitations, is that it produces very, very nice output. troff doesn't
>> seem to compare to that.
>
> I'm guessing you've never run troff, but only nroff. I'm also guessing
> that if you *have* run troff, you've only run it using the man page macros.
Your guess is as good as mine! ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> it's far more verbose and, thus, hurts readability?
>>
>> Far more verbose, and as a consequence it's almost self-explanatory
>> what it does. (Unlike a collection of symbols that have no
>> widely-accepted meaning outside of regex languages...)
>
> symbols like $ or >>=?
FWIW, I think that >>= is a stupid name choice too. Especially for a
function that you almost never need to mention by name anyway...
> yeah, every language has them and you *learn* to live with them. or you
> just endlessly refuse to learn and whine all day long about them...
Look who's whining.
> you are correct though in that the Lisp way of spelling out names is
> more self-explanatory than the Haskell abuse of perlisms.
Almost all of Haskell's operators are just standard mathematical symbols
that everybody already knows. I consider this /more/ readable, not less.
Perl, on the other hand, seems to choose characters at random on a
"which punctuation marks haven't we used yet?" basis. :-P
(There are of course Haskell packages that define rather too many
obscure operators. For example, the arrows package defines operators
such as ***, &&& and >==>. I end up having to look them up every single
time I need to know what they do. I don't consider this to be a good idea.)
>>> then try this in your little language:
>>>
>>> // A phone number with or without hyphens:
>>> [2-9]\d{2}-?\d{3}-?\d{4}
>>>
>>> It looks pretty much like a template for a phone number. I'm sure yours
>>> will look like a little backwards forth script and will be much harder
>>> to figure out.
>>
>> I actually can't figure out what that does, so I can't implement it.
>
> BS.
...or you could have just told me what it does rather than swearing
about it...
>> 1. Commands have cryptic names like "*" or "+".
>
> more than frakkin' $ or >>= ??!
>
> you quite throw away reason completely when you try to invent reasons
> for why you dislike something, don't you?
You've managed to find two operators in the entire Haskell language
which are a bit dubious. Big deal.
>> 2. Literal characters aren't quoted, so it's hard to tell what's
>> literal and what's a command.
>
> there's only .*+?^$\ for commands and the rest are grouping chars ()[]{}
> and literal chars. what's to be confused?
How about "-"? That's not on your list. I'm pretty sure I saw some
examples mentioning ":" as well. How many others are there?
(Of course, it's a trick question. The answer depends on "which of the
20,000 regex variants are we arguing about?")
>> (And 3. since spaces are literal characters, you can't even use
>> spacing to make the structure of the expression clearer.)
>
> you can in perl regex extensions.
So how do you tell the difference between literal whitespace and
whitespace that's just for readability?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/11/2010 05:07 PM, Warp wrote:
> Invisible<voi### [at] dev null> wrote:
>> 1. Commands have cryptic names like "*" or "+".
>
> You might as well argue that math is cryptic because it uses notation
> like "1+2=3".
I'm sure you can find an ample supply of people who make precisely this
argument.
Almost none of them are arguing that 1+2=3 is cryptic though. They're
arguing about some equation with sums, limits, Greek and Hebrew letters,
wonky arrows, funny hats on things, and abbreviations like "tan", "Gal"
and "Arg".
The basics of mathematical notation are so ubiquitous throughout the
Western world that nobody considers it cryptic. And it's no coincidence
that most programming languages copy this notation - after all,
everybody already knows what it does.
Anyone who's used a computer for a length of time is probably familiar
with "*" as a wildcard character, so that's not too bad. It's the other
characters which are less self-evident. (Plus the fact that "*" is
actually a prefix operator, which I hadn't realised.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/11/2010 08:20 PM, Darren New wrote:
> Invisible wrote:
>>>>> (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?
>
> Your parser won't parse "+3" as a valid number.
Huh? Oh wait, I didn't see the "optional" word before the decimal point.
So assuming I'm guessing the bracketing correctly, you want
do
option (char '+' <|> char '-')
many1 digit
option (do char '.'; many1 digit)
option (do char 'E'; option (char '+' <|> char '-'); many1 digit)
>> Sure. Except without any guarantee of syntactic correctness.
>
> Again, until the first time you run it. So?
If you don't see why this is critically important, I'm not sure what
else I can say to that...
> Clearly you have no guarantee of semantic correctness, so this really
> isn't a problem, given that with your syntactic correctness you still
> got the expression wrong. :-)
Semantic correctness is impossible to guarantee.
>> 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.
>
> It can be checked at compile time if your language cares to. That's not
> an aspect of the regexp, but an aspect of you using Haskell.
I've yet to find a Haskell regex library that provides compile-time
guarantees either. After all, it's just a flat string with no structure.
> And if you wrote the code and never ran it, then guess what, you have
> worse problems than syntax errors in your regexps.
That's like saying "type checking is pointless, because you have to test
your code anyway". Yes, you /do/ have to test your code. But if the
computer can find the easy bugs instantly without you having to wait for
the entire test suite to run, you get stuff done a lot quicker.
>> 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.
>
> How do you construct your parser programatically in Haskell? That looks
> like code to me.
A parser is just a data structure. For example, "digit" is a parser, and
when you say "many1 digit", you're calling the "many1" function, passing
it the "digit" parser as argument, and getting a new parser as the
result. You just programmatically constructed a parser.
Obviously that's a fairly trivial example, but you're manipulating
parser objects with a Turing-complete programming language. You get the
idea.
Of course, you can manipulate strings-that-happen-to-be-regexs in a
similar way. It's just that there's no checking of any kind that what
you're doing with them is sensible. It's a bit like trying to build an
XML file by string manipulation. Yes, it can be done. Yes, you can make
it work. And yes, it's incredibly fragile. This is why almost everybody
uses a real XML library that guarantees that the resulting XML document
will be at least well-formed, if nothing else.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 12/11/2010 10:52, Invisible a écrit :
> Anyone who's used a computer for a length of time is probably familiar
> with "*" as a wildcard character,
Unless it's a SQL usage, where the wildcard for any string is "%"
instead of "*" (when not using regular expression).
And of course "_" is the substitute for one character in SQL (instead of
"?" in some shell... and of "." in other places)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>>> Sure. Except without any guarantee of syntactic correctness.
>>
>> Again, until the first time you run it. So?
>
> If you don't see why this is critically important, I'm not sure what
> else I can say to that...
Oh, it would be handy, sure. But it's trivial to test whether a literal
regexp is syntactically valid. It's no more "critically important" to
ensure a literal regular expression is valid before you run it than it is to
ensure a Haskell program is valid before you compile it.
>> Clearly you have no guarantee of semantic correctness, so this really
>> isn't a problem, given that with your syntactic correctness you still
>> got the expression wrong. :-)
>
> Semantic correctness is impossible to guarantee.
Yes, and that's my point. Even with your syntactic correctness, you got the
parser for the numbers wrong.
> I've yet to find a Haskell regex library that provides compile-time
> guarantees either. After all, it's just a flat string with no structure.
So is a printf statement, yet GCC manages to check that when it's a literal.
Actually, I wouldn't be surprised if Perl or other languages with actual
regexp literals in the syntax of the language checked them for correctness
at compile time.
>> And if you wrote the code and never ran it, then guess what, you have
>> worse problems than syntax errors in your regexps.
>
> That's like saying "type checking is pointless, because you have to test
> your code anyway". Yes, you /do/ have to test your code. But if the
> computer can find the easy bugs instantly without you having to wait for
> the entire test suite to run, you get stuff done a lot quicker.
Certainly. But it's pretty easy to check in an external program, since there
*isn't* type information etc built into the regular expression. Chances are
if it's big enough to need testing, you're going to develop it in a separate
program full of test strings and then copy it into the production system.
> A parser is just a data structure. For example, "digit" is a parser, and
> when you say "many1 digit", you're calling the "many1" function, passing
> it the "digit" parser as argument, and getting a new parser as the
> result. You just programmatically constructed a parser.
How do you build a parser based on (for example) what the user typed in at
runtime, while still ensuring syntactic correctness?
> Obviously that's a fairly trivial example, but you're manipulating
> parser objects with a Turing-complete programming language. You get the
> idea.
Show me an example of such manipulation?
> Of course, you can manipulate strings-that-happen-to-be-regexs in a
> similar way. It's just that there's no checking of any kind that what
> you're doing with them is sensible. It's a bit like trying to build an
> XML file by string manipulation. Yes, it can be done. Yes, you can make
> it work. And yes, it's incredibly fragile.
No it's not.
> This is why almost everybody
> uses a real XML library that guarantees that the resulting XML document
> will be at least well-formed, if nothing else.
Uh, yes. And that's the way you make it not fragile. I'm not following you.
If you're using a library to construct regular expressions, of course the
library is going to be invoked in a way that makes it impossible to
construct syntactically invalid regular expressions, just like your parser is.
You're comparing Haskell against brain-dead worst-possible-stupidity regular
expression libraries, and saying "See? My way is better!"
--
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 wrote:
> How about "-"? That's not on your list. I'm pretty sure I saw some
> examples mentioning ":" as well. How many others are there?
Those are both shortcuts for typing that aren't part of the formalism. You
can take any regexp with that and expand it into one without in a trivial
way. Basically, 0-9 means 0123456789.
> So how do you tell the difference between literal whitespace and
> whitespace that's just for readability?
You use a different symbol for the regular whitespace, like "\ " or like
:space: or something like that.
--
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 wrote:
> The basics of mathematical notation are so ubiquitous throughout the
> Western world
And the basics of regexp notation is mathematical. As well as being
ubiquitous throughout the programming world. Which is why we're equating the
two.
> Anyone who's used a computer for a length of time is probably familiar
> with "*" as a wildcard character, so that's not too bad.
And where do you think the "*" meaning "wildcard" came from?
> It's the other characters which are less self-evident.
I'm sure you'd find quite a few mathematicians being confused by
6 = 2 * 3
2 = 6 / 3
which is why APL used an actual multiplication and division sign.
>(Plus the fact that "*" is
> actually a prefix operator, which I hadn't realised.)
No it isn't.
--
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 wrote:
>>> If there are more than three digits, the above parser fails, and no
>>> other alternatives are tried (i.e., no backtracking).
>>
>> Then you aren't doing what regular expressions can do.
>
> I don't see how that is the case.
You really should learn the essential basics of an entire heirarchy of
formal language theory.
>> In order to *get* the power of regexp, *your* parser has to backtrack.
>> So if you turn backtracking off, there are trivial regular expressions
>> you can't match. If you turn backtracking on, you're using more time and
>> space than a regular expression engine.
>
> Do you have a concrete example?
http://swtch.com/~rsc/regexp/regexp1.html
Or, in your language
many (char 'a')
many (char 'a')
many (char 'a')
char 'a'
char 'a'
char 'a'
Now match that against "aaaaaa".
The problem is the first "many (char 'a')" eats the whole string.
Without backtracking, you claim the string fails to match.
*With* backtracking, you're now taking an exponential amount of time to
match something you could match in six comparisons.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Semantic correctness is impossible to guarantee.
>
> Yes, and that's my point. Even with your syntactic correctness, you got
> the parser for the numbers wrong.
So because you can't find /all/ bugs automatically, it's pointless to
try to find /any/ bugs automatically?
All I can say to that is: I do not agree.
>> It's a bit like trying to build an
>> XML file by string manipulation. Yes, it can be done. Yes, you can
>> make it work. And yes, it's incredibly fragile.
>
> No it's not.
I give up.
> If you're using a library to construct regular expressions, of course
> the library is going to be invoked in a way that makes it impossible to
> construct syntactically invalid regular expressions, just like your
> parser is.
>
> You're comparing Haskell against brain-dead worst-possible-stupidity
> regular expression libraries, and saying "See? My way is better!"
I have yet to see anybody construct a regex in any way other than typing
it out by hand, or gluing strings together by hand.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
