Hey,
I'm sure this topic was already discussed a thousand times, but here's
my list of random ideas if CL ever was to get standardized again (ha-ha,
fat chance).
- custom CLOS specializers
- non-opaque user types
- non-opaque readtables
- separating a file into multiple compilation unit
- sensible system definition facility
that's it. /me off to work on my pattern matcher and write some diffs
for editor-hints.
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
On 28 Dez., 20:43, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
> Hey,
>
> I'm sure this topic was already discussed a thousand times, but here's
> my list of random ideas if CL ever was to get standardized again (ha-ha,
> fat chance).
>
> - custom CLOS specializers
> - non-opaque user types
> - non-opaque readtables
> - separating a file into multiple compilation unit
> - sensible system definition facility
>
> that's it. /me off to work on my pattern matcher and write some diffs
> for editor-hints.
>
> --
> You only have power over people so long as you don't take everything
> away from them. But when you've robbed a man of everything he's no longer
> in your power -- he's free again. -- Aleksandr Isayevich Solzhenitsyn
See also:
http://www.cliki.net/Proposed%20Extensions%20To%20ANSI
On Dec 28, 8:43 pm, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
> - custom CLOS specializer
Can you explain this?
> - non-opaque user types
> - non-opaque readtables
In my opinion opaque types leave the implementations a lot of room for
improvement and optimization, hiding the actual details. Furthermore,
I do not think it is a sensible measure to expose the string length,
or the string data pointer for the users to manipulate. Having safe
accessors (CHAR, LENGTH, etc) is more on the OO spirit.
> - separating a file into multiple compilation unit
Again, can you elaborate?
> - sensible system definition facility
Is it really needed to standardize this? No other language community
has a standard, beyond de facto ones. What is missing is a good
library to do this, with constraints on what can be done and what
should not.
Juanjo
thus spoke Juanjo <·····················@googlemail.com>:
> On Dec 28, 8:43 pm, Stanisław Halik <··············@tehran.lain.pl>
> wrote:
>> - custom CLOS specializer
> Can you explain this?
Being able to define specializers at the same level as the EQL
specializer. Namely, AND, OR and friends. Maybe something even more
fancy.
>> - non-opaque user types
>> - non-opaque readtables
> In my opinion opaque types leave the implementations a lot of room for
> improvement and optimization, hiding the actual details.
There's not much to optimize with readtables, not only the reader
algorithm's dead simple, but it's not really well-suited for
high-performance processing (see cl-serializer).
Non-opaque user types would be sweet to do some logic on them, e.g.
simplify them, check whether there are any objects matching the
expression (opaque SATISFIES type notwithstanding), etc.
>> - separating a file into multiple compilation unit
> Again, can you elaborate?
It's a PITA to have EVAL-WHEN for functions-used-in-macros, but it's
silly to put macros in a separate file. WITH-COMPILATION-UNIT only
merges multiple files in a compilation unit, but never splits a file
into many ones.
>> - sensible system definition facility
> Is it really needed to standardize this
Not really.
--
You only have power over people so long as you don’t take everything
away from them. But when you’ve robbed a man of everything he’s no longer
in your power — he’s free again. -- Aleksandr Isayevich Solzhenitsyn
On 2008-12-31, Stanisław Halik <·······@test123.ltd.pl> wrote:
> thus spoke Juanjo <·····················@googlemail.com>:
>
>> On Dec 28, 8:43 pm, Stanisław Halik <··············@tehran.lain.pl>
>> wrote:
>>> - separating a file into multiple compilation unit
>> Again, can you elaborate?
>
> It's a PITA to have EVAL-WHEN for functions-used-in-macros, but it's
> silly to put macros in a separate file.
If you think it's silly, can't you just not do it?
Macros and their helper functions don't have to be in a separate file.
The EVAL-WHEN around the helper functions can be just around the helper
functions, not the entire file.
> WITH-COMPILATION-UNIT only
> merges multiple files in a compilation unit, but never splits a file
> into many ones.
What do you think it is you could express with multiple compilation
units in one file that you can't easily express now?
You already have control over things like what package is used for
reading forms, and what optimizations apply over an expression.