Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #58802 > unrolled thread

"Recognizing" a parser generator (and a compiler compiler)

Back to article view | Back to comp.lang.forth

Contents

  "Recognizing" a parser generator (and a compiler compiler) Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:29 -0700
    Re: "Recognizing" a parser generator (and a compiler compiler) hughaguilar96@gmail.com - 2017-05-07 21:57 -0700
      Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-08 09:55 +0100
    Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-08 09:41 +0100
      Re: "Recognizing" a parser generator (and a compiler compiler) Joel Rees <joel.rees@gmail.com> - 2017-05-08 21:07 -0700
        Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-09 07:50 +0100
          Re: "Recognizing" a parser generator (and a compiler compiler) "Elizabeth D. Rather" <erather@forth.com> - 2017-05-08 21:39 -1000
            Re: "Recognizing" a parser generator (and a compiler compiler) "HAA" <someone@microsoft.com> - 2017-05-10 15:27 +1000
              Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-10 08:21 +0100
                Re: "Recognizing" a parser generator (and a compiler compiler) "HAA" <someone@microsoft.com> - 2017-05-10 18:15 +1000
            Re: "Recognizing" a parser generator (and a compiler compiler) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:53 -0700
              Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-10 08:59 +0100
        Re: "Recognizing" a parser generator (and a compiler compiler) mhx@iae.nl - 2017-05-10 02:52 -0700
          Re: "Recognizing" a parser generator (and a compiler compiler) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:59 +0200
            Re: "Recognizing" a parser generator (and a compiler compiler) Joel Rees <joel.rees@gmail.com> - 2017-05-10 05:46 -0700
            Re: "Recognizing" a parser generator (and a compiler compiler) mhx@iae.nl - 2017-05-10 05:48 -0700

#58802 — "Recognizing" a parser generator (and a compiler compiler)

What am I missing, Alex?

I don't write lex and yacc (or flex and bison) in Forth because they just get in the way.

I have <BUILDS, I mean, CREATE DOES>

(Which I was struggling with over the weekend, but that's another story not worth posting about.)

Each word in Forth defines its own syntax. Each word in Forth has its own attached semantics.

A Forth program is explicitly a language.

Or am I way out in left field?

I think, if I were required to write formally provable Forth, I'd prefer to use provable CPU and restrict myself to a provable basic vocabulary, and build from there. (Hasn't this been done at least once?)

--
Joel Rees

Trying to reinvent the industry in my own mind:
http://defining-computers.blogspot.jp/

[toc] | [next] | [standalone]

#58804

On Sunday, May 7, 2017 at 7:29:33 PM UTC-7, Joel Rees wrote:
> What am I missing, Alex?
> 
> I don't write lex and yacc (or flex and bison) in Forth because they just get in the way.

Recognizers are a very bad idea. This is an effort to give Forth syntax --- but a fundamental feature of Forth is that it doesn't have syntax --- most people (including myself) got into Forth originally because it was easy to understand and straight-forward.

Right now, the major problem with ANS-Forth is ambiguity, with every ANS-Forth compiler (SwiftForth, VFX and gForth) being incompatible with each other. Recognizers are just more ambiguity. Lots of Forth-200x aspiring leaders will write recognizers in the hope that they will pick up some followers so they can honestly describe themselves as a leaders. All of these recognizers will clash with each other, so you get a balkanization of Forth-200x. Every program will have to declare a dependency as to which recognizers it requires to be installed for the program to work, so none of the programs will be compatible with each other. In many cases you may have the needed recognizers installed for your program to supposedly work, but your program will still not work because of the order that the recognizers were installed.

The Forth-200x committee fail to understand the purpose of a standard --- portability of programs.

Alex McDonald has said on multiple occasions that he: "does standards for a living." He promotes recognizers because they are gratuitous complexity --- he hopes to get promoted to the Forth-200x committee --- his goal with recognizers is to prove to everybody that he is smarter than they are, or at least to confuse everybody, which is pretty much the same thing: 
"If you can't dazzle 'em with brilliance, then baffle 'em with bull!"

[toc] | [prev] | [next] | [standalone]

#58812

On 5/8/2017 05:57, hughaguilar96@gmail.com wrote:
> On Sunday, May 7, 2017 at 7:29:33 PM UTC-7, Joel Rees wrote:
>> What am I missing, Alex?
>> 
>> I don't write lex and yacc (or flex and bison) in Forth because
>> they just get in the way.
> 
> Recognizers are a very bad idea. This is an effort to give Forth
> syntax --- but a fundamental feature of Forth is that it doesn't have
> syntax --- most people (including myself) got into Forth originally
> because it was easy to understand and straight-forward.

No, it's not an effort to give Forth "syntax". Have you read the 
proposal? It clearly says

    The Forth compiler can be extended easily. The Forth
    interpreter however has a fixed set of capabilities as outlined
    in section 3.4 of the standard text: Words from the dictionary
    and some numbers.

    It's not easily possible to use the Forth text interpreter in
    an application or system extension context. The building blocks
    (FIND, COMPILE,, >NUMBER etc) are available but there is a gap
    between them and what the Forth interpreter does. Applications
    need to use either additional system provided and system
    specific intermediate words (if available) or have to re-invent
    the wheel to use e.g. numbers with a sign or hex numbers with
    the $ prefix.

    Some Forth interpreters have ways to add new data types. That
    makes it possible to use a loadable library to implement new
    data types to be handled like the built-in ones. An example are
    the floating point numbers. They have their own parsing and
    data handling words including a stack of their own.

    To actually handle data in the Forth context, the processing
    actions need to be STATE aware. It would be nice if the Forth
    text interpreter, that maintains STATE, is able to do the data
    processing without exposing STATE to the data handling methods.
    For that the different methods need to be registered somehow.



> 
> Right now, the major problem with ANS-Forth is ambiguity, with every

That's a matter of opinion; you appear to be the only person claiming 
this. "Major" seems to be a bit over dramatic.

> ANS-Forth compiler (SwiftForth, VFX and gForth) being incompatible
> with each other. Recognizers are just more ambiguity. Lots of
> Forth-200x aspiring leaders will write recognizers in the hope that
> they will pick up some followers so they can honestly describe
> themselves as a leaders. 

Sigh. Unlike you, most folks here aren't engaged in dick measuring contests.

> All of these recognizers will clash with
> each other, so you get a balkanization of Forth-200x. Every program
> will have to declare a dependency as to which recognizers it requires
> to be installed for the program to work, so none of the programs will
> be compatible with each other. In many cases you may have the needed
> recognizers installed for your program to supposedly work, but your
> program will still not work because of the order that the recognizers
> were installed.

Complete bollox. This from a man that can't even handle a pointer.

> 
> The Forth-200x committee fail to understand the purpose of a standard
> --- portability of programs.
> 
> Alex McDonald has said on multiple occasions that he: "does standards
> for a living." He promotes recognizers because they are gratuitous
> complexity --- he hopes to get promoted to the Forth-200x committee
> --- his goal with recognizers is to prove to everybody that he is
> smarter than they are, or at least to confuse everybody, which is
> pretty much the same thing: "If you can't dazzle 'em with brilliance,
> then baffle 'em with bull!"
> 

Or write long meaningless posts on CLF. Seems to work for you.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#58808

On 5/8/2017 03:29, Joel Rees wrote:
> What am I missing, Alex?

Am I the Alex you're asking? I'm sorry, I don't have any context for
this question.

> 
> I don't write lex and yacc (or flex and bison) in Forth because they
> just get in the way.

But guessing, I suspect you might be over-reading into the recognizer
proposal the word "parse". In Forth, this does not mean a traditional
parse, but simply identifying a white space delimited word.

> 
> I have <BUILDS, I mean, CREATE DOES>
> 
> (Which I was struggling with over the weekend, but that's another
> story not worth posting about.)
> 
> Each word in Forth defines its own syntax. Each word in Forth has its
> own attached semantics.

That's not strictly true. Words like IF pass semantic clues to their 
corresponding ELSE THEN on the stack.

> 
> A Forth program is explicitly a language.
> 
> Or am I way out in left field?
> 
> I think, if I were required to write formally provable Forth, I'd
> prefer to use provable CPU and restrict myself to a provable basic
> vocabulary, and build from there. (Hasn't this been done at least
> once?)

I'm not sure where this came from.

> 
> -- Joel Rees
> 
> Trying to reinvent the industry in my own mind: 
> http://defining-computers.blogspot.jp/
> 



-- 
Alex

[toc] | [prev] | [next] | [standalone]

#58871

On Monday, May 8, 2017 at 5:41:30 PM UTC+9, Alex wrote:
> On 5/8/2017 03:29, Joel Rees wrote:
> > What am I missing, Alex?
> 
> Am I the Alex you're asking? I'm sorry, I don't have any context for
> this question.

:)

Sorry. This does seem to have been out-of-the-blue.

> > I don't write lex and yacc (or flex and bison) in Forth because they
> > just get in the way.
> 
> But guessing, I suspect you might be over-reading into the recognizer
> proposal the word "parse".

Or the word, "recognizer". 

> In Forth, this does not mean a traditional
> parse, but simply identifying a white space delimited word.

In your Forth, you mean.

But don't we have access to regular expressions?

And, since space is the only delimiter Forth actually recognizes
(not exaggerating much, here), is it wise to try to add such an 
override to the basic language?
 
> > I have <BUILDS, I mean, CREATE DOES>
> > 
> > (Which I was struggling with over the weekend, but that's another
> > story not worth posting about.)
> > 
> > Each word in Forth defines its own syntax. Each word in Forth has its
> > own attached semantics.
> 
> That's not strictly true. Words like IF pass semantic clues to their 
> corresponding ELSE THEN on the stack.

No, it is true. ELSE and THEN are syntactically and semantically parts 
of IF. You haven't properly parsed your IF until you've parsed the 
optional ELSE and the trailing THEN.

The fact that we use further words (sub-words? not really) in parsing
a word does not mean that each of the words in use does not have its 
own syntax and semantics.

> > A Forth program is explicitly a language.
> > 
> > Or am I way out in left field?
> > 
> > I think, if I were required to write formally provable Forth, I'd
> > prefer to use provable CPU and restrict myself to a provable basic
> > vocabulary, and build from there. (Hasn't this been done at least
> > once?)
> 
> I'm not sure where this came from.

Well, I see I was somewhat out in left field on your proposal. But 
I think not very far.

Have you ever used lex and yacc? Or even worked on a program that 
is constructed using them?
 
-- 
Joel Rees
 
Trying to reinvent the industry in my own mind: 
http://defining-computers.blogspot.jp/

[toc] | [prev] | [next] | [standalone]

#58875

On 5/9/2017 05:07, Joel Rees wrote:
> On Monday, May 8, 2017 at 5:41:30 PM UTC+9, Alex wrote:
>> On 5/8/2017 03:29, Joel Rees wrote:
>>> What am I missing, Alex?
>> 
>> Am I the Alex you're asking? I'm sorry, I don't have any context
>> for this question.
> 
> :)
> 
> Sorry. This does seem to have been out-of-the-blue.
> 
>>> I don't write lex and yacc (or flex and bison) in Forth because
>>> they just get in the way.
>> 
>> But guessing, I suspect you might be over-reading into the
>> recognizer proposal the word "parse".
> 
> Or the word, "recognizer".
> 
>> In Forth, this does not mean a traditional parse, but simply
>> identifying a white space delimited word.
> 
> In your Forth, you mean.

No, in all Forths. If you look at the standard, it makes it clear that 
the only elements that are inspected character by character are words 
(whitespace delimited) that may be interpreted as numbers.

> 
> But don't we have access to regular expressions?

No. Unless you use a library, it's not part of standard Forth.

> 
> And, since space is the only delimiter Forth actually recognizes (not
> exaggerating much, here), is it wise to try to add such an override
> to the basic language?

We're not. A recognizer is invoked on whitespace delimited word boundaries.

> 
>>> I have <BUILDS, I mean, CREATE DOES>
>>> 
>>> (Which I was struggling with over the weekend, but that's
>>> another story not worth posting about.)
>>> 
>>> Each word in Forth defines its own syntax. Each word in Forth has
>>> its own attached semantics.
>> 
>> That's not strictly true. Words like IF pass semantic clues to
>> their corresponding ELSE THEN on the stack.
> 
> No, it is true. ELSE and THEN are syntactically and semantically
> parts of IF. You haven't properly parsed your IF until you've parsed
> the optional ELSE and the trailing THEN.

We're going to have to disagree. They have compile-time semantics that 
are different from their run-time semantics for one.

> 
> The fact that we use further words (sub-words? not really) in
> parsing a word does not mean that each of the words in use does not
> have its own syntax and semantics.

That contradicts what you said above?

> 
>>> A Forth program is explicitly a language.
>>> 
>>> Or am I way out in left field?
>>> 
>>> I think, if I were required to write formally provable Forth,
>>> I'd prefer to use provable CPU and restrict myself to a provable
>>> basic vocabulary, and build from there. (Hasn't this been done at
>>> least once?)
>> 
>> I'm not sure where this came from.
> 
> Well, I see I was somewhat out in left field on your proposal. But I
> think not very far.
> 
> Have you ever used lex and yacc? Or even worked on a program that is
> constructed using them?

No, although I have written a burg. (Forth doesn't have a requirement 
for either lex or yacc.)

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#58876

On 5/8/17 8:50 PM, Alex wrote:
> On 5/9/2017 05:07, Joel Rees wrote:
>>
>>>> I have <BUILDS, I mean, CREATE DOES>
>>>>
>>>> (Which I was struggling with over the weekend, but that's
>>>> another story not worth posting about.)
>>>>
>>>> Each word in Forth defines its own syntax. Each word in Forth has
>>>> its own attached semantics.
>>>
>>> That's not strictly true. Words like IF pass semantic clues to
>>> their corresponding ELSE THEN on the stack.
>>
>> No, it is true. ELSE and THEN are syntactically and semantically
>> parts of IF. You haven't properly parsed your IF until you've parsed
>> the optional ELSE and the trailing THEN.
>
> We're going to have to disagree. They have compile-time semantics that
> are different from their run-time semantics for one.

Joel, the thing you have to realize here is that there is *zero* 
"syntactic" connection between IF, ELSE, and THEN. Each is interpreted 
in turn and does whatever it's defined to do. That is, IS compiles 
something followed by a reserved cell usually containing zero, and 
leaves that address on the stack. This location will normally be filled 
in subsequently by either ELSE or THEN, but each of those words is 
completely independent and has no real syntactic connection. Even a 
user-defined word that expects on the compile-time stack the kind of 
address that IF leaves and does something appropriate with it can work. 
In fact, I remember an occasion years ago when one of our programmers 
was grappling with a singularly awkward customer specification defined a 
sequence that went:

	IF ... ELSE ... MAYBE ... THEN ...

Words in Forth have their stack arguments and their semantics (they do 
what they do), and there are expected logical sequences in the mind of 
the programmer, but that is not syntax. When the text interpreter 
finishes compiling what it compiles for IF it's done. There's something 
compiled for a runtime behavior of IF followed by an empty cell there, 
and the cell's address left on the stack, but the *interpreter* has no 
internal expectation of finding any particular words to do something 
about it.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#58923

Elizabeth D. Rather wrote:
> On 5/8/17 8:50 PM, Alex wrote:
> > On 5/9/2017 05:07, Joel Rees wrote:
> >>
> >>>> I have <BUILDS, I mean, CREATE DOES>
> >>>>
> >>>> (Which I was struggling with over the weekend, but that's
> >>>> another story not worth posting about.)
> >>>>
> >>>> Each word in Forth defines its own syntax. Each word in Forth has
> >>>> its own attached semantics.
> >>>
> >>> That's not strictly true. Words like IF pass semantic clues to
> >>> their corresponding ELSE THEN on the stack.
> >>
> >> No, it is true. ELSE and THEN are syntactically and semantically
> >> parts of IF. You haven't properly parsed your IF until you've parsed
> >> the optional ELSE and the trailing THEN.
> >
> > We're going to have to disagree. They have compile-time semantics that
> > are different from their run-time semantics for one.
>
> Joel, the thing you have to realize here is that there is *zero*
> "syntactic" connection between IF, ELSE, and THEN. Each is interpreted
> in turn and does whatever it's defined to do. That is, IS compiles
> something followed by a reserved cell usually containing zero, and
> leaves that address on the stack. This location will normally be filled
> in subsequently by either ELSE or THEN, but each of those words is
> completely independent and has no real syntactic connection.
> ...

ANS defines syntax through the use of 'orig', 'dest', 'of-sys' etc whose
sole purpose is to restrict what you may mix & match legally, if not
practically.

[toc] | [prev] | [next] | [standalone]

#58928

On 5/10/2017 06:27, HAA wrote:
> ANS defines syntax through the use of 'orig', 'dest', 'of-sys' etc whose
> sole purpose is to restrict what you may mix & match legally, if not
> practically.

Let's take DUP. It takes one stack element and produces two. AND OR + - 
and so on all have restrictions as to how they may be used.

http://www.jguru.com/faq/view.jsp?EID=81

This is a good definition of syntax vs semantics.

"A language is a set of valid sentences. What makes a sentence valid? 
You can break validity down into two things: syntax and semantics. The 
term syntax refers to grammatical structure whereas the term semantics 
refers to the meaning of the vocabulary symbols arranged with that 
structure. Grammatical (syntactically valid) does not imply sensible 
(semantically valid), however."

ANS Forth (by this definition) has no syntax, but the semantics for 
every word are important.

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#58945

Alex wrote:
> On 5/10/2017 06:27, HAA wrote:
> > ANS defines syntax through the use of 'orig', 'dest', 'of-sys' etc whose
> > sole purpose is to restrict what you may mix & match legally, if not
> > practically.
>
> Let's take DUP. It takes one stack element and produces two. AND OR + -
> and so on all have restrictions as to how they may be used.
>
> http://www.jguru.com/faq/view.jsp?EID=81
>
> This is a good definition of syntax vs semantics.
>
> "A language is a set of valid sentences. What makes a sentence valid?
> You can break validity down into two things: syntax and semantics. The
> term syntax refers to grammatical structure whereas the term semantics
> refers to the meaning of the vocabulary symbols arranged with that
> structure. Grammatical (syntactically valid) does not imply sensible
> (semantically valid), however."
>
> ANS Forth (by this definition) has no syntax, but the semantics for
> every word are important.

According to dpANS "Forth has a simple, operator-ordered syntax."
3.4.1.2 defines "syntax" as referring execution sequence, control flow
and so on.  It uses the word "semantics" to reference modes of
behavior of a word e.g. "interpretation semantics".

[toc] | [prev] | [next] | [standalone]

#58939

On Tuesday, May 9, 2017 at 4:39:35 PM UTC+9, Elizabeth D. Rather wrote:
> On 5/8/17 8:50 PM, Alex wrote:
> > On 5/9/2017 05:07, Joel Rees wrote:
> >>
> >>>> I have <BUILDS, I mean, CREATE DOES>
> >>>>
> >>>> (Which I was struggling with over the weekend, but that's
> >>>> another story not worth posting about.)
> >>>>
> >>>> Each word in Forth defines its own syntax. Each word in Forth has
> >>>> its own attached semantics.
> >>>
> >>> That's not strictly true. Words like IF pass semantic clues to
> >>> their corresponding ELSE THEN on the stack.
> >>
> >> No, it is true. ELSE and THEN are syntactically and semantically
> >> parts of IF. You haven't properly parsed your IF until you've parsed
> >> the optional ELSE and the trailing THEN.
> >
> > We're going to have to disagree. They have compile-time semantics that
> > are different from their run-time semantics for one.
> 
> Joel, the thing you have to realize here is that there is *zero* 
> "syntactic" connection between IF, ELSE, and THEN.

It's true that they are written to be loosely coupled. But ...

> Each is interpreted 
> in turn and does whatever it's defined to do. That is, IS compiles 

( IF )

> something followed by a reserved cell usually containing zero, and 
> leaves that address on the stack. This location will normally be filled 
> in subsequently by either ELSE or THEN, but each of those words is 
> completely independent and has no real syntactic connection.

In the common implementation. But ...

> Even a 
> user-defined word that expects on the compile-time stack the kind of 
> address that IF leaves and does something appropriate with it can work. 
> In fact, I remember an occasion years ago when one of our programmers 
> was grappling with a singularly awkward customer specification defined a 
> sequence that went:
> 
> 	IF ... ELSE ... MAYBE ... THEN ...

Good thing that you knew your interpreter used the common techniques
so you could define MAYBE to fit the larger syntax.

The fact that Forth words are written as simple nearly context-free
automata does nothing to negate the larger syntax. Nor does the fact 
that you can, at run-time add to the grammar to provide additional 
syntax (and semantics).

Forths are two-stack machines implemented as loose collections of 
state machines. (I'm not talking about the return stack and the 
parameter stack when I say that here, I'm talking about the heap we 
call a dictionary. That's the other stack for the mathematician.)

Each state machine has a grammar and syntax, but the collection is 
also an automaton which has a grammar and syntax.

> Words in Forth have their stack arguments and their semantics (they do 
> what they do), and there are expected logical sequences in the mind of 
> the programmer, but that is not syntax. When the text interpreter 
> finishes compiling what it compiles for IF it's done.

When you say that, you have to understand that you have just described 
the syntax of the larger machine.

> There's something 
> compiled for a runtime behavior of IF followed by an empty cell there, 
> and the cell's address left on the stack, but the *interpreter* has no 
> internal expectation of finding any particular words to do something 
> about it.

Only in the sense of the interpreter as the word (state machine) 
INTERPRET.

The loose collection very much has an expectation. That the expectation 
can be filled by words defined on-the-fly is a separate issue.

Otherwise, we could not meaningfully talk about Forth as a language.

--
Joel Rees

Delusions of being a novelist:
http://reiisi.blogspot.com/p/novels-i-am-writing.html

[toc] | [prev] | [next] | [standalone]

#58940

On 5/10/2017 08:53, Joel Rees wrote:
> The fact that Forth words are written as simple nearly context-free
> automata does nothing to negate the larger syntax. Nor does the fact
> that you can, at run-time add to the grammar to provide additional
> syntax (and semantics).

I'd like to see a formal grammar specification for Forth. Is such a 
thing possible? IMHO about the only words that have this notion are 
parsing words like : VALUE CONSTANT and those that have some form of 
control flow requirements like ; IF THEN ELSE .

-- 
Alex

[toc] | [prev] | [next] | [standalone]

#58951

On Tuesday, May 9, 2017 at 6:07:36 AM UTC+2, Joel Rees wrote:
> On Monday, May 8, 2017 at 5:41:30 PM UTC+9, Alex wrote:
> > On 5/8/2017 03:29, Joel Rees wrote:
> > > What am I missing, Alex?
> > 
[..] 
> Have you ever used lex and yacc? Or even worked on a program that 
> is constructed using them?

Currently I am one of the NGSPICE maintainers. This open source
SPICE program uses lex and yacc to build the interpreter 
for its simulator engine. 

The lex/yacc tools make for *very* difficult reading, and the
make process (2000 files on windows/linux) is true horror.
I am not sure if lex/yacc are helping or just obstructing. 
They are not used consistently and the results are so-so.

There are many places in (NG)SPICE where Forth would
be a dream to work with. E.g. the behavioral sources
build parse-trees that are interpreted (!) by the
simulation engine. This is where *a lot* of run-time
is spend, especially for the kind of circuits I am
interested in. On-the-fly compilation (i.e. Forth)
would be vastly more efficient. I probably should
say "will be" :-)

-marcel

[toc] | [prev] | [next] | [standalone]

#58954

In article <5187a636-8855-4b7a-859f-9f5a06574a45@googlegroups.com>,
 <mhx@iae.nl> wrote:
>On Tuesday, May 9, 2017 at 6:07:36 AM UTC+2, Joel Rees wrote:
>> On Monday, May 8, 2017 at 5:41:30 PM UTC+9, Alex wrote:
>> > On 5/8/2017 03:29, Joel Rees wrote:
>> > > What am I missing, Alex?
>> >
>[..]
>> Have you ever used lex and yacc? Or even worked on a program that
>> is constructed using them?
>
>Currently I am one of the NGSPICE maintainers. This open source
>SPICE program uses lex and yacc to build the interpreter
>for its simulator engine.
>
>The lex/yacc tools make for *very* difficult reading, and the
>make process (2000 files on windows/linux) is true horror.
>I am not sure if lex/yacc are helping or just obstructing.
>They are not used consistently and the results are so-so.
>
>There are many places in (NG)SPICE where Forth would
>be a dream to work with. E.g. the behavioral sources
>build parse-trees that are interpreted (!) by the
>simulation engine. This is where *a lot* of run-time
>is spend, especially for the kind of circuits I am
>interested in. On-the-fly compilation (i.e. Forth)
>would be vastly more efficient. I probably should
>say "will be" :-)

What are the chance for creating a hybrid system?
Not replacing the whole system, but replacing a part
where Forth would be better, then maybe expanding it?
>
>-marcel
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#58973

On Wednesday, May 10, 2017 at 7:00:54 PM UTC+9, Albert van der Horst wrote:
> In article <5187a636-8855-4b7a-859f-9f5a06574a45@googlegroups.com>,
>  <mhx@somewhere> wrote:
> >On Tuesday, May 9, 2017 at 6:07:36 AM UTC+2, Joel Rees wrote:
> >> On Monday, May 8, 2017 at 5:41:30 PM UTC+9, Alex wrote:
> >> > On 5/8/2017 03:29, Joel Rees wrote:
> >> > > What am I missing, Alex?
> >> >
> >[..]
> >> Have you ever used lex and yacc? Or even worked on a program that
> >> is constructed using them?
> >
> >Currently I am one of the NGSPICE maintainers. This open source
> >SPICE program uses lex and yacc to build the interpreter
> >for its simulator engine.
> >
> >The lex/yacc tools make for *very* difficult reading,

My sympathies, and much appreciation.

> > and the
> >make process (2000 files on windows/linux) is true horror.
> >I am not sure if lex/yacc are helping or just obstructing.
> >They are not used consistently and the results are so-so.
> >
> >There are many places in (NG)SPICE where Forth would
> >be a dream to work with. E.g. the behavioral sources
> >build parse-trees that are interpreted (!) by the
> >simulation engine. This is where *a lot* of run-time
> >is spend, especially for the kind of circuits I am
> >interested in. On-the-fly compilation (i.e. Forth)
> >would be vastly more efficient. I probably should
> >say "will be" :-)

Be careful. Replacing one part my ripple into the entire source.

Okay if you have the time and the rest of the team gets on the 
bandwagon, but be careful.

> What are the chance for creating a hybrid system?
> Not replacing the whole system, but replacing a part
> where Forth would be better, then maybe expanding it?

Again, caution is called for here, too. The reasons for 
using yacc and lex include the idea that they can be formally
analyzed (to a certain extent).

When working bottom up, it's easy to construct conflicting 
grammars that work within the target context, but can be 
impossible to formally analyze for broader contexts.

And we really don't have a lot of standardized tools for 
that.

-- 
Joel Rees

Dreaming of becoming a novelist:
http://reiisi.blogspot.com/p/novels-i-am-writing.html

[toc] | [prev] | [next] | [standalone]

#58974

On Wednesday, May 10, 2017 at 12:00:54 PM UTC+2, Albert van der Horst wrote:
> In article <5187a636-8855-4b7a-859f-9f5a06574a45@googlegroups.com>,
>  <mhx@iae.nl> wrote:
> >On Tuesday, May 9, 2017 at 6:07:36 AM UTC+2, Joel Rees wrote:
> >> On Monday, May 8, 2017 at 5:41:30 PM UTC+9, Alex wrote:
> >> > On 5/8/2017 03:29, Joel Rees wrote:
> >> > > What am I missing, Alex?
> >> >
> >[..]
> >> Have you ever used lex and yacc? Or even worked on a program that
> >> is constructed using them?
> >
> >Currently I am one of the NGSPICE maintainers. This open source
> >SPICE program uses lex and yacc to build the interpreter
> >for its simulator engine.
> >
> >The lex/yacc tools make for *very* difficult reading, and the
> >make process (2000 files on windows/linux) is true horror.
> >I am not sure if lex/yacc are helping or just obstructing.
> >They are not used consistently and the results are so-so.
> >
> >There are many places in (NG)SPICE where Forth would
> >be a dream to work with. E.g. the behavioral sources
> >build parse-trees that are interpreted (!) by the
> >simulation engine. This is where *a lot* of run-time
> >is spent, especially for the kind of circuits I am
> >interested in. On-the-fly compilation (i.e. Forth)
> >would be vastly more efficient. I probably should
> >say "will be" :-)
> 
> What are the chance for creating a hybrid system?
> Not replacing the whole system, but replacing a part
> where Forth would be better, then maybe expanding it?

Forth can already call the NGSPICE dll/so. In that
way one can take over the NGSPICE interpreter. It's 
a huge cosmetic improvement, but adds no functionality.

Taking over a standard algorithm inside the 
computing core is more work. It have spent the past
years just to get an understanding of what is going 
on, as there is no documentation to speak off. A 
callback scheme appears to be possible. The biggest 
problem will be to suppress the urge to rewrite 
everything.

-marcel

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web