Is there any readers that do this.
Python is great, it uses 2d and don't make us to live in one long line
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new member
programmer dvorak is better :)
On Feb 9, 2013 3:39 PM, "vemv" wrote:
> I like the parentheses better. My only complaint is that I have to press
>> the shift key to type them.
>>
>
> You can always remap your keyboard / keyboard bindings. For example in
> emacs:
>
> (define-key clojure-mode-map "9
For those too young to have seen this:
http://www.globalnerdy.com/2009/02/05/hacklabtos-lisp-machine-keyboard/
--
Softaddicts sent by ibisMail from my ipad!
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to c
:))
Luc P.
> ITT: emacs users complaining about modifier keys.
>
> Sorry, but as a Vim guy, I couldn't help laughing.
> On Feb 9, 2013 6:46 PM, "Gregory Graham" wrote:
>
> >
> > I like the parentheses better. My only complaint is that I have to press
> >>> the shift key to type them.
> >>
ITT: emacs users complaining about modifier keys.
Sorry, but as a Vim guy, I couldn't help laughing.
On Feb 9, 2013 6:46 PM, "Gregory Graham" wrote:
>
> I like the parentheses better. My only complaint is that I have to press
>>> the shift key to type them.
>>>
>>
>> You can always remap your ke
> I like the parentheses better. My only complaint is that I have to press
>> the shift key to type them.
>>
>
> You can always remap your keyboard / keyboard bindings. For example in
> emacs:
>
> (define-key clojure-mode-map "9" 'paredit-open-round)
>
Thank-you, I'll try that.
--
--
You r
>
> I like the parentheses better. My only complaint is that I have to press
> the shift key to type them.
>
You can always remap your keyboard / keyboard bindings. For example in
emacs:
(define-key clojure-mode-map "9" 'paredit-open-round)
--
--
You received this message because you are su
Unless the function is threaded (->), the function call is always in the
car position in a list, the args are the cdr elements.
On Feb 8, 2013 5:41 AM, "Max Gonzih" wrote:
> I can't understand how to distinguish where is function call and where
> is var in function arguments. Should it be indent
I can't understand how to distinguish where is function call and where
is var in function arguments. Should it be indented too?
On 02/08/2013 01:14 PM, faenvie wrote:
>>A simple workaround I've considered, but haven't gotten around to doing anything about in e.g.
Emacs, is to simply tone down t
>>A simple workaround I've considered, but haven't gotten around to doing
anything about in e.g. Emacs, is to simply tone down the parens visually in
the editor.
Just last week i was astouned how readable clojure is, when its proper
indented and the parenteses are invisible. This insight came u
2013/2/7 Herwig Hochleitner :
> On Feb 4, 2013 7:58 PM, "Dave Sann" wrote:
>>
>> The syntax does complect in one case.
>> When you really do want a list as opposed to a function call. hence quote
>> and (list ...)
>
>
> The evaluation rules are clojure's implementation of reduction in lambda
> cal
yes, I did not mean to imply otherwise.
On Friday, 8 February 2013 09:04:43 UTC+11, Jason Lewis wrote:
>
> `quote` is a feature, not a bug. Its not just for distinguishing between
> lists and function calls, its for deferring evaluation. Its also been part
> of Lisp since the beginning... IIRC,
On Feb 4, 2013 7:58 PM, "Dave Sann" wrote:
> The syntax does complect in one case.
> When you really do want a list as opposed to a function call. hence quote
> and (list ...)
>
The evaluation rules are clojure's implementation of reduction in lambda
calculus.
Every clojure form has an associate
`quote` is a feature, not a bug. Its not just for distinguishing between
lists and function calls, its for deferring evaluation. Its also been part
of Lisp since the beginning... IIRC, its in McCarthy's paper that defined
the first lisp.
On Feb 4, 2013 7:58 PM, "Dave Sann" wrote:
> The syntax do
Having worked with a number of languages sensitive to white spaces including
"magic" columns reminiscent of the paper cards, I honestly do not find any
sex-appeal in a syntax relying on spaces, line breaks and indentation.
It's error prone, errors are harder to detect, and breaks the tool chain.
If someone does write a Lisp with significant whitespace, can we please
call it "Whitespathe"?
On 7 February 2013 10:30, Marco Munizaga wrote:
> We had this talk with scheme. They called it I expressions. Here is the
> link http://srfi.schemers.org/srfi-49/srfi-49.html
>
> Do it because you can,
We had this talk with scheme. They called it I expressions. Here is the link
http://srfi.schemers.org/srfi-49/srfi-49.html
Do it because you can, and so you can decide for yourself what to think about
it.
--
--
You received this message because you are subscribed to the Google
Groups "Clojur
Actually I think python style indention will over-complicate code. When
writing python style clojure you will always need to think in which clojure
with parentheses it will be transformed.
Personally I love parentheses. Imho Lisp is easy and S-expressions are
awesome :)
On Monday, February 4,
Please No!!
I don't think it would help newcomers at all - it takes only a few days to
get used to s-expressions. Coming from a C/Java world I found significant
whitespace in Python to be just as much of a mental leap. And it would
cause enormous confusion if two different syntaxes were in use.
Orthodox synonyms:
according to the book, acknowledged, admitted, approved, authoritative,
buttoned-down, by the numbers, canonical, conformist, conservative,
conventional, correct, customary, devout, die-hard, doctrinal, established, in
line, legitimate, official, old-line, pious, proper, punc
2013/2/4 Sergey Didenko
> My point is to introduce a second-class syntax to attract orthodox
> users. Definitely not migrating.
>
OK, I can see how I missed that point. I would say then: go ahead,
transform a couple of clojure source files to that style and see, if you
can lure someone orthodox
>
> A simple workaround I've considered, but haven't gotten around to doing
> anything about in e.g. Emacs, is to simply tone down the parens visually in
> the editor. Hierarchy of color, size, contrast, etc. matters a lot in
> perception, and by making the parens slightly less obvious visual
Having written Python code professionally for about 7 years and taken to
Clojure as a serious hobby for a year and a half, I have thought a lot
about the differences between the two languages.
While parens provide simple and powerful homoiconicity (and they have a
somewhat pleasing aesthetic --
When I taught myself Scheme and Common Lisp more than ten years ago, I
didn't have any problem with the parentheses, probably because I just
learned a little bit of C/C++ or Pascal (Delphi) and were eager to
learn Emacs (one of the two major editors in the Unix/Linux world)
when I switched to the t
On Feb 5, 2013, at 12:15 AM, Rich Morin wrote:
> On Feb 4, 2013, at 19:49, deliminator wrote:
>> Long story short: want more people to love lisp?
>> Implement paredit for more editors.
>
> +1!
-1
Just another data point and YMMV, but I've long loved Lisp and long hated
paredit. I do agree, ho
On Feb 4, 2013, at 19:49, deliminator wrote:
> Long story short: want more people to love lisp?
> Implement paredit for more editors.
+1!
-r
--
http://www.cfcl.com/rdmRich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Sof
I believe the parenthesis issue is best addressed in the editor. Emacs for
example has paredit. Problem is, not all editors have an equivalent to
paredit.
A colleague uses sublime text, for which there is (or was) no paredit
equivalent. It was painful watching him getting tripped up over unbala
I used to be a big Python user, and I liked the use of whitespace for
structure back then. The only time it caused me a problem was when cutting
and pasting code fragments, which didn't happen very often. Now that I've
been using Racket (Scheme) and Clojure for a while, I like the parentheses
b
If you just think about the impacts of removing the top most parens and how you
could hide this to tools like macros that may fiddle with your sexps you can
only
conclude that such a change is unlikely to happen. Plus changes to the
compiler, IDEs, etc ...
Phthon has the following delimiters:
h
The syntax does complect in one case.
When you really do want a list as opposed to a function call. hence quote
and (list ...)
On Tuesday, 5 February 2013 07:06:37 UTC+11, tbc++ wrote:
>
> Parens actually don't complect, they have a very very clear meaning. They
> organize functions and argumen
I love the parenthesis please dont take them away ;) I dont want to
learn a language syntax. I want a language "without a syntax" . And thats
why i love clojure .
Josh
On Tue, Feb 5, 2013 at 2:57 AM, Leonardo Borges wrote:
> Honestly I find myself missing S-Expressions in other languages
Honestly I find myself missing S-Expressions in other languages now.
The structure they provide is extremely useful in my opinion -
especially when writing macros.
Also, syntax is only one of the many facets of Clojure - if all the
benefits and features Clojure provides doesn't cut it for newcomer
The problem of readability of S-expressions has been discussed since the
beginnings of Lisp.
Some known alternative notations:
http://en.wikipedia.org/wiki/M-expression
http://readable.sourceforge.net/
On Mon, 4 Feb 2013 22:01:30 +0200
Sergey Didenko wrote:
> Hi,
>
> For us as Clojure communi
On Feb 4, 2013, at 5:33 PM, Rich Morin wrote:
>> Significant white space is the most horrifying development in programming
>> languages in the last 20 years.
>
> Oh, I think it has some competition there (but mostly agree).
>
>
>> Please kill this thread.
>
> There, I disagree. Clojurists sh
On Feb 4, 2013, at 15:15, Jason Lewis wrote:
> Significant white space is the most horrifying development in programming
> languages in the last 20 years.
Oh, I think it has some competition there (but mostly agree).
> Please kill this thread.
There, I disagree. Clojurists should be open to th
Significant white space is the most horrifying development in programming
languages in the last 20 years. Please kill this thread.
On Feb 4, 2013 5:25 PM, "Armando Blancas" wrote:
> What do you think?
>
>
> I think, go right ahead and give it to them. Worst that could happen is
> you gain insight
>
> What do you think?
I think, go right ahead and give it to them. Worst that could happen is you
gain insights into language design. I'd be interested in your users'
comments; what worked, what didn't. If you really believe in that idea,
don't give it up before you learn something from it
On Feb 4, 2013, at 2:01 PM, Sergey Didenko wrote:
> For example the following quicksort implementation
>
> (defn qsort [[pivot & xs]]
> (when pivot
>(let [smaller #(< % pivot)]
> (lazy-cat (qsort (filter smaller xs))
> [pivot]
> (qsort (remove smaller xs
Again, I don't think it will help attract new users, at least not the way
we want. Parentheses are an important part of the language and it's not
something a beginner can just pick up later. If they're scared of
parentheses now, they'll be scared when they try to jump from this
paren-lite syntax to
My point is to introduce a second-class syntax to attract orthodox
users. Definitely not migrating.
The rules of transformation can be so simple that any useful library
written by Clojure Python style adopters could be translated to the
canonical style automatically with a few line program.
> I c
I can't see the community migrating to such a syntax, even if somebody
bothered to implement a reader for it.
For me, the parentheses are vital in editing my source code. With lisp, I'm
editing faster than with any other language, thanks to paredit.
Regarding people seeing parens as an obstacle: O
If someone is able to show me the homoiconity expressed in a better way than
clojure I'll buy it.
mimmo
On Feb 4, 2013, at 9:15 PM, Sergey Didenko wrote:
> Unfortunately I don't know Python good enough to answer this. The
> point though is just to mimic Python a very tiny bit. Basically to
> co
Sergey's example code seems to have arguments to a function happen on the
same line while new function calls appear on new lines. So:
filter
smaller xs
...would be the equivalent of filter(smaller(xs)).
Anyway, I agree that parens don't add any more clutter. Having to *always*
have all the arg
Unfortunately I don't know Python good enough to answer this. The
point though is just to mimic Python a very tiny bit. Basically to
convert some of "(" and ")" to indentations.
> Sois that the python equivalent to which of these?
> filter(smaller(xs))
> filter(smaller, xs)
> filter(smaller(),
The main point is to reach new market by providing parentheses-lite
Clojure syntax.
Of course real serious Clojurians will be using the current syntax :)
> Parens actually don't complect, they have a very very clear meaning. They
> organize functions and arguments. Let's take one line from your e
Parens actually don't complect, they have a very very clear meaning. They
organize functions and arguments. Let's take one line from your example:
filter smaller xs
Sois that the python equivalent to which of these?
filter(smaller(xs))
filter(smaller, xs)
filter(smaller(), xs())
filter(small
Hi,
For us as Clojure community it is easy to see how Clojure benefits
from being a Lisp. Homoiconity, extreme conciseness, esoteric look and
feel, etc.
However it is hard to see from the inside how Clojure as ecosystem
(probably) suffer from being a Lisp. Please don't throw rotten eggs at
me, I
47 matches
Mail list logo
