I am new to Mathematica, have used RStudio before for R and like the feature for brackets' autocompletion. There are plenty of different brackets are used in Mathematica code and it is handy to have same feature there. May be I just missed where the setting for it is?
Go to Insert -> Typesetting to find the keyboard shortcuts for inserting matching [], () or {}. On OS X it's Option-Command-].
There's information on matching brackets in the documentation.
The good news is that this functionality is much less needed in Mathematica than in R. In Mathematica, instead of writing
f[g[h[x]]]
I like to write the completely equivalent but much more readable
f#g#h[x]
Instead of writing
lapply(arr, f)
we would write
f /# arr
in Mathematica. This is equivalent to Map[f, arr] but has no brackets.
It's worth putting in some time to learn how to use these weird looking operators effectively. While it's certainly possible to use them to make your code cryptic and unintelligible, when used correctly, they can improve readability significantly. It just requires experience and a little discipline. I recommend you look at https://mathematica.stackexchange.com/ to get used to the idiomatic use of these operators.
While learning Mathematica keep in mind that there is a subjective (or "cultural") element to "readability". You'll need to get used to the community standards and common idioms before all of this starts making sense. That's why I suggest reading Mathematica.SE.
Update: I forgot to mention the somewhat annoying [[ ... ]] notation for Part. Go to the bottom my Mathematica page to see how to set up keyboard shortcuts for inserting the equivalent but more readable 〚. esc [ esc also works but I find it too tedious.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
So having watched 3 hours of youtube videos, and spent equally long reading about Lisp, I've yet to see these "magic macros" that allow one to write DSLs, or even do simple things like 4 + 5 without nesting this inside some braces.
There is some discussion here: Common lisp: is there a less painful way to input math expressions? but the syntax doesn't look any nicer, and still requires some enclosing fluff to define where the macro starts and ends.
So here is the challenge, define an infix macro, then use it without having to enclose it with some kind of additional syntax. I.e.
Some macro definition here
1 + 2
NOT
Some macro definition here
(my-macro 1 + 2)
NOT
Some macro definition here
ugly-syntax 1 + 2 end-ugly-syntax
If this is not possible in Lisp, then what is all the fuss about? It's kinda like saying "you have awesome powerful macros that allow for cool DSLs, provided those DSLs are wrapped in Lisp like syntax".
Of course you can implement what you're talking about in Lisp.
One big difference between Lisp and other languages is that nothing is fixed and you've control on what the reader does on every single character of the input source code. Literally.
Consider for example the project CL-Python and its mixed-syntax Lisp/Python mode.
Basically in that mode if what you type starts with an open parenthesis then it's considered Lisp, otherwise it's considered Python (including multi-line constructs).
...HOWEVER...
this kind of macro/reader-macro library is implemented rarely, because one of the main advantages of the s-expression approach is that it's well composable and you can build other macros on top of existing macros, raising the level of the language.
Once abandoned the regularity of s-expression approach, writing macros becomes annoying because to write code that manipulates code you need to consider the several different constructs of the language, precedence rules, special rules, special syntax forms.
Languages that are not based on s-expression sometimes provide real macro processing capability but working on the AST level, i.e. after some parsing processing has already been done in a fixed way. Moreover the macro code in these languages looks really weird because the code the macro is manipulating, inspecting or building doesn't look like real code.
Sometimes in other languages instead you only find text-based macros that are basically search-replace. To see an example of how ugly things can get consider the Python standard library implementation of collections.namedtuple (around line 284) and its set of absurd limitations induced just because of that implementation.
Another example of how things can get horribly complex once you force yourself to a template-only approach to avoid the complexity of manipulating an irregular and special cased language is C++ template metaprogramming.
A simple s-expression based language and quasi-quotation instead makes macro code much easier to write and read and understand, and that's why Lisp code doesn't move away from it. Not because it cannot, but because it doesn't make sense to go to a worse syntax for no reason.
In Lisp you "bend" the language a little by adding the abstractions that are really needed without however breaking everything else and, most important, without dropping the ability to do more bending in the future if needed. Writing a macro/reader-macro that makes the expression parsing the nightmare of say C++ and at the same time removes the ability to write further macros and add more constructs (or makes it impossibly hard) would be a nonsensical suicide.
Even a macro like (infix x + y * z) is just an exercise... I doubt that any lisper would use that to write real code... why on earth would someone reintroduce the absurd function/operator duality and the nightmare of precedence/associativity rules? If you don't like Lisp then just don't use Lisp.
For a lisper it's not the (infix and ) part that is ugly... it's what is in the middle.
Also why do you think that 2+3*6 is "naturally" 20? Because the teacher hit you on the palms of your hands with a stick when you were a kid until you got it right?
lately I have been programming a lot with Elixir, and like in ruby, it is expected to write code using snake_case.
But this is starting to get really uncomfortable. Right now it hurts a bit, so I though it would be a good idea to bindunderscore to another key, in which I don't have to press shift.
Is there an easy way of doing that?
Or if you have another tip to avoid that it would be nice as well.
In emacs, the syntactic analysis is surprisingly little.
For example, if I wish to indent parameter names differently than the types in a function declaration, like so:
void myfunction(
int
test
);
int is considered an arglist-intro, and test is considered as arglist-cont. However, if I add any more parameters, they'll all be considered arglist-cont, so indenting arglist-cont wouldn't do the desired effect.
So here's what I'm wondering: Is it possible to make my own syntactic analysis thingy for emacs so that it'll recognize and differentiate cases like this (this isn't the only case, by the way)? And if so, how?
Yes, of course you can write whatever you want. Emacs is free software, it comes with sources, so you can modify them as you wish.
However, please be aware that Emacs is quite widely used, including by some very smart hackers. This means that Emacs limitations usually (but, of course, not always!) have a good reason behind them (in your case, the reason is that the C syntax is quite complex). The implication is that doing what you want to do might be harder than you might be thinking. Not that it should discourage you, of course!
PS. You asked "is it possible to make my own syntactic analysis", not "how to do that" :-)
PPS. As for "how", you will have to start with cc-engine.el.
I'm bewildered by all the built-in Mathematica functions that purport to prevent evaluation in some way: Unevaluated, Defer, Hold, and over half a dozen of the form Hold*. The Mathematica documentation just explains each function in isolation without explaining why you would choose one or the other. Can anyone offer a coherent explanation of all these functions? The whole thing seems like a convoluted mess to me. Relating it all to Lisp macros might be a good place to start.
Most of the Mathematica language is amazingly well-designed but it seems like Wolfram really painted himself into a corner on this aspect. Or I could be missing something.
These are pretty tricky constructs, and it's tough to give clear explanations; they aren't as straightforward as Lisp macros (or, for that matter, the relationship between Lisp's QUOTE and EVAL). However, there's a good, lengthy discussion available in the form of notes from Robby Villegas's 1999 talk "Unevaluated Expressions" on Wolfram's website.
Defer is omitted from that talk, because it's new as of Mathematica 6.0. It's a lot like HoldForm, except that when it's output in a front-end (but not a bare kernel) it's stripped away, leaving an expression that can be used as input. This is very useful if you want to programmatically construct expressions that a user can edit and evaluate, say in a palette.
Depending on my mood I seem to waffle back and forth between wanting a Lisp-1 and a Lisp-2. Unfortunately beyond the obvious name space differences, this leaves all kinds of amusing function name/etc problems you run into. Case in point, trying to write some code tonight I tried to do (map #'function listvar) which, of course, doesn't work in CL, at all. Took me a bit to remember I wanted mapcar, not map. Of course it doesn't help when slime/emacs shows map IS defined as something, though obviously not the same function at all.
So, pointers on how to minimize this short of picking one or the other and sticking with it?
Map is more general than mapcar, for example you could do the following rather than using mapcar:
(map 'list #'function listvar)
How do I keep scheme and CL separate in my head? I guess when you know both languages well enough you just know what works in one and not the other. Despite the syntactic similarities they are quite different languages in terms of style.
Well, I think that as soon you get enough experience in both languages this becomes a non-issue (just with similar natural languages, like Italian and Spanish). If you usually program in one language and switch to the other only occasionally, then unfortunately you are doomed to write Common Lisp in Scheme or vice versa ;)
One thing that helps is to have a distinct visual environment for both languages, using syntax highlighting in some other colors etc. Then at least you will always know whether you are in Common Lisp or Scheme mode.
I'm definitely aware that there are syntactic differences, though I'm certainly not fluent enough yet to automatically use them, making the code look much more similar currently ;-).
And I had a feeling your answer would be the case, but can always hope for a shortcut <_<.
The easiest way to keep both languages straight is to do your thinking and code writing in Common Lisp. Common Lisp code can be converted into Scheme code with relative ease; however, going from Scheme to Common Lisp can cause a few headaches. I remember once where I was using a letrec in Scheme to store both variables and functions and had to split it up into the separate CL functions for the variable and function namespaces respectively.
In all practicality though I don't make a habit of writing CL code, which makes the times that I do have to all the more painful.