[M3devel] source paths to generics?

[Jay K]

I guess neither of us looked outside of m3front.
The code runs. Not clear if the strings can get output.
Maybe from asserts or Compiler.ThisFile in a generic?
I"ll try some more.

jair:m3core jay$ grep -i parseimp ../../m3-sys/cm3/src/Builder.m3
    ids := M3Front.ParseImports (source, s.m3env);


 - Jay


----------------------------------------
> Date: Wed, 29 Jun 2016 19:34:13 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] source paths to generics?
>
> Hmm. I poked around a bit, and it looks like there is some cruft here,
> left over from something.
>
> The only call I can find on M3Header.Parse is M3Front.m3:37. This is
> in M3Front.ParseImports. I can find no calls on that at all. (There
> are other procedures by this name.)
>
> Also, it appears M3Header.ParseImports actually collects the exports, the imports,
> the generic actuals.
>
> As for the concocted (by M3Header) name of the form <instantiation> => <generic>,
> this looks to be used only to initialize the scanner's file number while scanning
> up through the formals of the generic, but that is not used.
>
> On 06/29/2016 11:34 AM, Jay K wrote:
>> 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
>>>
>>
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>>
>
> --
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel