[deleted]
Ask HN: If you were designing Common Lisp today, what would you change?
21–30 of 32 posts
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#22Rename Lisp to Heap-p, Polyp, Matrixp, or Affinep
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#23I developed a language called TXR Lisp, which has ties with Common Lisp in many areas. If you look at the reference manual, which is conveniently one giant manual page available in HTML form, there are numerous dialect notes that mention ANSI Common Lisp; a chunk of that would likely be things I might change in Common Lisp. Some things I would fix without changing Common Lisp: * redefine "binding" as being an associa…
> loop would support application-defined clauses. lisp loop is a macro, can be modified to support above request. > * in the area of pathnames, I would have the language specify precisely how POSIX and Windows paths correspond to pathname objects. Elang/elixir approach where (pathname ) provides a standard way to access file/path without having to know what the underlying file system is (unless check atrributes) > *…
A CL implementation's loop macro cannot be modified without modifying the implementation, but your application can carry its own loop macro. Possibly, such a loop macro can generate code written in the standard loop macro, so that (enhanced-loop ) just emits (loop ) but if it detects nonstandard clauses, it expands them into standard clauses.
Lisp being what it is, you are rarely at the mercy of the implementation, when it comes to a language feature, unless the feature has to do with accessing some semantics deep in the implementation, and the problem is with that semantics and not the porcelain.
It is still undesirable for programmers to bring their ehanced-loop to the table. Because Bob has bob-loop, and Amy has amy-loop and they would like to combine their code where both bob-loop and amy-loop features are used not just in the same code but in the same loop. That just turns into a PITA. If they are lucky, amy-loop has some awkward syntax for specifying that a given invocation should generate code for some loop other than cl:loop, so they write (amy-loop :target bob-loop ...). Then amy-loop transforms all the amy-loop clauses it sees, leaves alone anything it doesn't understands and spits out bob-loop syntax. (This is not easy; skipping unfamiliar, non-standard loop syntax is going to involve guesswork because the clauses aren't nicely parenthesized!)
That would all be simpler if they could just write custom clauses for standard loop. Bob would write his in the bob-lib package; Amy in amy-lib. Everything works together out of the box; if you have bob-lib and amy-lib, you can use loop with bob-loop and amy-loop clauses.
I don't substantially understand the rest of your remarks, except to the extent that certain key words in my remarks serve as their prompts. The holidays being over, you should be able to get a medication refill now.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#24Some sort of governing entity. The ANSI standard has left the language totally dead in the water, and is the single biggest thing holding back this really quite beautiful language Package local nicknames. The situation that libraries like Alexandria are in is really sad. Nested namespacing/packages. The ability to alias imports, like in Python. In the same vein, most symbols in the spec should be moved into a standar…
Another take is that a bunch of clever people not only got the job done, but recognized that their role is done and went their separate ways.
A similar thing happened in hardware with the HDMI spec.
The worst thing in programming languages is these insipid language committees that refuse to disband. If you look at C and C++, it's obvious the main thing they care about above all is their self-preservation: the ability to continue meeting and tinkering with languages that everyone else critically depends on being stable.
The goal of no technical committee should be its own self-preservation.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#25Some sort of governing entity. The ANSI standard has left the language totally dead in the water, and is the single biggest thing holding back this really quite beautiful language Package local nicknames. The situation that libraries like Alexandria are in is really sad. Nested namespacing/packages. The ability to alias imports, like in Python. In the same vein, most symbols in the spec should be moved into a standar…
Another take is that a bunch of clever people not only got the job done, but recognized that their role is done and went their separate ways. A similar thing happened in hardware with the HDMI spec. The worst thing in programming languages is these insipid language committees that refuse to disband. If you look at C and C++, it's obvious the main thing they care about above all is their self-preservation: the ability…
This is so true. Once it's done: stop working on it. All this instability serves nobody in the longer term. At the same time: lots of stuff is released half baked or worse and as a result you get a decade of goal post moving and backwards incompatibility for free.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#26Earlier quoted context omitted.
> loop would support application-defined clauses. lisp loop is a macro, can be modified to support above request. > * in the area of pathnames, I would have the language specify precisely how POSIX and Windows paths correspond to pathname objects. Elang/elixir approach where (pathname ) provides a standard way to access file/path without having to know what the underlying file system is (unless check atrributes) > *…
A CL implementation's loop macro cannot be modified without modifying the implementation, but your application can carry its own loop macro. Possibly, such a loop macro can generate code written in the standard loop macro, so that (enhanced-loop ) just emits (loop ) but if it detects nonstandard clauses, it expands them into standard clauses. Lisp being what it is, you are rarely at the mercy of the implementation, w…
> ... The holidays being over, you should be able to get a medication refill now.
to much line spacing is a python thing, lisp is to parenthetical.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#27Earlier quoted context omitted.
> loop would support application-defined clauses. lisp loop is a macro, can be modified to support above request. > * in the area of pathnames, I would have the language specify precisely how POSIX and Windows paths correspond to pathname objects. Elang/elixir approach where (pathname ) provides a standard way to access file/path without having to know what the underlying file system is (unless check atrributes) > *…
A CL implementation's loop macro cannot be modified without modifying the implementation, but your application can carry its own loop macro. Possibly, such a loop macro can generate code written in the standard loop macro, so that (enhanced-loop ) just emits (loop ) but if it detects nonstandard clauses, it expands them into standard clauses. Lisp being what it is, you are rarely at the mercy of the implementation, w…
Not explicitly noted in original message was, reply to remarks were about examples of how that already exists in lisp without need to modify lisp.
'basic' loop in lisp is tree/heap traversal from initial outer ().
The standard loop macro just provides appropriate way/window dressing to quickly comprehend what's being done (aka while, counter loop, do while, repeat, etc).
What's refered to as generators in other languages, is implicit in how lisp traverses ().
per return a struct and not a list: Generator approach would 'store the list of values' and return a single struct every time called until no more structs from 'original turn'.
traversal of () is the 'generic loop' in lisp. (clos or not)
set/quote discussion also left out the needed eval command.
stated 'rebinding' is already implicet in s-expressions used in lisp. request as given is an lvalue = rvalue(s) interpretation (m-expression). s-expressions are core of lisp. convertion lisp to use m-expressions instead of s-expressions would mean creating a new language.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#28Earlier quoted context omitted.
A CL implementation's loop macro cannot be modified without modifying the implementation, but your application can carry its own loop macro. Possibly, such a loop macro can generate code written in the standard loop macro, so that (enhanced-loop ) just emits (loop ) but if it detects nonstandard clauses, it expands them into standard clauses. Lisp being what it is, you are rarely at the mercy of the implementation, w…
Not explicitly noted in original message was, reply to remarks were about examples of how that already exists in lisp without need to modify lisp. 'basic' loop in lisp is tree/heap traversal from initial outer (). The standard loop macro just provides appropriate way/window dressing to quickly comprehend what's being done (aka while, counter loop, do while, repeat, etc). What's refered to as generators in other langu…
> basic' loop in lisp is tree/heap traversal from initial outer ().
That's completely false, except that loops can be used to code a tree traversal.
Looping is a control construct centered around a backward branch, updates to iteration variables and termination testing. Loops can compile code that has nothing to do with the heap.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#29I developed a language called TXR Lisp, which has ties with Common Lisp in many areas. If you look at the reference manual, which is conveniently one giant manual page available in HTML form, there are numerous dialect notes that mention ANSI Common Lisp; a chunk of that would likely be things I might change in Common Lisp. Some things I would fix without changing Common Lisp: * redefine "binding" as being an associa…
A few more points.
* The :test argument of various sequence processing and other functions would default to equal, not eql. The eql choice is incredibly poor. It doesn't benefit programs that use numbers, symbols or characters as keys, just breaks programs that use lists or strings.
* I would fix the equal function's inconsistencies, like how it recurses across conses, but not vectors.
* I would clean up the following issue in the CL condition system: certain behaviors of condition raising are implemented in specific functions. In CL, if you want an unhandled error condition to drop into the debugger, you have to signal it using the error function. It's that function which performs the callback. If you signal the condition with signal, and it is not handled, then signal just returns. WTF? I would fix that, so that all manner of signaling an error condition will go into the debugger or terminate or whatever.
Re: Ask HN: If you were designing Common Lisp today, what would you change?
#30Earlier quoted context omitted.
Not explicitly noted in original message was, reply to remarks were about examples of how that already exists in lisp without need to modify lisp. 'basic' loop in lisp is tree/heap traversal from initial outer (). The standard loop macro just provides appropriate way/window dressing to quickly comprehend what's being done (aka while, counter loop, do while, repeat, etc). What's refered to as generators in other langu…
> basic' loop in lisp is tree/heap traversal from initial outer (). That's completely false, except that loops can be used to code a tree traversal. Looping is a control construct centered around a backward branch, updates to iteration variables and termination testing. Loops can compile code that has nothing to do with the heap.
Why prefer a non-functional construct over a functional construct in a functional language?
The lisp loop macro simplifies the s-expression tree/heap traversal for benifit of coder/reader. The lisp loop macro is implilmented based on s-expression tree traversal.
Trees are used with closures. Heaps are used with objects. (lisp & non-lisp)
In lisp can debate what's an 'object', but multiple thunks are managed through a heap structure.
Tree (or heap form of tree) order traversals are forms of binary backward branching.
Tree traversal can be structured so 'iteration variables' are not needed. Default lisp termination is 'NIL'
If only returning a single struc (with no memory management), then heap not required.
If returning multiple strucs in a list/tree (aka multiple s-expressions), then the s-expression 'thunks' will be managed via heap.