[M3devel] source paths to generics?

[Jay K]

There is similar code in Module.m3 and that is the code producing
the data "I don't like".

M3Header isn't dead but I haven't seen it run yet.

I changed them from "=>" to "1=>" and "2=>" and looked
where those occur in the output .s files under -keep.

This is kinda something I wish were easier, like more strings
need to be longer for easier finding w/o ambiguity (the flip
side of my context arguments!)

As things stand, I can't check that in.
I suppose maybe with a CG.comment but nevermind.

 - Jay



----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: [M3devel] source paths to generics?
> Date: Wed, 29 Jun 2016 15:22:14 +0000
>
> mfront/src/misc/M3Header.m3 has this:
>
>
> (* build a synthetic file name & start reading *)
> filename := old_filename & " => " & filename;
> Scanner.Push (filename, s.generic, is_main := Scanner.in_main);
>
>
> and instantiated generics aren't what I thought.
> I thought the build system or compiler did a textual
> substitution of the generic parameters into the entire implementation,
> and saved that to the file system,
> and had the assert/debug paths point to it.
>
> So could step through what looks exactly like an .m3 file.
>
> But it doesn't. The instantiated file is a little stub, like:
>
> jair:libm3 jay$ more I386_DARWIN/TextAtomTbl.m3
> (*generated by m3build*)
>
> MODULE TextAtomTbl = Table (Text, Atom) END TextAtomTbl.
>
>
> so I have one or two proposals.
>
> 1) old_filename above contains the target, it looks like:
>
> "../I386_DARWIN/TextAtomTbl.m3 => ../src/table/Table.mg"
> or
> "../I386_DARWIN/TextAtomTbl.m3 => ../src/table"
>
> These both occur.
> I'm not sure what the second is, seems like a mistake.
>
> I suggest the first string in both pairs be changed to be the leaf element, like:
>
> "TextAtomTbl.m3 => ../src/table/Table.mg"
> or
> "TextAtomTbl.m3 => ../src/table"
>
> and maybe the second string in both cases should be as it is in the second pair.
>
> 2) Possibly it should reall just be:
> ../src/table/Table.mg
>
> and developer can step through that, knowing that it is a somewhat abstracted
> form of what is running
>
> I'm willing to do this under like:
>
> CONST TemporaryForTargetConvergence = TRUE
>
> or
> VAR TemporaryForTargetConvergence: BOOLEAN;
>
> and a command line switch, but I suspect it isn't really useful to anyone asis,
> so might as well remove target unconditionally.
>
>
> ?
>
> - Jay
>
>
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Wed, 29 Jun 2016 09:44:51 +0000
>> Subject: [M3devel] source paths to generics?
>>
>> I haven't fully verified this, but it appears for example if I debug a generic, or fail an assert in a generic,
>> the source file I am told about is the instantiated i3/m3 file.
>>
>> This isn't particularly useful for the programmer or convenient for the compiler, right?
>>
>> The programmer would rather see the .ig/.mg files, and this is easy to provide in the compiler?
>> I guess it is slightly easier in the compiler, but easy to do better?
>>
>> I should look into make it so?
>>
>> My real agenda is I want to see:
>> ../src/foo.mg
>>
>> instead of
>> I386_DARWIN/foo.m3
>>
>> I don't want the target variation, but other points seem true also, right?
>>
>> Right? The line numbers match between them, and the generic syntax is so close to "normal" that a programmer not used to it won't be confused, right?
>>
>> I'll try to poke around more.
>>
>> - Jay
>>
>>
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>