On Sonntag, 26. Juli 2020 10:56:32 CEST Akim Demaille wrote:
> >> That's indeed a possible choice in the implementation of GLR parser
> >> generators: to sit GLR on top of LR(0). I've never seen performance
> >> reports that compare both approach though.
> >>
> >> However, most implementations us
On 7/26/20 10:56, Akim Demaille wrote:
The most frequent cited good reasons to write parsers by hand is:
3. tailored error messages
Instead of some dummy "unexpected foo, expected bar or baz", writing
something really helping.
All you have to do is write a rule for the incorrect construc
Hi Christian,
> Le 20 juil. 2020 à 14:51, Christian Schoenebeck a
> écrit :
>
> On Samstag, 18. Juli 2020 08:47:07 CEST Akim Demaille wrote:
>>> Le 14 juil. 2020 à 13:31, Christian Schoenebeck
>>> a écrit :
>>>
>>> On Montag, 13. Juli 2020 07:56:57 CEST Akim Demaille wrote:
>>>
>>> For the '
On Samstag, 18. Juli 2020 08:47:07 CEST Akim Demaille wrote:
> > Le 14 juil. 2020 à 13:31, Christian Schoenebeck
> > a écrit :
> >
> > On Montag, 13. Juli 2020 07:56:57 CEST Akim Demaille wrote:
> >
> > For the 'married' parser, in the form imagined by me, there would be no
> > lookahead token,
Hi Adrian,
> Le 18 juil. 2020 à 10:26, Adrian Vogelsgesang a
> écrit :
>
> Hi Akim, hi Christian,
>
> Really interesting thread and discussion!
> I almost feel guilty for only picking up one particular point ;)
>
> Akim's comment
>> No, it's also about the targeted model. Most other GLR par
Hi Akim, hi Christian,
Really interesting thread and discussion!
I almost feel guilty for only picking up one particular point ;)
Akim's comment
> No, it's also about the targeted model. Most other GLR parser generators
> address a somewhat simpler issue: their parsers generate the final AST.
>
> Le 14 juil. 2020 à 13:31, Christian Schoenebeck a
> écrit :
>
> On Montag, 13. Juli 2020 07:56:57 CEST Akim Demaille wrote:
>
> For the 'married' parser, in the form imagined by me, there would be no
> lookahead token, as a lookahead token implies a context-unaware scanner.
>
> Instead,
Hi Christian,
> Le 14 juil. 2020 à 13:44, Christian Schoenebeck a
> écrit :
>
>> -Except for GLR parsers (@pxref{Compiler Requirements for GLR}), the C
>> -code that Bison generates requires only C89 or later. However, Bison
>> -itself requires common C99 features such as declarations after
>>
On Dienstag, 14. Juli 2020 07:02:36 CEST Akim Demaille wrote:
> > Le 13 juil. 2020 à 07:56, Akim Demaille a écrit :
> >> Le 12 juil. 2020 à 19:47, Christian Schoenebeck
> >> a écrit :>>
> >> And BTW:
> >>> The GLR parsers require a compiler for ISO C89 or later.
> >>
> >> Tough requirement! ;-)
On Montag, 13. Juli 2020 07:56:57 CEST Akim Demaille wrote:
> > Le 12 juil. 2020 à 19:47, Christian Schoenebeck
a écrit :
> >> Additionally,the programmer must fully understand how
> >> and when the parser handles tokens, otherwise subtle bugsmay be
> >> introduced.
> >
> > I don't see what they
Hi Christian,
> Le 13 juil. 2020 à 07:56, Akim Demaille a écrit :
>
>> Le 12 juil. 2020 à 19:47, Christian Schoenebeck
>> a écrit :
>>
>> And BTW:
>>
>>> The GLR parsers require a compiler for ISO C89 or later.
>>
>> Tough requirement! ;-)
>
> Yes, we could get rid of that mention, indeed.
> Le 12 juil. 2020 à 19:47, Christian Schoenebeck a
> écrit :
>
>> Additionally,the programmer must fully understand how
>> and when the parser handles tokens, otherwise subtle bugsmay be introduced.
>
> I don't see what they exactly had in mind here for that to claim.
Bison is "lazy" wrt f
On Donnerstag, 9. Juli 2020 06:51:38 CEST Akim Demaille wrote:
> > Le 8 juil. 2020 à 22:14, Akim Demaille a écrit :
> >
> > That reminds me of a paper I read long ago, someone proposing
> > "heisentokens": having the scanner return multiple tokens concurrently,
> > for the different scanning opti
Hi, there's this there
> On 9 Jul 2020, at 06:51, Akim Demaille wrote:
>
>> Le 8 juil. 2020 à 22:14, Akim Demaille a écrit :
>>
>> That reminds me of a paper I read long ago, someone proposing
>> "heisentokens": having the scanner return multiple tokens concurrently,
>> for the different scann
Hi Daniele,
> Le 9 juil. 2020 à 00:25, Daniele Nicolodi a écrit :
>
>> But the profits would be stunning: you could write parsers in a very
>> straight-
>> forward way, even for very complex languages. And on the other side it would
>> eventually allow to design languages in a much more user f
> Le 8 juil. 2020 à 22:14, Akim Demaille a écrit :
>
> That reminds me of a paper I read long ago, someone proposing
> "heisentokens": having the scanner return multiple tokens concurrently,
> for the different scanning options, branched into GLR to follow the
> various options and let dead en
On 08/07/2020 15:30, Christian Schoenebeck wrote:
> On Mittwoch, 8. Juli 2020 22:14:23 CEST Akim Demaille wrote:
>>> So yes, you could certainly address this to work correctly with Flex with
>>> additional measures,
>>
>> The case you are citing above is straightforward to handle the same
>> way I
On Mittwoch, 8. Juli 2020 22:14:23 CEST Akim Demaille wrote:
> > So yes, you could certainly address this to work correctly with Flex with
> > additional measures,
>
> The case you are citing above is straightforward to handle the same
> way I did with the BASIC. That's fairly simple given that t
> Le 6 juil. 2020 à 22:17, Christian Schoenebeck a
> écrit :
>
> Ok, no idea where one can see the original code (if public at all). I just
> found this:
>
> http://newton.freehostia.com/hp/bas/TREKPT.txt
There are some most beautiful BASIC idioms in there. I love this:
5245 LET L=ABS(A
Hi Christian,
> Le 8 juil. 2020 à 12:15, Christian Schoenebeck a
> écrit :
>
> On Mittwoch, 8. Juli 2020 06:24:13 CEST Akim Demaille wrote:
>> I still think you can address this case with Flex, but I agree it's
>> going to be painful. I would go for something like
>>
>> sp [ \t]*
>> do D{
On Mittwoch, 8. Juli 2020 06:24:13 CEST Akim Demaille wrote:
> > As I don't speak BASIC, let me rephrase this problem in FORTRAN IV which
> > is also "blank agnostic":
> >
> > DO = , [, ]
> >
> > It is not until you reach the comma after the first expression that you
> > know whether the stat
Hi John,
> Le 7 juil. 2020 à 10:55, John P. Hartmann a écrit :
>
> On 7/7/20 05:35, Akim Demaille wrote:
>> I believe you need to read again the documentation of /
>> 'r/s'
>
> It is not as simple as that.
Actually the message you are quoting was really just an answer to Maury,
for BASIC.
> A
Hi,
> On 7 Jul 2020, at 10:55, John P. Hartmann wrote:
>
> On 7/7/20 05:35, Akim Demaille wrote:
>> I believe you need to read again the documentation of /
>> 'r/s'
>
> It is not as simple as that. As I don't speak BASIC, let me rephrase this
> problem in FORTRAN IV which is also "blank agnos
On 7/7/20 05:35, Akim Demaille wrote:
I believe you need to read again the documentation of /
'r/s'
It is not as simple as that. As I don't speak BASIC, let me rephrase
this problem in FORTRAN IV which is also "blank agnostic":
DO = , [, ]
It is not until you reach the comma after the
> Le 6 juil. 2020 à 22:01, Maury Markowitz a écrit :
>
>> On Jul 6, 2020, at 3:23 PM, Akim Demaille wrote:
>>
>> FOR/{sp}{id}{sp}={sp}{num}{sp}TO{sp}{num} { printf("for: %s\n", yytext); }
>
> This is a very different style than what I have seen in the past. In the
> past, most examples of
I remember many years ago reading through the IBM 360 (Mainframe)
assembler code for the Fortran 66 H compiler to understand how the
Hollerith constants were parsed.
I suspect finding an "H" after an integer (and skipping that many
following characters) might be problematic for today's scanners.
T
On Montag, 6. Juli 2020 21:48:19 CEST Maury Markowitz wrote:
> > On Jul 6, 2020, at 1:30 PM, Christian Schoenebeck
> > wrote: Which would resolve that ambiguity of
> > your example, if it actually exists, as I have never seen "FOREX" as
> > valid BASIC loop definition before, if there is, sources
> On Jul 6, 2020, at 3:23 PM, Akim Demaille wrote:
>
> FOR/{sp}{id}{sp}={sp}{num}{sp}TO{sp}{num} { printf("for: %s\n", yytext); }
This is a very different style than what I have seen in the past. In the past,
most examples of flex tend to match against the tokens as individual items and
retur
> On Jul 6, 2020, at 1:30 PM, Christian Schoenebeck
> wrote:
> Which would resolve that ambiguity of your example, if it actually exists, as
> I have never seen "FOREX" as valid BASIC loop definition before, if there is,
> sources for that specification appreciated.
BASIC Computer Games, Super S
Hi Maury,
> Le 6 juil. 2020 à 18:25, Maury Markowitz a écrit :
>
> Moving to a new thread - I was surprised I could even post, previous efforts
> were bounced from the list server for no obvious reason.
That's really weird.
>> On Jul 6, 2020, at 9:04 AM, Christian Schoenebeck
>> wrote:
>>
On Montag, 6. Juli 2020 18:25:56 CEST Maury Markowitz wrote:
> Moving to a new thread - I was surprised I could even post, previous efforts
> were bounced from the list server for no obvious reason. Someone helpfully
> posted for me in the past. And now everything is magically working, so I
> hope
Moving to a new thread - I was surprised I could even post, previous efforts
were bounced from the list server for no obvious reason. Someone helpfully
posted for me in the past. And now everything is magically working, so I hope
you don't all mind the duplicate.
> On Jul 6, 2020, at 9:04 AM, C
32 matches
Mail list logo
