To me, as a newbie common-lisper (I am in my 2nd year - still wet behind the ears), these are three of the many features that I simply wished were in my daily-work languages (C++ and sons): - The iteration cycle -- the best old idea - modify your application as it runs. It's dirty, mostly non-deterministic, and you might not be able to reproduce the same steps if you started again, but hey - sometimes you just need to attach to your stuff change it on the fly and keep going - without hefty restarts. - Dynamic special variables -- the ability to "hook" and change something deep, communicating with it through a *special* medium created at lexical scope (binding). This is just too awesome to skip in other languages! I miss it a lot! It's not a global variable really - it's more than that literally! - Multiple Value Returns -- and not like Python, where you need to take care of not caring about values you do not care - this simply beats everything else I've used! You can safely extend your API with cases that you have not accounted for, and still the old code would work just fine. - The CLOS multiple-dispatch -- this is the best idea I've heard in all the OO I did - combined with the eql matching - this is so much needed techniquie - no more visitor pattern indeed. I've actually grokked the visitor pattern, after I understood how the multiple-dispatch works.
Off course there are others things: macroses, exception-handling, etc and many others... But I'm still learning these, so I can't tell yet.
Dimiter "malkia" Stanev wrote: > To me, as a newbie common-lisper (I am in my 2nd year - still wet > behind the ears), these are three of the many features that I simply > wished were in my daily-work languages (C++ and sons): > - The iteration cycle -- the best old idea - modify your > application as it runs. It's dirty, mostly non-deterministic, and you > might not be able to reproduce the same steps if you started again, but > hey - sometimes you just need to attach to your stuff change it on the > fly and keep going - without hefty restarts. > - Dynamic special variables -- the ability to "hook" and change > something deep, communicating with it through a *special* medium created > at lexical scope (binding). This is just too awesome to skip in other > languages! I miss it a lot! It's not a global variable really - it's > more than that literally!
so far so good.
> - Multiple Value Returns -- and not like Python, where you need > to take care of not caring about values you do not care - this simply > beats everything else I've used! You can safely extend your API with > cases that you have not accounted for, and still the old code would work > just fine. > - The CLOS multiple-dispatch -- this is the best idea I've heard > in all the OO I did - combined with the eql matching - this is so much > needed techniquie - no more visitor pattern indeed. I've actually > grokked the visitor pattern, after I understood how the > multiple-dispatch works.
two things that are indeed special and I use 0.1% of the time. Not sure how that multiplies out.
> Off course there are others things: macroses, exception-handling, > etc and many others... But I'm still learning these, so I can't tell yet.
Yes, it is a list, macros possibly being the only thing some other language will not have. Hell, even Scheme does not have useful macros.
On Tue, 27 Jan 2009 18:45:17 -0800, <mal...@mac.com> wrote: >What gives you power in CL, that you don't have in other languages
It's a blind men and the elephant situation. For instance:
> - Multiple Value Returns -- and not like Python, where you need to > take care of not caring about values you do not care - this simply beats > everything else I've used! You can safely extend your API with cases > that you have not accounted for, and still the old code would work just > fine.
I've done that, and until I read this, I never would have mentioned it as a 'power' in that elephant.
> To me, as a newbie common-lisper (I am in my 2nd year - still wet > behind the ears), these are three of the many features that I simply > wished were in my daily-work languages (C++ and sons): > - The iteration cycle -- the best old idea - modify your > application as it runs. It's dirty, mostly non-deterministic, and you > might not be able to reproduce the same steps if you started again, but > hey - sometimes you just need to attach to your stuff change it on the > fly and keep going - without hefty restarts. > - Dynamic special variables -- the ability to "hook" and change > something deep, communicating with it through a *special* medium created > at lexical scope (binding). This is just too awesome to skip in other > languages! I miss it a lot! It's not a global variable really - it's > more than that literally! > - Multiple Value Returns -- and not like Python, where you need to > take care of not caring about values you do not care - this simply beats > everything else I've used! You can safely extend your API with cases > that you have not accounted for, and still the old code would work just > fine. > - The CLOS multiple-dispatch -- this is the best idea I've heard in > all the OO I did - combined with the eql matching - this is so much > needed techniquie - no more visitor pattern indeed. I've actually > grokked the visitor pattern, after I understood how the > multiple-dispatch works.
> Off course there are others things: macroses, exception-handling, etc > and many others... But I'm still learning these, so I can't tell yet.
Multiple value returns are something I really miss in C#, I could mimic with references but it's not the same thing. Lambda, very convenient. High order functions. ... Though other langauges have many of those, they are usually not well integrated, unnatural and cumbersome to use. Something like making octopus by adding extra legs to a dog. So it's very important if language integrates some feature else nobody will use it, except some experts in a pissing contests.
1. Writing a compiler to compile LISP programs into machine language. 2. Writing a program to check proofs in a class of formal logical systems. 3. Writing programs for formal differentiation and integration. 4. Writing programs to realize various algorithms for generating proofs in predicate calculus. 5. Making certain engineering calculations whose results are formulas rather than numbers. 6. Programming the Advice Taker system.
'code as data' is then an application of computing with symbol expressions.
On Jan 27, 8:43 pm, GP lisper <spamb...@CloudDancer.com> wrote:
> On Tue, 27 Jan 2009 18:45:17 -0800, <mal...@mac.com> wrote: > >What gives you power in CL, that you don't have in other languages
> It's a blind men and the elephant situation. For instance:
> > - Multiple Value Returns -- and not like Python, where you need to > > take care of not caring about values you do not care - this simply beats > > everything else I've used! You can safely extend your API with cases > > that you have not accounted for, and still the old code would work just > > fine.
> I've done that, and until I read this, I never would have mentioned it > as a 'power' in that elephant.
Indeed. Lisp has many advantages, but Multiple Value Returns is much nicer done in FORTH (or other stack oriented languages?). Now FORTH might be a good idea which time has come and gone and I don't really miss stack counting, but it has some beauty to it.
guenth...@gmail.com wrote: > Now FORTH might be a good idea which time has come and gone and I don't really > miss stack counting, but it has some beauty to it.
I have tried Factor recently, a Factor/Lisp/Joy-inspired stack language.. it is quite fun, although I have no idea how to get useful stuff done with it.
> The real unique distinctive of Lisp is that it's absolutely > invincible. > So you can either love it or hate (read: envy) it, but you can't beat > it...
I've beaten it many times, but the religious zealots refused to admit it.
>> On 28 Gen, 03:45, "Dimiter \"malkia\" Stanev" <mal...@mac.com> wrote: >>> Lisp >> The real unique distinctive of Lisp is that it's absolutely >> invincible. >> So you can either love it or hate (read: envy) it, but you can't beat >> it...
> I've beaten it many times, but the religious zealots refused > to admit it.
> Dimiter "malkia" Stanev wrote: > > To me, as a newbie common-lisper (I am in my 2nd year - still wet > > behind the ears), these are three of the many features that I simply > > wished were in my daily-work languages (C++ and sons): > > - The iteration cycle -- the best old idea - modify your > > application as it runs. It's dirty, mostly non-deterministic, and you > > might not be able to reproduce the same steps if you started again, but > > hey - sometimes you just need to attach to your stuff change it on the > > fly and keep going - without hefty restarts. > > - Dynamic special variables -- the ability to "hook" and change > > something deep, communicating with it through a *special* medium created > > at lexical scope (binding). This is just too awesome to skip in other > > languages! I miss it a lot! It's not a global variable really - it's > > more than that literally!
> so far so good.
> > - Multiple Value Returns -- and not like Python, where you need > > to take care of not caring about values you do not care - this simply > > beats everything else I've used! You can safely extend your API with > > cases that you have not accounted for, and still the old code would work > > just fine. > > - The CLOS multiple-dispatch -- this is the best idea I've heard > > in all the OO I did - combined with the eql matching - this is so much > > needed techniquie - no more visitor pattern indeed. I've actually > > grokked the visitor pattern, after I understood how the > > multiple-dispatch works.
> two things that are indeed special and I use 0.1% of the time. Not sure > how that multiplies out.
> > Off course there are others things: macroses, exception-handling, > > etc and many others... But I'm still learning these, so I can't tell yet.
> Yes, it is a list, macros possibly being the only thing some other > language will not have. Hell, even Scheme does not have useful macros.
asand...@gmail.com wrote: > On Jan 28, 2:56 am, Kenneth Tilton <kentil...@gmail.com> wrote: >> Dimiter "malkia" Stanev wrote: >>> To me, as a newbie common-lisper (I am in my 2nd year - still wet >>> behind the ears), these are three of the many features that I simply >>> wished were in my daily-work languages (C++ and sons): >>> - The iteration cycle -- the best old idea - modify your >>> application as it runs. It's dirty, mostly non-deterministic, and you >>> might not be able to reproduce the same steps if you started again, but >>> hey - sometimes you just need to attach to your stuff change it on the >>> fly and keep going - without hefty restarts. >>> - Dynamic special variables -- the ability to "hook" and change >>> something deep, communicating with it through a *special* medium created >>> at lexical scope (binding). This is just too awesome to skip in other >>> languages! I miss it a lot! It's not a global variable really - it's >>> more than that literally! >> so far so good.
>>> - Multiple Value Returns -- and not like Python, where you need >>> to take care of not caring about values you do not care - this simply >>> beats everything else I've used! You can safely extend your API with >>> cases that you have not accounted for, and still the old code would work >>> just fine. >>> - The CLOS multiple-dispatch -- this is the best idea I've heard >>> in all the OO I did - combined with the eql matching - this is so much >>> needed techniquie - no more visitor pattern indeed. I've actually >>> grokked the visitor pattern, after I understood how the >>> multiple-dispatch works. >> two things that are indeed special and I use 0.1% of the time. Not sure >> how that multiplies out.
>>> Off course there are others things: macroses, exception-handling, >>> etc and many others... But I'm still learning these, so I can't tell yet. >> Yes, it is a list, macros possibly being the only thing some other >> language will not have. Hell, even Scheme does not have useful macros.
>> kth
> It depends on what you call "useful".
Here, I'll use it in a sentence:
"Anyone not clear on the meaning of useful would love writing macros in Scheme."
Dimiter "malkia" Stanev wrote: > - Multiple Value Returns -- and not like Python, where you need to > take care of not caring about values you do not care - this simply beats > everything else I've used! You can safely extend your API with cases > that you have not accounted for, and still the old code would work just > fine.
Multiple values are handled much more elegantly in other languages, like tuples in OCaml, Haskell and F#.
> - The CLOS multiple-dispatch -- this is the best idea I've heard in > all the OO I did - combined with the eql matching - this is so much > needed techniquie - no more visitor pattern indeed. I've actually > grokked the visitor pattern, after I understood how the > multiple-dispatch works.
Pattern matching is related but not a replacement for multiple dispatch that you may like to look at.
On 2009-01-30, Jon Harrop <j...@ffconsultancy.com> wrote:
> Dimiter "malkia" Stanev wrote: >> - Multiple Value Returns -- and not like Python, where you need to >> take care of not caring about values you do not care - this simply beats >> everything else I've used! You can safely extend your API with cases >> that you have not accounted for, and still the old code would work just >> fine.
> Multiple values are handled much more elegantly in other languages, like > tuples in OCaml, Haskell and F#.
Remember the song folks:
You can lead him to Lisp, but he sees just parentheses. But syntax he likes looks like ve-ne-re-al disease.
Even if tuples in and of themselves are nice in these languages, the overall syntax is indecipherable dog's breakfast that is more geared toward obfuscated programming contests than real work.
Look at Haskell. The Haskell 98 spec has to use a special superscript notation to collapse the million precedence levels. Any language in whose syntactic specification there is a need to use variables over the domain of precedence levels, and discuss them algebraically, should be tossed out the window by anyone with a shred of sanity.
Kaz Kylheku wrote: > Even if tuples in and of themselves are nice in these languages, the > overall syntax is indecipherable dog's breakfast that is more geared > toward obfuscated programming contests than real work.
No reason why Lisp 3.0 cannot have decent support for tuples and do away with cons cells, multiple value bind, values, separate namespaces and all the other useless cruft.
On Feb 1, 2:19 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> Kaz Kylheku wrote: > > Even if tuples in and of themselves are nice in these languages, the > > overall syntax is indecipherable dog's breakfast that is more geared > > toward obfuscated programming contests than real work.
> No reason why Lisp 3.0 cannot have decent support for tuples and do away > with cons cells, multiple value bind, values, separate namespaces and all > the other useless cruft.
But CL has support for tuples. We call them vectors. CONS cells are there in any functional language that supports lists (I may be stupid, but I fail to see what 1::[2; 3] is... also considering how this operator is called in the OCaml manual). Multiple Value Bind can be macroed away. Separate namespaces are an intriguing beast. I do think that they are not all that needed, at least the one separating functions from values, but then again, there are separate namespaces in other languages as well.
Of course, your definition of "cruft" may vary. If you want to look at some crufty code you can peruse a source file to be fed fed to camlp4. Looks like the "look ma, no cons cells" has some drawbacks after all. :)
On Sun, 01 Feb 2009 07:36:35 -0800, Marco Antoniotti wrote: > On Feb 1, 2:19 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>> No reason why Lisp 3.0 cannot have decent support for tuples and do >> away with cons cells, multiple value bind, values, separate namespaces >> and all the other useless cruft.
> But CL has support for tuples. We call them vectors. CONS cells are > there in any functional language that supports lists (I may be stupid, > but I fail to see what 1::[2; 3] is... also considering how this > operator is called in the OCaml manual). Multiple Value Bind can be > macroed away. Separate namespaces are an intriguing beast. I do think > that they are not all that needed, at least the one separating functions > from values, but then again, there are separate namespaces in other > languages as well.
> Of course, your definition of "cruft" may vary. If you want to look at > some crufty code you can peruse a source file to be fed fed to camlp4. > Looks like the "look ma, no cons cells" has some drawbacks after all. :)
I think that lists built of cons cells are very neat, because Lisp exposes the mechanism of constructing simple linked lists and you can go under the hood if you prefer. I would never trade this for an "abstract" list mechanism that has some interface for traversing the list, but if one is bothered by cons cells, such a mechanism can be easily implemented in Lisp. Again, the fact that it is not done should be a hint.
I don't see why we should do away with multiple values. Tuples are not a replacement, since functions that return multiple values can behave as single-values functiond if the caller does not capture the other values. Consider
(defun plot-function (function ...) ;; plots the univariate function ...)
With tuples, one would have to extract the first value of the tuple, which is a nice pastime for F# programmers who love to waste their time with patterns, but I don't really care for it.
Separate namespaces are something completely orthogonal to the issues above. I personally like them and they don't bother me at all.
Marco Antoniotti <marc...@gmail.com> writes: > On Feb 1, 2:19 am, Jon Harrop <j...@ffconsultancy.com> wrote: >> Kaz Kylheku wrote: >> > Even if tuples in and of themselves are nice in these languages, the >> > overall syntax is indecipherable dog's breakfast that is more geared >> > toward obfuscated programming contests than real work.
>> No reason why Lisp 3.0 cannot have decent support for tuples and do away >> with cons cells, multiple value bind, values, separate namespaces and all >> the other useless cruft.
> But CL has support for tuples. We call them vectors.
Vectors would be the CL equivalent of OCaml's arrays, not tuples. Tuples are kind of their own thing without a direct CL conceptual equivalent. Sometimes they're replaced by lists, sometimes multiple value return. Sometimes cons cells are used where an OCaml programmer would use 2-tuples.
> CONS cells are there in any functional language that supports lists (I > may be stupid, but I fail to see what 1::[2; 3] is... also considering > how this operator is called in the OCaml manual).
1::[2; 3] is (cons 1 '(2 3)). So yes, OCaml has cons cells with the caveat that the cdr is only allowed to point to another cons cell or nil (improper lists are prohibited).
- Michael
-- mouse, n: A device for pointing at the xterm in which you want to type. Confused by the strange files? I cryptographically sign my messages. For more information see <http://www.elehack.net/resources/gpg>.
> Marco Antoniotti <marc...@gmail.com> writes: > > On Feb 1, 2:19 am, Jon Harrop <j...@ffconsultancy.com> wrote: > >> Kaz Kylheku wrote: > >> > Even if tuples in and of themselves are nice in these languages, the > >> > overall syntax is indecipherable dog's breakfast that is more geared > >> > toward obfuscated programming contests than real work.
> >> No reason why Lisp 3.0 cannot have decent support for tuples and do away > >> with cons cells, multiple value bind, values, separate namespaces and all > >> the other useless cruft.
> > But CL has support for tuples. We call them vectors.
> Vectors would be the CL equivalent of OCaml's arrays, not tuples. > Tuples are kind of their own thing without a direct CL conceptual > equivalent. Sometimes they're replaced by lists, sometimes multiple > value return. Sometimes cons cells are used where an OCaml programmer > would use 2-tuples.
Yes. This is the fine print and everybody here - pardon my sarcasm, not directed at you :) - is aware of that. (aren't we all?!?)
> > CONS cells are there in any functional language that supports lists (I > > may be stupid, but I fail to see what 1::[2; 3] is... also considering > > how this operator is called in the OCaml manual).
> 1::[2; 3] is (cons 1 '(2 3)). So yes, OCaml has cons cells with the > caveat that the cdr is only allowed to point to another cons cell or nil > (improper lists are prohibited).
Of course. I think people here are also aware of *that*... (again, aren't we all?!?) :) You for sure are. I am, long time CLLers are... :)
Tamas K Papp wrote: > I think that lists built of cons cells are very neat, because Lisp > exposes the mechanism of constructing simple linked lists and you can > go under the hood if you prefer.
Can you elaborate with an example of what you mean by "going under the hood"?
> I would never trade this for an > "abstract" list mechanism that has some interface for traversing the > list, but if one is bothered by cons cells, such a mechanism can be > easily implemented in Lisp. Again, the fact that it is not done > should be a hint.
That's some seriously flawed logic right there. Modern features do not get successfully retrofitted onto Lisp because the people familiar with these features never go back to Lisp and the few who continue to use Lisp remain blissfully unaware of what they are missing out on.
Indeed, the confusion surrounding tuples in this thread would have highlighted this your you had you known what tuples were used for. As it is, you could only resort to considering far more people are choosing OCaml and Haskell over Lisp.
> I don't see why we should do away with multiple values. Tuples are > not a replacement, since functions that return multiple values can > behave as single-values functiond if the caller does not capture the > other values. Consider
> (defun plot-function (function ...) > ;; plots the univariate function > ...)
> With tuples, one would have to extract the first value of the tuple, > which is a nice pastime for F# programmers who love to waste their > time with patterns, but I don't really care for it.
That great "benefit" of silently dropping parts of your data.
> Separate namespaces are something completely orthogonal to the issues > above. I personally like them and they don't bother me at all.
Ironically, the code you just wrote was needlessly obfuscated by this ridiculous flaw in Lisp. Specifically, you used lambdas as a workaround for separate namespaces.
In OCaml or F#, you just do:
plot sin plot floor
because the "sin" function is just another variable (and floor doesn't return the fractional part).
On 1 Feb., 22:42, Jon Harrop <j...@ffconsultancy.com> wrote:
> Ironically, the code you just wrote was needlessly obfuscated by this > ridiculous flaw in Lisp. Specifically, you used lambdas as a workaround for > separate namespaces.
> In OCaml or F#, you just do:
> plot sin > plot floor
(plot 'sin) or (plot #'sin) works fine.
> because the "sin" function is just another variable (and floor doesn't > return the fractional part).
jos...@corporate-world.lisp.de wrote: > On 1 Feb., 22:42, Jon Harrop <j...@ffconsultancy.com> wrote: >> Ironically, the code you just wrote was needlessly obfuscated by this >> ridiculous flaw in Lisp. Specifically, you used lambdas as a workaround >> for separate namespaces.
>> In OCaml or F#, you just do:
>> plot sin >> plot floor
> (plot 'sin) or (plot #'sin) works fine.
Which is comparable verbosity to the destructuring that Tamas was referring to.
>> because the "sin" function is just another variable (and floor doesn't >> return the fractional part).
On 2009-02-01, Michael Ekstrand <mich...@elehack.net> wrote:
> Marco Antoniotti <marc...@gmail.com> writes: >> On Feb 1, 2:19 am, Jon Harrop <j...@ffconsultancy.com> wrote: >>> Kaz Kylheku wrote: >>> > Even if tuples in and of themselves are nice in these languages, the >>> > overall syntax is indecipherable dog's breakfast that is more geared >>> > toward obfuscated programming contests than real work.
>>> No reason why Lisp 3.0 cannot have decent support for tuples and do away >>> with cons cells, multiple value bind, values, separate namespaces and all >>> the other useless cruft.
>> But CL has support for tuples. We call them vectors.
> Vectors would be the CL equivalent of OCaml's arrays, not tuples.
Only restricted uses of vectors in CL are equivalent to OCaml arrays.
Don't forget that a vector in CL can have heterogeneous contents.
> Tuples are kind of their own thing without a direct CL conceptual > equivalent.
When you write the syntax for a tuple, you're making something that might be called an anonymous struct. It's compatible with other such structs that have the same number of elements, of the same types, in the same order.
It is kind of to structs what lambda is to functions, loosely speaking.
It's not impossible to visualize a Lisp extension for this. Regular Lisp structs are not anonymous. They are named, and use name equivalence. So they can't be used directly. I don't see how anonymous structs like tuples would be all that useful in Lisp. They have no reason to exists, because if you want to represent a pair of values, which are integer and string, respectively, just go ahead and use a vector or list:
#(123 "456") ;; effectively a tuple
Tuples are used in these autistic languages like Haskell and OCaml in situations when the programmer wants a collection of values of heterogeneous types, but the type system gets in the way of a vector or list being used.
The problem that tuples solve does not have a counterpart in Common Lisp.
>> CONS cells are there in any functional language that supports lists (I >> may be stupid, but I fail to see what 1::[2; 3] is... also considering >> how this operator is called in the OCaml manual).
> 1::[2; 3] is (cons 1 '(2 3)). So yes, OCaml has cons cells with the > caveat that the cdr is only allowed to point to another cons cell or nil
You mean to another cons cell which holds an integer! Oops.
> jos...@corporate-world.lisp.de wrote: > > On 1 Feb., 22:42, Jon Harrop <j...@ffconsultancy.com> wrote: > >> Ironically, the code you just wrote was needlessly obfuscated by this > >> ridiculous flaw in Lisp. Specifically, you used lambdas as a workaround > >> for separate namespaces.
> >> In OCaml or F#, you just do:
> >> plot sin > >> plot floor
> > (plot 'sin) or (plot #'sin) works fine.
> Which is comparable verbosity to the destructuring that Tamas was referring > to.
> >> because the "sin" function is just another variable (and floor doesn't > >> return the fractional part).
> > CL-USER 34 > (floor 3.5) > > 3 > > 0.5
> > CL-USER 35 > (identity (floor 3.5)) > > 3
> > Read a Lisp book before you post again.
> $ ocaml > Objective Caml version 3.10.2
> # floor 2.3;; > - : float = 2.
> Read the context before you post again.
You are in the wrong context. This is not fa.caml. This is c.l.l.
Both (plot 'sin) and (plot 'floor) work fine. The lambdas in Tamas post were not needed and your post about some namespace blabla is only babbling. The LAMBDA macro is also not a workaround since it is not needed, since the functions objects can be passed directly.
You should better work on your F# business instead of wasting time with comp.lang.lisp.
