Hi Matthias, hi all, > We are concerned with the production of complex DSLs and haven't made the > production of easy DSLs -- like the one you see on Linkedin -- easy. >
Yes, I understand that. It makes me think of my general experience with the Racket documentation - even with the Guide, which - following Noel's recommendation :-) - I've read by now, partly trying out things while reading, but skipping some of the more detailed parts I have no immediate use for. I don't exactly know how to say this, - I don't want to talk about the obvious inhomogeneity of the Guide, I can imagine where this comes from - but for me sometimes even within one single chapter, there's an extremely steep curve, the beginning seems "obvious" but then there are concepts implied, or functions used, that you need to look up in the Reference, and there then you have the function definition but not really the contextual knowledge... Okay, now I think I have it: My biggest handicap is that even though I need & want to study the extended examples sometimes included in the Guide to really learn something, it takes an unproportionally big amount of time for me to understand them (I could give examples, but I'm embarassed here :-;) ... - for various reasons I think: Sometimes I just have to look up too many other functions, sometimes the examples are, for me, just "inherently difficult" somehow. In fact I think the problem is there's just a tremendous gap between people who work with Racket, or scheme, or at least have substantial related experience, or others who have at most 2-3 hours a week for the whole of pursuing an own project, trying out things in Racket etc., and no transfer to or from daily work (in contrast to, say, your students :-) ). >>> The other half is implementing the parser/constraint checker/semantics, >>> which happens within the language module/package. For that, you need to >>> study things such as syntax-parse and the syntax system and then >>> syntax-case and -- for easy style -- plain old syntax-rules. So the reverse >>> order of what I just wrote will usually do you much more good than the >>> actual order. >>> Yes, I've been aware of that even before I read the macro-related chapters in the Guide. But here too, I have a similar problem: While I got a grasp on syntax-rules and syntax-case themselves, and the - very - basic concepts like read vs. expansion phase, I quickly ran into problems following the links to the Reference, in this case, the Syntax Model chapter. (To give an example, even if this may sound silly: Already in chapter 1.2.1 "Identifiers and binding", I didn't completely get the phase levels - phase level -1 remained a mystery to me.) I guess an "iterative flow" of frequently writing Racket code, reading others' code and looking up things again in the Reference would help - but here again, that's impossible to fit in 3 hours time / week... >>> Other than that, look at things such as Algol 6o (in the core and a tad >>> old) and Jay's Datalog language (on Planet, and recent) to study some >>> example.s >>> Thanks for the hint. I will have a look at Datalog - from just shortly looking at the documentation right now, I think it will be a very fitting example, or model, for what I'm interested in. (I say interested in, because after what I've written above I cannot pretend I could handle a similar-scale project in my spare time :-;) Ciao, Sigrid _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
