[parenscript-devel] Printer inconsistencies as of 60154a
Vladimir Sedach
vsedach at gmail.com
Sat May 5 23:19:44 UTC 2012
I've pushed a patch that reverts pretty-printing except for object
literals. Let me know if anything else looks weird.
Vladimir
On Mon, Apr 2, 2012 at 10:37 PM, Daniel Gackle <danielgackle at gmail.com> wrote:
> < 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
>
>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
More information about the parenscript-devel
mailing list