Hi,
I would like an expert opinion on the following issue:
I usually define macros with a plan for extension even if I don't have
any extension in mind at that moment. For example:
(with-foo ()
;do something
)
Latter on, I might think of adding some arguments, e.g.,
(with-foo (:bar t :frob nil)
;do something
)
As I have the discipline of always leaving an empty list as macro
argument it's easier to extend the macro without breaking the code.
Regarding the macro definition, when I don't have yet an extension in
mind, I usually write something along the following lines:
(defmacro with-foo (() &body body)
...)
Is this OK?
I was under the impression that the empty list in the macro lambda
list was used just for destructuring an equivalent empty list in the
macro arguments. However, we can also see the macro definition as:
(defmacro with-foo (nil &body body)
...)
Now, it looks like I'm trying to bind the parameter 'nil', which is
obviously illegal.
What do you think?
[Btw: CMUCL accepts the macro, CLISP rejects the macro]
Thanks in advance,
Ant�nio Leit�o.
Antonio Menezes Leitao wrote:
> Hi,
>
> I would like an expert opinion on the following issue:
>
> I usually define macros with a plan for extension even if I don't have
> any extension in mind at that moment. For example:
>
> (with-foo ()
> ;do something
> )
>
> Latter on, I might think of adding some arguments, e.g.,
>
> (with-foo (:bar t :frob nil)
> ;do something
> )
>
> As I have the discipline of always leaving an empty list as macro
> argument it's easier to extend the macro without breaking the code.
>
> Regarding the macro definition, when I don't have yet an extension in
> mind, I usually write something along the following lines:
>
> (defmacro with-foo (() &body body)
> ...)
>
> Is this OK?
>
> I was under the impression that the empty list in the macro lambda
> list was used just for destructuring an equivalent empty list in the
> macro arguments. However, we can also see the macro definition as:
>
> (defmacro with-foo (nil &body body)
> ...)
>
> Now, it looks like I'm trying to bind the parameter 'nil', which is
> obviously illegal.
>
> What do you think?
I'd just do
(defmacro with-foo ((&rest args) &body body)
(declare (ignore args))
...)
You can add your keys incrementally later on.
Cheers
--
Marco
On Mon, 26 Apr 2004 17:35:22 -0400, Marco Antoniotti wrote:
> I'd just do
>
> (defmacro with-foo ((&rest args) &body body)
> (declare (ignore args))
> ...)
>
> You can add your keys incrementally later on.
Sure. That's what I had to do as soon as the compiler complained.
What I want to know is whether this was a bug in my code or a bug in the
Common Lisp compiler.
Thanks,
Antonio Leitao
On Mon, 26 Apr 2004 23:40:44 +0200, Frode Vatvedt Fjeld wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>> (defmacro with-foo ((&rest args) &body body)
>> (declare (ignore args))
>> ...)
>
> This also works:
>
> (defmacro with-foo (options &body body)
> (declare (ignore options))
> ...)
Both alternatives allow you to pass arguments to the macro when it
doesn't accept them (yet).
The rational behind my solution is that all uses of the macro are properly
checked at compile time both before and after extending the macro.
Anyway, that was not my question. I just want to know if it is legal or
not.
Thanks,
Antonio Leitao.
Antonio Menezes Leitao <··············@evaluator.pt> writes:
> Both alternatives allow you to pass arguments to the macro when it
> doesn't accept them (yet).
Well.. (assert (null options)) then.
> Anyway, that was not my question. I just want to know if it is
> legal or not.
I believe it is legal, and that it is CLisp that isn't conformant.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld wrote:
>>Anyway, that was not my question. I just want to know if it is
>>legal or not.
>
>
> I believe it is legal, and that it is CLisp that isn't conformant.
The CLISP team and I have had discussions about this. gcl/ansi-tests
takes one approach, they take another. It would be good if someone
could resolve the disagreement.
Paul
Antonio Menezes Leitao wrote:
> Hi,
>
> I would like an expert opinion on the following issue:
>
> I usually define macros with a plan for extension even if I don't have
> any extension in mind at that moment. For example:
>
> (with-foo ()
> ;do something
> )
>
> Latter on, I might think of adding some arguments, e.g.,
>
> (with-foo (:bar t :frob nil)
> ;do something
> )
>
> As I have the discipline of always leaving an empty list as macro
> argument it's easier to extend the macro without breaking the code.
That is not "discipline", that is being too lazy to do things right. How
hard is it to globally change "(with-gusto" to "(with-gusto ()"? Instead
you confuse readers of the code into thinking the macro takes arguments.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <·····················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> > As I have the discipline of always leaving an empty list as macro
> > argument it's easier to extend the macro without breaking the code.
>
> That is not "discipline", that is being too lazy to do things right. How
> hard is it to globally change "(with-gusto" to "(with-gusto ()"? Instead
> you confuse readers of the code into thinking the macro takes arguments.
If you don't have access to all the callers (e.g. they're in customer
code), it's *very* hard.
I think it's a good idea to maintain a consistent style for all WITH-*
macros. The general format of (with-<whatever> (<options>) <body>) is
well-known to most Lisp programmers.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> In article <·····················@twister.nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>>As I have the discipline of always leaving an empty list as macro
>>>argument it's easier to extend the macro without breaking the code.
>>
>>That is not "discipline", that is being too lazy to do things right. How
>>hard is it to globally change "(with-gusto" to "(with-gusto ()"? Instead
>>you confuse readers of the code into thinking the macro takes arguments.
>
>
> If you don't have access to all the callers (e.g. they're in customer
> code), it's *very* hard.
>
> I think it's a good idea to maintain a consistent style for all WITH-*
> macros. The general format of (with-<whatever> (<options>) <body>) is
> well-known to most Lisp programmers.
Oh, sure, and this is an oddball thing to be discussing simply because
most macros /do/ have some useful options. coincidentally, over the past
few days I was indeed surprised when I found myself creating an oft-used
Cello macro "with-layers" which took no options, just a series of layer
specifications for rendering a node. But that is the way I coded it,
with no options, because it took no options.
If that ever has to change, no big deal, I'll just do what Microsoft does:
with-layers-ex
Anyway, if the rule is "any macro, shipped as part of an API which has
not been thought out enough to know whether options might be necessary
to users too lazy to change their code with one global replace when you
might have to add the options, should take a dummy options parameter"...
uh, no argument!
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On Tue, 27 Apr 2004 03:08:22 +0000, Kenny Tilton wrote:
>
>
> Barry Margolin wrote:
>> In article <·····················@twister.nyc.rr.com>,
>> Kenny Tilton <·······@nyc.rr.com> wrote:
>>
>>
>>>>As I have the discipline of always leaving an empty list as macro
>>>>argument it's easier to extend the macro without breaking the code.
>>>
>>>That is not "discipline", that is being too lazy to do things right.
If you think that, when you design a macro, you can decide in advance
that it will never need options, IMHO, you are overestimating the human
capacity to foresee the future.
>>>How hard is it to globally change "(with-gusto" to "(with-gusto ()"? Instead
>>>you confuse readers of the code into thinking the macro takes arguments.
Just like Barry said, it is hard. It's not that you have to
change code. You also have to change people's minds so that they do not
use the old macro syntax. That's harder. They tend to become annoyed.
> ...
> coincidentally, over the past
> few days I was indeed surprised when I found myself creating an oft-used
> Cello macro "with-layers" which took no options, just a series of layer
> specifications for rendering a node. But that is the way I coded it,
> with no options, because it took no options.
>
> If that ever has to change, no big deal, I'll just do what Microsoft does:
>
> with-layers-ex
>
> Anyway, if the rule is "any macro, shipped as part of an API which has
> not been thought out enough to know whether options might be necessary
> to users too lazy to change their code with one global replace when you
> might have to add the options, should take a dummy options parameter"...
> uh, no argument!
>
> kenny
Why do you use a less flexible solution when you have a perfectly good one
available?
Do you really think it is better to ask the users to change? Or force
people who want the options to use a different macro?
Antonio Leitao.
Antonio Menezes Leitao wrote:
> On Tue, 27 Apr 2004 03:08:22 +0000, Kenny Tilton wrote:
>
>
>>
>>Barry Margolin wrote:
>>
>>>In article <·····················@twister.nyc.rr.com>,
>>> Kenny Tilton <·······@nyc.rr.com> wrote:
>>>
>>>
>>>
>>>>>As I have the discipline of always leaving an empty list as macro
>>>>>argument it's easier to extend the macro without breaking the code.
>>>>
>>>>That is not "discipline", that is being too lazy to do things right.
>
>
> If you think that, when you design a macro, you can decide in advance
> that it will never need options, IMHO, you are overestimating the human
> capacity to foresee the future.
That is not what I said. I said that when it changes I will add the
options slot to the macro, then visit each occurrence of the macro in my
code to decide if the new option or options which prompted the addition
of the slots super-argument need specification. That is not a problem
for anyone with enough discipline. :) If as might happen I have reason
to believe no existing use will require anything other than the defaults
I might be specifying, and there are dozens and dozens to change, hello
WinGREP.
>
>
>>>>How hard is it to globally change "(with-gusto" to "(with-gusto ()"? Instead
>>>>you confuse readers of the code into thinking the macro takes arguments.
>
>
> Just like Barry said, it is hard. It's not that you have to
> change code. You also have to change people's minds so that they do not
> use the old macro syntax. That's harder. They tend to become annoyed.
Nonsense. What is annoying is thinking a macro takes options because of
silliness like having a place for options when options are not required.
besides, I did not hear anyone (except you now) say that the options
were an unwritten substandard we developers were required to follow.
What was said -- and i agree -- is that your null options idea would not
cause much confusion because Lispniks are so accustomed to the pattern.
>
>
>>...
>
>
>>coincidentally, over the past
>>few days I was indeed surprised when I found myself creating an oft-used
>>Cello macro "with-layers" which took no options, just a series of layer
>>specifications for rendering a node. But that is the way I coded it,
>>with no options, because it took no options.
>>
>>If that ever has to change, no big deal, I'll just do what Microsoft does:
>>
>> with-layers-ex
>>
>>Anyway, if the rule is "any macro, shipped as part of an API which has
>>not been thought out enough to know whether options might be necessary
>>to users too lazy to change their code with one global replace when you
>>might have to add the options, should take a dummy options parameter"...
>>uh, no argument!
>>
>>kenny
>
>
> Why do you use a less flexible solution when you have a perfectly good one
> available?
(a) with-layers-ex was a joke
(b) with-layers-ex is /more/ flexible. I have extended the API with a
new entry point. I have my users' attention. If they use it, they have
to read the doc and find out how it is different. Maybe it gets a better
name, because it deserves one, one which suggests the different role it
performs. If it really is just an extended with-layers, they get to
think about where they might want to take advantage of the new options.
Tell me more about your imagined users. What happens when some other
aspect of your API changes? Suppose you refactor and make a function
more general, such that it needs a new required argument. How are you
going to make that change so that none of your users has to change their
code?
New versions of libraries sometimes breaks client code. Nothing is going
to stop that. developers can deal with it. So it is no justification for
fake macro parameters. what is important is a respect for honest
programming. that is the only way out. don't get cute in programming, it
is the road to hell. if your macro takes no options, it should have no
parameter for options. it really is that simple.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <·····················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Antonio Menezes Leitao wrote:
>
> > On Tue, 27 Apr 2004 03:08:22 +0000, Kenny Tilton wrote:
> >
> >
> >>
> >>Barry Margolin wrote:
> >>
> >>>In article <·····················@twister.nyc.rr.com>,
> >>> Kenny Tilton <·······@nyc.rr.com> wrote:
> >>>
> >>>
> >>>
> >>>>>As I have the discipline of always leaving an empty list as macro
> >>>>>argument it's easier to extend the macro without breaking the code.
> >>>>
> >>>>That is not "discipline", that is being too lazy to do things right.
> >
> >
> > If you think that, when you design a macro, you can decide in advance
> > that it will never need options, IMHO, you are overestimating the human
> > capacity to foresee the future.
>
> That is not what I said. I said that when it changes I will add the
> options slot to the macro, then visit each occurrence of the macro in my
> code to decide if the new option or options which prompted the addition
> of the slots super-argument need specification. That is not a problem
> for anyone with enough discipline. :) If as might happen I have reason
> to believe no existing use will require anything other than the defaults
> I might be specifying, and there are dozens and dozens to change, hello
> WinGREP.
The expectation is typically that all the existing users of the macro
will be OK with using the default values of the new options.
I still don't see how WinGREP can help the macro author -- the changes
you're talking about have to be made by the macro *users*. The
"discipline" the OP is talking about is in making changes to his library
in an upward-compatible fashion, so that existing callers don't need to
be modified unless they need to take advantage of the new features.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> In article <·····················@twister.nyc.rr.com>,
> Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>>Antonio Menezes Leitao wrote:
>>
>>
>>>On Tue, 27 Apr 2004 03:08:22 +0000, Kenny Tilton wrote:
>>>
>>>
>>>
>>>>Barry Margolin wrote:
>>>>
>>>>
>>>>>In article <·····················@twister.nyc.rr.com>,
>>>>>Kenny Tilton <·······@nyc.rr.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>As I have the discipline of always leaving an empty list as macro
>>>>>>>argument it's easier to extend the macro without breaking the code.
>>>>>>
>>>>>>That is not "discipline", that is being too lazy to do things right.
>>>
>>>
>>>If you think that, when you design a macro, you can decide in advance
>>>that it will never need options, IMHO, you are overestimating the human
>>>capacity to foresee the future.
>>
>>That is not what I said. I said that when it changes I will add the
>>options slot to the macro, then visit each occurrence of the macro in my
>>code to decide if the new option or options which prompted the addition
>>of the slots super-argument need specification. That is not a problem
>>for anyone with enough discipline. :) If as might happen I have reason
>>to believe no existing use will require anything other than the defaults
>>I might be specifying, and there are dozens and dozens to change, hello
>>WinGREP.
>
>
> The expectation is typically that all the existing users of the macro
> will be OK with using the default values of the new options.
Sure.
>
> I still don't see how WinGREP can help the macro author -- the changes
> you're talking about have to be made by the macro *users*.
Well if we are talking about the OP, the context was someone
/invariably/ following the dummy-options practice, not just in API
macros. And it sure sounded as if this was during the rough and tumble
of development, not an upward-compatibility adjustment on the eve of
publishing library.
You injected that very reasonable special case. As for those users, hey,
when libraries move forward, users' code sometimes breaks. We can never
eliminate that entirely. So it comes down to a trade-off between
confusing the user with a bogus macro signature or possibly saving them
some work should a macro possibly change in a published library. I think
my vote is clear <g>, and I think this horse rightly dead.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On Tue, 27 Apr 2004 12:52:17 +0000, Kenny Tilton wrote:
>>>>>How hard is it to globally change "(with-gusto" to "(with-gusto ()"?
As Barry already pointed out (and I concur), that's something very hard to
do when your code is already in use by other programmers.
Moreover, as you certainly know, it is in general impossible for a static
analysis to identify all the points where the macro might being used. The
macro name might be generated dynamically in other macro definitions, or
it might be possible that some program reads and evaluates expressions
that references the macro. If you think I'm talking nonsense, I suggest
you take a look at the SNePS system (you can google for it) where this
sort of things are common. Your WinGREP doesn't even understand the
difference between symbols with the same name but belonging to different
packages, much less all the other possible ways to generate code
containing the macro call.
>>>>>Instead you confuse readers of the code into thinking the macro takes
>>>>>arguments.
You are the first one to complain about the confusion. It's a pattern
that most Lispers understand. If you don't use it, then as soon as you
change the macro you will confuse all the other programmers that were used
to the old version and that don't need to specify any options (they didn't
before).
>> Just like Barry said, it is hard. It's not that you have to change
>> code. You also have to change people's minds so that they do not use
>> the old macro syntax. That's harder. They tend to become annoyed.
>
> Nonsense. What is annoying is thinking a macro takes options because of
> silliness like having a place for options when options are not required.
> besides, I did not hear anyone (except you now) say that the options
> were an unwritten substandard we developers were required to follow.
> What was said -- and i agree -- is that your null options idea would not
> cause much confusion because Lispniks are so accustomed to the pattern.
Most people understand that "options" are, well, optional. They only have
to specify them if they know that the macro will do something different
with those options. On the other hand, If you tell other programmers that
your macro doesn't have options, they will not write the empty option list
but they will be forced to change their code when you decide to add
options. If you tell them that the macro doesn't need options now but that
it might accept some in the future, they will code accordingly and you are
free to add those options without disturbing their code. I don't
understand your problem with this approach.
>> Why do you use a less flexible solution when you have a perfectly good
>> one available?
>
> (a) with-layers-ex was a joke
> (b) with-layers-ex is /more/ flexible. I have extended the API with a
> new entry point. I have my users' attention. If they use it, they have
> to read the doc and find out how it is different. Maybe it gets a better
> name, because it deserves one, one which suggests the different role it
> performs. If it really is just an extended with-layers, they get to
> think about where they might want to take advantage of the new options.
>
> Tell me more about your imagined users. What happens when some other
> aspect of your API changes? Suppose you refactor and make a function
> more general, such that it needs a new required argument. How are you
> going to make that change so that none of your users has to change their
> code?
We are not talking about the same thing here. You stressed the new
_required_ argument because you probably know that, in general, you extend
an API function with new _keyword_ arguments precisely because you do not
want to break old code.
Obviously, if you need extra _required_ arguments, then that's not exactly
an extension. That's something new that really breaks code so it is
necessary to change all callers. No options here.
> New versions of libraries sometimes breaks client code. Nothing is going
> to stop that. developers can deal with it. So it is no justification for
> fake macro parameters. what is important is a respect for honest
> programming.
Should I read in your statement that my aproach to options in
with-whatever macros is the sign of a dishonest programmer?
> that is the only way out. don't get cute in programming, it is the road
> to hell. if your macro takes no options, it should have no parameter for
> options. it really is that simple.
Besides the "confusion" that you mentioned initially (and with which I
might agree to a certain extent), you didn't give any really meaningful
argument that supports your point of view. "Don't get cute in
programming", "road to hell" and "honest programming" are subjective
statements which do not add much value to this discussion.
Finally, and independently of opinions regarding the pros/cons of the
approach, I just want to return to my original question:
Is my approach legal (in the ANSI CL sense) or not?
Best regards,
Antonio Leitao.
Antonio Menezes Leitao wrote:
>>New versions of libraries sometimes breaks client code. Nothing is going
>>to stop that. developers can deal with it. So it is no justification for
>>fake macro parameters. what is important is a respect for honest
>>programming.
>
>
> Should I read in your statement that my aproach to options in
> with-whatever macros is the sign of a dishonest programmer?
Nice twist. :) My turn: only if by "dishonest programmer" you mean
/only/ that they write dishonest code. I have spent as much time over
the past twenty-five years performing major overhauls on existing
systems as I have writing original systems. So I happen to be especially
sensitive to self-misdocumenting (aka "dishonest") code. Mind you, this
optionless-option is a relatively minor transgression, but c.l.l. is
boring these days and I had fallen out of the top-ten posters so I had
to start /some/ idiotic subthread.
>
> Is my approach legal (in the ANSI CL sense) or not?
I have meaning to say, the fact that you have to ask may be a message
from god. :)
But AllegroCL likes it. And Lispworks -- more of a stickler in my
experience -- also likes it. I looked at the hyperspec and saw nothing
discouraging, but I am no Lisp expert.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <·····················@twister.nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Antonio Menezes Leitao wrote:
> >>New versions of libraries sometimes breaks client code. Nothing is going
> >>to stop that. developers can deal with it. So it is no justification for
> >>fake macro parameters. what is important is a respect for honest
> >>programming.
> >
> >
> > Should I read in your statement that my aproach to options in
> > with-whatever macros is the sign of a dishonest programmer?
>
> Nice twist. :) My turn: only if by "dishonest programmer" you mean
> /only/ that they write dishonest code.
How about:
(defmacro with-foo ((&rest options) &body body)
(if options (error "Sorry, this version of with-foo doesn't support
any options"))
...)
E.
You can have it both ways. If you NEED to
supply backward compatibility to with-foo, have
the with-foo macro detect if there are any
keyword parameters in the first element
of the body. But I agree with Kenny, if the
macro has no options do not imply that there are.
Original with-foo, (no null option list syntax defined)
(defmacro with-foo (&body body)
Return original with-foo transform here)
Optioned with-foo, with backward compatibility
(defmacro with-foo (&body body)
(when (null body) (error "What the!!"))
(destructuring-bind (&key (arg1 nil) (arg2 nil))
(when (keyword-argument-list (first body))
(first body))
Return optioned with-foo transform here))
Wade
Wade Humeniuk <····································@telus.net> wrote in message news:<·····················@clgrps12>...
> You can have it both ways. If you NEED to
> supply backward compatibility to with-foo, have
> the with-foo macro detect if there are any
> keyword parameters in the first element
> of the body. But I agree with Kenny, if the
> macro has no options do not imply that there are.
>
One reason for implying that there are (apart from the blindingly
obvious `don't screw your users if you might ever want to extend the
syntax' which is so obvious I'm was surprised that Kenny could argue
against it untilk I realised he was Bill Gates - are you Bill Gates
too?) is that it might help things that generate Lisp code, since it
looks more regular.
I wrote a list comprehension macro last night. (I've been writing a
lot of Python, and this and the iteration protocol are its only good
features as a language that I can see. The list comprehension macro
came out of a Lisp implementation of python-style iteration).
Originally it let you do stuff like:
(gather x
for (i '((1 2 3) 1 '(2 3)))
when (consp i)
for (x i)
when (evenp x))
->
(collecting
(for (i ((1 2 3) 1 '(2 3)))
(when (consp i)
(for (x i)
(when (evenp x)
(collect x))))))
But I realised that binding forms would be useful too:
(gather x
for (i l)
let ((y (f i)))
...)
->
(collecting
(for (i l)
(let ((y (f i)))
...)))
So I allowed LET and LET* as clauses too. Then I realised that if I
just *took out* the thing that checked for `clause operators', it
would work with *any* `standard-contract-WITH' style macro. So now
you can do:
(gather x
with-open-file (in f ...)
for (x (iter in :by :line)))
But the macros have to be standard-contract - they need to take a
first argument before the body. Of course, it turns out that (I
think) things are OK. If you havew a broken WITH macro, then I think
you can do this amazing trick:
(gather x
macrolet ((with/working ...))
with/working ()
...)
I'm not actually sure that will work though. You can certainly wrap a
MACROLET around the whole thing.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> So I allowed LET and LET* as clauses too. Then I realised that if I
> just *took out* the thing that checked for `clause operators', it
> would work with *any* `standard-contract-WITH' style macro. So now
> you can do:
>
> (gather x
> with-open-file (in f ...)
> for (x (iter in :by :line)))
>
> But the macros have to be standard-contract - they need to take a
> first argument before the body. Of course, it turns out that (I
> think) things are OK. If you havew a broken WITH macro, then I think
> you can do this amazing trick:
>
> (gather x
> macrolet ((with/working ...))
> with/working ()
> ...)
>
> I'm not actually sure that will work though. You can certainly wrap a
> MACROLET around the whole thing.
The thing about with- macros that don't take a first argument is that
you can pretend they take an empty one:
(defmacro with-no-args (&body forms) ...)
(with-no-args ()
...)
What with () being a pretty harmless form to put at the top of a body.
So, still no problem for your loop-alike.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* Thomas F Burdick wrote:
> The thing about with- macros that don't take a first argument is that
> you can pretend they take an empty one:
> (defmacro with-no-args (&body forms) ...)
> (with-no-args ()
> ...)
> What with () being a pretty harmless form to put at the top of a body.
> So, still no problem for your loop-alike.
Other than that you tend to throw up all over the keyboard when you
look at it, no.
--tim
On Wed, 28 Apr 2004 03:35:08 +0000, Wade Humeniuk wrote:
> You can have it both ways. If you NEED to
> supply backward compatibility to with-foo, have
> the with-foo macro detect if there are any
> keyword parameters in the first element
> of the body. But I agree with Kenny, if the
> macro has no options do not imply that there are.
I'm not implying that there are. I'm implying that there might be options
in the future. However, my strongest argument is that with-foo kind of
macros have this pattern of use.
> Original with-foo, (no null option list syntax defined)
>
> (defmacro with-foo (&body body)
> Return original with-foo transform here)
>
> Optioned with-foo, with backward compatibility
>
> (defmacro with-foo (&body body)
> (when (null body) (error "What the!!")) (destructuring-bind (&key
> (arg1 nil) (arg2 nil))
> (when (keyword-argument-list (first body))
> (first body))
> Return optioned with-foo transform here))
>
> Wade
I want to thank everybody for all the proposed solutions. However, that's
not the issue here. The issue goes as follows:
1- The with-foo macros have a pattern for including the macro 'arguments'
(I mean, other arguments besides de body). This pattern is
(with-foo (arg1 arg2 ... argn)
form1
form2
...
formm)
2- Given the fact that _it's a pattern_, most programmers that whan to
use the macro will write
(with-foo (
and then wonder about other arguments to the macro. Then, they look at
the documentation or the arglist or whatever and they see that the macro
don't have options, _yet_. So, they close the argument list and keep
writing
(with-foo ()
...)
3- The fact that I _forced_ them (including myself) to write an empty
argument list allows me to later add whatever arguments I might think are
usefull (with appropriate defaults) without breaking the code they have
written.
I could give you a more "mathematical" argument by saying that the natural
extension of the with-... macro options to zero options is an empty list:
(with-foo (bar baz)
...)
(with-foo (bar)
...)
(with-foo ()
...)
That's the general idea. If you don't agree, fine.
What I want to know is whether this "natural extension" is allowed by ANSI
CL or not.
My rational is the following:
According to the Hyperspec,
Anywhere in a macro lambda list where a parameter name can appear, and
where ordinary lambda list syntax (as described in Section 3.4.1
(Ordinary Lambda Lists)) does not otherwise allow a list, a
destructuring lambda list can appear in place of the parameter name.
When this is done, then the argument that would match the parameter is
treated as a (possibly dotted) list, to be used as an _argument list_
for satisfying the parameters in the embedded _lambda list_. This is
known as destructuring.
Obviously, the concepts of _argument list_ and _lambda list_ include the
empty list. (I couldn't find anything that says otherwise).
This means that I can write a macro call containing an empty list "to be
used as an argument list for satisfying the parameters in the embedded
lambda list":
(macro ... () ...)
The macro lambda list must contain an embedded lambda list that matches
the empty list. The unique solution is:
(defmacro macro (... () ...)
...)
It looks like a QED. However, the Hyperspec also says:
a macro lambda list has the following syntax:
reqvars::= var*
...
_var_ is not specified on the section for "Macro lambda lists" but it is
on the section for "Ordinary lambda lists":
A var or supplied-p-parameter must be a symbol that is not the name of a
constant variable.
The concept of constant variable includes also the empty list. As a
result, if we assume that the _var_ definition for Ordinary lambda lists
is also valid for Macro lambda lists, a macro lambda list cannot have ()
as a macro parameter.
I now looks that there is a contradition in the Hyperspec.
Is there a way out?
Thanks,
Antonio Leitao.
Antonio Menezes Leitao <··············@evaluator.pt> wrote in message news:<······························@evaluator.pt>...
> I now looks that there is a contradition in the Hyperspec.
>
> Is there a way out?
I don't think so, I think that NIL is fine, and it means the empty
list - so it means what you'd think it would when writing
(defmacro with-x (() &body forms) ...)
At least that's what I think the people who have read the spec
carefully are saying. Am I wrong?
--tim
On Wed, 28 Apr 2004 08:21:11 -0700, Tim Bradshaw wrote:
> Antonio Menezes Leitao <··············@evaluator.pt> wrote in message news:<······························@evaluator.pt>...
>
>> I now looks that there is a contradition in the Hyperspec.
>>
>> Is there a way out?
>
> I don't think so, I think that NIL is fine, and it means the empty
> list - so it means what you'd think it would when writing
>
> (defmacro with-x (() &body forms) ...)
>
> At least that's what I think the people who have read the spec
> carefully are saying. Am I wrong?
I think you are right. But I if understood Paul Dietz correctly, the
people behind CLISP think otherwise. I think they are wrong but I'm
looking forward to read what they have to say about this issue.
Antonio Leitao.
Antonio Menezes Leitao <··············@evaluator.pt> writes:
> I'm implying that there might be options in the future. However, my
> strongest argument is that with-foo kind of macros have this pattern
> of use.
Usually, but not always. ANSI CL has WITH-STANDARD-IO-SYNTAX. (Emacs
Lisp has more examples, but I'm not sure they are relevant to this
discussion.)
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff <·········@nocrew.org> wrote in message news:<··············@junk.nocrew.org>...
>
> Usually, but not always. ANSI CL has WITH-STANDARD-IO-SYNTAX. (Emacs
> Lisp has more examples, but I'm not sure they are relevant to this
> discussion.)
I think it's OK if there's *no possibility* that arguments might ever
make sense. In this case I think that it would have been qute nice if
WITH-STANDARD-IO-SYNTAX did have some options, for instance to set a
standard syntax and then alter it in one form:
(with-standard-io-syntax (:print-case :downcase)
...)
Is less indentation than what you have to do now, and perhapos
clearer.
--tim
Antonio Menezes Leitao wrote:
[...]
> It looks like a QED. However, the Hyperspec also says:
>
> a macro lambda list has the following syntax:
>
> reqvars::= var*
>
> ...
>
> _var_ is not specified on the section for "Macro lambda lists" but it is
> on the section for "Ordinary lambda lists":
>
> A var or supplied-p-parameter must be a symbol that is not the name of a
> constant variable.
I have made the same mistake before. However, the relevant details are
given in "3.4.4.1 Destructuring by Lambda Lists":
"Anywhere in a macro lambda list where a parameter name can appear,
[...] a destructuring lambda list can appear in place of the parameter
name."
...and lists of course always also include empty lists.
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
Pascal Costanza wrote:
>> _var_ is not specified on the section for "Macro lambda lists" but it is
>> on the section for "Ordinary lambda lists":
>>
>> A var or supplied-p-parameter must be a symbol that is not the name
>> of a
>> constant variable.
>
>
> I have made the same mistake before. However, the relevant details are
> given in "3.4.4.1 Destructuring by Lambda Lists":
>
> "Anywhere in a macro lambda list where a parameter name can appear,
> [...] a destructuring lambda list can appear in place of the parameter
> name."
>
> ...and lists of course always also include empty lists.
And the constraint that a var is not a symbol that is the name of
a constant variable means that NIL is not ambiguous.
Paul
Paul F. Dietz wrote:
> Pascal Costanza wrote:
>
>>> _var_ is not specified on the section for "Macro lambda lists"
>>> but it is on the section for "Ordinary lambda lists":
>>>
>>> "A var or supplied-p-parameter must be a symbol that is not the
>>> name of a constant variable."
>>
>> I have made the same mistake before. However, the relevant details
>> are given in "3.4.4.1 Destructuring by Lambda Lists":
>>
>> "Anywhere in a macro lambda list where a parameter name can appear,
>> [...] a destructuring lambda list can appear in place of the
>> parameter name."
>>
>> ...and lists of course always also include empty lists.
>
> And the constraint that a var is not a symbol that is the name of a
> constant variable means that NIL is not ambiguous.
Good point.
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
Hello!
Pascal Costanza <········@web.de> wrote:
>[...]
>>> ...and lists of course always also include empty lists.
>> And the constraint that a var is not a symbol that is the name of a
>> constant variable means that NIL is not ambiguous.
>Good point.
But lists (i.e. destructuring lambda lists *instead* of a var) aren't
vars in the first place...
Kind regards,
Hannah.
Paul F. Dietz <·····@dls.net> wrote:
+---------------
| Pascal Costanza wrote:
| > ...and lists of course always also include empty lists.
|
| And the constraint that a var is not a symbol that is the name of
| a constant variable means that NIL is not ambiguous.
+---------------
But according to the CLHS, NIL *is* a constant variable, so if empty
lists are legal and constant variables aren't, then it's ambiguous, yes?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Paul F. Dietz <·····@dls.net> wrote:
> +---------------
> | Pascal Costanza wrote:
> | > ...and lists of course always also include empty lists.
> |
> | And the constraint that a var is not a symbol that is the name of
> | a constant variable means that NIL is not ambiguous.
> +---------------
>
> But according to the CLHS, NIL *is* a constant variable, so if empty
> lists are legal and constant variables aren't, then it's ambiguous, yes?
...but the restriction for constant variables is only given for ordinary
lambda lists, not for macro lambda lists. The description for macro
lambda lists says that they are like ordinary lambda lists, with some
exceptions. () is clearly allowed in macro lambda lists, and () and NIL
are indistinguishable, as Jeremy has already pointed out. It's
reasonable to consider NIL as one of the exceptions that macro lambda
lists make.
Again, I think it's important to ask the question why an implementation
should _insist_ on disallowing NIL in such a situation. This wouldn't
solve a problem, AFAICS.
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
Pascal Costanza wrote:
> ...but the restriction for constant variables is only given for ordinary
> lambda lists, not for macro lambda lists. The description for macro
> lambda lists says that they are like ordinary lambda lists, with some
> exceptions. () is clearly allowed in macro lambda lists, and () and NIL
> are indistinguishable, as Jeremy has already pointed out. It's
> reasonable to consider NIL as one of the exceptions that macro lambda
> lists make.
Another argument: you can destructure lists in macro lambda lists
with something like this:
(defmacro m ((foo bar baz)) `(list ,bar ,baz ,foo))
(macroexpand '(m (1 2 3))) ==> (list 2 3 1)
However, you can also destructure using dotted patterns:
(defmacro m2 ((x y . z)) `(list ,x ,y ',z))
(macroexpand '(m2 (1 2 3))) ==> (list 1 2 '(3))
But ordinary lists are dotted lists, so the first macro was really
(defmacro m ((foo bar baz . nil)) `(list ,bar ,baz ,foo))
with the NIL in the macro lambda list matching the NIL in (1 2 3 . NIL).
Paul
On Wed, 28 Apr 2004 11:43:08 +0200, Pascal Costanza wrote:
> Antonio Menezes Leitao wrote:
> [...]
>
>> It looks like a QED. However, the Hyperspec also says:
>>
>> a macro lambda list has the following syntax:
>>
>> reqvars::= var*
>>
>> ...
>>
>> _var_ is not specified on the section for "Macro lambda lists" but it
>> is on the section for "Ordinary lambda lists":
>>
>> A var or supplied-p-parameter must be a symbol that is not the name
>> of a constant variable.
>
> I have made the same mistake before. However, the relevant details are
> given in "3.4.4.1 Destructuring by Lambda Lists":
>
> "Anywhere in a macro lambda list where a parameter name can appear,
> [...] a destructuring lambda list can appear in place of the parameter
> name."
>
> ...and lists of course always also include empty lists.
>
Thanks. That's also my opinion. In order to remove the
contradiction we need to consider 3.4.4.1 as overriding the _var_
definition on section 3.4.1 (that is used in 3.4.4). In this case, given
the fact that the definition of destructuring lambda lists (in 3.4.5)
explicitly allows an empty list, we conclude that empty lists must be
allowed in macro lambda lists.
I would like to know what is the opinion of the CLISP authors regarding
this issue.
Antonio Leitao.
Wade Humeniuk wrote:
> You can have it both ways. If you NEED to
> supply backward compatibility to with-foo, have
> the with-foo macro detect if there are any
> keyword parameters in the first element
> of the body. But I agree with Kenny, if the
> macro has no options do not imply that there are.
I think this is a very academic discussion. Maybe the OP thinks it is
highly likely that he is going to add options very soon to his macro,
but he just doesn't want to in the first iteration of coding. In such a
scenario I guess it would be reasonable to add a place holder like he
suggests.
The important thing is that it's legal that you can say "()" and "nil"
in a macro lambda list.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
* Kenny Tilton wrote:
> That is not what I said. I said that when it changes I will add the
> options slot to the macro, then visit each occurrence of the macro in
> my code to decide if the new option or options which prompted the
> addition of the slots super-argument need specification. That is not a
> problem for anyone with enough discipline. :) If as might happen I
> have reason to believe no existing use will require anything other
> than the defaults I might be specifying, and there are dozens and
> dozens to change, hello WinGREP.
And you'll check it for everyone else who uses your macro as well? Or
perhaps you'll just decide to change it and screw them, which seems to
be the implication from the stuff I elided. I'm *really* glad I don't
have to use any code you've `designed' like this.
--tim
Tim Bradshaw wrote:
> * Kenny Tilton wrote:
>
>
>>That is not what I said. I said that when it changes I will add the
>>options slot to the macro, then visit each occurrence of the macro in
>>my code to decide if the new option or options which prompted the
>>addition of the slots super-argument need specification. That is not a
>>problem for anyone with enough discipline. :) If as might happen I
>>have reason to believe no existing use will require anything other
>>than the defaults I might be specifying, and there are dozens and
>>dozens to change, hello WinGREP.
>
>
> And you'll check it for everyone else who uses your macro as well? Or
> perhaps you'll just decide to change it and screw them, which seems to
> be the implication from the stuff I elided.
people who pay extra will be notified of the change, probably when their
compiler refuses to rebuild their application. otherwise, yes, screw the
others. why do you think I taking all the extra time required to
maintain an ASDF definition and test it out under Lispworks, and work in
the code necessary to run under Linux? the more people I can suck in,
the more projects I can sabotage.
I'm *really* glad I don't
> have to use any code you've `designed' like this.
resistance is futile. all your event streams are belong to us.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<····················@twister.nyc.rr.com>...
ded.> Tim Bradshaw wrote:
>
> people who pay extra will be notified of the change, probably when their
> compiler refuses to rebuild their application. otherwise, yes, screw the
> others. why do you think I taking all the extra time required to
> maintain an ASDF definition and test it out under Lispworks, and work in
> the code necessary to run under Linux? the more people I can suck in,
> the more projects I can sabotage.
I realised this last night. Your scheme of providing the extra
functionality under a new name is amazingly reminiscent of CIFS (or
SMB, what is its right name this week?), which has repeatedly extended
things by adding new entry points to the API and leaving the old ones
around, to make everyone's life miserable.
I think you're Bill Gates. I'm quite sure I've never seen you and Bill
Gates in the same room. You both employ hordes of underpayed monkeys
to write your code. And you're both American, so it's practically
certain you're actually the same person (most americans are, in my
experience). This explains a lot.
--tim
the nice lady will be along with my medication any minute i expect
Tim Bradshaw wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<····················@twister.nyc.rr.com>...
> ded.> Tim Bradshaw wrote:
>
>>people who pay extra will be notified of the change, probably when their
>>compiler refuses to rebuild their application. otherwise, yes, screw the
>>others. why do you think I taking all the extra time required to
>>maintain an ASDF definition and test it out under Lispworks, and work in
>>the code necessary to run under Linux? the more people I can suck in,
>>the more projects I can sabotage.
>
>
> I realised this last night. Your scheme of providing the extra
> functionality under a new name is amazingly reminiscent of CIFS (or
> SMB, what is its right name this week?), which has repeatedly extended
> things by adding new entry points to the API and leaving the old ones
> around, to make everyone's life miserable.
>
> I think you're Bill Gates. I'm quite sure I've never seen you and Bill
> Gates in the same room. You both employ hordes of underpayed monkeys
> to write your code. And you're both American, so it's practically
> certain you're actually the same person (most americans are, in my
> experience). This explains a lot.
Underpaid? Nonsense. The parking lot is full of nylon, low-elongation
kernmantle rope. None of them drives a vine any more. Six weeks vacation
back in the rainforest, banana bashes every Friday...hello? We do
discourage the sh*t-flinging, but then they have c.l.l. for that.
I must be someone else. <checks wallet> Definitely must be someone else.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
* Kenny Tilton wrote:
> Underpaid? Nonsense. The parking lot is full of nylon, low-elongation
> kernmantle rope. None of them drives a vine any more. Six weeks
> vacation back in the rainforest, banana bashes every Friday...hello?
> We do discourage the sh*t-flinging, but then they have c.l.l. for
> that.
Ah, it's *your* monkeys who do that. Now we know who to blame for the
trolls (er, monkeys, or are they apes anyway, I never can tell).
> I must be someone else. <checks wallet> Definitely must be someone else.
I had a really good response to this but it was way too likely to
cause offence even for me...
--tim
Tim Bradshaw wrote:
> I had a really good response to this but it was way too likely to
> cause offence even for me...
Great, now you have left it to my imagination and I am even more
offended. This must be a case of non-restraining restraint.
:)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·····················@twister.nyc.rr.com>...
> Tim Bradshaw wrote:
> > I had a really good response to this but it was way too likely to
> > cause offence even for me...
>
> Great, now you have left it to my imagination and I am even more
> offended. This must be a case of non-restraining restraint.
>
well, it involved hitler *and* osama bin laden...
Tim Bradshaw wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·····················@twister.nyc.rr.com>...
>
>>Tim Bradshaw wrote:
>>
>>>I had a really good response to this but it was way too likely to
>>>cause offence even for me...
>>
>>Great, now you have left it to my imagination and I am even more
>>offended. This must be a case of non-restraining restraint.
>>
>
>
> well, it involved hitler *and* osama bin laden...
Because I think the signature of a macro should correspond to the
arguments it expects? Or are we going back to my outrageous remarks
about GUIs looking good and being easy to program? Yes, clearly the work
of Satan. C'mon, everyone, it's time for Omigod! They Killfiled Kenny!
You're just pissed off at me because I thought of basing a portable CL
GUI on OpenGL and OpenAL and you didn't. Or is it because you do Java
and XML all day? Or is it just that damn nationalized health system that
can't get your meds to you on time?
:)
This should cheer you up: cl-openal has now been integrated into Cello.
The "Just Shoot Me!" screen capture widget now sounds like Nikon F5 with
motordrive. And every button makes a neat little Star Wars blurp. If the
Savages of CLIM liked my screen shots, wait till they /hear/ the damn
Light Panel. Makes a pinball machine seem understated. Hmmm, do I need a
"Just Wiretap Me!" widget?
Anyway, I need some help. Can some Spinal Tap fan remind me what Nigel
said was the "saddest of all keys" or notes or whatever it was? I found
29mb of Cello notes playing the entire chromatic whatsit and want to get
to work on a splash screen.
To Hell with me,
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> This should cheer you up: cl-openal has now been integrated into
> Cello. The "Just Shoot Me!" screen capture widget now sounds like
> Nikon F5 with motordrive. And every button makes a neat little Star
> Wars blurp. If the Savages of CLIM liked my screen shots, wait till
> they /hear/ the damn Light Panel. Makes a pinball machine seem
> understated. Hmmm, do I need a "Just Wiretap Me!" widget?
>
> Anyway, I need some help. Can some Spinal Tap fan remind me what Nigel
> said was the "saddest of all keys" or notes or whatever it was?
Key of D minor. If your are into modal scales maybe something in mixolydian
is appropriate[1].
> I found 29mb of Cello notes playing the entire chromatic whatsit and
> want to get to work on a splash screen.
>
> To Hell with me,
The locrian scale with its tritone (devil's note) will certainly help ;)
[1] "...even in mere melodies there is an imitation of character,
for the musical modes differ essentially from one another,
and those who hear them are differently affected by each.
Some of them make men sad and grave, like the so-called
Mixolydian..."
- Aristotle, "Politics"
--
Torkel Holm
Torkel Holm wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>This should cheer you up: cl-openal has now been integrated into
>>Cello. The "Just Shoot Me!" screen capture widget now sounds like
>>Nikon F5 with motordrive. And every button makes a neat little Star
>>Wars blurp. If the Savages of CLIM liked my screen shots, wait till
>>they /hear/ the damn Light Panel. Makes a pinball machine seem
>>understated. Hmmm, do I need a "Just Wiretap Me!" widget?
>>
>>Anyway, I need some help. Can some Spinal Tap fan remind me what Nigel
>>said was the "saddest of all keys" or notes or whatever it was?
>
>
> Key of D minor. If your are into modal scales maybe something in mixolydian
> is appropriate[1].
Ok, I got 3 files here, deeper to higher: d1, d2, d3 ranging across
three octaves(?). I am leaving out the sharps, figure that's not it. So
D minor is? Seems like a tough call between d2 and d3.
> The locrian scale with its tritone (devil's note) will certainly help ;)
Surfed around and found an astonishing amount of info, but not much in
the way of WAV files. Odd that. I must say it is fascinating how
technical is music, tho in hindsight it certainly makes sense.
thx.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Torkel Holm wrote:
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>This should cheer you up: cl-openal has now been integrated into
>>>Cello. The "Just Shoot Me!" screen capture widget now sounds like
>>>Nikon F5 with motordrive. And every button makes a neat little Star
>>>Wars blurp. If the Savages of CLIM liked my screen shots, wait till
>>>they /hear/ the damn Light Panel. Makes a pinball machine seem
>>>understated. Hmmm, do I need a "Just Wiretap Me!" widget?
>>>
>>>Anyway, I need some help. Can some Spinal Tap fan remind me what Nigel
>>> said was the "saddest of all keys" or notes or whatever it was?
>> Key of D minor. If your are into modal scales maybe something in
>> mixolydian is appropriate[1].
The mandolin break in Stonehenge is mixolydian.
> Ok, I got 3 files here, deeper to higher: d1, d2, d3 ranging across
> three octaves(?). I am leaving out the sharps, figure that's not it.
> So D minor is? Seems like a tough call between d2 and d3.
I am not sure if I understand you but the D minor scale has no sharps
and the B is flat.
I think this is a correct quote from the movie:
Nigel: Yeah, it's part of a...trilogy really, a musical trilogy I'm doing...
in... D minor, which I always find is really the saddest of all keys
really. I don't know why, but it makes people weep instantly,
you play a..baaaaa...baaaaaa.... it's the horn part.
Marty: It's very pretty.
>> The locrian scale with its tritone (devil's note) will certainly help ;)
>
> Surfed around and found an astonishing amount of info, but not much in
> the way of WAV files. Odd that. I must say it is fascinating how
> technical is music, tho in hindsight it certainly makes sense.
If your are looking for samples of tritones (three whole tones) then
the heavy metal industry is a good shot. Black Sabbath with Black
Sabbath is the classical example. A more modern example is the intro
in Enter Sandman (Metallica).
--
Torkel Holm
Torkel Holm <······@ii.uib.no> wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> > Surfed around and found an astonishing amount of info, but not much in
> > the way of WAV files. Odd that. I must say it is fascinating how
> > technical is music, tho in hindsight it certainly makes sense.
> If your are looking for samples of tritones (three whole tones) then
> the heavy metal industry is a good shot. Black Sabbath with Black
> Sabbath is the classical example. A more modern example is the intro
> in Enter Sandman (Metallica).
I'm fond of YYZ (Rush) and Indiscipline (King Crimson) as tritone
examples, but I don't think either of these qualifies as metal.
Michael
> You're just pissed off at me because I thought of basing a portable CL
> GUI on OpenGL and OpenAL and you didn't. Or is it because you do Java
> and XML all day? Or is it just that damn nationalized health system that
> can't get your meds to you on time?
The kind of meds *I* prefer come from dubious people with large shiny
cars and, ehem, south american connections: I don't think you can get
them on the NHS. As for Java. No, Python. Which is, actually, worse.
Java implementations are at least competent and it's relatively
untainted by evil open-source ideology. But really, I'm just English,
and therefore essentially nasty.
Funnily enough, the machine I bought in 1999 had a fashy graphics card
because I wanted to to stuff with OpenGL (not a GUI though: data
visualisation stuff). I never did. I think doing a GUI based on
openGL is pretty smart (we could now have a big fight about how I
think that doing a GUI at all is a waste of time since Windows Has
Won, but let's skip that and get straight to the gratuitous
insults...)
> Anyway, I need some help. Can some Spinal Tap fan remind me what Nigel
> said was the "saddest of all keys" or notes or whatever it was? I found
> 29mb of Cello notes playing the entire chromatic whatsit and want to get
> to work on a splash screen.
if it is indeed d minor you want d,f,a in some combination for the
base chord.
··········@tfeb.org (Tim Bradshaw) writes:
since Windows Has Won
Ah, yes, just like IBM Has Won.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Tim Bradshaw <···@cley.com> writes:
> * Duane Rettig wrote:
>
> > Ah, yes, just like IBM Has Won.
>
> They never had anywhere *near* Windows' market share.
I think they had closer to 100% than MS ever has. IBM never had
an Apple; as long as Apple has existed, MS have had a hard time
chewing up the 95% and above percentile. And then came linux ...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
* Duane Rettig wrote:
> I think they had closer to 100% than MS ever has. IBM never had
> an Apple; as long as Apple has existed, MS have had a hard time
> chewing up the 95% and above percentile. And then came linux ...
I forget the figures - my copy of the big blue book is somewhere in
storage, but I remember it being 70-80% market share. No, they didn't
have an Apple: they had several - Burroughs, Honeywell, NCR, Univac,
RCA, General Electric, and CDC were the traditional seven, I think.
I'm not sure whether the 70-80% includes or excludes the
plug-compatible people - I expect it excludes them, so their
`effective' market share was probably higher.
MS have not only got 90+% of desktop market share, they've got *so*
much mind share that linux desktops are pretty much just knockoffs of
Windows. I use Evolution where I'm working, and, well, it's just
Outlook with ideology, and not working quite so well.
Linux desktops may well do a lot of damage to Windows, especially in
certain environments, but they'll do this damage by being close enough
to Windows that no one really cares. If Windows comes up with
something, then a short while later, the Linux desktops will have it
too.
At least Cello is not a Windows knockoff.
--tim
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> I forget the figures - my copy of the big blue book is somewhere in
> storage, but I remember it being 70-80% market share. No, they didn't
> have an Apple: they had several - Burroughs, Honeywell, NCR, Univac,
> RCA, General Electric, and CDC were the traditional seven, I think.
> I'm not sure whether the 70-80% includes or excludes the
> plug-compatible people - I expect it excludes them, so their
> `effective' market share was probably higher.
>
Following up to myself, how sad I am...
Anyway, in the above I'm getting side-tracked into niggling about
numbers, which isn't the point. IBM *did* win, in precisely the same
way as MS have won. IBM's fall from being a monopolist didn't happen
because someone came along and produced a better mainframe: it
happened because completely different markets appeared, and IBM
weren't able to dominate them. Most famously, personal computing
happened. IBM *still* dominate the mainframe market, it's just that
there are other markets now (although the mainframe market is far from
dead).
Similarly, MS's fall from being a monopolist, if it happens, won't
happen because someone produces a better desktop environment: it will
happen because some completely different market appears, which MS fail
to dominate. A couple of current candidates would be games consoles
and phones.
Trying to produce a better desktop environment to displace MS (as
opposed to filling a niche) is fighting the last war, the same way as
all the Lisp web servers implemented around 2000 were fighting the
last war. We need to fight the next war, instead.
--tim
(There are still reasons to fear more about MS than IBM - I don't
think IBM ever got to the point where they essentially could set the
computing curriculum in schools, for instance, which MS more-or-less
do: well, they don't, but governments set curricula which are `learn
how to use Windows' in a rather thin disguise.)
··········@tfeb.org (Tim Bradshaw) writes:
> Trying to produce a better desktop environment to displace MS (as
> opposed to filling a niche) is fighting the last war, the same way as
> all the Lisp web servers implemented around 2000 were fighting the
> last war. We need to fight the next war, instead.
It would have been nice if people had written those in the 90s, when I
didn't have the Lisp skills to do a good job at it, but I don't know
that I'd describe it as fighting the last war. More like scratching
one's own itch. There's still a lot of jobs doing web app
programming, so it's nice to have the tools that make it easy to write
these in Lisp.
That said, if Lispers are around the edge of whatever's the Next Big
Thing, hopefully they'll do a better job of jumping on it with Lisp in
a timely fashion than web-app folks did.
Hmm, I wonder how hard it would be to target Java cell phones with Linj?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* Thomas F Burdick wrote:
> It would have been nice if people had written those in the 90s, when I
> didn't have the Lisp skills to do a good job at it, but I don't know
> that I'd describe it as fighting the last war. More like scratching
> one's own itch. There's still a lot of jobs doing web app
> programming, so it's nice to have the tools that make it easy to write
> these in Lisp.
But web application development is not writing a web server: it *was*
doing that in about 1994, but by 2000 it had become this huge task
involving enterprise web bean container application servlet XML
stacks. That's not a *good* thing, but if you want to compete you now
have to talk all these languages. The same way that if you want to
compete on the desktop you have to play well with the standard desktop
environment.
Of course, it's fine to write a web server, a GUI library, or even
some kind of web application framework, but if you want to `succeed'
you have to fight the next war. Of course, `success' means becoming a
creeping horror in about 5 years time, the way J2EE has.
> That said, if Lispers are around the edge of whatever's the Next Big
> Thing, hopefully they'll do a better job of jumping on it with Lisp in
> a timely fashion than web-app folks did.
I hope so. Spend more time looking ahead, and less back.
> Hmm, I wonder how hard it would be to target Java cell phones with Linj?
That would be quite interesting, I think.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Thomas F Burdick wrote:
>
> > It would have been nice if people had written those in the 90s, when I
> > didn't have the Lisp skills to do a good job at it, but I don't know
> > that I'd describe it as fighting the last war. More like scratching
> > one's own itch. There's still a lot of jobs doing web app
> > programming, so it's nice to have the tools that make it easy to write
> > these in Lisp.
>
> But web application development is not writing a web server: it *was*
> doing that in about 1994
You're right, but having a web server in your Lisp image still helps
build Y2K-like web apps. Actually...
> , but by 2000 it had become this huge task
> involving enterprise web bean container application servlet XML
> stacks.
.. it helps more with Y2K4-like web apps (yes, the non-abbreviation is
necessary, we're talking about the www, after all). For some reason,
it seems to have scaled back a little, probably because no one has
money for 100 Suns and Oracle licenses anymore. At least, there seems
to be a larger chunk of web app development that is more friendly to
This Weird System I Have Here.
> I hope so. Spend more time looking ahead, and less back.
>
> > Hmm, I wonder how hard it would be to target Java cell phones with Linj?
>
> That would be quite interesting, I think.
Crap, why do I get the feeling I'm going to start crashing my phone...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Tim Bradshaw <···@cley.com> writes:
> Of course, it's fine to write a web server, a GUI library, or even
> some kind of web application framework, but if you want to `succeed'
> you have to fight the next war. Of course, `success' means becoming a
> creeping horror in about 5 years time, the way J2EE has.
What is the next war? I would like to plan for it. I'm really hoping
I have some semblance of Lisp skill when the shooting starts.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
In article <··············@david-steuber.com>,
David Steuber <·····@david-steuber.com> wrote:
>Tim Bradshaw <···@cley.com> writes:
>
>> Of course, it's fine to write a web server, a GUI library, or even
>> some kind of web application framework, but if you want to `succeed'
>> you have to fight the next war. Of course, `success' means becoming a
>> creeping horror in about 5 years time, the way J2EE has.
>
>What is the next war? I would like to plan for it. I'm really hoping
>I have some semblance of Lisp skill when the shooting starts.
According to the prevailing gossip right now (which, as I'm sure
everybody knows, is infallible, and boy I wonder if Pointcast will
ever be taken out as a too-powerful monopoly for its control over
important push technology?), it's SOA. That is, "Service Oriented
Architecture," which is basically a philosophical approach to Web
service deployment.
As it happens, Lisp is basically a perfect language for SOA -- it
doesn't need a GUI front-end, it can run on a server so clients don't
need to care what language it's written in, it's specifically
language-independent, and (theoretically) XML maps really well to Lisp
ways of processing.
What CL needs to enable that scenario is a layered Web services stack,
consisting of:
1. One of:
a. A really good XML parser that's the de-facto standard for the
environment, and which everyone basically agrees to use, or...
b. A standard (de-facto or otherwise) way to pass parsed XML
documents around. In the Java world, this would be an interface
like SAX or DOM; I'm not sure what it would be in Lisp.
2. Common XML pipeline tools like XSLT and XPath. I could be
convinced that these are unnecessary, and that native Lisp
constructs could give you the expressive power in a more
integrated fashion, though. It'd be cool if true, because it
would simplify things nicely.
3. SOAP stuff. This needs to build on top of the XML layer, which is
why the XML layer needs to be standardized at either the
implementation or interface level.
4. Support libraries for some of the WS-* standards, maybe. I'm not
personally sure how much value these add (but remember, we're
talking about The Future Of Technology, here), so this is fairly
optional, but it couldn't hurt.
5. Oh, and an HTTP library. I think that a mod_lisp already exists,
which should be fine. Heck, a CGI library should really be
sufficient...
--
Mike Kozlowski
http://www.klio.org/mlk/
Mike Kozlowski wrote:
> In article <··············@david-steuber.com>,
> David Steuber <·····@david-steuber.com> wrote:
>
> As it happens, Lisp is basically a perfect language for SOA -- it
> doesn't need a GUI front-end, it can run on a server so clients don't
> need to care what language it's written in, it's specifically
> language-independent, and (theoretically) XML maps really well to Lisp
> ways of processing.
>
> What CL needs to enable that scenario is a layered Web services stack,
> consisting of:
>
> 1. One of:
> a. A really good XML parser that's the de-facto standard for the
> environment, and which everyone basically agrees to use, or...
> b. A standard (de-facto or otherwise) way to pass parsed XML
> documents around. In the Java world, this would be an interface
> like SAX or DOM; I'm not sure what it would be in Lisp.
CL-XML comes pretty darn close. Granted. It's documentantion is not up
to par, but I am willin to give James Anderson *a lot* of credit for
what he has accomlished.
>
> 2. Common XML pipeline tools like XSLT and XPath. I could be
> convinced that these are unnecessary, and that native Lisp
> constructs could give you the expressive power in a more
> integrated fashion, though. It'd be cool if true, because it
> would simplify things nicely.
CL-XML has XPath and XQuery built in. XSLT should not be a difficult
thing. What I think is missing is a nice XSchema translator based on
CL-XML.
> 3. SOAP stuff. This needs to build on top of the XML layer, which is
> why the XML layer needs to be standardized at either the
> implementation or interface level.
SOAP stuff is not necessarily the way to go, but it'll be nice to have.
I would not like any "implementation standardized" solution.
>
> 5. Oh, and an HTTP library. I think that a mod_lisp already exists,
> which should be fine. Heck, a CGI library should really be
> sufficient...
mod_lisp and mod_lisp2 work just fine (modulo "you get what you help
with", that is, if you don't use it, you don't help finding bugs etc etc)
Cheers
--
Marco
From: ··········@YahooGroups.Com
Subject: SOA = Service Oriented Architecture (was: Macro lambda list)
Date:
Message-ID: <REM-2004jul22-001@Yahoo.Com>
> From: Mike Kozlowski <···@klio.org>
> >What is the next war? I would like to plan for it. I'm really hoping
> >I have some semblance of Lisp skill when the shooting starts.
> According to the prevailing gossip right now ...
> ... it's SOA. That is, "Service Oriented
> Architecture," which is basically a philosophical approach to Web
> service deployment.
Is this just the obvious next step from Client/Server and RPC (Remote
Procedure Call)? Client asks server for some service and gets it in
machine-processible form and then adds value before passing to
customer?
> As it happens, Lisp is basically a perfect language for SOA -- it
> doesn't need a GUI front-end, it can run on a server so clients don't
> need to care what language it's written in, it's specifically
> language-independent, and (theoretically) XML maps really well to Lisp
> ways of processing.
How is Lisp language-independent?? Or is that a dangling pronoun,
refers to something other than Lisp?
I'm considering writing an XML parser from scratch. It seems to me the
parser needs to include the following levels:
- Guessing what character encoding the XML is written in (7-bit
US-ASCII, ISO-8859-1 (Latin-1), UTF-8, UCS-2 (codes BMP only), UCS-2E
(a.k.a. UTF-16) and UTF-32), what direction (low-first or high-first)
the multi-byte versions (the last three of the six listed above) are
written, and verifying the first line of the file looks correct in that
guessed encoding, and setting up that particular mapping from file
bytes to UniCode points.
- Parsing the surface syntax of XML, namely the various <...> forms and
the character entities &name; and &decimal; etc. and the contiguous
sequences of literal characters between them.
- Matching opening-container and closing tags to establish hierarchial
structure.
- Validating the hierarchial structure against a DTD or schema that has
been parsed separately.
So did I leave out anything needed in an XML parser?
> What CL needs to enable that scenario is a layered Web services stack,
> consisting of:
> 1. One of:
> a. A really good XML parser that's the de-facto standard for the
> environment, and which everyone basically agrees to use, or...
> b. A standard (de-facto or otherwise) way to pass parsed XML
> documents around. In the Java world, this would be an interface
> like SAX or DOM; I'm not sure what it would be in Lisp.
Why only one of those? Anyway, there's no funding available to pay
anyone to do the work to get a really good anything in CL, and you
aren't likely to get anything really good from somebody who has no
decent source of income and is threatened with homelessness due to no
way to pay the rent.
> 5. Oh, and an HTTP library. I think that a mod_lisp already exists,
> which should be fine. Heck, a CGI library should really be
> sufficient...
It seems to me we need CL to be able to handle both ends of a
connection, service-supplier and service-user, and IIRC mod_lisp
handles only the supplier/server, not the user/client, right? I already
have somewhat of a server-side CGI library that I use for my own
CGI demos, but the demos talk to regular user clients so I haven't had
any need in that context to write the client-side CGI stuff because
lynx is quite sufficient to talk to my demos. But of course if I ever
get around to implementing RPC/HTTP in any form (s-expressions, XML,
whatever), that will require CL-based client-side software.
Are there any demo WebServer sites that handle ficticious XML sessions,
so that client-side XML software could be tested against the demo
server, or even so that potential software developers could manually
play with the demo to make sure they understood the XML session before
seriously designing their code? (It's one thing to read a book or
technical specification about how XML and SOAP work, but that's not
quite like having a live server to talk to to see if you understood it
correctly.) A google search shows some sample XML documents, such as:
http://java.sun.com/developer/earlyAccess/xml/examples/#files
:which would provide test data to somebody developing a parser, but
doesn't cover the full XML session using SOAP etc. the way a live demo
server would.
* David Steuber wrote:
> What is the next war? I would like to plan for it. I'm really hoping
> I have some semblance of Lisp skill when the shooting starts.
If I knew, I probably wouldn't say (but I don't, honest...)
--tim
David Steuber wrote:
> What is the next war? I would like to plan for it. I'm really hoping
> I have some semblance of Lisp skill when the shooting starts.
"The best way to predict the future is to invent it." - Alan Kay
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
David Steuber wrote:
> Tim Bradshaw <···@cley.com> writes:
>
>
>>Of course, it's fine to write a web server, a GUI library, or even
>>some kind of web application framework, but if you want to `succeed'
>>you have to fight the next war. Of course, `success' means becoming a
>>creeping horror in about 5 years time, the way J2EE has.
>
>
> What is the next war? I would like to plan for it. I'm really hoping
> I have some semblance of Lisp skill when the shooting starts.
Virtual Reality. For web sites, games, chat, education, and
hush-hush-say-no-more.
You'll want a portable, 3D sound & graphics Lisp library with built-in
text-to-speech and physics engine. some sort of constraints hack will be
essential.
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> Virtual Reality. For web sites, games, chat, education, and
> hush-hush-say-no-more.
>
> You'll want a portable, 3D sound & graphics Lisp library with built-in
> text-to-speech and physics engine. some sort of constraints hack will be
> essential.
I wonder, where could I possibly find such a thing?
Well, you're certainly aiming high; I appreciate that. I'm going to wait
for the SBCL-portable version to actually use it, though.
Svein Ove Aas wrote:
> Kenny Tilton wrote:
>
>
>>Virtual Reality. For web sites, games, chat, education, and
>>hush-hush-say-no-more.
>>
>>You'll want a portable, 3D sound & graphics Lisp library with built-in
>>text-to-speech and physics engine. some sort of constraints hack will be
>>essential.
>
>
> I wonder, where could I possibly find such a thing?
:( Rainer won't let me advertise anymore. (look at my sig! look at my
sig! third line!!)
> Well, you're certainly aiming high; I appreciate that.
Piece of cake. <gasp gasp>
The only bits missing are text-to-speech and ODE, which looks like the
way to go for physics. The latter seems to be quite active. available
for win32 and *nix, and I see mention of OS X builds on the list. Not
sure if those require X11.
As for text-to-speech, festival covers win32 and linux. Conceivably this
could be the first capability requiring conditionalized code and we drop
into different native libs for speech.
> I'm going to wait
> for the SBCL-portable version to actually use it, though.
Which OS? One porter is threatening to spend some time next week on a
cmucl/linux port, and we already have an allegrocl/linux port. we also
have lispworks/win, so lispworks/linux should be a dunk. Another
potential porter is willing to look at an OpenMCL/OSX port, so I am
toying with forming a posse to bring in OS X. I'd be riding Lispworks
trial. I just need help learning that whacko frameworks crap (which I
hear is actually pretty good) to build all the frickin libs.
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> Svein Ove Aas wrote:
>> I'm going to wait
>> for the SBCL-portable version to actually use it, though.
>
> Which OS? One porter is threatening to spend some time next week on a
> cmucl/linux port, and we already have an allegrocl/linux port. we also
> have lispworks/win, so lispworks/linux should be a dunk. Another
> potential porter is willing to look at an OpenMCL/OSX port, so I am
> toying with forming a posse to bring in OS X. I'd be riding Lispworks
> trial. I just need help learning that whacko frameworks crap (which I
> hear is actually pretty good) to build all the frickin libs.
That would be Linux/x86 and eventually Linux/amd64. It would also be
Windows, except for the strange difficulties I seem to be having trying
to run SBCL in it. I might be getting Lispworks to deal with that; I hope
I don't, since that would mean open-source development for Lisp gets yet
another platform to run on.
(CLISP doesn't count; I need *fast* code.)
Helping you port it is actually on my todo-list; it's just that it's
somewhere between "learn Lisp properly" and "write a human-level AI", so
it may take a while.
Svein Ove Aas wrote:
> Kenny Tilton wrote:
>
>
>>Svein Ove Aas wrote:
>>
>>>I'm going to wait
>>>for the SBCL-portable version to actually use it, though.
>>
>>Which OS? One porter is threatening to spend some time next week on a
>>cmucl/linux port, and we already have an allegrocl/linux port. we also
>>have lispworks/win, so lispworks/linux should be a dunk. Another
>>potential porter is willing to look at an OpenMCL/OSX port, so I am
>>toying with forming a posse to bring in OS X. I'd be riding Lispworks
>>trial. I just need help learning that whacko frameworks crap (which I
>>hear is actually pretty good) to build all the frickin libs.
>
>
> That would be Linux/x86 and eventually Linux/amd64.
Oh, well that should be easy. The cmucl porter I mentioned reports
getting callbacks from C into Lisp working, and I think that is the only
deep technical problem I created by choosing the libraries I did. UFFI
does the rest, and we have seen Cello running on Linux, so I think it is
just a matter of elbow grease.
On OS X, well, I am clueless, but I would like not to require X11. I
think that means dumping Freeglut for OS X and using to Apple's Aqua
Glut. I believe that also offers the same Glut patches necessary for
Lisp-style iterative development.
Now the question is, do I get a G5 desktop to go with my two phat
20-inch Apple CRTs, or a huge PowerBook? I have become quite comfortable
now with a laptop as my main system, but with a G5 I could put up some
Cello frame rates that would really piss off Rahul.
:)
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Hmm, I wonder how hard it would be to target Java cell phones with Linj?
Or with Armed Bear CL?
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
On Tue, 04 May 2004 10:41:45 -0700, Thomas F. Burdick wrote:
> ··········@tfeb.org (Tim Bradshaw) writes:
> [...]
> Hmm, I wonder how hard it would be to target Java cell phones with Linj?
As hard as target Java cell phones with Java.
Antonio Leitao
Antonio Menezes Leitao <··············@evaluator.pt> writes:
>> Hmm, I wonder how hard it would be to target Java cell phones with Linj?
>
> As hard as target Java cell phones with Java.
E.g. a pain in the *ss, it seems :-(
--
(espen)
On Wed, 05 May 2004 09:58:40 +0200, Espen Vestre wrote:
> Antonio Menezes Leitao <··············@evaluator.pt> writes:
>
>>> Hmm, I wonder how hard it would be to target Java cell phones with
>>> Linj?
>>
>> As hard as target Java cell phones with Java.
>
> E.g. a pain in the *ss, it seems :-(
Humm. I thought that Thomas F. Burdick was asking about a comparison
between Linj and other languages, excluding Java, to target Java cell
phones. In this case, I would put Linj on the same league as Java in what
regards the integration with the libraries needed to target Java cell
phones. In what regards Linj versus (any) other language for targeting
Java cell phones, my answer should have been:
_In the worst case_, as hard as target Java cell phones with Java.
In general, due to the fact that Linj output is Java, Linj should be, at
least, as good as Java for the same task. There are (a few trivial)
programs where Linj might be an overkill. However, in most cases, Linj
quickly gives you more productivity than Java.
Just to see if I could prove my claim I gave a first look at the "MIDP 2.0
Introduction to Using Sockets and Datagrams" that is available at Nokia
site. MIDP is the Mobile Information Device Profile and is part of "the
Java runtime environment for today's most popular compact mobile
information devices, such as cell phones and mainstream PDAs". At least,
that's what Sun claims :-)
At the Nokia site, I could find some example files and I decided to
rewrite one of them. In this rewrite, I didn't care about writing good
Linj code but only about replicating the original Java code. I couldn't
compile it because there seems to be some mismatch between the Nokia
examples and the Sun libraries for the MIDP API. Anyway, the Linj program
has 126 lines while the Nokia Java program has 185 lines. By the way, the
original Nokia program was written with really bad indentation, totalling
270 lines (excluding the Copyright, disclaimer & such) so I decided to
re-indent it according to Linj pretty-printer conventions to get those 185
lines.
I looked at the result to understand where were the savings and the main
reasons are:
- defclass generates the needed readers and writers (in this example, it
only saves one writer (the Nokia code doesn't use readers and writers)
- I created a simple macro for the following repetition:
if (out != null) {
try {
out.close();
synchronized(this) {
out = null;
}
} catch (Exception e) {
// there is nothing we can do: ignore
}
}
if (in != null) {
try {
in.close();
synchronized(this) {
in = null;
}
} catch (Exception e) {
// there is nothing we can do: ignore
}
}
The macro is:
(defmacro safe-close (obj var)
`(unless (eq ,var null)
(ignore-errors
(close ,var)
(with-lock (,obj)
(setf ,var null)))))
and the above statements are written in Linj as
(safe-close this out)
(safe-close this in)
- Linj infers several import statements. Those related to the standard
Java APIs do not need to be declared.
- Linj code is more compact. In fact, it's common to replace Java
fragments of the form
}
}
}
}
with Linj fragments of the form
))))
Anyway, I think this example is extremely short to show many Linj
advantages. If I were developing this from scratch I would probably
explore more Linj features.
If anyone wants to see the Linj and Java files, just ask me.
Antonio Leitao.
Antonio Menezes Leitao <··············@evaluator.pt> writes:
> _In the worst case_, as hard as target Java cell phones with Java.
My comment was just out of frustration: Where I work, we had a summer
intern that implemented a java program for mobile devices for us, and
I was astonished at the weird limitations he stumbled upon. First of
all, we were not able to make the application run on one very popular
and nice phone (the Sony Ericsson T610) because of ridiculously
limited memory (and it seems that the new 630 is just as limited).
But even on those devices where the application actually runs, we had
to work our way around a number of difficulties, like the fact that
you can just forget about generating large rsa keys, which is probably
mostly due to the quality of the java libraries (I mean, those things
have processors speeds that equals top-of-the-line computers from just
a few years ago!). Or worse: Ridiculous limits on the length of URLs,
and not the same limit on different devices.
> Anyway, I think this example is extremely short to show many Linj
> advantages. If I were developing this from scratch I would probably
> explore more Linj features.
I think we'll have a look at linj.
We just love to use lisp _everywhere_ :-)
--
(espen)
On Thu, 06 May 2004 10:12:51 +0200, Espen Vestre wrote:
> Antonio Menezes Leitao <··············@evaluator.pt> writes:
>
>> _In the worst case_, as hard as target Java cell phones with Java.
>
> My comment was just out of frustration: Where I work, we had a summer
> intern that implemented a java program for mobile devices for us, and
> I was astonished at the weird limitations he stumbled upon. First of
> all, we were not able to make the application run on one very popular
> and nice phone (the Sony Ericsson T610) because of ridiculously
> limited memory (and it seems that the new 630 is just as limited).
> But even on those devices where the application actually runs, we had
> to work our way around a number of difficulties, like the fact that
> you can just forget about generating large rsa keys, which is probably
> mostly due to the quality of the java libraries (I mean, those things
> have processors speeds that equals top-of-the-line computers from just
> a few years ago!). Or worse: Ridiculous limits on the length of URLs,
> and not the same limit on different devices.
Ummm. There's nothing that Linj can do about that. The idea behind Linj
is to provide a Common Lisp flavour to programming _with_ Java libraries.
If these libraries are crap, so will be the Linj program. Anyway, when we
don't have access to Java libraries (and we don't need neither applets,
nor "write once, run (debug?) everywhere", nor the security model, nor
the remaining few qualities of Java), Common Lisp is a much better choice.
>> Anyway, I think this example is extremely short to show many Linj
>> advantages. If I were developing this from scratch I would probably
>> explore more Linj features.
>
> I think we'll have a look at linj.
> We just love to use lisp _everywhere_ :-)
I'm looking forward to read your comments.
Antonio Leitao
··········@tfeb.org (Tim Bradshaw) writes:
> (There are still reasons to fear more about MS than IBM - I don't
> think IBM ever got to the point where they essentially could set the
> computing curriculum in schools, for instance, which MS more-or-less
> do: well, they don't, but governments set curricula which are `learn
> how to use Windows' in a rather thin disguise.)
Do you mean the so called "European Computer^H^H^H^H^H^H^H^H^HWindows
Driving License"? I have had a look at one of the textbooks used for
that in Italy. The section on operating systems didn't include even a
tiny, half line mention of just the existence of other operating
systems, not even for the sake of historical reference. This is
scarier than the black choppers...
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
* Paolo Amoroso wrote:
> Do you mean the so called "European Computer^H^H^H^H^H^H^H^H^HWindows
> Driving License"?
No, the UK national curriculum (which might be related).
Tim Bradshaw <···@cley.com> writes:
> * Paolo Amoroso wrote:
>
> > Do you mean the so called "European Computer^H^H^H^H^H^H^H^H^HWindows
> > Driving License"?
>
> No, the UK national curriculum (which might be related).
All your mind are belong to us. You have no chance. Make your time.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Tim Bradshaw <···@cley.com> writes:
> Linux desktops may well do a lot of damage to Windows, especially in
> certain environments, but they'll do this damage by being close enough
> to Windows that no one really cares. If Windows comes up with
> something, then a short while later, the Linux desktops will have it
> too.
"If Windows come up with something"? Hah, you forgot to emphasize the IF!
Have you actually seen any of the pictures from a few months ago, where BG
was presenting their prototype "PC of the future"? Not only did it look
like a cheap macintosh clone, they even cloned the background desktop
picture of OS X!
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
>
> "If Windows come up with something"? Hah, you forgot to emphasize the IF!
> Have you actually seen any of the pictures from a few months ago, where BG
> was presenting their prototype "PC of the future"? Not only did it look
> like a cheap macintosh clone, they even cloned the background desktop
> picture of OS X!
I think there is no reason to get excited. BG steals the ideas and
makes them popular. Do you remember OS/2?
--
Marco Gidde
Marco Gidde <···········@tiscali.de> writes:
> I think there is no reason to get excited.
no, but, I think it's pretty amazing how low they're willing to go.
Google is good for refreshing my memory. The prototype I was thinking
of was the "Athens" prototype Gates showed off at WinHEC one year ago.
I didn't quite find the picture I was thinking of, but you should be
able to see the OS X-ripoff desktop picture here:
http://www.microsoftusernetwork.com/unnews/athens.htm
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Marco Gidde <···········@tiscali.de> writes:
>
> > I think there is no reason to get excited.
>
> no, but, I think it's pretty amazing how low they're willing to go.
>
> Google is good for refreshing my memory. The prototype I was thinking
> of was the "Athens" prototype Gates showed off at WinHEC one year ago.
>
> I didn't quite find the picture I was thinking of, but you should be
> able to see the OS X-ripoff desktop picture here:
>
> http://www.microsoftusernetwork.com/unnews/athens.htm
Ug, they're making a Mac for people with no sense of style.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Google is good for refreshing my memory. The prototype I was thinking
> of was the "Athens" prototype Gates showed off at WinHEC one year ago.
...and now the news ticked in that HP & MS are going to show a new
prototype at this years' WinHEC, starting in Seattle today. I wonder
what this years' rip-off is?
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
>
> > Google is good for refreshing my memory. The prototype I was thinking
> > of was the "Athens" prototype Gates showed off at WinHEC one year ago.
>
> ...and now the news ticked in that HP & MS are going to show a new
> prototype at this years' WinHEC, starting in Seattle today. I wonder
> what this years' rip-off is?
Some work out the ideas and some (usually others) make the money. You
have the choice between getting angry about almost everything or
getting cynical. I chose the latter :-)
Marco
Marco Gidde <···········@tiscali.de> writes:
> Some work out the ideas and some (usually others) make the money. You
> have the choice between getting angry about almost everything or
> getting cynical. I chose the latter :-)
I choose to have fun. This is just a good laugh, and I hope they had a
good laugh at Apple, too. Or do you think they all shouted: "Bastards!
They stole our patented desktop wallpaper! We're going to lose all our
customers now!"?
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> I choose to have fun. This is just a good laugh, and I hope they had
> a good laugh at Apple, too. Or do you think they all shouted:
> "Bastards! They stole our patented desktop wallpaper! We're going
> to lose all our customers now!"?
I'm not a Mac user, but what I heard and what I saw made me think,
that there is a bit more about it than just fancy wallpapers.
The hackers at Apple probably had a good laugh, but I doubt that the
management was very amused. Or maybe they simply trust in their loyal
users.
Marco
Tim Bradshaw wrote:
> openGL is pretty smart (we could now have a big fight about how I
> think that doing a GUI at all is a waste of time since Windows Has
> Won, ...
Yeah, but do you want to /program/ win32? One scary thing over here at
Chez Kenny is that things like Petzold (win32 tome) have no relevance.
Nothing involves the OS. Not the graphics, not the cool sound effects,
and not the event stream. As for the application frameworks, MFC? never
heard of it. Shucks, it runs under Linux, 'nuff said.
I know you think consistent look and feel matters, which is part of why
Apple is suing me for this:
ftp://common-lisp.net/pub/project/cello/mandel-scroller.png
That was actually an implicit response to your objection to Cello:
native look-and-feel is easy to copy with a powerful, um, GUI. Those
scrollbars have a mac-p attribute which puts the arrows at opposite ends
of the scrollbar when nil. win32-ish appearance has been left as an
exercise, but check out the "cell pre-cursor" screenshots on tt.com. To
a pixel.
Anyway, I /really/ don't think my Cherry 2000 porno sim will sink or
swim on the nativity of the look/feel.
but let's skip that and get straight to the gratuitous
> insults...)
>
...
> if it is indeed d minor you want d,f,a in some combination for the
> base chord.
I don't have to put up with that kind of abuse. Do I hear you and Torkel
saying I am not looking for one note, but rather a chord? Well, what is
iDVD for if not my Special Edition Spinal Tap? This is kinda cool, I can
actually create three OpenAL contexts (I get up to 32 on my setup) and
bind d,f, and a wav files to them and then kick them all off at once.
What I had been doing was playing the same galloping horse wav on five
or six contexts with staggered start times to create a stampede. Kinda
worked, but could have been better. I should have varied the gain and
maybe even played with the pitch, but really I think a second wav of a
different galloping horse is needed.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> Tim Bradshaw wrote:
>
>> openGL is pretty smart (we could now have a big fight about how I
>> think that doing a GUI at all is a waste of time since Windows Has
>> Won, ...
>
>
> Yeah, but do you want to /program/ win32? One scary thing over here at
> Chez Kenny is that things like Petzold (win32 tome) have no relevance.
> Nothing involves the OS. Not the graphics, not the cool sound effects,
> and not the event stream. As for the application frameworks, MFC? never
> heard of it. Shucks, it runs under Linux, 'nuff said.
>
> I know you think consistent look and feel matters, which is part of why
> Apple is suing me for this:
>
> ftp://common-lisp.net/pub/project/cello/mandel-scroller.png
>
> That was actually an implicit response to your objection to Cello:
> native look-and-feel is easy to copy with a powerful, um, GUI.
No it isn't.
I like cello, but to conclude that look and feel is easy to copy because
you can easily make a brushed-metal window with sky-blue lozenges for
scrollbars is akin to the mistake that beginning programmers make: that
"hello world' is easy to write, therefore software is easy.
Don't fool yourself: GUI toolkits are big and complicated with thousands
of edge cases that actually matter to users and are very hard to get
right (where "right" must needs be defined by what makes users
comfortable).
GUIs don't belong to the same domain as application programming; they
belong to the same domain as industrial design for consumer products,
which is one of the hardest things in the world to succeed at.
mikel wrote:
> Kenny Tilton wrote:
>
>>
>>
>> Tim Bradshaw wrote:
>>
>>> openGL is pretty smart (we could now have a big fight about how I
>>> think that doing a GUI at all is a waste of time since Windows Has
>>> Won, ...
>>
>>
>>
>> Yeah, but do you want to /program/ win32? One scary thing over here at
>> Chez Kenny is that things like Petzold (win32 tome) have no relevance.
>> Nothing involves the OS. Not the graphics, not the cool sound effects,
>> and not the event stream. As for the application frameworks, MFC?
>> never heard of it. Shucks, it runs under Linux, 'nuff said.
>>
>> I know you think consistent look and feel matters, which is part of
>> why Apple is suing me for this:
>>
>> ftp://common-lisp.net/pub/project/cello/mandel-scroller.png
>>
>> That was actually an implicit response to your objection to Cello:
>> native look-and-feel is easy to copy with a powerful, um, GUI.
>
>
> No it isn't.
>
> I like cello, but to conclude that look and feel is easy to copy because
> you can easily make a brushed-metal window with sky-blue lozenges ...
Ah, you had no way of knowing this (unless you noticed me shaking Anton
off my tail with the news that this is my third industrial-strength GUI
and hence could have assumed I must have done the Right Thing) but I
also implemented:
- lozenge size reflects pct of text visible in scroll pane
- scroll bars appear and disappear dynamically as window is resized (and
as the content changes size if I do not have a bug there).
- arrows move one application-defineable increment, autorepeat if held down
- clicking in lozenge trough moves a scroll-pane's distance (doh! I
forgot to subtract an arrow-increment! gotta fix that). autorepeat if
held down.
- speaking of autorepeat, that needs to be enhanced to get the
"double-click time" from the OS, Freeglut does not offer that.
- when I get to the text editor, it will scroll the cursor into view if
it has been scrolled out, after a cursor movement or editing action
- this one is hard to explain, but if the scroll pane is dynamically
resized such that one may as well bring in some scrolled off stuff, it
does. or one do. or does.
- page up/down and the cursor keys work if the scroller has the focus,
an impossibility on the Mac Back In the Day, not sure where they stand
on that under OS X.
for
> scrollbars is akin to the mistake that beginning programmers make: that
> "hello world' is easy to write, therefore software is easy.
>
> Don't fool yourself: GUI toolkits are big and complicated with thousands
> of edge cases ...
Tell me about it. Even the third time around I was impressed by the
hairiness of scrolling. I am sure deets remain.
that actually matter to users and are very hard to get
> right (where "right" must needs be defined by what makes users
> comfortable).
>
> GUIs don't belong to the same domain as application programming; they
> belong to the same domain as industrial design for consumer products,
> which is one of the hardest things in the world to succeed at.
Nonsense. Just do what Bill does. Copy Apple. :)
Seriously, the bit Kenny is doing is just "make a powerful (Cells!)
portable (OpenGL/AL/FTGL) Common Lisp GUI with an industrial strength
workalike for something in-between Windows and the Mac". Anyone wanting
closer fit to some native system then throws in a few hours of
conditionalized tweaks and away they go. That just happens not to be a
concern for me.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: David Steuber
Subject: Re: The Saddest of all Application Frameworks [was Re: Macro lambda list]
Date:
Message-ID: <87ad0tqr5y.fsf@david-steuber.com>
Kenny Tilton <·······@nyc.rr.com> writes:
> - page up/down and the cursor keys work if the scroller has the focus,
> an impossibility on the Mac Back In the Day, not sure where they stand
> on that under OS X.
AFAIK, it is not the scrollers that need the focus, but the window
that they operate on for the cursor keys, page up, page down, and
home, end to move the window contets up and down. The scrollers
themselves do not take focus.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
Kenny Tilton wrote:
> mikel wrote:
>> Kenny Tilton wrote:
>>> That was actually an implicit response to your objection to Cello:
>>> native look-and-feel is easy to copy with a powerful, um, GUI.
>>
>>
>>
>> No it isn't.
>>
>> I like cello, but to conclude that look and feel is easy to copy
>> because you can easily make a brushed-metal window with sky-blue
>> lozenges ...
>
>
> Ah, you had no way of knowing this (unless you noticed me shaking Anton
> off my tail with the news that this is my third industrial-strength GUI
> and hence could have assumed I must have done the Right Thing)
Except that a two-second glance at that image tells me already that it
isn't the Right Thing. It doesn't look like an Aqua application at all;
it looks like something crudely posing as an Aqua application. You can
respond that with additional labor you can make it look arbitrarily
close to right, but then you are just making my argument for me. And
that doesn't begin to address "feel", which is harder yet.
Based on your own description, you have not implemented a good OSX UI,
or a good OSX UI framework, or even a good OSX UI toolkit that could be
used to implement such a framework. What you have implemented is (at
least some of) a graphics and events library that might be good enough
to implement a toolkit that might be good enough to implement a
framework that might be good enough to implement a good OSX application.
> for
>
>> scrollbars is akin to the mistake that beginning programmers make:
>> that "hello world' is easy to write, therefore software is easy.
>>
>> Don't fool yourself: GUI toolkits are big and complicated with
>> thousands of edge cases ...
>
>
> Tell me about it. Even the third time around I was impressed by the
> hairiness of scrolling. I am sure deets remain.
While I agree with that, and with the sentiment that getting this sort
of stuff right can be hairy (I did the resize code in the brushed-metal
QuickTime MoviePlayer, for example, and there are *far* more cases there
than you can possibly imagine), you are still a few laters of
abstraction below the level of an application UI, and none of thee
intervening layers are any easier to get right.
> Seriously, the bit Kenny is doing is just "make a powerful (Cells!)
> portable (OpenGL/AL/FTGL) Common Lisp GUI with an industrial strength
> workalike for something in-between Windows and the Mac". Anyone wanting
> closer fit to some native system then throws in a few hours of
> conditionalized tweaks and away they go. That just happens not to be a
> concern for me.
Change "throws in a few hours of conditionalized tweaks" to "throws in a
few thousand hours of design, architecture, implementation, and
conditionalized tweaks" and I agree with you. And for doing the first
(and easiest, but still absolutely essential) part of that, you have my
gratitude.
mikel wrote:
> .... What you have implemented is (at
> least some of) a graphics and events library that might be good enough
> to implement a toolkit that might be good enough to implement a
> framework that might be good enough to implement a good OSX application.
<snip>
> ... you are still a few laters of
> abstraction below the level of an application UI, and none of thee
> intervening layers are any easier to get right.
>
<snip>
> Change "throws in a few hours of conditionalized tweaks" to "throws in a
> few thousand hours of design, architecture, implementation,
Hush now, you'll scare the children.
One thing that happens with Cells is that the grail of object reuse
becomes a reality, simply because so much more flexibility is obtained
when an instance slot can be envalued with a function instead of a
literal value. Any Lispnik knows the power of first-class functions as
function arguments: the function becomes programmable. Same thing with
Cells and CLOS.
It sounds to me as if you are describing how hard it is to create a
cast-in-concrete framework which can produce any application. Starting
with that kind of contradiction, yes, I can see the need for a terrific
effort and multiple layers of abstraction. but the trick is to lose the
concrete, and Cells do that.
I successfully built a quite large clinical trial management workgroup
document management yada yada browser add-change-delete etc etc system
using my "toolkit", and was able to give it a top-to-bottom makeover in
five days when a new analyst came on board and presented me with some
new screen mockups. A second makeover in as many days was done when
folks attending demos said it could use some eye-candy (and I agreed).
Just a base layer of core classes/functionality -- containers, key
handling, mouse handling, focus management -- boom! yer done. OK, it
took me a few months of fiddling before the framework stabilized, but
that's not too bad, and it all just works and it is actually fun to
program these things.
Mind you, none of this is at all comprehensible without having
programmed with Cells, esp. a GUI. The scary thing is that I have
underhyping the little critters all these years.
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> mikel wrote:
>
>> .... What you have implemented is (at least some of) a graphics and
>> events library that might be good enough to implement a toolkit that
>> might be good enough to implement a framework that might be good
>> enough to implement a good OSX application.
>
>
> <snip>
>
>> ... you are still a few laters of abstraction below the level of an
>> application UI, and none of thee intervening layers are any easier to
>> get right.
>>
>
> <snip>
>
>> Change "throws in a few hours of conditionalized tweaks" to "throws in
>> a few thousand hours of design, architecture, implementation,
>
>
> Hush now, you'll scare the children.
>
> One thing that happens with Cells is that the grail of object reuse
> becomes a reality, simply because so much more flexibility is obtained
> when an instance slot can be envalued with a function instead of a
> literal value. Any Lispnik knows the power of first-class functions as
> function arguments: the function becomes programmable. Same thing with
> Cells and CLOS.
>
> It sounds to me as if you are describing how hard it is to create a
> cast-in-concrete framework which can produce any application. Starting
> with that kind of contradiction, yes, I can see the need for a terrific
> effort and multiple layers of abstraction. but the trick is to lose the
> concrete, and Cells do that.
>
> I successfully built a quite large clinical trial management workgroup
> document management yada yada browser add-change-delete etc etc system
> using my "toolkit", and was able to give it a top-to-bottom makeover in
> five days when a new analyst came on board and presented me with some
> new screen mockups. A second makeover in as many days was done when
> folks attending demos said it could use some eye-candy (and I agreed).
>
> Just a base layer of core classes/functionality -- containers, key
> handling, mouse handling, focus management -- boom! yer done. OK, it
> took me a few months of fiddling before the framework stabilized, but
> that's not too bad, and it all just works and it is actually fun to
> program these things.
>
> Mind you, none of this is at all comprehensible without having
> programmed with Cells, esp. a GUI. The scary thing is that I have
> underhyping the little critters all these years.
That you believe this to be a response to my point makes my point for
me: good UI is not about programming.
mikel wrote:
> Kenny Tilton wrote:
>> Hush now, you'll scare the children.
>>
>> One thing that happens with Cells is that the grail of object reuse
>> becomes a reality, simply because so much more flexibility is obtained
>> when an instance slot can be envalued with a function instead of a
>> literal value. Any Lispnik knows the power of first-class functions as
>> function arguments: the function becomes programmable. Same thing with
>> Cells and CLOS.
>>
>> It sounds to me as if you are describing how hard it is to create a
>> cast-in-concrete framework which can produce any application. Starting
>> with that kind of contradiction, yes, I can see the need for a
>> terrific effort and multiple layers of abstraction. but the trick is
>> to lose the concrete, and Cells do that.
>>
>> I successfully built a quite large clinical trial management workgroup
>> document management yada yada browser add-change-delete etc etc system
>> using my "toolkit", and was able to give it a top-to-bottom makeover
>> in five days when a new analyst came on board and presented me with
>> some new screen mockups. A second makeover in as many days was done
>> when folks attending demos said it could use some eye-candy (and I
>> agreed).
>>
>> Just a base layer of core classes/functionality -- containers, key
>> handling, mouse handling, focus management -- boom! yer done. OK, it
>> took me a few months of fiddling before the framework stabilized, but
>> that's not too bad, and it all just works and it is actually fun to
>> program these things.
>>
>> Mind you, none of this is at all comprehensible without having
>> programmed with Cells, esp. a GUI. The scary thing is that I have
>> underhyping the little critters all these years.
>
>
> That you believe this to be a response to my point makes my point for
> me: good UI is not about programming.
Sorry; this is quite elliptical. I was pretty tired.
My point is this: the ability to make things on the screen is necessary,
but not sufficient, to create a good UI. The ability to make things on
the screen is the easier part of doing good UI; no matter how easy you
make it, the hard part still has to be addressed. If you somehow made a
library that would translate your thoughts into working code with no
actual affort on your part, the hard part of doing good UI would still
be hard.
Good UI is an industrial design problem, not a programming problem.
Industrial design is hard to do well, and its difficulty grows
exponentially with the number of interacting parts a user must
manipulate. The goodness of a UI is not predicted by questions like how
many lines of code it takes to put a complicated interactive image on
the screen, or how much programmer effort it takes to change look and
feel. It is predicted by quantities such as the proportion of times an
unschooled user makes an unthinking choice and the software does what he
or she expects, or the proportion of times an unschooled user infers
that a particular feature must exist and is able to find it in a second
or two.
A UI library can be badly designed in the sense that it gets in the way
of exploring alternatives, or makes it unnecessarily hard to put things
on the screen. But no matter how good a UI library is, it doesn't do
anything to solve what is actually hard about UI. Solving that requires
a particular kind of attention to particular kinds of details, and a lot
of practical knowledge about what people working in a given domain are
likely to care about.
When you offered a screenshot that you evidently think looks like an OSX
application, you provided evidence that you aren't thinking in that
particular way, because, based on your remarks, you believe there are
only trivial differences between the apperance of an OSX application and
that image; OSX users, however, will disagree in great numbers and
passionately, which means that you are not thinking about some of the
issues that the implementor of a toolkit for OSX apps must think
about--and that's just considering the visual design, which is, again,
the easy part. OSX users care a lot about 'feel' issues, which are very
complicated to address, no matter how easy the library code makes it to
implement things.
Similarly, when you reply to my points by arguing that it is so easy to
give one of your apps a makeover, that is evidence that you are ignoring
the more difficult part of making a good UI, that you believe that in
solving the easy part, you have solved the problem.
Even solving the easy part is very useful, but it doesn't solve the
problem. Not even close.
From: David Steuber
Subject: Re: The Saddest of all Application Frameworks [was Re: Macro lambda list]
Date:
Message-ID: <87u0yz8v8t.fsf@david-steuber.com>
mikel <·····@evins.net> writes:
> Good UI is an industrial design problem, not a programming
> problem. Industrial design is hard to do well, and its difficulty
> grows exponentially with the number of interacting parts a user must
> manipulate. The goodness of a UI is not predicted by questions like
> how many lines of code it takes to put a complicated interactive image
> on the screen, or how much programmer effort it takes to change look
> and feel. It is predicted by quantities such as the proportion of
> times an unschooled user makes an unthinking choice and the software
> does what he or she expects, or the proportion of times an unschooled
> user infers that a particular feature must exist and is able to find
> it in a second or two.
I'm relieved to hear that UI design is a difficult problem. It has
been one thing that has given me the most headaches with any
application I've worked on when I had to start dealing with a human
interface.
Even in the small world of HTML (I say small because there is a well
defined markup and HTTP protocol to go with it) interfaces, usability
seems to be the hardest thing to get right. Taking form data and
putting it into a bucket (like an Oracle database) is easy. Doing SQL
queries on it and getting back useful datasets is easy. Choosing how
to display it to the user in a way for a human to read is hard. HTML
is not hard. Dealing with that human IO device is hard.
Of course a programmer is also a human. I expect this is the biggest
reason why designing good libraries is difficult.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
mikel wrote:
>> That you believe this to be a response to my point makes my point for
>> me.....
> When you offered a screenshot that you evidently think looks like an OSX
> application, you provided evidence that you ....
> .... based on your remarks, you believe ....
> Similarly, when you reply to my points by ... that is evidence that you are ignoring...
> the more difficult part of making a good UI, that you believe that in
> solving the easy part, you have solved the problem.
This is delightful. No matter what I say or do, you determine for me
what I meant or intended or thought and then respond to that, your own
conclusions. The fusion folks should be so close to a self-sustaining burn.
I think you mean well and are trying only to make the process more
efficent by reducing the round-trips, but that is a false economy. your
guesswork adds more to the open-items queue than it would remove, which
cannot happen anyway until the guesswork is established as accurate.
Hellooooo briar patch!
I cannot wait to find out what I meant by all that, and which of your
points I just proved. And in the spirit of accelerating the dialog, here
is my response in advance to whatever you say next: "See!"
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
>
> mikel wrote:
>
>>> That you believe this to be a response to my point makes my point for
>>> me.....
>
>
>> When you offered a screenshot that you evidently think looks like an
>> OSX application, you provided evidence that you ....
>
>
>> .... based on your remarks, you believe ....
>
>
>> Similarly, when you reply to my points by ... that is evidence that
>> you are ignoring...
>
>
>> the more difficult part of making a good UI, that you believe that in
>> solving the easy part, you have solved the problem.
>
>
> This is delightful. No matter what I say or do, you determine for me
> what I meant or intended or thought and then respond to that, your own
> conclusions. The fusion folks should be so close to a self-sustaining burn.
You said "native look-and-feel is easy to copy with a powerful, um,
GUI", and to demonstrate your point you offered an image that doesn't
copy native look and feel.
When I said UI design was difficult, you explained that giving your
program a makeover was easy.
Both of these responses are nonresponsive. It's reasonable therefore to
suppose that others of your responses are likely to also be nonresponsive.
Cello may be great for building native look and feel on various
platforms, but what you've said about it so far doesn't offer any reason
to think so. It just suggests that what you say about Cello is unlikely
to offer any information about whether it's good for that purpose.
mikel wrote:
> You said "native look-and-feel is easy to copy with a powerful, um,
> GUI", and to demonstrate your point you offered an image that doesn't
> copy native look and feel.
If you've been following along over the months, Kenny has posted images
that look like various operating systems. They haven't been perfect, but
they're improving. Of all the cross platform GUI frameworks available
for CL, Cello appears to be evolving the most quickly.
> When I said UI design was difficult, you explained that giving your
> program a makeover was easy.
Do you think that Kenny is designing a UI, or copying one or more
existing designs? The two statements above could both be true, because
Kenny is in the (enviable?) position of having a small user base, and
can fix bugs in his framework without worrying about whether 5,000
application developers have been relying on the behaviour of his 1.0
code to write their applications, scheduled to be released concurrently
with his 1.0 operating system.
Kenny seems to be saying "I've outsourced the tough decisions on UI
design to Apple's R&D labs" and you're not accepting that that is possible.
> Both of these responses are nonresponsive. It's reasonable therefore to
> suppose that others of your responses are likely to also be nonresponsive.
>
> Cello may be great for building native look and feel on various
> platforms, but what you've said about it so far doesn't offer any reason
> to think so. It just suggests that what you say about Cello is unlikely
> to offer any information about whether it's good for that purpose.
He's offered links to the code, so you can see for yourself. Expecting
him to defend the possibility of doing what he is clearly doing seems
rather strange.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> mikel wrote:
> > You said "native look-and-feel is easy to copy with a powerful, um,
> > GUI", and to demonstrate your point you offered an image that doesn't
> > copy native look and feel.
>
> If you've been following along over the months, Kenny has posted images
> that look like various operating systems.
Hmm, I must have missed them.
> They haven't been perfect, but
> they're improving. Of all the cross platform GUI frameworks available
> for CL, Cello appears to be evolving the most quickly.
It does?
>
> > When I said UI design was difficult, you explained that giving your
> > program a makeover was easy.
>
> Do you think that Kenny is designing a UI, or copying one or more
> existing designs? The two statements above could both be true, because
> Kenny is in the (enviable?) position of having a small user base, and
> can fix bugs in his framework without worrying about whether 5,000
> application developers have been relying on the behaviour of his 1.0
> code to write their applications, scheduled to be released concurrently
> with his 1.0 operating system.
>
> Kenny seems to be saying "I've outsourced the tough decisions on UI
> design to Apple's R&D labs" and you're not accepting that that is possible.
Apple's UI design is described here:
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/index.html
Keep me informed if there is a cross platform library that is
remotely capable of supporting UI features like that of Aqua.
Bringing up a window with some texture and
some fake OSX scrollbars is about
0,5% of what Apple's Aqua user interface provides.
Apple has a page where they describe some of the difference
between the Windows and the Mac OS X user experience.
http://developer.apple.com/ue/switch/windows.html
This is stuff that is really hard to do with cross
platform code.
> > Both of these responses are nonresponsive. It's reasonable therefore to
> > suppose that others of your responses are likely to also be nonresponsive.
> >
> > Cello may be great for building native look and feel on various
> > platforms, but what you've said about it so far doesn't offer any reason
> > to think so. It just suggests that what you say about Cello is unlikely
> > to offer any information about whether it's good for that purpose.
>
> He's offered links to the code, so you can see for yourself. Expecting
> him to defend the possibility of doing what he is clearly doing seems
> rather strange.
(IMHO) Currently the best cross platform GUI toolkit is LispWorks'
CAPI. It supports X11/Motif (a bit ugly), Windows and Mac OS X.
It still lacks a lot of stuff one might want - but for quite some
applications (like the LispWorks development environment)
it is sufficient.
Sometimes it is funny when cll is Kenny's advertising channel.
Sometimes it is not.
Rainer Joswig wrote:
> Sometimes it is funny when cll is Kenny's advertising channel.
> Sometimes it is not.
This is going to be very embarrassing for you when you sign up for
cello-devel.
:)
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Cameron MacKinnon wrote:
> mikel wrote:
>
>> You said "native look-and-feel is easy to copy with a powerful, um,
>> GUI", and to demonstrate your point you offered an image that doesn't
>> copy native look and feel.
>
>
> If you've been following along over the months, Kenny has posted images
> that look like various operating systems. They haven't been perfect, but
> they're improving. Of all the cross platform GUI frameworks available
> for CL, Cello appears to be evolving the most quickly.
>
>> When I said UI design was difficult, you explained that giving your
>> program a makeover was easy.
>
>
> Do you think that Kenny is designing a UI, or copying one or more
> existing designs? The two statements above could both be true, because
> Kenny is in the (enviable?) position of having a small user base, and
> can fix bugs in his framework without worrying about whether 5,000
> application developers have been relying on the behaviour of his 1.0
> code to write their applications, scheduled to be released concurrently
> with his 1.0 operating system.
>
> Kenny seems to be saying "I've outsourced the tough decisions on UI
> design to Apple's R&D labs" and you're not accepting that that is possible.
>
>> Both of these responses are nonresponsive. It's reasonable therefore
>> to suppose that others of your responses are likely to also be
>> nonresponsive.
>>
>> Cello may be great for building native look and feel on various
>> platforms, but what you've said about it so far doesn't offer any
>> reason to think so. It just suggests that what you say about Cello is
>> unlikely to offer any information about whether it's good for that
>> purpose.
>
>
> He's offered links to the code, so you can see for yourself. Expecting
> him to defend the possibility of doing what he is clearly doing seems
> rather strange.
>
>
Actually, I have his code already, and I like it. It sounds to me like
he's saying that Cello will make it easy to design a UI, or easy t
reproduce the native look and feel of various platforms. I don't believe
it. I hope he proves me wrong.
Cameron MacKinnon wrote:
> mikel wrote:
>
>> You said "native look-and-feel is easy to copy with a powerful, um,
>> GUI", and to demonstrate your point you offered an image that doesn't
>> copy native look and feel.
>
>
> If you've been following along over the months, Kenny has posted images
> that look like various operating systems. They haven't been perfect, but
> they're improving. Of all the cross platform GUI frameworks available
> for CL, Cello appears to be evolving the most quickly.
>
>> When I said UI design was difficult, you explained that giving your
>> program a makeover was easy.
>
>
> Do you think that Kenny is designing a UI, or copying one or more
> existing designs? The two statements above could both be true, because
> Kenny is in the (enviable?) position of having a small user base, and
> can fix bugs in his framework without worrying about whether 5,000
> application developers have been relying on the behaviour of his 1.0
> code to write their applications, scheduled to be released concurrently
> with his 1.0 operating system.
>
> Kenny seems to be saying "I've outsourced the tough decisions on UI
> design to Apple's R&D labs" and you're not accepting that that is possible.
>
>> Both of these responses are nonresponsive. It's reasonable therefore
>> to suppose that others of your responses are likely to also be
>> nonresponsive.
>>
>> Cello may be great for building native look and feel on various
>> platforms, but what you've said about it so far doesn't offer any
>> reason to think so. It just suggests that what you say about Cello is
>> unlikely to offer any information about whether it's good for that
>> purpose.
>
>
> He's offered links to the code, so you can see for yourself. Expecting
> him to defend the possibility of doing what he is clearly doing seems
> rather strange.
By the way, we are clearly not talking about the same thing; I blame myself.
mikel wrote:
> Kenny Tilton wrote:
>
>>
>>
>> mikel wrote:
>>
>>>> That you believe this to be a response to my point makes my point
>>>> for me.....
>>
>>
>>
>>> When you offered a screenshot that you evidently think looks like an
>>> OSX application, you provided evidence that you ....
>>
>>
>>
>>> .... based on your remarks, you believe ....
>>
>>
>>
>>> Similarly, when you reply to my points by ... that is evidence that
>>> you are ignoring...
>>
>>
>>
>>> the more difficult part of making a good UI, that you believe that in
>>> solving the easy part, you have solved the problem.
>>
>>
>>
>> This is delightful. No matter what I say or do, you determine for me
>> what I meant or intended or thought and then respond to that, your own
>> conclusions. The fusion folks should be so close to a self-sustaining
>> burn.
>
>
> You said "native look-and-feel is easy to copy with a powerful, um,
> GUI", and to demonstrate your point you offered an image that doesn't
> copy native look and feel.
and maybe someday you will say how it does not. are you thinking I meant
the whole window? I was just talking about the scroller and resize
widget. are you saying Apple's graphics are better than mine? Yep.
other? (and please, something other than an undisputed ode to the
Unbearable Staggeringness of UIs).
more important, the full context is "I do not give a New York City
subway rat's ass about native look-and-feel and native is an explicit
/non/-goal of Cello. besides, it is easy to yada yada." So whether I am
right about the latter has nothing to do with Cello as advertised. If
anyone else misconstrued my remarks to think I meant "use Cello to build
applications with native interfaces"... good lord, no. It is easy enough
to develop widgets that work like native widgets (eg, a button is not
considered clicked until the mouse is released over the button), so your
users will be comfortable using your app, but they will also know you
did not use Aqua/Cocoa/whatever to build it (albeit not in those terms).
Cello has a few widgets now with more coming, and they work like
native widgets I do respect the work of Apple and consistency /is/ good
and Cello makes it easy to copy the substance of widget workings, but
when it comes to things like having the scroller arrow positioning
correspond to the OS X user preference setting--/that/ is left as an
exercise for another day.
Right now the bet is that a portable CL GUI will be valuable without
native look-and-feel. I sure as hell plan to ship commercial apps with
it, and they will have great interfaces.
> Both of these responses are nonresponsive. It's reasonable therefore to
> suppose that others of your responses are likely to also be nonresponsive.
See? You still don't get it. way too meta-thready. I respond and you say
"unresponsive!". Says you! How else can I respond to that, especially
having had unsupported charges of unresponsivesness and/or immateriality
thrown in my face? Free advice: lose this style of discourse. Just say
something specific about how Cello cannot be used to build applications,
because that is what I am hearing, and having built applications with
Cello precursors (and the users loved the interface) I must say I am on
the edge of my seat.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
> Right now the bet is that a portable CL GUI will be valuable without
> native look-and-feel. I sure as hell plan to ship commercial apps with
> it, and they will have great interfaces.
Sounds great. I look forward to it.
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·····················@twister.nyc.rr.com>...
> Right now the bet is that a portable CL GUI will be valuable without
> native look-and-feel. I sure as hell plan to ship commercial apps with
> it, and they will have great interfaces.
>
This is plausible I think. People are now used to dealing with big
complicated web `applications' which have not-entirely-native
interfaces, and often very bad ones indeed, both because good ones are
very hard, and because, well, they're just crap basically. So if you
can do better than that, you might win.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> People are now used to dealing with big complicated web
> `applications' which have not-entirely-native interfaces, and often
> very bad ones indeed, both because good ones are very hard, and
> because, well, they're just crap basically.
what's more, people are nowadays used to native apps with
non-native-looking GUI's, like Winamp. what's more, people seem to
actually _like_ such things, if the widespread enthusiasm about
"themes" and "skins" is anything to judge from.
never idealize people.
--
Purely applicative languages are poorly applicable.
-- Alan Perlis
Michael Livshin wrote:
> ··········@tfeb.org (Tim Bradshaw) writes:
>
>
>>People are now used to dealing with big complicated web
>>`applications' which have not-entirely-native interfaces, and often
>>very bad ones indeed, both because good ones are very hard, and
>>because, well, they're just crap basically.
>
>
> what's more, people are nowadays used to native apps with
> non-native-looking GUI's, like Winamp. what's more, people seem to
> actually _like_ such things, if the widespread enthusiasm about
> "themes" and "skins" is anything to judge from.
>
> never idealize people.
>
I see two changes since the day when apps delivered for the Mac which
were pure look-and-feel ports of DOS applications (albeit with GUIs)
died a quick death: (1) users spend more time on the web than anything
else, so "standard UI" is out the window (2) users no longer need the
crutch of every application working exactly the same in order to be able
to use them; their facility with interfaces has been generalized through
exposure to many kinds to a higher order ability to "click that, see
what happens" or "hit right-click (or the Mac equivalent)" and see what
happens.
Speaking of which (right-click), this is not a black & white issue.
Cello (when it gets pop-up menus) will include context-sensitive menus.
Scrollers do work like standard scrollers. Buttons are /not/ considered
clicked until the mouseup, and only if the mouse is still over the
button clicked. etc etc etc.
Demon Kenny has done more real-world app development than any of these
yabos nipping at his heels, and unlike this Usenet bullshit, he takes it
seriously.
slim kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
>
> Speaking of which (right-click), this is not a black & white issue.
> Cello (when it gets pop-up menus) will include context-sensitive menus.
Personally, I hate context sensitive menus. At least ones that change
order and displayed items instead of just ghosting out inapplicable items.
Amiga magicmenu did it right - the ordinary "top of screen menus" were just
moved to wherever the mouse was on right click. Context sensitivity was
limited to greying out inapplicable menu items, no crazy jumping items.
That way you COULD LEARN WHERE THE $&$#ING MENU ITEMS WERE. The way
"context menus" are implemented on Windows and Linux (haven't used a mac
enough to comment) makes me nauseous.
Right now you have top-menu, toolbar, right-click context menu, all with
overlapping functionality. Just give me a big scrolly menu on the right
click, ghosting entries that don't make sense in context. Who needs a
toolbar or top-menu?
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: The Saddest of all Application Frameworks
Date:
Message-ID: <w4chduxp11w.fsf@boris.cd.chalmers.se>
David Golden <············@oceanfree.net> writes:
> Right now you have top-menu, toolbar, right-click context menu, all with
> overlapping functionality. Just give me a big scrolly menu on the right
> click, ghosting entries that don't make sense in context. Who needs a
> toolbar or top-menu?
Multi-level pie-menu would be nicer. Scrolling menus, as well as
"steppy" menus (those that tend to have a small triangle in the
right end on some items) are just /so/ inconvenient.
Regards,
'mr, who also feels this is the appropriate time to point out that
the only /convenient/ scrollbars are the Athena-style ones.
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
> ...
>
> Regards,
>
> 'mr, who also feels this is the appropriate time to point out that
> the only /convenient/ scrollbars are the Athena-style ones.
Let me be the first to congratulate you on your intelligence, your
discernment, and your taste.
--
Fred Gilham ······@csl.sri.com
When trying to reach the lowest common denominator, you have to be
prepared for the occasional division by zero.
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
>
> > ...
> >
> > Regards,
> >
> > 'mr, who also feels this is the appropriate time to point out that
> > the only /convenient/ scrollbars are the Athena-style ones.
>
> Let me be the first to congratulate you on your intelligence, your
> discernment, and your taste.
I wonder what you'll say about me when I note that they don't work
very well with the one-button mouse on my iBook... (duck)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick writes:
> I wonder what you'll say about me when I note that they don't work
> very well with the one-button mouse on my iBook... (duck)
Do Apple mice still have buttons? Here's a quote from Tim Bradshaw
from a couple years ago, courtesy of Google:
Tim Bradshaw wrote:
> Justin Johnson wrote:
> > User interface designed for apes? Seems to look a bit more like a
> > Mac to me.
>
> True. It's hard to get non-simian-optimized user interfaces any
> more. The mac is probably the cause. They don't even have a
> *single* button on their mice any more, do they - it was too hard to
> hit reliably I suppose. Now you just kind of hammer away at the top
> of the mouse until something happens.
(Sorry Tim, but you're so darn quotable.)
--
Fred Gilham ······@csl.sri.com
The density of a textbook must be inversely proportional to the
density of the students using it. --- Dave Stringer-Calvert
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> Thomas F. Burdick writes:
> > I wonder what you'll say about me when I note that they don't work
> > very well with the one-button mouse on my iBook... (duck)
>
> Do Apple mice still have buttons? Here's a quote from Tim Bradshaw
> from a couple years ago, courtesy of Google:
>
> Tim Bradshaw wrote:
> > Justin Johnson wrote:
> > > User interface designed for apes? Seems to look a bit more like a
> > > Mac to me.
> >
> > True. It's hard to get non-simian-optimized user interfaces any
> > more. The mac is probably the cause. They don't even have a
> > *single* button on their mice any more, do they - it was too hard to
> > hit reliably I suppose. Now you just kind of hammer away at the top
> > of the mouse until something happens.
>
> (Sorry Tim, but you're so darn quotable.)
I'm not sure what you and Tim want out of a UI, but I'm rather a fan
of simian-oriented UIs. I mean, my cat would prefer to sniff,
scratch, and poke at things; but me, if walking away caused my machine
to do something, I'd be a little disturbed. I probably wouldn't start
flinging feces, but you never know...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> I'm not sure what you and Tim want out of a UI, but I'm rather a fan
> of simian-oriented UIs. I mean, my cat would prefer to sniff,
> scratch, and poke at things; but me, if walking away caused my machine
> to do something, I'd be a little disturbed. I probably wouldn't start
> flinging feces, but you never know...
Flinging feces is what windows does.
I came across an XP machine the other day for the first time. After
about ten seconds of fiddling with it, I wanted to take a baseball bat
to it.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
From: Tim Bradshaw
Subject: Re: The Saddest of all Application Frameworks
Date:
Message-ID: <ey3r7tzuaox.fsf@cley.com>
* Fred Gilham wrote:
> Do Apple mice still have buttons? Here's a quote from Tim Bradshaw
> from a couple years ago, courtesy of Google:
I believe the true simian interfaces currently in development at apple
will have no mice at all, instead you'll just batter anything in sight
until it works. Most usenet articles are already composed this way.
--tim
Fred Gilham wrote:
> Thomas F. Burdick writes:
>
>>I wonder what you'll say about me when I note that they don't work
>>very well with the one-button mouse on my iBook... (duck)
>
> Do Apple mice still have buttons?
It's obvious that you have never used a Mac. This argument is similar to
the "lots of silly parentheses" argument used against Lisp, and it's as
wrong.
Mac users very happily use three-button mice since a long time. However:
The fact that Apple only provides single-button mice makes developers
think harder about usability issues - all functions have to be
accessible via that single button. It's one of those things that make
you feel much more comfortable with Macs than with Windows.
(BTW, the downside of Mac OS X is that not everything is accessible via
key strokes at the moment - that's one of the things I am missing from
the Windows world. I hope Apple will fix that sometime.)
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> writes:
> Fred Gilham wrote:
>> Do Apple mice still have buttons?
>
> It's obvious that you have never used a Mac.
Um, no.
New Apple mice (some of them, at least), don't have buttons. You
press the entire mouse down to register a click. For example,
http://www.g4store.com/news/macworldexpo2000/mouse/
Or check the mice for sale at the Apple store.
(I think Fred's post comes under the heading "Humor".)
--
Alan Shutko <···@acm.org> - I am the rocks.
"We're explorers from another galaxy." - Alien
Alan Shutko <···@acm.org> writes:
> Pascal Costanza <········@web.de> writes:
>
> > Fred Gilham wrote:
>
> >> Do Apple mice still have buttons?
> >
> > It's obvious that you have never used a Mac.
>
> Um, no.
>
> New Apple mice (some of them, at least), don't have buttons. You
> press the entire mouse down to register a click. For example,
>
> http://www.g4store.com/news/macworldexpo2000/mouse/
>
> Or check the mice for sale at the Apple store.
>
> (I think Fred's post comes under the heading "Humor".)
Um, yes, thanks, it was supposed to be a little humor. Perhaps it was
too little to be detectable. Sorry about that. I thought I whacked
the emoticon key. Must have missed.... $-) Oops, lets get it right
this time. %') ··@:-( %*} %+{ %-(I) %-) %-6 %-<I> %-\ %-^ %-{ %-| %-}
%-~ %\v &-| &.(.. &:-) '-) :-) There, got it.
--
Fred Gilham ······@csl.sri.com
When my years have come and gone, I hope I'll have the wisdom to fly
like a bird of fire into the twilight sky of life. -- Vincent Sargenti
Alan Shutko <···@acm.org> wrote in message news:<··············@wesley.springies.com>...
> Pascal Costanza <········@web.de> writes:
>
> > Fred Gilham wrote:
>
> >> Do Apple mice still have buttons?
> >
> > It's obvious that you have never used a Mac.
>
> Um, no.
>
> New Apple mice (some of them, at least), don't have buttons. You
> press the entire mouse down to register a click. For example,
>
> http://www.g4store.com/news/macworldexpo2000/mouse/
>
> Or check the mice for sale at the Apple store.
>
> (I think Fred's post comes under the heading "Humor".)
I have Apple's buttonless mouse with Bluetooth. Very nice.
Highly recommended.
From: Karl A. Krueger
Subject: Re: The Saddest of all Application Frameworks
Date:
Message-ID: <c79j21$4q4$1@baldur.whoi.edu>
Pascal Costanza <········@web.de> wrote:
> (BTW, the downside of Mac OS X is that not everything is accessible via
> key strokes at the moment - that's one of the things I am missing from
> the Windows world. I hope Apple will fix that sometime.)
You can bind a keyboard shortcut to any menu item in the Keyboard &
Mouse control panel in OS X 10.3.
You can also access the menu bar with Ctrl-F2, then select menus with
the arrow keys and menu items with either the arrows or by typing the
first letter of the menu item.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
Karl A. Krueger wrote:
> Pascal Costanza <········@web.de> wrote:
>
>>(BTW, the downside of Mac OS X is that not everything is accessible via
>>key strokes at the moment - that's one of the things I am missing from
>>the Windows world. I hope Apple will fix that sometime.)
>
> You can bind a keyboard shortcut to any menu item in the Keyboard &
> Mouse control panel in OS X 10.3.
>
> You can also access the menu bar with Ctrl-F2, then select menus with
> the arrow keys and menu items with either the arrows or by typing the
> first letter of the menu item.
I wasn't aware of that - thanks!
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
From: Rahul Jain
Subject: Re: The Saddest of all Application Frameworks
Date:
Message-ID: <87hdupdpx9.fsf@nyct.net>
Pascal Costanza <········@web.de> writes:
> Mac users very happily use three-button mice since a long time.
You mean four-button.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
mikel <·····@evins.net> wrote in message news:<·····················@newssvr29.news.prodigy.com>...
>
> That you believe this to be a response to my point makes my point for
> me: good UI is not about programming.
This reminds me of arguments I used to have with Metafont and (to a
lesser extent) TeX people (I am, or was, a TeX person back then,
anyway: I wish I still was, actually). People would say that if you
wanted to design type, then you could learn Metafont and then you'd be
able to do it, and much faster than it was traditionally done. My
response was that you probably can't design decent type in the first
place because I don't think it's a talent many people have, but if you
want to do it what you need to do is to study a huge number of types,
learn how they work, learn how to draw them, then eventually *draw*
your type design (in lots of sizes so you can understand the
constraints &c) then finally you can use Metafont to implement it.
And this will take you 10 years, of which a year or so will be
designing a typeface, and a couple of months of that year will be
implementing it in Metafont.
This is not to say that Kenny (or one of his many monkeys) does not
have these skills. (See how nice I'm being? Now we've established
that he is, in fact, the Evil Overlord, I figure I'd better be nice to
him in case he dispatches his black helicopters and $^(9((((!NO
CARRIER
--tim
Tim Bradshaw wrote:
> mikel <·····@evins.net> wrote in message news:<·····················@newssvr29.news.prodigy.com>...
>
>
>>That you believe this to be a response to my point makes my point for
>>me: good UI is not about programming.
>
>
> This reminds me of arguments I used to have with Metafont and (to a
> lesser extent) TeX people (I am, or was, a TeX person back then,
> anyway: I wish I still was, actually). People would say that if you
> wanted to design type, then you could learn Metafont and then you'd be
> able to do it, and much faster than it was traditionally done. My
> response was that you probably can't design decent type in the first
> place because I don't think it's a talent many people have, but if you
> want to do it what you need to do is to study a huge number of types,
> learn how they work, learn how to draw them, then eventually *draw*
> your type design (in lots of sizes so you can understand the
> constraints &c) then finally you can use Metafont to implement it.
> And this will take you 10 years, of which a year or so will be
> designing a typeface, and a couple of months of that year will be
> implementing it in Metafont.
I agree: it's the same type of argument.
From: David Steuber
Subject: Re: The Saddest of all Application Frameworks [was Re: Macro lambda list]
Date:
Message-ID: <87zn8p880p.fsf@david-steuber.com>
mikel <·····@evins.net> writes:
> Tim Bradshaw wrote:
> > mikel <·····@evins.net> wrote in message news:<·····················@newssvr29.news.prodigy.com>...
> >
> >> That you believe this to be a response to my point makes my point
> >> for me: good UI is not about programming.
> > This reminds me of arguments I used to have with Metafont and (to a
> > lesser extent) TeX people (I am, or was, a TeX person back then,
> > anyway: I wish I still was, actually). People would say that if you
> > wanted to design type, then you could learn Metafont and then you'd be
> > able to do it, and much faster than it was traditionally done. My
> > response was that you probably can't design decent type in the first
> > place because I don't think it's a talent many people have, but if you
> > want to do it what you need to do is to study a huge number of types,
> > learn how they work, learn how to draw them, then eventually *draw*
> > your type design (in lots of sizes so you can understand the
> > constraints &c) then finally you can use Metafont to implement
> > it. And this will take you 10 years, of which a year or so will be
> > designing a typeface, and a couple of months of that year will be
> > implementing it in Metafont.
>
> I agree: it's the same type of argument.
Bad puns really shouldn't go unpunished.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber wrote:
> mikel <·····@evins.net> writes:
>
>
>>Tim Bradshaw wrote:
>>
>>>mikel <·····@evins.net> wrote in message news:<·····················@newssvr29.news.prodigy.com>...
>>>
>>>
>>>>That you believe this to be a response to my point makes my point
>>>>for me: good UI is not about programming.
>>>
>>>This reminds me of arguments I used to have with Metafont and (to a
>>>lesser extent) TeX people (I am, or was, a TeX person back then,
>>>anyway: I wish I still was, actually). People would say that if you
>>>wanted to design type, then you could learn Metafont and then you'd be
>>>able to do it, and much faster than it was traditionally done. My
>>>response was that you probably can't design decent type in the first
>>>place because I don't think it's a talent many people have, but if you
>>>want to do it what you need to do is to study a huge number of types,
>>>learn how they work, learn how to draw them, then eventually *draw*
>>>your type design (in lots of sizes so you can understand the
>>>constraints &c) then finally you can use Metafont to implement
>>>it. And this will take you 10 years, of which a year or so will be
>>>designing a typeface, and a couple of months of that year will be
>>>implementing it in Metafont.
>>
>>I agree: it's the same type of argument.
>
>
> Bad puns really shouldn't go unpunished.
;-)
Tim Bradshaw wrote:
> And this will take you 10 years, of which a year or so will be
> designing a typeface, and a couple of months of that year will be
> implementing it in Metafont.
Bad analogy, tho it seems to be what Mikel is saying. I see youse guys
talking about two things at once, jumping from one to the other as suits
the foxhole from which you are sniping. There is micro-UI (buttons do
not take effect until released, but scroll arrows jump a line
immediately because if held down they auto-repeat -- come to think of
it, the rule might be "/anything/ that autorepeats also takes effect on
the mousedown". Cello will do that. Then there is the UI design above
the micro-behavior of widgets, the way widgets work together given the
semantics of the application. Is there some framework that understands
the application i am writing and guarantees good UI given some minimum
level of cooperation from me? If so, that is wonderful, but let's not
redefine "application framework" to mean that, it really is worthy of a
new word. Let's call it a "bradshawnian fantasy". :)
>
> This is not to say that Kenny (or one of his many monkeys) does not
> have these skills. (See how nice I'm being? Now we've established
> that he is, in fact, the Evil Overlord, ...
Evil Overlord? See! You know nothing of marketing. We are building a
brand here, we need "Kenny" in there somewhere. "Demon Kenny" and "Slim
Kenny" are the finalists.
I figure I'd better be nice to
> him in case he dispatches his black helicopters and $^(9((((!NO
Ah, you still think I am The Software Developer Who Can Afford An Air
Force. Could explain these ridiculous fuel bills, tho....
slim kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> "Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
Kenny> Evil Overlord? See! You know nothing of marketing. We are building a
Kenny> brand here, we need "Kenny" in there somewhere. "Demon Kenny" and
Kenny> "Slim Kenny" are the finalists.
Is this some kind of the opposite to "Fat Elvis"?
:-)
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Christian Lynbech wrote:
>>>>>>"Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
>
>
> Kenny> Evil Overlord? See! You know nothing of marketing. We are building a
> Kenny> brand here, we need "Kenny" in there somewhere. "Demon Kenny" and
> Kenny> "Slim Kenny" are the finalists.
>
> Is this some kind of the opposite to "Fat Elvis"?
Word up! (Where is Burdick when I need him?) You most know your hip-hop.
But it's a parallel, not a contrast: Marshal Mathers aka Eminem aka Slim
Shady even notes in a lyric that he, like Elvis, is a white musician who
got rich copying black music. Clear the kids from the room, then check
it out:
http://www.eminem.com
If I have it right, Slim Shady is the evil side, Eminem the good side.
kayintee
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Christian Lynbech wrote:
> >>>>>>"Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
> >
> >
> > Kenny> Evil Overlord? See! You know nothing of marketing. We are building a
> > Kenny> brand here, we need "Kenny" in there somewhere. "Demon Kenny" and
> > Kenny> "Slim Kenny" are the finalists.
> >
> > Is this some kind of the opposite to "Fat Elvis"?
>
> Word up! (Where is Burdick when I need him?) You most know your hip-hop.
I was wondering if that's where you were going with that. I'd suggest
"Ken Shady", personally.
> If I have it right, Slim Shady is the evil side, Eminem the good side.
Well, you have the first part right.
His current group is advertising themselves as having "Malt Liquor
flows" -- not evil, but it might now qualify as "good".
Actually, considering that you're always dragging Lispers in NYC to
your bars, and bragging about what your bartender thinks about your
Lisp programs, maybe it's appropriate (not that I'm suggesting you
drink OE).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
How about Tilted Kenny..
On 04 May 2004 21:42:50 -0700, Thomas F. Burdick
<···@famine.OCF.Berkeley.EDU> wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>> Christian Lynbech wrote:
>> >>>>>>"Kenny" == Kenny Tilton <·······@nyc.rr.com> writes:
>> >
>> >
>> > Kenny> Evil Overlord? See! You know nothing of marketing. We are
>> building a
>> > Kenny> brand here, we need "Kenny" in there somewhere. "Demon Kenny"
>> and
>> > Kenny> "Slim Kenny" are the finalists.
>> >
>> > Is this some kind of the opposite to "Fat Elvis"?
>>
>> Word up! (Where is Burdick when I need him?) You most know your hip-hop.
>
> I was wondering if that's where you were going with that. I'd suggest
> "Ken Shady", personally.
>
>> If I have it right, Slim Shady is the evil side, Eminem the good side.
>
> Well, you have the first part right.
> His current group is advertising themselves as having "Malt Liquor
> flows" -- not evil, but it might now qualify as "good".
>
> Actually, considering that you're always dragging Lispers in NYC to
> your bars, and bragging about what your bartender thinks about your
> Lisp programs, maybe it's appropriate (not that I'm suggesting you
> drink OE).
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
mikel <·····@evins.net> writes:
> [..] GUIs don't belong to the same domain as application
> programming; they belong to the same domain as industrial design for
> consumer products, which is one of the hardest things in the world
> to succeed at.
I tend to agree, and this is just one of the reasons I see why there
should be a much deeper and cleaner separation between applications
(which can be defined loosely as state + functions) and GUIs or
(human) interaction systems in general.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> mikel <·····@evins.net> writes:
>
> > [..] GUIs don't belong to the same domain as application
> > programming; they belong to the same domain as industrial design for
> > consumer products, which is one of the hardest things in the world
> > to succeed at.
>
> I tend to agree, and this is just one of the reasons I see why there
> should be a much deeper and cleaner separation between applications
> (which can be defined loosely as state + functions) and GUIs or
> (human) interaction systems in general.
Deeper even than MVC? Currently that is the 'design pattern' used by
Cocoa. I guess Java.Swing must use it also since Sun also pushes MVC.
I am not really sold on MVC myself. I certainly agree that the view
needs to be seperate from the application logic. However, the
decoupling of model-controler is something I don't quite get the
advantage of.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
David Steuber wrote:
> Frode Vatvedt Fjeld <······@cs.uit.no> writes:
>
>
>>mikel <·····@evins.net> writes:
>>
>>
>>>[..] GUIs don't belong to the same domain as application
>>>programming; they belong to the same domain as industrial design for
>>>consumer products, which is one of the hardest things in the world
>>>to succeed at.
>>
>>I tend to agree, and this is just one of the reasons I see why there
>>should be a much deeper and cleaner separation between applications
>>(which can be defined loosely as state + functions) and GUIs or
>>(human) interaction systems in general.
>
>
> Deeper even than MVC? Currently that is the 'design pattern' used by
> Cocoa. I guess Java.Swing must use it also since Sun also pushes MVC.
>
> I am not really sold on MVC myself. I certainly agree that the view
> needs to be seperate from the application logic. However, the
> decoupling of model-controler is something I don't quite get the
> advantage of.
In Cello every view has a slot for a model instance. As an experiment I
tried multiple-inheritance early on, in which an instance could be both
a model and a view, but did not like it at all. As for control, that is
a separate abstract class hierarchy and I create instantiable controls
by inheriting from a view and a control. So a window structure consists
of pure views and view-controls in a tree.
Works great.
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
David Steuber wrote:
> Frode Vatvedt Fjeld <······@cs.uit.no> writes:
>
>
>>mikel <·····@evins.net> writes:
>>
>>
>>>[..] GUIs don't belong to the same domain as application
>>>programming; they belong to the same domain as industrial design for
>>>consumer products, which is one of the hardest things in the world
>>>to succeed at.
>>
>>I tend to agree, and this is just one of the reasons I see why there
>>should be a much deeper and cleaner separation between applications
>>(which can be defined loosely as state + functions) and GUIs or
>>(human) interaction systems in general.
>
>
> Deeper even than MVC? Currently that is the 'design pattern' used by
> Cocoa. I guess Java.Swing must use it also since Sun also pushes MVC.
>
> I am not really sold on MVC myself. I certainly agree that the view
> needs to be seperate from the application logic. However, the
> decoupling of model-controler is something I don't quite get the
> advantage of.
Model is state. Controller is a set of actions that can change the
state. View is presentation that enables you to observe the state. You
separate the model from the controller so that adding a new way to
change the state doesn't have to mean changing all the old ways of
changing the state, and so that debugging one method of changing the
state doesn't have to mean simultaneously debugging all the other ways
of changing the state.
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·····················@twister.nyc.rr.com>...
> I know you think consistent look and feel matters, which is part of why
> Apple is suing me for this:
>
> ftp://common-lisp.net/pub/project/cello/mandel-scroller.png
>
> That was actually an implicit response to your objection to Cello:
> native look-and-feel is easy to copy with a powerful, um, GUI. Those
> scrollbars have a mac-p attribute which puts the arrows at opposite ends
> of the scrollbar when nil. win32-ish appearance has been left as an
> exercise, but check out the "cell pre-cursor" screenshots on tt.com. To
> a pixel.
That's not really what I meant. Something like Windows (and I suppose
gnome and kde) are huge enormous frameworks which applications get
dropped into (you know this, of course). And they have all this
centralised control - you can set something like how wide scrollbars
are, and *every* application will pick up the change. Except for
Emacs, which has its own scrollbar implementation, for some reason.
My claim is that if you want to live in the windows world (or the
gnome world, or whatever) then you have to do *all* this behaviour or
you'll end up like Emacs. And I think that's *really* hard.
The alternative is to be your own application framework, which I think
is easier. I've always said that that's futile, because Windows Has
Won. But may be that's wrong, I don't really know any more.
--tim
From: John Thingstad
Subject: Re: The Saddest of all Application Frameworks [was Re: Macro lambda list]
Date:
Message-ID: <opr7fhvjzgxfnb1n@news.chello.no>
Have you updated emacs lately.
I am currently using a version 21.3.50.01.
It has a toolbar and has CUA style cut ad paste support.
Options move to options menu. Help menu on the right,
file menu on te left, windows scrollbasr and menus
,support for pictures etc.
Agreeably it hs taken some time, but emacs is actually starting
to look and behave like a windows app.
There are (and will always be) a few oddities.
Like the minibuffer. And and the use of option buffers instead of dialogs.
But it much less of a turnoff for a first time user.
P� 3 May 2004 03:40:06 -0700, skrev Tim Bradshaw <··········@tfeb.org>:
That's not really what I meant. Something like Windows (and I suppose
> gnome and kde) are huge enormous frameworks which applications get
> dropped into (you know this, of course). And they have all this
> centralised control - you can set something like how wide scrollbars
> are, and *every* application will pick up the change. Except for
> Emacs, which has its own scrollbar implementation, for some reason.
>
> My claim is that if you want to live in the windows world (or the
> gnome world, or whatever) then you have to do *all* this behaviour or
> you'll end up like Emacs. And I think that's *really* hard.
>
> --tim
--
Sender med M2, Operas revolusjonerende e-postprogram: http://www.opera.com/
John Thingstad wrote:
> Have you updated emacs lately.
> I am currently using a version 21.3.50.01.
> It has a toolbar and has CUA style cut ad paste support.
> Options move to options menu. Help menu on the right,
> file menu on te left, windows scrollbasr and menus
> ,support for pictures etc.
> Agreeably it hs taken some time, but emacs is actually starting
> to look and behave like a windows app.
I will just jump in here to note that those who have been to the
tilton-technology site to check out the Cellp precursor screen shots
will have seen version 0 of the makeover sequence, which looks a lot
like a typical Windows app. The contents were drawn by Cello--
(precursor) using win32 GDI 3d-effects, and the app handled the win32
messages which announced changes by the user in the display control
panel to the preferred color scheme.
Doing that in Cello would mean a little hacking of Freeglut since it
handles/hides OS messages, and if anyone is /that/ obsessed with native
they can kill a few days on that. I would do it, but I just do not have
the resources; all my money these days is going into helicopter fuel.
slim kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
From: Tim Bradshaw
Subject: Re: The Saddest of all Application Frameworks
Date:
Message-ID: <ey3ekq1migj.fsf@cley.com>
* John Thingstad wrote:
> Have you updated emacs lately.
I've tried, but the gnu ftp site has only had placeholders for about 6
months since someone compromised it, I think. Gives you real
confidence in their backups and general competence...
--tim
http://ftp.gnu.org/emacs/windows contains 21.3 now but try this instead:
http://sourceforge.net/projects/nqmacs/
it is a bit more updated.
ps. The problem is that that they had been compromized for some time.
They therfore couln't trust the backups and had to check the source by
hand.
P� Mon, 03 May 2004 20:14:20 +0100, skrev Tim Bradshaw <···@cley.com>:
> * John Thingstad wrote:
>> Have you updated emacs lately.
>
> I've tried, but the gnu ftp site has only had placeholders for about 6
> months since someone compromised it, I think. Gives you real
> confidence in their backups and general competence...
>
> --tim
--
Sender med M2, Operas revolusjonerende e-postprogram: http://www.opera.com/
Hi Ant�nio,
Ant�nio Menezes Leitao wrote:
> (defmacro with-foo (nil &body body)
> ...)
>
> Now, it looks like I'm trying to bind the parameter 'nil', which is
> obviously illegal.
I am not expert, but this make me think loudly:
If you are worried with this implementation dependent problem, why
wouldn't you put a "dummy" argument in the definition of your macro?
I mean, do you think this would be possible:
(defmacro with-foo ((&key dummy) &body body)
(declare (ignore dummy))
...)
Then, when you want to use a more productive parameter, you could remove
the ignore declaration. A problem seems to occur for non-keyword
parameters ...
Camille.
Camille Troillard wrote:
> Hi Ant�nio,
>
>
> Ant�nio Menezes Leitao wrote:
>
>> (defmacro with-foo (nil &body body)
>> ...)
>>
>> Now, it looks like I'm trying to bind the parameter 'nil', which is
>> obviously illegal.
>
> I am not expert, but this make me think loudly:
> If you are worried with this implementation dependent problem, why
> wouldn't you put a "dummy" argument in the definition of your macro?
> I mean, do you think this would be possible:
>
> (defmacro with-foo ((&key dummy) &body body)
> (declare (ignore dummy))
> ...)
I don't think that's a good idea from an aesthetical perspective. Your
definition allows users to say this:
(with-foo (:dummy whatever)
...)
...and Lisp IDEs will tell you that WITH-FOO accepts the :dummy keyword
parameter. This would likely confuse users of your library.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
In article <···········@newsreader2.netcologne.de>,
Pascal Costanza <········@web.de> wrote:
> Camille Troillard wrote:
>
> > Hi Ant�nio,
> >
> >
> > Ant�nio Menezes Leitao wrote:
> >
> >> (defmacro with-foo (nil &body body)
> >> ...)
> >>
> >> Now, it looks like I'm trying to bind the parameter 'nil', which is
> >> obviously illegal.
> >
> > I am not expert, but this make me think loudly:
> > If you are worried with this implementation dependent problem, why
> > wouldn't you put a "dummy" argument in the definition of your macro?
> > I mean, do you think this would be possible:
> >
> > (defmacro with-foo ((&key dummy) &body body)
> > (declare (ignore dummy))
> > ...)
>
> I don't think that's a good idea from an aesthetical perspective. Your
> definition allows users to say this:
>
> (with-foo (:dummy whatever)
> ...)
>
> ...and Lisp IDEs will tell you that WITH-FOO accepts the :dummy keyword
> parameter. This would likely confuse users of your library.
(defmacro with-foo ((&key dummy) &body body)
(declare (ignore dummy))
"Execute body in an environment with FOOing enabled.
DUMMY is a placeholder for future options."
...)
I hope that IDEs that show the parameter lists will also show the
documentation string, which clears up the confusion.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Antonio Menezes Leitao wrote:
> Regarding the macro definition, when I don't have yet an extension in
> mind, I usually write something along the following lines:
>
> (defmacro with-foo (() &body body)
> ...)
>
> Is this OK?
Yes. These are nested lambda lists, so this is as correct as (defun f ()
...) is.
> I was under the impression that the empty list in the macro lambda
> list was used just for destructuring an equivalent empty list in the
> macro arguments. However, we can also see the macro definition as:
>
> (defmacro with-foo (nil &body body)
> ...)
>
> Now, it looks like I'm trying to bind the parameter 'nil', which is
> obviously illegal.
>
> What do you think?
Yes, that's illegal. Lambda lists are defined by way of a grammar, and
that grammar does not mention NIL. However, it talks about variable
names that must be symbols, but disallows names of constant variables.
If you look up "constant variable" in the glossary, NIL is explicitly
included as an example of a constant variable.
See 3.4.1 in the HyperSpec.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza wrote:
>
> Antonio Menezes Leitao wrote:
>
>> Regarding the macro definition, when I don't have yet an extension in
>> mind, I usually write something along the following lines:
>>
>> (defmacro with-foo (() &body body)
>> ...)
>>
>> Is this OK?
>
> Yes. These are nested lambda lists, so this is as correct as (defun f ()
> ...) is.
>
>> I was under the impression that the empty list in the macro lambda
>> list was used just for destructuring an equivalent empty list in the
>> macro arguments. However, we can also see the macro definition as:
>>
>> (defmacro with-foo (nil &body body)
>> ...)
>>
>> Now, it looks like I'm trying to bind the parameter 'nil', which is
>> obviously illegal.
>>
>> What do you think?
>
> Yes, that's illegal. Lambda lists are defined by way of a grammar, and
> that grammar does not mention NIL. However, it talks about variable
> names that must be symbols, but disallows names of constant variables.
> If you look up "constant variable" in the glossary, NIL is explicitly
> included as an example of a constant variable.
>
> See 3.4.1 in the HyperSpec.
I disagree. This isn't an `ordinary lambda list' (3.4.1), but a
`macro lambda list' (3.4.4), and () is a `destructuring lambda list'
(3.4.5) with no elements. Since "nil" and "()" are indistinguishable
after passing through the reader, both forms are valid. The issue is
essentially the same as in
(defun foo nil)
which is also valid, if a little strange.
Jeremy.
Jeremy Yallop wrote:
> I disagree. This isn't an `ordinary lambda list' (3.4.1), but a
> `macro lambda list' (3.4.4), and () is a `destructuring lambda list'
> (3.4.5) with no elements. Since "nil" and "()" are indistinguishable
> after passing through the reader, both forms are valid. The issue is
> essentially the same as in
>
> (defun foo nil)
>
> which is also valid, if a little strange.
Ah, right. Sorry for the cofusion.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
On Mon, 26 Apr 2004 23:41:06 +0200, Pascal Costanza wrote:
>
> Antonio Menezes Leitao wrote:
>
>> Regarding the macro definition, when I don't have yet an extension in
>> mind, I usually write something along the following lines:
>>
>> (defmacro with-foo (() &body body)
>> ...)
>>
>> Is this OK?
>
> Yes. These are nested lambda lists, so this is as correct as (defun f ()
> ...) is.
>
>> I was under the impression that the empty list in the macro lambda
>> list was used just for destructuring an equivalent empty list in the
>> macro arguments. However, we can also see the macro definition as:
>>
>> (defmacro with-foo (nil &body body)
>> ...)
>>
>> Now, it looks like I'm trying to bind the parameter 'nil', which is
>> obviously illegal.
>>
>> What do you think?
>
> Yes, that's illegal. Lambda lists are defined by way of a grammar, and
> that grammar does not mention NIL. However, it talks about variable
> names that must be symbols, but disallows names of constant variables.
> If you look up "constant variable" in the glossary, NIL is explicitly
> included as an example of a constant variable.
>
So you are saying that the macro is both legal and illegal? In case you
didn't notice, nil = (). Or am I misunderstanding you?
Best regards,
Antonio Leitao.
Antonio Menezes Leitao wrote:
> So you are saying that the macro is both legal and illegal? In case you
> didn't notice, nil = (). Or am I misunderstanding you?
This was a brainfart on my side. Ignore my posting. ;)
You're right, nil = (), and that's it. I think using nil in macro lambda
lists should be legal.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
* Antonio Menezes Leitao wrote:
> (defmacro with-foo (() &body body)
> ...)
> Is this OK?
I think it is, but I haven't read the spec to check.
I tend to do:
(defmacro with-foo ((&key) &body body)
...)
Which is also, I think, OK, but perhaps clearer.
--tim
Tim Bradshaw <···@cley.com> wrote:
+---------------
| I tend to do:
| (defmacro with-foo ((&key) &body body)
| ...)
+---------------
Hmmm... Yes, given the absence of &ALLOW-OTHER-KEYS, one would hope
that the implmentation would complain if the macro were given any args
in that place. But CMUCL doesn't. In fact, it doesn't even complain
about odd-length keyword args or non-keywords there:
> (defmacro with-foo ((&key) &body body)
`',body)
> (with-foo () ljh lj h)
(LJH LJ H)
> (with-foo (:abc) ljh lj h)
(LJH LJ H)
> (with-foo (abc) ljh lj h)
(LJH LJ H)
>
(Oops.)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
>>>>> "rw" == Rob Warnock <····@rpw3.org> writes:
rw> Hmmm... Yes, given the absence of &ALLOW-OTHER-KEYS, one would hope
rw> that the implmentation would complain if the macro were given any args
rw> in that place. But CMUCL doesn't.
the next version (or the monthly snapshot binary releases) will.
,----
| CL-USER> (with-foo (abc) ljh lj h)
| Error while parsing arguments to defmacro with-foo:
| Odd number of elements in keyword/value list: (abc)
| [Condition of type lisp::defmacro-ll-broken-key-list-error]
`----
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
On Tue, 27 Apr 2004 09:27:12 +0200, Eric Marsden wrote:
>>>>>> "rw" == Rob Warnock <····@rpw3.org> writes:
>
> rw> Hmmm... Yes, given the absence of &ALLOW-OTHER-KEYS, one would hope
> rw> that the implmentation would complain if the macro were given any args
> rw> in that place. But CMUCL doesn't.
>
> the next version (or the monthly snapshot binary releases) will.
>
Will it also accept the following:
(defun test (&foo &bar)
(list &foo &bar))
I do not write code like that myself, but it may happen as result of macro
expansions.
Thanks,
Antonio Leitao.
>>>>> "Antonio" == Antonio Menezes Leitao <··············@evaluator.pt> writes:
Antonio> Will it also accept the following:
Antonio> (defun test (&foo &bar)
Antonio> (list &foo &bar))
Do you really mean &foo and &bar? Then the answer is that this
produces a error.
Ray
Raymond Toy wrote:
>>>>>>"Antonio" == Antonio Menezes Leitao <··············@evaluator.pt> writes:
>
>
> Antonio> Will it also accept the following:
>
> Antonio> (defun test (&foo &bar)
> Antonio> (list &foo &bar))
>
> Do you really mean &foo and &bar? Then the answer is that this
> produces a error.
>
Why should it? &FOO and &BAR are regular symbols which are not part of
LAMBDA-LIST-KEYWORDS.
Cheers
--
Marco
>>>>> "Marco" == Marco Antoniotti <·······@cs.nyu.edu> writes:
Marco> Raymond Toy wrote:
>>>>>>> "Antonio" == Antonio Menezes Leitao <··············@evaluator.pt> writes:
Antonio> Will it also accept the following:
Antonio> (defun test (&foo &bar)
Antonio> (list &foo &bar))
>> Do you really mean &foo and &bar? Then the answer is that this
>> produces a error.
>>
Marco> Why should it? &FOO and &BAR are regular symbols which are not part
Marco> of LAMBDA-LIST-KEYWORDS.
Good point. I guess they should be valid parameter names. At least I
couldn't find anything forbidding such things after looking through
the CLHS for a few minutes.
Ray
Raymond Toy <···@rtp.ericsson.se> wrote in message news:<···············@edgedsp4.rtp.ericsson.se>...
>
> Good point. I guess they should be valid parameter names. At least I
> couldn't find anything forbidding such things after looking through
> the CLHS for a few minutes.
I think they are. To hark back to an earlier thread about
overly-verbose compilers, I think this is a *great* example of where a
style warning would be appropriate (although possibly not as great as
something like
(defun foo (grunge::&key ...) ...)
where GRUNGE::&KEY is not CL::&KEY).
--tim
>>>>> "aml" == Antonio Menezes Leitao <··············@evaluator.pt> writes:
aml> Will it also accept the following:
aml>
aml> (defun test (&foo &bar)
aml> (list &foo &bar))
it was signaling an error for this type of code, but now only issues a
style-warning. Thanks for pointing out the problem!
,----
| CL-USER> (test 1 2)
| ; In: lambda (&foo &bar)
| ; #'(lambda (&foo &bar) (block test #))
| ; Note: &foo uses lambda-list keyword naming convention, but is not a recognized lambda-list keyword.
| ; Note: &bar uses lambda-list keyword naming convention, but is not a recognized lambda-list keyword.
| (1 2)
`----
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
On Tue, 27 Apr 2004 17:07:21 +0200, Eric Marsden wrote:
>>>>>> "aml" == Antonio Menezes Leitao <··············@evaluator.pt> writes:
>
> aml> Will it also accept the following:
> aml>
> aml> (defun test (&foo &bar)
> aml> (list &foo &bar))
>
> it was signaling an error for this type of code, but now only issues a
> style-warning. Thanks for pointing out the problem!
>
> ,----
> | CL-USER> (test 1 2)
> | ; In: lambda (&foo &bar)
> | ; #'(lambda (&foo &bar) (block test #))
> | ; Note: &foo uses lambda-list keyword naming convention, but is not a recognized lambda-list keyword.
> | ; Note: &bar uses lambda-list keyword naming convention, but is not a recognized lambda-list keyword.
> | (1 2)
> `----
I'm not sure a warning is the best solution. The code I exemplified is
generated by macro expansion. It will be annoying to receive a warning
that you don't have any way to avoid.
However, it is definitely better to have a warning than to have an
error :-)
Thanks,
Antonio Leitao.