[M3devel] source paths to generics?

[Rodney M. Bates]

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