ptkwt
1/17/2006 7:58:00 PM
In article <433qi6F1km3i4U1@individual.net>,
Robert Klemme <bob.news@gmx.net> wrote:
>Phil Tomson wrote:
>> In article <4316f8F1iis3gU1@individual.net>,
>> Robert Klemme <bob.news@gmx.net> wrote:
>>> Phil Tomson wrote:
>>>> if?(a==10){ x << 0 }else?{x+=1}
>>>>
>>>> would become:
>>>> --VHDL
>>>> if(a=10) then
>>>> x <= 0;
>>>> else
>>>> x <= x + 1;
>>>> end
>>>
>>> I'm afraid this won't be possible without actually parsing the code.
>>> Reason being that you don't get access to the source code (for
>>> example for the condition "a==10") during normal ruby execution.
>>
>> Unless a is an object with an '==' method. (that's the situation I
>> have, actually). The '==' could be overriden to enable it to produce
>> VHDL code.
>
>What happens if someone writes "10 == a"?
That's already an issue even in the simulation context. 'coerce' is your
friend in these situations. Since 'a' is likely to be a member of one of
three or four classes it's not too difficult to get around this with coerce.
> To me it looks as if the code
>generation while execution would be too fragile / complicated.
It's not really code generation while executing (well, I guess it is in a
sense). The code would be executed in two distinct contexts:
1) simulation (runs like a normal Ruby program)
2) translation : well, it still runs like a normal Ruby program, but instead
of, for example, the 'if?' method doing some conditional call on the passed in
block, the 'if?' method reports itself and executes the block (full of other
objects/methods that report themselves) and the 'else?' executes as well.
I sent another reply yesterday using some code to explain, but it seems to
have not made it to the list.
Basically, there would be two modules: Simulation (for the simulation context)
and ToVHDL (for the translation context). Depending on which module was
mixed-in to the DSL's class, you're either going to Simulate or Translate.
(that's a bit simplistic, there would actually need to be two different
collections of modules, but you get the idea). In the ToVHDL module(s) things
like operators report themselves, like so:
def ==(other)
if other.respond_to? :name
"#{name} = #{other.name}"
else #immediate value
"#{name} = #{other}"
end
end
Oh, if only 'if', 'else', 'while' and 'case' were just methods in Ruby that
would make things a lot easier ;-)
> The
>cleanest solution is probably to parse the DSL and emit VHDL and / or Ruby
>(if it's not already Ruby).
I'm still not giving up yet ;-) but yes, I may end up having to do that.
Like I said, it might be possible to do a mix of the two somehow.
>
>> Basically I need the DSL to either:
>> 1) execute
>> - or -
>> 2) translate to VHDL
>> (execution mode, translation mode)
>> If I only allow certain types of objects in the DSL (doable, actually
>> it's kind of already that way) I can override lots of operator
>> methods so that they can produce VHDL code.
>>
>> ...of course, I still might end up having to parse the code, but I
>> don't want to give up yet ;-) Or it could be that I end up with a
>> mix of both: some minimal parsing in addition to the method
>> overriding.
>
>Well, at least you can stick with Ruby - there are parser implementations
>for ruby code already.
Yeah, there are, but they always lag behind the current Ruby implementation.
Whenever there are changes to Ruby they don't show up right away. Also, I
think this is an interesting exercise to see if I can avoid using a parser.
....though, I'm casting envious glances over at Io at this point. This would
all be pretty trivial in Io it seems (partly because in Io things like 'if',
'else' 'while', etc. _are_ methods and partly because you have access to the
AST at any time.
Phil