Joey Hess <[EMAIL PROTECTED]> writes: > Won't each frontend have to implement it?
Not, it's only a description. A frontend could be given access to it in any manner, You could even write a C interface that returns structs based on the description, or whatever. > I think we're going off on a pointless tangent. Let me ask you: how is this > proposal for a language implemented in the frontend different that the > original proposal for a shell script that that communicates with the > frontend? I don't see any significant differences. We've moved the language > into the frontend and changed the language from shell to something we think > up, those are the only differences I see. The shell is not really as expressive a data representation language as the specialized scheme like language. Forget for a moment that it has parenthesis, it doesn't really matter what the syntax is at this moment. > Why don't we then just send the frontend a lump of shell code and use that > as our implementation language? The only reason I see why not is that then > the frontend would have to parse the shell code. Well, then, why not make > there be an interface between the shell code and the frontend (like the one > originally proposed, say) and the frontend just pasres that? Ok, if there's > an interface we can move the shell code out of the frontend and into the > backend, and we're back to the original proposal. But why use shell as a specialized data description language? Wether it's some scheme like variant, or something else with ASN.1 or whatever, your not describing instructions, your describing a peice of data, a question and an answer. <... schemish data representation language> > How is this different from: > > #!/bin/sh -e <...> Because one is description of a data entity, and the other is a set of instructions for getting some string from a user and basically simulating a protocol. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
