[parenscript-devel] Printer inconsistencies as of 60154a
Daniel Gackle
danielgackle at gmail.com
Tue Apr 3 02:37:43 UTC 2012
< What does everyone think of just trying to pretty-print object
literals with multiple members >
Pretty-printing those and whatever JS calls its (foo(), bar())
PROGN-like thing would be the sweet spot. I'd assume the printing
logic would be very similar in both cases.
On Mon, Apr 2, 2012 at 1:09 PM, Vladimir Sedach <vsedach at gmail.com> wrote:
> Pretty-printing is sort of hackish - there's not really any lookahead
> or backtracking, which is why the first example situation happens.
>
> Maybe that whole approach should be scrapped. What does everyone think
> of just trying to pretty-print object literals with multiple members?
> (Before, all the key:values were printed on one line)
>
> Vladimir
>
> On Fri, Mar 30, 2012 at 2:42 AM, Daniel Gackle <danielgackle at gmail.com>
> wrote:
> > I've been trying to upgrade our PS version and have some problems to
> > report. This email concerns issues with the changes to the printer in
> > commit 60154a. Accordingly, the code samples below need to be
> > formatted in a fixed-width font to be readable. Also, they're all in
> > JS rather than PS for obvious reasons. I can provide the corresponding
> > PS forms if desired.
> >
> > First, a simple for loop used to be printed like this:
> >
> > for (var n = 0; n < 10; n += 1) {
> > blah(n);
> > };
> >
> > is now:
> >
> > for (var n = 0; n < 10;
> > n += 1) {
> > blah(n);
> > };
> >
> > Not sure if that was intended, but it's so nonstandard that I can't
> > bear to look at it. If one were going to put line breaks in the for
> > loop declaration, surely there ought to be a line per clause rather
> > than an arbitrary break between the second and third. But three lines
> > is too many and anyway the whole thing is weird; it really belongs
> > on one line.
> >
> > Second, there seem to be bugs in how expressions in a comma-delimited
> > list are line-separated and indented. Apologies for the contrived JS
> > here, but I have to make the lines long enough to trigger an
> > indentation. Code that used to be in one line like this:
> >
> > var obj = (obj3433 = { }, (obj3433.foooooooooooo =
> > 'oooooooooooooooooooooooooooooooo', obj3433.baaaaaaaaar =
> > 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', obj3433));
> >
> > is now being indented like this:
> >
> > var obj = (obj3433 = { },
> > (obj3433.foooooooooooo =
> 'oooooooooooooooooooooooooooooooo',
> > obj3433.baaaaaaaaar = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', obj3433));
> >
> > I like the idea, but it seems the third (and any subsequent) lines
> > ought to be aligned with the second.
> >
> > Here's a real example of the same problem from our code:
> >
> > var bucket = (g4 = m1 - sol[label],
> > (g5 = m2 - sol[label],
> > (g6 = rcplus === 'col' ? rect3437[0] : rect3437[2],
> > (g7 = rcplus === 'col' ? rect3437[1] : rect3437[3],
> > rc === 'col' ? [g4, g5, g6, g7] : [g6, g7, g4, g5]))));
> >
> > There are other more complex examples of nested grouped expressions
> > that are coming out pretty strangely:
> >
> > var sh = (
> > obj3439 = { markup : packIgrid(markup), tiling :
> csh.tiling,
> > ultc : ultc,
> > ultr : ultr },
> > (
> > (g3 = (it = csh.coldeltas, it != null && it !== false ? xcopy(it) :
> null),
> > g3 != null ? (obj3439.coldeltas = g3) : null),
> > (
> > g4 = (it3440 = csh.rowdeltas,
> > it3440 != null && it3440 !== false ? xcopy(it3440) : null),
> > g4 != null ? (obj3439.rowdeltas = g4) : null),
> > obj3439));
> >
> > It does seem like a good idea to not have all this on one line, but
> > it's far from clear what the indentation policy is.
> >
> > Similar inconsistencies afflict curly braces:
> >
> > queueMsg(brl, {
> > acknowledge : true }, mailbox);
> >
> > or:
> >
> > return ss.appointmentTicket = { col : c + (cols || 0),
> > row : r + (rows || 0) };
> >
> > and here's a monster one:
> >
> > var REGRESSIONS = [{ type : 'js', target : 'ff', file1 : 'f1', file2 :
> 'f2'
> > }, {
> >
> > type : 'js',
> >
> > target : 'ie6',
> >
> > file1 : 'ie61',
> >
> > file2 : 'ie62' }, {
> >
> > type : 'js',
> >
> > target : 'ie7',
> >
> > file1 : 'ie71',
> >
> > file2 : 'ie72' }, {
> >
> > type : 'js',
> >
> > target : 'ie8',
> >
> > file1 : 'ie81',
> >
> > file2 : 'ie82' }, {
> >
> > type :
> > 'js',
> >
> > target :
> > 'safari',
> >
> > file1 :
> > 'saf1',
> >
> > file2 :
> > 'saf2' }, {
> >
> >
> > type : 'js',
> >
> >
> > target : 'chrome',
> >
> >
> > file1 : 'chr1',
> >
> >
> > file2 : 'chr2' }, {
> >
> >
> > type : 'js',
> >
> >
> > target : 'node',
> >
> >
> > file1 : 'n1',
> >
> >
> > file2 : 'n2' }, {
> >
> >
> > type : 'html',
> >
> >
> > target : 'ff',
> >
> >
> > file1 : 'hf1',
> >
> >
> > file2 : 'hf2' }, {
> >
> >
> > type :
> > 'html',
> >
> >
> > target
> :
> > 'ie6',
> >
> >
> > file1 :
> > 'hie61',
> >
> >
> > file2 :
> > 'hie62' }, {
> >
> >
> >
> > type : 'html',
> >
> >
> >
> > target : 'ie7',
> >
> >
> >
> > file1 : 'hie71',
> >
> >
> >
> > file2 : 'hie72' }, {
> >
> >
> >
> > type : 'html',
> >
> >
> >
> > target : 'ie8',
> >
> >
> >
> > file1 : 'hie81',
> >
> >
> >
> > file2 : 'hie82' }, {
> >
> >
> >
> > type : 'html',
> >
> >
> >
> > target : 'safari',
> >
> >
> >
> > file1 : 'hsaf1',
> >
> >
> >
> > file2 : 'hsaf2' }, {
> >
> >
> >
> >
> > type : 'html',
> >
> >
> >
> >
> > target : 'chrome',
> >
> >
> >
> >
> > file1 : 'hchr1',
> >
> >
> >
> >
> > file2 : 'hchr2' }, {
> >
> >
> >
> >
> > type : 'css',
> >
> >
> >
> >
> > target : 'chrome',
> >
> >
> >
> >
> > file1 : 'c1',
> >
> >
> >
> >
> > file2 : 'c2' }, {
> >
> >
> >
> >
> > type : 'css',
> >
> >
> >
> >
> > target : 'ie8',
> >
> >
> >
> >
> > file1 : 'ie1',
> >
> >
> >
> >
> > file2 : 'ie2' }];
> >
> > I have some respect for how much harder this problem is than it
> > appears to be, having worked on similar issues for our Numen REPL and
> > not being too happy with what I came up with. That being said, these
> > changes to the printer probably make the JS less readable in our case
> > rather than more readable. It would be better to do less and have it
> > be consistent. At a minimum, I hope we can fix the more indecorous
> > areas.
> >
> > Daniel
> >
> >
> >
> >
> > _______________________________________________
> > parenscript-devel mailing list
> > parenscript-devel at common-lisp.net
> > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
> >
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20120402/aa70c68f/attachment.html>
More information about the parenscript-devel
mailing list