Our Own Little Language

Many Programming Languages Can Be Extended Upon Somewhat Easily. Such As Python, Or Lua. As Well As Language Bridges Between Languages, Python And Lua Can Be Bridged Together With Lunatic-Python, Which Allows You To Invoke The Python Interpreter From Within Lua And The Lua Interpreter Inside Of Python. Anyway I Was Wondering If Anybody Here Is Familiar With The Superset Of C, Cilk.It Is Intended For Massive Parallelism In C Programs.I Was Wondering If Somebody Could Help Me Develop Wrappers For:
  • Swig
  • ,
  • Flex
  • ,
  • Bison
  • ,
  • Cilk
  • ,
  • ImageMagick
  • ,
  • Nyquist
  • FFLL
  • ,
  • Tesseract OCR
  • , And
  • Evolving Objects
For A Nice Little Collection Of Systems For Use In A New Programming Languages Or Extensions To Existing Ones, Extreme Programming I Will Call This Brainiac And Have Already Been Working On This For A While, However I Am A Beginner And Not Yet Have Enough Code For A Release, Other Than For A Collection Of Utilities.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Weird, looks like spam to

Weird, looks like spam to me. Or an English beginner, or maybe a primary school student? If its the latter, its nice to see that they are starting young when posting to LtU.

Not Spam

Nah, it's not spam, but I had to read it a second time to ascertain this.

Welcome to LtU!

We are glad that you are excited about programming languages! You obviously have much to learn, and I genuinely hope we can be of assistance. However, I seriously doubt any of us are interested in working on your project. For starters:

1. Learn how to capitalize properly. It really does make it rather difficult to read. We aren't going to take you seriously otherwise. (Are you using your own program to do capitalization for you?)

2. Preview before you post. That way you can go back and correct formatting problems, like those that appear in your bulleted list items.

3. We prefer that LtU'ers use their real name as their user name, as per the site policy. Please re-register with a different user name if you wish to participate here.

Also, realize that all of us have substantial programming experience, and many of us have (or are working on) post-graduate degrees in Computer Science. A select few of the LtU crew are actually quite famous, especially among programmers.

Though you have stumbled into an elite forum, hopefully we are not elitist. Anybody with relevant interests should feel welcome to participate. However, you need to understand the community.

Lurk more, and focus on asking the right questions at first. See if you can't get some of us to expound on something or another. Work on learning Scheme, Common Lisp, Haskell, OCaml, or SML, and learn one of these languages well. (This will take a few years.) Don't embark on a grand project to solve everything just yet. Concentrate on small projects that you can turn around quickly to benefit your own education, and get these projects done.

A few pointers that will hopefully shorten your path to enlightenment:

1. Syntax is nice, but it's not the hard part of programming languages. Learn how to write parsers and move on. There is nothing magic about Flex and Bison. You should be able to write a parser with or without these types of tools. The real difficulty is what a language means, not what it looks like.

2. Integrating two existing software projects, especially two programming languages, can be arbitrarily difficult. It is often impractical. Python and Lua benefit from being almost the same language: nothing is so radically different that it makes integration truly challenging. Integrating some of the other projects you mention, especially all of them, is another matter entirely.

3. There is nothing magic about Cilk. There are numerous approaches to concurrency, some of which are also highly efficient. All of the languages I suggested learning support concurrency; Erlang, Occam, Oz, and Orc are among others that are worth mentioning.

I don't want to scare you off: I wrote this because I can empathize, and we hope you'll stick around to learn something!

Well Thank You Leon

Thank you for the constructive criticism. Don't worry about the whole beginner at English thing, I am not a stupid person, I just capitalize everything, it is a bad habit. Also I have decided to start with a much smaller project to write a domain specific markup language for Neural Network Design

I Have Done What You Said

I have registered a new account under my real name, sorry for not reading the site policy, I'm a noob. Now that we have that straightened out, i was wondering if anybody could point me in the direction of where i might find out how to implement my own Domain Specific Language based on xml?

Welcome again. As for XML,

Welcome again. As for XML, it is generally a declarative language. Is your DSL about declaring stuff and transformations, you can use straight XML with an appropriate schema and XSLT. If not, XML is probably not appropriate (you could still use it as intermediary representation).


Well, a DSL for neural networks sounds like a reasonable goal. Unforunately, I don't know much about neural nets, so I wouldn't be able to help other than some general pointers about writing interpreters.

What, exactly, do you mean by "based on xml"? Referring back to my first point, XML is almost entirely syntax, and almost no semantics. While I see value in a common syntax for data exchange, XML seems terribly complicated for what it accomplishes, and I feel it falls short even on data exchange functionality.

A comparable alternative is Lisp S-Expressions (sexps). Erlang's data model is essentially sexps, with a different syntax. Most incarnations of sexps are both simpler and offer a richer data semantics. (standard integers, floating-point numbers, symbols, arrays, etc. i.e., not everything is a string.)

Indeed, the various XML libraries for Common Lisp, Scheme, Erlang, and even Haskell are far more pleasurable to use than say, the Document Object Model. These libraries translate an XML string into an sexp, which is conveniently manipulated in these languages, and then translate these sexps back to XML.

It's actually not difficult to write naive interpreters, especially once you are comfortable with recursion and induction. There is basically two steps in this case: the parser, which takes program text and turns it into an abstract syntax tree (essentially the same thing as an algebraic datatype in ML/Haskell, or s-expression in Lisp/Scheme), and then the interpreter, which is a structural recursion over the syntax involving environments. (An environment maps variable names to values, kind of like a python dictionary, but not quite, because these can't easily handle multiple variable instances with the same name, as happens with recursion. A stack of dictionaries would work.) Conceptually:

parse : String -> Syntax
evaluate :  Environment * Syntax -> Environment

The function parse takes a string and returns a syntax object, and evaluate takes a an environment and a syntax object and returns a new environment, possibly doing something else as well. (such as I/O.) By changing the binding of a variable in the new environment, you can implement imperative languages with variable re-assignments, without using assignment statements explicitly in your interpreter.

As for parsing, learn about recursive-descent parsing, in addition to parser generators. Hopefully, that will help de-mystify things.

I'm not sure exactly what to recommend, reading wise. The Essentials of Programming Languages comes to mind. All in all, I like the book, although I don't think I'd want to try to learn about structural induction and algebraic datatypes from the first chapter alone.

I learned structural induction from Introduction to Functional Programming using Haskell shortly after the second edition came out. I really like it's presentation, and I think the ML/Haskell type system and syntax for pattern matching is extremely helpful for beginners.