...

While the sql reader syntax e.g. [select * table] is convenient for humans it doesn't allow for being used by other functions or does it?

(read-from-string "") as a last resort, otherwise it reads into a CLOS based AST anyways and that you can construct programmatically.

note: the SQL reader and AST stuff is on the TODO to be moved into hu.dwim.quasi-quote and rebased on its infrastructure. but it's not high priority, and wouldn't change anything conceptually...

...

In my opinion such a sql reader syntax is nice to have but not being able to extend the software through the use of functions is disastrous in my eyes. I have the feeling that we create two camps here, one the developers and the other the users. Personally I don't like that distinction and would

it's a library for developers, there are no two camps. it's only developers....

I made a rash judgement here, sorry.

...

much prefer to make the possibility of extending the software through the use of functions as easy as possible for the so called "user".

With that in mind I find myself using internal function and classes from the hu.dwim.rdbms package ( e.g. sql-and, sql-sequence-nextval-column, sql-identifier, sql-all-columns, sql-= ) and writing wrapper functions for it e.g.

we didn't put too much effort into deciding what should be exported and be part of a long-time API, and what isn't. but while (not) doing that we were on the conservative side...

Maybe we should separate the sql reader syntax "stuff" from the rest, so we have one more package to maintain? :)

Please make sure that you expose a "relative" low level interface that can be accessed programmatically and is as expressive as necessary so that a great variety of extension can be build on top of it. I find it somewhat puzzling that the sql reader syntax was not build on top of such an interface. After all, the sql reader syntax should be just an extension?

If I think about I often work in one package despite the fact that two would be warranted just to get things done. Maintaining packages is hassle. So maybe not so puzzling after all ...

...

What do you think about what I just said. Did I go wrong somewhere? And if the above is really an issue, any ideas as how to handle it?

define your own convenience functions? if they seem to be generally useful, propose an extension (but to spare some time, the naming convention you use in your functions will not go though :)

Yes, I will stick to my convenience functions and adapt to your future changes.

As for the naming convention I'm more than willing to compromise and there are many ways for dealing with this e.g. emacs abbrev mode, graham's abbrev macro or just inline functions for personal use.

Don't worry, I never expected my naming convention to go through.

...

Right now I did create another system and package called hu.dwim.rdbms.oracle.ext for things like the above. (The names above are not carved into stone tablets. I often change my mind before I settle for certain names and yes,   often the wrappers seem unnecessary but I don't want to change the package definition of hu.dwim.rdbms   and/or prefer shorter names.)

that's a good compromise and leaves you the freedom to use names/shortcuts you prefer. even if such utils were provided by the main lib, it would not please everyone... so the way to go is to provide a preferably complete skeleton of functionality using descriptive and sometimes long names, and let people do their shortcuts if the need be.

we stick to long names (and use fuzzy completion in slime).

-- attila

--  chris

!DSPAM:4cd40a5848581824115346!