0

I am thinking about small language specifically for graphs that would provide a lot of functionality to manipulate graphs and the like.

So when I was pondering over the syntax of the language, I read about the functional and the 'obvious' imperative paradigm. How does one decide what kind of a language style would be better? Which one would suit my use case better? I would appreciate answers with some good reasons and explanations.

EDIT: As for the audience for this language: I believe non programmers/researchers who have no prior programming experience, would still be able to use graphs would benefit from it.

EDIT: If you feel that this question is not useful, you are open to vote it down, but please add a comment as to why you feel it deserves it. It might help me in going a long way.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Gooner
  • 1,380
  • 2
  • 14
  • 25
  • It depends on your audience. If people are likely to have a math background functional would probably be obvious. I'm not sure what you mean by manipulating graphs though. – Earlz Aug 03 '11 at 16:20
  • Like operations on graphs -> finding the minimum spanning tree, other operations like matching graphs etc. A language in which the basic "type" is a graph type. – Gooner Aug 03 '11 at 16:29
  • 2
    Why not just write a library for a easy-to-use and powerful language, eg: Python? – utdemir Aug 03 '11 at 16:33
  • Why would you do this, rather than just using a library in an existing language? – Marcin Aug 03 '11 at 16:33
  • Sure, I believe that if someone has a no prior programming experience, will first have to learn the languages syntax and only then learn how to program graphs. Right? This on the other hand is more like an interactive shell where you can play around with graphs. – Gooner Aug 03 '11 at 17:19

2 Answers2

1

IMO when you try design some simple language, you usually have some idea who will use it and what it will do. Then, try to 'use it' first, think about how writing in it should look like. Don't think about paradigms and that stuff - it's something you start to worry when your language goes larger - but maybe it wont:) It can end as a simple interactive shell with basic mathematical-like syntax.

Adam Jurczyk
  • 2,153
  • 12
  • 16
1

Not really an answer to most of your questions, but I've designed a few toy languages (and thought about some non-toy ones). I find it helpful to think about the sorts of things I expect to be done in the language, and then try to actually write some sample programs before designing it, to see how the concepts come out.

It can be hard not to get caught up in extraneous detail like what needs parentheses, exactly how you indicate structure, how you declare variables and types (if you do), etc etc. You're not really interested in syntax at this stage (which is a little weird when you're writing a sample program), so it's closer to pseudocode. But it can help to solidify what primitives you need, what are the concepts that users of your language will be thinking in.

If you're still weighing up fundamental choices like imperative vs functional, try doing it several different ways. For example, what are the building blocks your language would need to provide to write graph transformations in an imperative style? What about in a functional style? Doing this can help you get a feel for what works well in each approach, what problems you'd need to solve for each approach, and so on.

Ben
  • 68,572
  • 20
  • 126
  • 174