guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nyacc support for extension languages


From: Nala Ginrut
Subject: Re: nyacc support for extension languages
Date: Mon, 20 Aug 2018 11:56:58 +0800

Super neat!
I think nycc can help to alleviate the pain of writing/tweaking parser, and
let people concentrate on implementing better middle-end then convert to
tree-il.


Matt Wette <address@hidden> 于 2018年8月20日周一 05:31写道:

> On 08/19/2018 02:28 PM, Joshua Branson wrote:
>
> > Matt Wette <address@hidden> writes:
> >
> >> I am working on providing a module to add to the nyacc distribution for
> >> the purpose of generating extension languages, and putting together a
> few
> >> extensions for demo.  So far I'm playing with javascript and matlab.
> >> These languages use a "nx-" prefix to designate them as "nyacc
> extension".
> >> One can interpret "nx" to also mean "not exactly", so "nx-matlab" is not
> >> exactly MATLAB.  It has taken some work to get my yacc like parser to
> >> parse expressions instead of files, so some work has gone into updating
> >> the nyacc parser.  nyacc/parse.scm now has parser generators that
> provide
> >> an #:interactive option and more robust default-reductions for
> generating
> >> parsers which work well in interactive mode.
> >>
> > This is super cool!  Is the goal to eventually make it exactly
> > matlab/exactly javascript?  Or will there always be some portability
> > issues?
> >
> I thought about this a bit.  I think hope for 100% compatibility is not
> there.
> For example, javascript strings are always 16bit code points, whereas
> Guile strings
> are either 8-bit characters or 32-bit code points.
>
> Also, I'd like to "fix" some problems in javascript.  For example
>
> var a = 1;
> if (1) {
>    var a = 2;
> }
> a => 2
> if (1) {
>    let a = 3;
> }
> a => 2
>
> I have made "var" inside blocks illegal. And "let" is not standard, but
> I'm adding it.
>
> I also want to make the underlying data model consistent among languages,
> so that may
> take some "massaging" of the language def's.
>
> Matt
>
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]