Here are some of my ideas:
;; this is a simple macro
(mapcar (λ (α) (+ α 10)) '(1 2 3 4))
;; this can be done with a reader macro
(mapcar Λ(+ α 10) '(1 2 3 4)) ;; greek characters are implicit
arguments in alphabetical order
;; this can also be done with a macro
(mapcar (« + 10) '(1 2 3 4)) ;; where '«' is like curry
;; this kind of compose implicitly takes function names as arguments
;; probably needs to be done after read and before compile by
processing the contents recursively
;; CL is not flexible enough to be able to implement easily such
syntax extensions
(find element list :key (a ° b ° c))
;; these are easy
(≠ 1 2)
(≤ 1 3)
(√ 16)
(Σ '(1 2 3 4))
(Π '(1 2 3 4))
;; recursive calls
(defun gcd (a b)
(if (= b 0)
a
(if (< a b)
(↻ b a)
(↻ b (mod a b)))))
and many more...
To type in a greek character one can either type 'lambda' and let
emacs replace it by 'λ' or bind it to a key such as C-l with an
appropriate prefix. It is also possible to type in 'lambda' and let
emacs display it as 'λ' even though the file contains the word
'lambda'. The other special characters could be handled similarily.
And as soon as we forget about storing and editing the code as simple
text files this whole notation issue becomes a matter of taste/
preference per user per session per whatever you want...
levy
On Feb 20, 4:01 am, levy <················@gmail.com> wrote:
> Here are some of my ideas:
>
> ;; this is a simple macro
> (mapcar (λ (α) (+ α 10)) '(1 2 3 4))
>
> ;; this can be done with a reader macro
> (mapcar Λ(+ α 10) '(1 2 3 4)) ;; greek characters are implicit
> arguments in alphabetical order
>
> ;; this can also be done with a macro
> (mapcar (« + 10) '(1 2 3 4)) ;; where '«' is like curry
>
> ;; this kind of compose implicitly takes function names as arguments
> ;; probably needs to be done after read and before compile by
> processing the contents recursively
> ;; CL is not flexible enough to be able to implement easily such
> syntax extensions
> (find element list :key (a ° b ° c))
>
> ;; these are easy
> (≠ 1 2)
> (≤ 1 3)
> (√ 16)
> (Σ '(1 2 3 4))
> (Π '(1 2 3 4))
>
> ;; recursive calls
> (defun gcd (a b)
> (if (= b 0)
> a
> (if (< a b)
> (↻ b a)
> (↻ b (mod a b)))))
>
> and many more...
>
> To type in a greek character one can either type 'lambda' and let
> emacs replace it by 'λ' or bind it to a key such as C-l with an
> appropriate prefix. It is also possible to type in 'lambda' and let
> emacs display it as 'λ' even though the file contains the word
> 'lambda'. The other special characters could be handled similarily.
>
> And as soon as we forget about storing and editing the code as simple
> text files this whole notation issue becomes a matter of taste/
> preference per user per session per whatever you want...
>
> levy
No, no, no.
The only reason why I am programming in fortran and lisp in UPPERCASE
is because I yearn for the good old days.
But seriously, I like the idea very much, except, that the one thing I
like more are, ahem, portability. Would this fly across platforms and
IDE's?
Mirko
·············@gmail.com writes:
> On Feb 20, 4:01 am, levy <················@gmail.com> wrote:
>> Here are some of my ideas:
>>
>> ;; this is a simple macro
>> (mapcar (λ (α) (+ α 10)) '(1 2 3 4))
>>
>> ;; this can be done with a reader macro
>> (mapcar Λ(+ α 10) '(1 2 3 4)) ;; greek characters are implicit
>> arguments in alphabetical order
>>
>> ;; this can also be done with a macro
>> (mapcar (« + 10) '(1 2 3 4)) ;; where '«' is like curry
>>
>> ;; this kind of compose implicitly takes function names as arguments
>> ;; probably needs to be done after read and before compile by
>> processing the contents recursively
>> ;; CL is not flexible enough to be able to implement easily such
>> syntax extensions
>> (find element list :key (a ° b ° c))
>>
>> ;; these are easy
>> (≠ 1 2)
>> (≤ 1 3)
>> (√ 16)
>> (Σ '(1 2 3 4))
>> (Π '(1 2 3 4))
>>
>> ;; recursive calls
>> (defun gcd (a b)
>> (if (= b 0)
>> a
>> (if (< a b)
>> (↻ b a)
>> (↻ b (mod a b)))))
>>
>> and many more...
>>
>> To type in a greek character one can either type 'lambda' and let
>> emacs replace it by 'λ' or bind it to a key such as C-l with an
>> appropriate prefix. It is also possible to type in 'lambda' and let
>> emacs display it as 'λ' even though the file contains the word
>> 'lambda'. The other special characters could be handled similarily.
>>
>> And as soon as we forget about storing and editing the code as simple
>> text files this whole notation issue becomes a matter of taste/
>> preference per user per session per whatever you want...
>>
>> levy
>
> No, no, no.
>
> The only reason why I am programming in fortran and lisp in UPPERCASE
> is because I yearn for the good old days.
>
> But seriously, I like the idea very much, except, that the one thing I
> like more are, ahem, portability. Would this fly across platforms and
> IDE's?
Of course. What matters is not what is in the file, or what you type,
but what is displayed.
When I type (SIGMA '(1 2 3 4)) in my lisp buffers in emacs, it
displays as (Σ '(1 2 3 4)), as part of font-locking, and I'm happy,
but it saves to files as (SIGMA '(1 2 3 4)) and my co-workers are happy,
and my lazy friend can type Alt-S-s, bound to (lambda () (interactive)
(insert "SIGMA")) and be happy too.
It more or less defeats the purpose of Unicode,
but that maintains backward compatibility.
--
__Pascal Bourguignon__
···@informatimago.com (Pascal J. Bourguignon) writes:
> Of course. What matters is not what is in the file, or what you type,
> but what is displayed.
>
> When I type (SIGMA '(1 2 3 4)) in my lisp buffers in emacs, it
> displays as (Σ '(1 2 3 4)), as part of font-locking, and I'm happy,
> but it saves to files as (SIGMA '(1 2 3 4)) and my co-workers are happy,
> and my lazy friend can type Alt-S-s, bound to (lambda () (interactive)
> (insert "SIGMA")) and be happy too.
This sounds pretty cool. Can you give me a hint how to configure that?
I have a hard time coming up with a good "apropos" word for this
functionality...
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Have a look at: http://darcs.informatimago.com/emacs/pjb-sources.el
search for greek-letter-font-lock and pretty-greek.
--
__Pascal Bourguignon__
·························@anevia.com
http://www.anevia.com
On 22 Feb, 14:35, "Leslie P. Polzer" <·············@gmx.net> wrote:
> Does anyone know whether there's something prepackaged for Vim that
> does such stuff?
Ah, I guess the conceal patch does just that.
Leslie
l> ;; CL is not flexible enough to be able to implement easily such
l> syntax extensions
l> (find element list :key (a � b � c))
if you really prefer (a � b � c) to (� a b c), and even (� a � b � c) won't
satisfy you, than perhaps it would be better for you to use some other
programming language.. Fortress?
P� Wed, 20 Feb 2008 13:57:21 +0100, skrev Alex Mizrahi
<········@users.sourceforge.net>:
> l> ;; CL is not flexible enough to be able to implement easily such
> l> syntax extensions
> l> (find element list :key (a � b � c))
>
> if you really prefer (a � b � c) to (� a b c), and even (� a � b � c)
> won't
> satisfy you, than perhaps it would be better for you to use some other
> programming language.. Fortress?
>
>
Unicode is not a rare thing in CL...
--------------
John Thingstad
"John Thingstad" <·······@online.no> writes:
> P� Wed, 20 Feb 2008 13:57:21 +0100, skrev Alex Mizrahi
> <········@users.sourceforge.net>:
>
>> l> ;; CL is not flexible enough to be able to implement easily such
>> l> syntax extensions
>> l> (find element list :key (a � b � c))
>>
>> if you really prefer (a � b � c) to (� a b c), and even (� a � b �
>> c) won't
>> satisfy you, than perhaps it would be better for you to use some other
>> programming language.. Fortress?
>>
>>
>
> Unicode is not a rare thing in CL...
Unicode *does not exist* in CL, but it may be available in
certain CL implementations...
P� Wed, 20 Feb 2008 18:50:53 +0100, skrev Raymond Wiker <···@RawMBP.local>:
> "John Thingstad" <·······@online.no> writes:
>
>> P� Wed, 20 Feb 2008 13:57:21 +0100, skrev Alex Mizrahi
>> <········@users.sourceforge.net>:
>>
>>> l> ;; CL is not flexible enough to be able to implement easily such
>>> l> syntax extensions
>>> l> (find element list :key (a � b � c))
>>>
>>> if you really prefer (a � b � c) to (� a b c), and even (� a � b �
>>> c) won't
>>> satisfy you, than perhaps it would be better for you to use some other
>>> programming language.. Fortress?
>>>
>>>
>>
>> Unicode is not a rare thing in CL...
>
> Unicode *does not exist* in CL, but it may be available in
> certain CL implementations...
... implementations.
In fact it is available in nearly all.
(Read the code and comments)
--------------
John Thingstad
l>>> ;; CL is not flexible enough to be able to implement easily such
l>>> syntax extensions
l>>> (find element list :key (a � b � c))
??>>
??>> if you really prefer (a � b � c) to (� a b c), and even (� a � b � c)
??>> won't satisfy you, than perhaps it would be better for you to use some
??>> other programming language.. Fortress?
??>>
JT> Unicode is not a rare thing in CL...
it's not about unicode, it's about using infix notation instead of prefix.
levy complained that CL is not flexible enough to be able to support infix
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> l>>> ;; CL is not flexible enough to be able to implement easily such
> l>>> syntax extensions
> l>>> (find element list :key (a � b � c))
> ??>>
> ??>> if you really prefer (a � b � c) to (� a b c), and even (� a � b � c)
> ??>> won't satisfy you, than perhaps it would be better for you to use some
> ??>> other programming language.. Fortress?
> ??>>
> JT> Unicode is not a rare thing in CL...
>
> it's not about unicode, it's about using infix notation instead of prefix.
> levy complained that CL is not flexible enough to be able to support infix
IMO, the latter claim is simply false.
Is one permitted to say that Java or C is not capable of adding 2 and
2, since it has no built-in AddTwoAndTwo() operation, or is someone
claiming lack of capability/flexibility obliged to consider that some
things will be possible and the language is flexible enough to
accommodate them without actually requiring the language to
pre-implement them?
The default CL parser is a reader, not an algebraic parser. But it's
under user control and you could change that. A great deal of its
design is intended to accommodate such needs.
Nothing other than mere lack of interest has kept CL programmers from
doing in CL what Vaughan Pratt did in MACLISP when he wrote CGOL. All
of the relevant capabilities are there.
If you want the capability, you can write it. The language designers
provided you a core that was "flexible enough".
Is Fortress "flexible enough" to do the reverse, supporting Lisp notation?
If not, which is the more notationally flexible?
På Fri, 22 Feb 2008 14:09:25 +0100, skrev Kent M Pitman
<······@nhplace.com>:
> "Alex Mizrahi" <········@users.sourceforge.net> writes:
>
>> l>>> ;; CL is not flexible enough to be able to implement easily such
>> l>>> syntax extensions
>> l>>> (find element list :key (a ½ b ½ c))
>> ??>>
>> ??>> if you really prefer (a ½ b ½ c) to (½ a b c), and even (½ a ½ b
>> ½ c)
>> ??>> won't satisfy you, than perhaps it would be better for you to use
>> some
>> ??>> other programming language.. Fortress?
>> ??>>
>> JT> Unicode is not a rare thing in CL...
>>
>> it's not about unicode, it's about using infix notation instead of
>> prefix.
>> levy complained that CL is not flexible enough to be able to support
>> infix
>
> IMO, the latter claim is simply false.
>
> Is one permitted to say that Java or C is not capable of adding 2 and
> 2, since it has no built-in AddTwoAndTwo() operation, or is someone
> claiming lack of capability/flexibility obliged to consider that some
> things will be possible and the language is flexible enough to
> accommodate them without actually requiring the language to
> pre-implement them?
>
> The default CL parser is a reader, not an algebraic parser. But it's
> under user control and you could change that. A great deal of its
> design is intended to accommodate such needs.
>
> Nothing other than mere lack of interest has kept CL programmers from
> doing in CL what Vaughan Pratt did in MACLISP when he wrote CGOL. All
> of the relevant capabilities are there.
>
> If you want the capability, you can write it. The language designers
> provided you a core that was "flexible enough".
>
> Is Fortress "flexible enough" to do the reverse, supporting Lisp
> notation?
>
> If not, which is the more notationally flexible?
I don't think it is lack of ability as much as lack of documentation which
is the problem. This exercise was just a attempt to clearify the power of
reader macros. The idea was to introduce a chapter in the CL cookbook
(probably without the Unicode). But I need to understand it myself first.
--------------
John Thingstad
If you quote me then please quote precisely, I hate politics where
people shuffle and filter words at will!
As I said: 'CL is not flexible enough to be able to implement easily
such
syntax extensions' where _easily_ is key I think.
levy
På Fri, 22 Feb 2008 12:05:31 +0100, skrev Alex Mizrahi
<········@users.sourceforge.net>:
> l>>> ;; CL is not flexible enough to be able to implement easily such
> l>>> syntax extensions
> l>>> (find element list :key (a ½ b ½ c))
> ??>>
> ??>> if you really prefer (a ½ b ½ c) to (½ a b c), and even (½ a ½ b
> ½ c)
> ??>> won't satisfy you, than perhaps it would be better for you to use
> some
> ??>> other programming language.. Fortress?
> ??>>
> JT> Unicode is not a rare thing in CL...
>
> it's not about unicode, it's about using infix notation instead of
> prefix.
> levy complained that CL is not flexible enough to be able to support
> infix
>
>
Guess he was wrong..
--------------
John Thingstad
On febr. 20, 13:57, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> l> ;; CL is not flexible enough to be able to implement easily such
> l> syntax extensions
> l> (find element list :key (a OE b OE c))
>
> if you really prefer (a OE b OE c) to (OE a b c), and even (OE a OE b OE c) won't
> satisfy you, than perhaps it would be better for you to use some other
> programming language.. Fortress?
What a constructive comment, down with mathematics and notations
invented there...
levy