[cad-linux-dev] Re: format as a mini-language
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- To: <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Mon, 8 Dec 2003 23:05:02 -0800
----- Original Message -----
From: "Eric Wilhelm" <ewilhelm@xxxxxxxxxxxxx>
To: <cad-linux-dev@xxxxxxxxxxxxx>
Sent: Monday, December 08, 2003 5:48 PM
Subject: [cad-linux-dev] Re: format as a mini-language
> > The following was supposedly scribed by
> > cr88192
> > on Monday 08 December 2003 07:10 pm:
>
> >I am not naturally very confident, so anything similar but better than
what
> >I can do seems like a discouragement...
>
> Read "The Art of Unix Programming" (Raymond). Read the entire thing.
Start
> at the beginning and read every word until you get to the end. Take time
> between some words to think. Read the referenced documents and books if
they
> catch your attention.
>
ok.
> Among the things you will gain may be to know the way of the zen master
> programmer. Unfortunately, this may cause you to drop-out of college if
you
> acquire too much zen and the professors try to pound it out of you.
>
eh?...
> You should also gain some much more concrete things such as how to know
when
> you are re-inventing the wheel and when you are justifiably tearing
> everything down to the ground for the sake of a fresh start. Also good
> things would be to know the value of a good, stiff punt when the edge
cases
> become too complex and to be able to see modular boundaries in your
design.
>
ok.
I know not if I have any real originality. most things I do seem to be
recreations of similar things, but usually with various differences from
what is more accepted/common.
a kind of ot example: bofore I had wanted an rpc protocol, eg, with a dense
representation, dynamic type system, a not overly-bloated/convoluted design,
.. I could try to design said protocols, but people seemed to beat me down
for not going with the soap/corba flow... eventually for most stuff I
settled on xml-rpc, as I can extend it, it has ok semantics, and it is
tolerable...
my plan then was to want a decent binary representation of xml (to cut some
of the space needed). there is wbxml, but too me wbxml doesn't seem that
good for this kind of task... mainstream wants to flog asn.1+schema
conversion (not good in my mind, as it does not retain a flexible
representation...).
I tried before to come up with my own representation. it was a little less
dense than wbxml, but seemed to me like it would be better suited (it
followed the convention of either allowing inline tagdefs or allowing
seperate tagdefs to be used...).
the w3c has put a workgroup on investigating the possibility of "general"
binary xml encodings, this could be useful...
with my language projects, it was that I had virtually no real understanding
of linguistics (except that I thought the approach taken by a lot of people,
eg, trying to use regexps, or tools like lex or yacc, seemed somewhat
doomed...).
the "straightforward" approach of "make a meta-language that evaluates into
a grammar tree, then a dictoionary and grammar rules are used to produce
statements", I had felt was just too naive...
I was also scared off by the fact that semantics vary a fair amount between
languages, and many details important in some are not existant in others...
I had been discouraged by other programs which took the (much less
user-coding intense) route of using "mechanized english" as the input and
converting based on source/target grammer and domain specific
dictionaries/grammar tweaks...
some were interested, but I was not confident I could beat out others. I was
unable to really straightforwardly parse either esperanto or mondlango (or
at least not without enforcing a lot more rules). a problem is that they are
still "too human" (I was often getting messed up grammar trees and
incoherent output...).
what I would need is very much closer to programming, but I doubt most would
use anything like programming for mechanical generation of text...
all this may be that I am wasting effort, or that I cave in too easily...
damn near every language I have tried making in the past few years is ending
up looking like some tweaked out version of lisp. it seems that it is one of
those languages you can endlessly recreate whatever way you want and still
retain a fair amount of stuff (it is difficult to find much you can't
represent using s-expressions and a minorly-extended lispy type system...).
of course, I do like case-sensitive names, which is one point in which I
differ from a lot of others who are into lisp, and I frequently blow stuff
off or break abstractions if they cause too many problems... I tend to
dislike arguing too long about issues that don't matter much (eg: saying
something wont work because the answer is not particularly elegant, and
"make it work" may involve some less than elegant approaches...).
if anything I think I have one of the few scheme implementations that has
escaped the monolithic "central interpreter" design of things. eg, I can
make self contained binaries, and my code links directly with c (as opposed
to a bunch of runtime linking/loading crap and needing to have a runtime
installed first...). of course the compiler is needed to be installed before
much can be compiled, but this is an acceptable cost...
it is still far from stable though.
> That's it for my soapbox. You may burn it now.
>
I don't know.
my mind is not clear, nor very stable...
I am probably just too ignorant of the details of things.
maybe I can do something tomorrow, I think I just wasted today.
all for now.
Other related posts:
