Message Boards Message Boards

2
|
10805 Views
|
15 Replies
|
34 Total Likes
View groups...
Share
Share this post:

[feature req] GUI-item for showing parentheses of grouping

When we write code and don't use parentheses, Mathematica still knows the grouping of expressions and operators, which results in a determined order of execution, because of the system's internal set of rules for priority/precendence. We can and sometimes must control the grouping of expressions/operators by adding parentheses in order to get the desired output. If parentheses aren't needed, we can see in FullForm[] that they get dropped along the way by Mathematica.

My idea/suggestion/feature request (for us to discuss, and for the Wolfram developers to consider) is:

How about a GUI-item, maybe in form of a button or within a context menu, which automatically expands the selected code in-line by adding parentheses for the recognized code structure, thus making the implicit precedence and grouping visible?

When we "multi-click" (double-click, triple-click, quadruple-click, quintuple-click, etc) with the left mouse-button in the middle of any large chunk of code, Mathematica automatically recognizes and selects the next bigger balanced compound expression ("code snippet"): this visual auto-select feature is already helpful in giving us a rough idea about the code line structure from inner to outer expressions. The context menu item "Un/Comment" alters the code by automatically adding $\text{(* *)}$ to the selected code. So why not have a similar context menu item for the auto-selected code snippet called "Show Grouping" or "Explicitize Grouping"?

My idea is powerful. I might be a beginner and always stay at that level but my ideas are great and contribute to the improvement of the Mathematica product, if they get implemented. I would love to hear what the Wolfram developers think of my idea and what the odds are that it gets implemented the sooner the better, thanks.

POSTED BY: Raspi Rascal
15 Replies

Just my two cents on this. When I first started transitioning to functional programming within wolfram language, I had some habits from the procedural and also legacy languages like Ada that I like to keep and Wolfram Language has the flexibility to allow for it. But as I started to code more and more in functional programming style, I suddenly realize that there simple work arounds that is already available.

If you write codes that are to complicated in terms of brackets. Try break it up by naming items

Use TreeForm to see structure

Use RightComposition if you don’t like the inside first of composite functions

Etc.

Being able to work with the brackets of Wolfram Language is one of the key skills. But after three years now programming in functional programming paradigm I have found the above to take care most of my brackets debugging needs

POSTED BY: Jack I Houng

I will offer a view from someone in the development arena but not a part of the User Interface team. This is neither as simple as matching to outer brackets (that successive clicking mentioned) nor Un/Comment. The reason is it will need to account for all elements in an expression rather than just the one highlighted. That is, if you highlight the third element and click twice you get the full expression. You are asking for parenthesizing all elements in this expression, not just the third. So there is more matching to be done. And this will need to be sensitive to the formatting. It can be done for StandardForm and InputForm. For FullForm there is no need. Can it be done for TraditionalForm? I don't know.

Again from the point of view of a developer, I would ask these questions. (1) What problem(s) does this solve? (2) How important is this feature? (3) Can these problems be tackled in different ways? (Obviously item (3) has bearing on item (2)). In this case, the problem solved is one of giving a relatively simple interface for parenthesizing infix and postfix operators. Which has use for say visual purposes (hence possibly is applicable in education environments). That stated, others have shown ways to do this, at least for simple cases, using programmatic means. Were I in the user interface group, and knowing what little I do of the functionality they tackle and the issues they need to address, I myself would not give this above low priority. To be fair, it's not functionality I myself would use, and of course that will have a negative influence on my opinion. But I remain stuck on item (2): is this really so important? Me, I want to have better formatting of mathematics (think: LaTeX layout). I want reliable exporting to PDF. I want better exporting to LaTeX. I'd like an ability to enter bibtex as associations and have it format to bbl. I have a number of other items on my wish list that are less geared to "academic paper" type needs but nonetheless involve the user interface.

I'm not claiming this suggestion lacks merit. I simply do not see it as something in which to sink more than a small amount of time. If it requires more (something I lack the expertise even to guess at) then I'd favor not pursuing it. Again, just my opinion.

POSTED BY: Daniel Lichtblau
Posted 2 years ago

Raspi,

  1. Wolfram Research cares deeply about our customers' feedback and aims to take it into consideration as much as possible.

  2. Any estimate on when any suggestion may get picked up or not will be next to impossible to make, be it now or in a year, given the volume and diversity of suggestions we get as well as the number of either long-term and quickly developing high-priority projects the development teams are working on in the interest of our customers.

Considering point 1., customer-facing teams do reach out to our development teams for comment whenever the interest in particular issues and ideas arises, but given point 2. that information may often not be available at a given point in time.

Best, Peter

POSTED BY: Peter Fleck
Posted 2 years ago

Hi Raspi,

the developers have not rejected this suggestion, but unfortunately I do not have any information whether or when it may be implemented.

It may be advisable to meanwhile limit the use of pre-, post- and in-fix notations for Wolfram Language functions to a certain extent and use other common best coding practices that improve code clarity.

Best, Peter

POSTED BY: Peter Fleck

Thanks Peter for your reply! I conclude that the status of my suggestion/request/idea is then "suspended" for the time being, which is a neutral word for saying that a decision/discussion hasn't been made about the suggestion or has been put on hold (for unknown reasons, maybe lack of manhours/time/urgency/priority) and, once it gets seriously discussed among them with the aim to finally take a decision (to adopt vs. to reject), there could still be a chance of rejection, in the end.

Lemme wait another year (time flies!), but next year I'd surely love to hear a clear status change. Chatting with the developers (phone, lunch, fair, camp, assembly, conference, party, pub, etc), one should be able to get some word/half-baked information out, e.g. if they are fond of the suggestion in principle, and if they could ballpark what the odds are that the feature gets implemented at all.

@Peter Maybe you get a chance to produce the desired bit of information after all … , thanks in advance for your help re this matter. As you could imagine, I would be elated to hear something like "raspi, in favor of just you, I did manage to get a word … and they believe the odds are only 20% that your nice idea gets implemented within the next 5 years, meaning that it's definitely not off the table, it actually made it on the to-do-list schedule (congrats raspi!), flagged with the lowest priority imaginable. So it'll come, but you shouldn't hold your breath since nobody knows what the world, or the team/company for that matter, will look like in 5 years."

POSTED BY: Raspi Rascal

@Peter Fleck Exactly 1.0yr has passed. We, the readers/the public, never learned what happened after your forwarding, e.g. whether the developers had rejected the idea, or not.

Please could someone tell us clearly if the feature request was indeed accepted for future implementation, i.e. my idea landed on the to-do-list schedule and developers have started working on it yet?

Imho, work on improving the User Interface be more important/more urgent in upcoming major Mathematica releases than work on adding more and more uberspecialized functions. Having "three tons" (3879+) of built-in Mathematica functions may be cool and fun but please let's improve the user experience (UX, User Interface, GUI) first. Thanks for your attention, appreciated, Andrews, Germany.

POSTED BY: Raspi Rascal

Thanks for thanking, the prospect (let me have some hopes up for this proposed new feature - your team might decide against it eventually, haha) and your attention @Peter, @Arnoud, @Karl, appreciated ymmd!

Crossing fingers, I would really enjoy and profit from such a feature in the GUI of Mathematica! And not only me, I am sure ::))

I will use your linked Product Feedback Form in future, too. Good to know, thank you.

POSTED BY: Raspi Rascal
Posted 3 years ago

Hi Raspi,

Thank you for your suggestion. I would just like to confirm to you that it has been forwarded to the appropriate developers.

In order to make our technical teams aware of your ideas for improvements, please use our Online Feedback Form so they can learn about it without delay.

Thank you very much!

POSTED BY: Peter Fleck

Hi Raspi,

not really what you want, but here is at least a simple function for examining expressions:

Attributes[makeObvious] = HoldAll;
(* makeObvious[expr_]:=Framed//@HoldForm[expr] *)
makeObvious[expr_] := Map[Framed, HoldForm[expr], {2, Depth[expr] - 1}]

With this we get e.g.:

enter image description here

POSTED BY: Henrik Schachner

Hi Henrik, thank you! Very cool, seems to work well with (smaller?) expressions (e.g. not with the NestWhile[] expression from my earlier post).

Imho it should be feasible to implement the idea, if the Wolfram GUI team likes it. Hope you'd like it!

POSTED BY: Raspi Rascal

Hi Hans, thanks for participating in the discussion. I am fully aware of that functionality: we can leap around with the mouse pointer and then click around (or use your keyboard shortcut) to get an idea of 'the next bigger balanced compound expression'. Even in your example there's quite some clicking (and memorization) involved and once the selection is gone, the information/clarity about the grouping is lost.

My ultrashort algebraic example wasn't a good example anyway. Better examples involve a combination of pure functions, patterns, Boolean operators, conditionals, summation/integration symbols, rules, and alike; there we learn that we must place parentheses! Usually for conciseness and elegance we do not write down superfluous parentheses or we simply forget to write them, when they're needed. Seeing parentheses, even if they are indeed superfluous, can help intelligibility and provides unambiguousness to the reader.

So, your "Ctrl + ." comes first, yes, and for some users/uses it might be enough. It selects a balanced expression and the selection expands to compound expressions depending on the position of the mouse pointer (poor mouse pointer placement shown hehe):

enter image description here

Then my "Show Groupings" comes next, it makes all (or all relevant) groupings within that pre-selected compound expression readily visible to any reader, not just to the person with the keyboard/mouse ;-)

Mind you, on a print-out (paper, book, screenshot) one cannot click around anymore. In such a case, unambiguous code like a+((b/c)*(d^e)) proves to be a good alternative to the reader/debugging user. In summary, "your" and "my" features go well together/belong together/complement each other, yes, but in terms of practical usage they are different enough.

POSTED BY: Raspi Rascal
Posted 3 years ago

Raspi, the feature you request may, in a way, already exist. It is the keyboard shortcut Ctrl + . (That last charcter is a period)

Documentation

enter image description here

enter image description here

enter image description here

enter image description here

POSTED BY: Hans Milton

Yes Sir ! Loving it . That's a primitive yet still good example , thank you . A more involved "input" for the new menu item to process would be:

NestWhile[
  Join @@ Table[
     Table[ReplacePart[s, #1 -> n], {n, #2}] & @@ 
      First@SortBy[{#, 
           Complement[Range@9, s[[First@#]], s[[;; , Last@#]], 
            Catenate@
             Extract[Partition[s, {3, 3}], Quotient[#, 3, -2]]]} & /@ 
         Position[s, 0, {2}], 
        Length@Last@# &], {s, #}] &, {sudoku}, ! FreeQ[#, 0] &]

That is a nesting of five pure functions. The most basic (and trivial) example would be an algebraic code line:

a + b / c * d ^ e

Selecting this code snippet with my mouse, then right-click context menu item "Show Grouping" should transform/expand the selected code snippet in situ ("in-line") to:

a + ((b / c) * (d ^ e)) (*smart transformation*)
(a + ((b / c) * (d ^ e))) (*brute silly transformation*)

Thus making the code snippet more intelligible and debuggable to the reader, if the code is hard to review or doesn't deliver the desired output. Using FullForm[] for understanding in-line code or for debugging purposes is not always the way to go, imho.

POSTED BY: Raspi Rascal

Just so I understand, for something like this:

f /@ g /@ {1,2,3}

You want a keystroke or menu item which adds parentheses, e.g. like so:

f /@ ( g /@ {1,2,3} )

To make the grouping more clear?

POSTED BY: Arnoud Buzing

A basic implementation to parenthesize a selection would be as follows:

b1 = Button["Parenthesize selection", Module[{x},
  x = CurrentValue["SelectionData"];
  NotebookWrite[ButtonNotebook[], RowBox[{"(", x, ")"}]]]]

And this is the inverse (assumes the selection includes the parentheses):

b2 = Button["Unparenthesize selection", Module[{x},
  x = CurrentValue["SelectionData"];
  NotebookWrite[ButtonNotebook[], Part[x, 1, 2]]]]

You can add these buttons to a docked cell to make available for all notebooks:

SetOptions[$FrontEndSession, 
 DockedCells -> {Cell[BoxData[ToBoxes@Row[{b1, b2}]]]}]

Change \ $FrontEndSession to \$FrontEnd to have it persist between restarts of the frontend.

Change things back with:

SetOptions[$FrontEndSession, DockedCells -> {}]

DISCLAIMER: This is just a simple prototype I wrote for you to experiment with. Implementing something like this that is production-grade is quite complicated because it needs to support large amount of edge cases (which this does not do). I won't be able to make improvements upon this, but you are welcome to (and anyone reading this is welcome to). This is not functionality I would use myself, because I prefer to write Wolfram Language code that is human readable in the first place (by limiting the amount of syntactic shortcuts).

POSTED BY: Arnoud Buzing
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract