Talk:Flex (lexical analyser generator)

message: Shouldn't flex be described as a "lexical analyzer generator", rather than a "lexical analyzer"? Lex is described as a "program that generates lexical analyzers".
:Agreed, changing it now. --fvw<SMALL>*</SMALL> 14:46, 2005 Jan 27 (UTC)
Can we please change the title to: Flex (lexical analyzer generator)? Thanks. 122.29.91.176 (talk) 08:53, 21 June 2008 (UTC)
replies: text: That would seem to be more consistent - assuming that one completed the task and moved similar topics which do not require disambiguation to use the same naming convention.  The latter comment of course is to avoid unnecessary wordiness. Tedickey (talk) 11:26, 21 June 2008 (UTC)

text: Why not just "flex (software)"? This is similar to lex (software), which had title issues too. Individ (talk) 07:51, 21 July 2009 (UTC)
replies: text: that seems a similar renaming (except that it's less descriptive - on the one hand, like saying that there's only one program named "flex", and on the other saying that its category is unimportant to the title).  Should we rename all of the text-editors, for instance (perhaps not). Tedickey (talk) 08:49, 21 July 2009 (UTC)
thread_title: Name of this topic

message: The non-flex example should be more concise, but is needed to illustrate the corresponding flex example Tedickey 10:56, 11 August 2007 (UTC)
replies: text: All examples should be thoroughly condensed. Throwing them out completely like some anon just did might not be such a bad idea. --MarSch 11:54, 5 November 2007 (UTC)

text: Other than constructing a tutorial-style shorter example, there's not much to be done.  (All of the examples I've written are much longer ;-) Tedickey 12:45, 5 November 2007 (UTC)

text: While reading this page, at first I actually thought the non-Flex example had something to do with Flex. It's not until reading "Now, contrast the above code with the code needed for a flex generated scanner for the same language" that the reader is made aware that what he just read had nothing to do with Flex. I guess having it be such a long example makes this kind of thing worse.  —Preceding unsigned comment added by 88.176.77.232 (talk) 12:10, 12 December 2010 (UTC)

text: When put_back reaches a newline character, cur_col is not set to the length of the previous line. Wouldn't it be better to leave cur_col and cur_line out of the example completely? As far as I can see they aren't used anywhere in the code.  —Preceding unsigned comment added by Thomerow (talk • contribs) 08:00, 29 April 2011 (UTC)

text: cur_line is arguably the "same" as yylineno; cur_col does not have an analog in flex (or lex) TEDickey (talk) 08:42, 29 April 2011 (UTC)
thread_title: Examples

message: Quex appears to be a lexical analyzer - there's a topic for that.  But it's not an implementation of lex or flex.  Unless it's in some manner a superset (compatible of course), then it's off-topic. Tedickey (talk) 20:17, 11 September 2009 (UTC)
thread_title:  Quex - offtopic? 

message: While the statement about the complexity may (or may not) be factual, the given reference (last paragraph, etc), does not support the statment Tedickey (talk) 22:40, 21 October 2009 (UTC)
replies: text: no - you're making an assumption about how often it's reallocated to do the resizing.  Resizing on each increase is something that a novice programmer might do; stating that it's done that way in flex is something that requires a more reliable source than you provided. Tedickey (talk) 20:57, 23 October 2009 (UTC)
replies: text: no - my comment has nothing to do with allocation.  The source clearly states that upon resizing, the input is also 'rescanned' from the beginning.  And rescanning is a linear-time process.  Hence O(m/8,000). AshtonBenson (talk) 18:20, 24 October 2009 (UTC)
replies: text: To settle the issue, we need more information than is given in that (actually very old - from 1993 - comment).  The "about 8k" is 8192, by the way, which corresponds to the array storage for yytext.  The comment implies that flex switches to pointer storage when it encounters a large token.  Determining the actual behavior will require a look at flex's source code Tedickey (talk) 19:36, 24 October 2009 (UTC)

text: Of course, your edit in Parsing expression grammar, is also disputed. Tedickey (talk) 20:01, 24 October 2009 (UTC)

text: I've spent a little time now reviewing older versions (2.4.3, 2.4.7, 2.5.3, and can explain the cause of your confusion (the documentation is misleading).  As I noted, the comment about large tokens dates back to 1993 (flex 2.4.1).  There are a few old versions available, so it's possible to see the evolution of the documentation.  The original comment (originally in "NEWS" for 2.4.1) states:
        - A flex scanner's internal buffer now dynamically grows if needed
          to match large tokens.  Note that growing the buffer presently
          requires rescanning the (large) token, so consuming a lot of
          text this way is a slow process.  Also note that presently the
          buffer does *not* grow if you unput() more text than can fit
          into the buffer.
A following comment in version 2.4.7 explains that this is the case that I mentioned (resizing yytext).  Quoting from flexdoc.1:
          input.  As mentioned above, with
          .B %pointer
          yytext grows dynamically to accomodate large tokens.  While this means your
          .B %pointer
          scanner can accomodate very large tokens (such as matching entire blocks
          of comments), bear in mind that each time the scanner must resize
          .B yytext
          it also must rescan the entire token from the beginning, so matching such
          tokens can prove slow.
The "info" file which you're reading on the web was written by a different person than the developer (Francois Pinard), and omits the detail that relates it directly to resizing yytext.  However, each time yytext is resized, flex attempts to double it.  That's rather far away from the behavior which you've claimed (there aren't a lot of doubling's available).  Tedickey (talk) 23:57, 27 October 2009 (UTC)
thread_title:  Quadratic Time Complexity 

message: I would support a merger of the Flexx++ article into this one. Jason Quinn (talk) 22:24, 7 January 2010 (UTC)
replies: text: It's likely that the user community for flex++ is so small that there would be no objections (iirc, the code doesn't compile anymore) Tedickey (talk) 23:41, 7 January 2010 (UTC)
thread_title:  Merger with Flex++ 

message: I see at least 2 areas where IMHO severe cleanup is necessary:
* example; I feel that example of manually written parser doesn't belong here (and comparison between manually written and flex-generated parsers may even constitute WP:OR)
* wording in Flex++ section is a mess (hasn't been rewritten after the merge).
Ipsign (talk) 12:10, 30 October 2010 (UTC)
thread_title:  Severe cleanup necessary 

message: A recent edit suggests that the output of flex++ has a dependency on the C run-time.  I'm not a flex or a flex++ expert but I suspect this is misleading; I expect the output should only depend on the CRTL if the input also depends on the CRTL, e.g, it contains calls to printf, etc.  Can someone confirm or deny, please, and (even better) offer a citation?  Msnicki (talk) 01:25, 24 November 2010 (UTC)
replies: text: It uses malloc 96.255.37.241 (talk) 01:31, 24 November 2010 (UTC)
replies: text: Okay, you need a memory allocator, but that functionality is often provided (in many, many applications) by a user routine anyway.  Take a look, e.g., at section 21.2 on this page, discussing how to override the default.  If that's all we're talking about, I wouldn't call that a dependency on the CRTL.  I'd call that that a dependency on malloc() or a user-supplied alternative.  Is there more than that? Msnicki (talk) 01:38, 24 November 2010 (UTC)

text: Based on this discussion, I've revised the passage to reflect that the output only depends on a memory allocator and whatever the input depended on.  Thanks!  Msnicki (talk) 00:03, 26 November 2010 (UTC)
thread_title:  Flex dependencies 

message: Hello fellow Wikipedians,
I have just modified one external link on Flex (lexical analyser generator). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20160303224333/http://flex.sourceforge.net/manual/Is-flex-GNU-or-not_003f.html to http://flex.sourceforge.net/manual/Is-flex-GNU-or-not_003f.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 07:59, 2 October 2017 (UTC)
thread_title:  External links modified