Re: as the dust settles (hopefully the last of this)

On Tue, 09 Sep 2008 15:27:19 +0100,
"Donal K. Fellows" <donal.k.fellows@xxxxxxxxxxxxxxxx> wrote:

Evil Son expressed very well what I was unable to. I do apologise to
all for the noise, it is a limitation that I face for reasons I really
don't feel like going into here and now. But since it went as far
down the tubes as it did, I will try to express once and for all what
happened, at least from my perspective, without repeating too much of
what Evil Son so aptly summarised, and a few bits he missed.


Fredderic wrote:
Well, actually my main issue was with a certain attitude that
particularly irks me, and the argument itself became the prime
example of it.
So you took out your irritation on c.l.t? Fie for shame!

Actually, no. Firstly, that's where it was, so that's where it got
said. But more relevantly, the bulk of the thread transpired very
fast. And I have to admit, I was trying to bring it back on track but
couldn't quite find the way (irritation does tend to limit ones field
of view a little) through the constant "please explain yet again
because I really can't be bothered listening, but I'm going to
counter-argue anyhow just for the sake of it". Yes, I'm sure that's
probably how I came across myself, in hindsight, but as Evil Son goes
on to point out, the information is there, and you for one apparently
didn't see it, or you wouldn't have made the next statement below.

In the meantime, since I couldn't figure out myself what I hadn't
already said, and was being greeted with "please explains" instead of
some sign of comprehension, that's what I did. I simply explained it
yet again, and again, hoping sooner or later to hit a variant that
would express the issue sufficiently, of what I'd already said
previously. Certainly the wrong technique, and I do apologise for the
noise, but I'm a little strange that way at times.

Note, however, the base topic had also evolved a little thoughout the
thread, at least from my perspective (which is the main reason I hadn't
stopped to summarise; my argument wasn't static, it was just waiting
for constructive input from the other side). It would have been much
better for everyone if the others involved would have at least tried to
follow suit and actively discuss alternatives even if they didn't agree
with them. It's all good and well for everyone to jump on the topic
now after the fact. Where were they during it?


The wrapper thing I don't like, but I'll live with if it ends up
being the final interface.

Speaking of the wrapper, though, your wrapper code will leave behind
[interp alias]s with nothing there to clean them up... That's why I
don't much like it - the amount of excess cruft just to complete the
wrapper cleanly, is significantly greater than just implementing it
in the original interface to begin with. (The [yield] sub-command
also, as provided, would have been better off mapped in...)
You've singularly failed to explain what the problem is with the
interface though. :-) (I'll not comment on the problems with the
implementation for now; proofs-of-concept are often not great when
examined too closely, but little is to be learned from the exercise.)

Again, that's clearly not the case. See Evil Son's response which
expresses my issues better than I could. Yours is the attitude I was
speaking of. I explained things several ways, sometimes more concise
than others, but the response was always the same; instead of
accepting the idea as offered and seeing where it leads, you don't even
know what I was talking about.

In the end, I may well end up that I was wrong. Then so be it. At
least the points were finally expressed, and it eventually appears to
have resolved into a useful discussion. For that alone, it was worth
it.


Along the way, I also expressed a few alternative APIs that would be
made readily possible by a naturally multi-argument coroutine
(resume) command. Not that they're not possible now, it just seems
bizarre to have a mountain of wrappers muddying the waters of what
should be a very clean but flexible API (talking specifically of the
TCL side of the API). Coroutines are a fairly fundamental feature,
after all, and as you say, certainly not complete.

Also, the current state of single optional arguments is just broken
in TCL. One only needs to observe the volume of calls for NULLs, the
whole [maybe] issue, and so forth, to see that. Given a single
optional argument allowing ANY value, there's no way to conclusively
determine whether any argument was specified at all (most languages
have either NULLs or some kind of argc, so far as I can tell). At least
with [proc], you can provide a sentinel value. Here, you can't even do
that. Being able to use [llength] to determine whether there IS an
argument, makes that possible without having to mess about with
specifying formal arguments for the coroutine (resume) command.

And thus I was pushing the API of multiple arguments. In the complex
case where we need [lassign] or multiple [lindex]s, try not to add extra
cruft (ie. those wrappers which were suggested to cram multiple
arguments through a single formal argument). In the simple case where
we only need one argument, perhaps a single [yield1] wrapper that
essentially just does an [lindex 0] for convenience. It's a balance
that I was looking for, not a wrapper-heavy kludge for a simple problem.

I've already said all that several times over, though. Does it make any
more sense _this_ time?


I'll add also that the "show use cases" argument falls short for
experimental interfaces, because it tends to breed esoteric use-cases,
most of which will never see the light of day past the experimental
stage, and those that do, mostly only do so in shaded corners where few
wonder. Most of what's left, while held up as proof that one interface
is perfect, can just as easily be re-worked by those who grok it to
demonstrate the virtues of the other. Plus when one interface is
presented, people will tend to envision their use cases to fit, so
unless it's glaringly wrong, opposing use cases simply won't
materialise. It's not that the use cases don't exist, it's just that
people are more interested in doing what they want to be doing, than
doing the extra work to make it fit an interface that is just as
plausible but doesn't actually exist.

In short, given a use case that does need to pass multiple values,
people will find a way to encapsulate or avoid representing those extra
values, even at the expense of some of their original concept, just so
they can get on with the more interesting parts. Use cases are a poor
measure of an experimental interface. I'd suggest a good number of
the present interface mistakes had perfectly plausible use cases also.
Which is why I much prefer open discussion with grass roots use cases,
if any are presented at all. It's the boring mundane ones that count,
the others can be adapted to fit.


Erroring is an issue that was on the back of my mind, but I really
wanted to get the current one out of the way first. [yield] by the
looks of it, almost needs to be a [return] clone. [return]
and friends would still cause the coroutine to terminate as it
presently does.


Again, I may well be wrong on all of this. But so may the existing
interface. Most likely the optimal interface is somewhere in between
that hasn't been found yet. But regardless, the present use cases I've
seen are being written to work with existing interface, not to prove
it. And they shouldn't be used to do so. In any case, what's needed is
discussion, and that's what I tried to have.


WHY does [lassign] complain if it doesn't have at least one
varName...? The semantics still hold true for zero arguments!
Because TIP#323 hasn't been approved yet.

Yes, and hopefully it will soon.

--
Fredderic

http://goodbye-microsoft.com/

Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 72 days, 23:35)

.

Relevant Pages

  • Re: Getting a ValueError with comtypes
    ... wrapper, but I've been struggling to get it to work. ... I am working with comtypes to interface Microsoft's DirectShow library. ... searches the $PATH to find type libraries. ... COMMETHOD(, HRESULT, 'Pause'), ...
    (comp.lang.python)
  • Re: [patch 05/11] syslets: core code
    ... It was not added by me - it is just a wrapper. ... though) - if you do not want to allocate it explicitly - it is possible ... What exactly do _you_ expect from interface? ... I can work with explicit structure allocation/deallocation/setup - ...
    (Linux-Kernel)
  • Re: compilers
    ... I do it on my free time, which isn't really that often now. ... an MS.NET interface will be ... This statement defines a wrapper to call a non-.NET DLL (QMClient.dll ... with the assumption that much of the core ...
    (comp.databases.pick)
  • Re: Cannot solve complex problem
    ... Interfaces as well as userdefined Collations are in ... And the wrapper as it comes as Binary has already ... ' to Implement the small Interface for userdefinable Collations ... Private SC As cStringCompare, LCID_DE As Long, LCID_DE_PhoneBook As Long ...
    (microsoft.public.vb.general.discussion)
  • Re: as the dust settles (Was: NRE committed: PLEASE TEST)
    ... being the final interface. ... He would need an ungainly wrapper. ... (I do believe that the current interface is the "standard" one but ... Evil Son ...
    (comp.lang.tcl)