John Chambers wrote:
| well if my 2p are worth at least 2p to you, do it in ansi C if you want
| anyone to use it. The advantages of portability and general
| comprehensability outweigh some fun features that nonstandard extensions
| may have. I like SNOBOL but I would avoid inflicting it on other
To: [EMAIL PROTECTED]
Subject: Re: [abcusers] ABCp proof of concept
Amazing! I taught SNOBOL (3 and 4) to graduate level music students in
19 (gulp) 69-70. I even wrote a primer to teach it. I did some fairly
hefty music analysis programs with it too. Now I've forgotten it all
and thought
Atwood, Robert C said:
... (snobal text removed) ...
Any thoughts on using a tool like lex/yacc / flex/bison for parser
generation?
For the parser that I am working on, I am using Python. I
have the complete parser working now, using simpleparse, which
uses an EBNF description as its input.
Any thoughts on using a tool like lex/yacc / flex/bison for parser
generation?
After some research around, I landed on re2c (http://re2c.sourceforge.net)
which is reported to create faster lexical scanners than lex. It uses a
different approach and creates a lexical scanner that has no library
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christian M.
Cepel
Sent: 26 August 2004 21:37
To: [EMAIL PROTECTED]
Subject: Re: [abcusers] ABCp proof of concept
Steven Bennett wrote:
Jeff Szuhay wrote:
Uh... Objective-C? :-P
(Oh, I couldn't help myself. You can
Hi there!
As you may have noticed, I have time to dedicate to this project only
during weekends. I would never had enough time to answer to all the email on
the list so I prefer to include all the suggestion in the proof of concept.
I hope you will have the time of downloading it, see if it
Jeff Szuhay wrote:
Someone stated that using ANSI C would be best but that we would
definitely want to use the object oriented extensions to make it object
oriented C (not C++)... Perhaps that is ANSI C today... I dunno... I
haven't programed in C for 5 years and perhaps ANSI has certified
Steven Bennett wrote:
Jeff Szuhay wrote:
Uh... Objective-C? :-P
(Oh, I couldn't help myself. You can slap me for that one),
I wouldn't slap you for that -- I almost answered the same thing myself, but
I suspect I would have meant it more seriously... grin
Objective-C was a big surprise to
Christian M. Cepel wrote:
Steven Bennett wrote:
Objective-C was a big surprise to me when I was forced to learn it for a Mac
programming contract. For a language which is basically standard C with a
very small set of extensions to add OO support, it's both easy to use and
surprisingly
Steven Bennett wrote:
As much though I love and prefer Objective C, and would use it for my own
projects, I'd still recommend straight ANSI C for this particular project,
given it's stated goals. Mainly because Objective-C isn't very well known
outside the Mac world, but also because there are
Mainly because Objective-C isn't very well known outside the Mac
world,
True, but it is firmly in GCC 3.1 and beyond.
but also because there are runtime bindings (just like C++)
This is a good point and a reason to stick with ANSI C.
To subscribe/unsubscribe, point your browser to:
I'd have to opt for the second option. Where myTune is a C struct and
it gets passed through to all the relevant apis. This sort of interface
can be made to be very OO and is trivially easy to wrap in an OO wrapper
for say C++ or Python etc. That seems to provide for maximim flexability.
Someone stated that using ANSI C would be best but that we would
definitely want to use the object oriented extensions to make it object
oriented C (not C++)... Perhaps that is ANSI C today... I dunno... I
haven't programed in C for 5 years and perhaps ANSI has certified an
updated C spec to
Paul Rosen wrote:
This certainly seems like a universal problem, not just ours. I'm only
familiar with the Windows environment, and it is simple to make a DLL with a
straight C or COM or .NET interface that any other windows program can use.
Is there no mechanism like that on MAC and LINUX?
Hi there!
Thanks for your replays. I try to summarize the points so far (at least my
conclusions), please correct me if I'm wrong.
1) To increase portability we should stick to plain ANSI C. I'm perfectly
fine with it. The complications I was referring to, Paul, were those that
you encounter
1) To increase portability we should stick to plain ANSI C. I'm
perfectly
fine with it. The complications I was referring to, Paul, were those
that
you encounter when you try to access a C++ library from another language
(including C).
Well, I see why you want to stick with C. I'll study
Paul Rosen said:
I am very interested in the work you're doing. Unfortunately, I have very
little time these days! Once in a while, I'll have a week where I can
spend a little time each evening on this, but not very often. If I had
time, I'd plunge right in the middle of the work.
Your
Remo D. wrote:
Hi there. I've prepared a proof of concept. It's only a scanner for ABC
files but already features Lua handlers (as well as C handlers).
My biggest concern is that ABC (especially when you try to support older
*and* newer versions, which is really necessary given how much stuff
As far as using Lua for the handlers, I'm not certain what advantage that
gains you if any, especially given how much context you'll need to be
passing back and forth to the handlers, and the need to call back into C
to
get the next token. (Is that even possible in Lua?) I suspect the
Hi Christian. You're right, comments are what I'm looking for.
I just want to add to what you said, that the scanner is 100% ANSI C (look
at abcpscan.re not at abcpscan.c!).
The next big decision to take is if the whole parser should be in C or if I
should start using Lua right now.
Consider
As always, comments are welcome. Actually more than welcome! If none is
interested I'll refrain to keep posting about it. Just let me know.
I am very interested in the work you're doing. Unfortunately, I have very
little time these days! Once in a while, I'll have a week where I can spend
a
Hi there. I've prepared a proof of concept. It's only a scanner for ABC
files but already features Lua handlers (as well as C handlers).
I've also tried to go into details: http://www.dentato.com/abcp/poc.htm but
it's hard to be clear and precise without becoming boring!
I compiled it on WinXP
22 matches
Mail list logo
