| |
| |
|
 | Ich möchte etwas Grundlegendes an Infinity ändern, da ich mit dem Sprachschatz noch nicht zufrieden bin.
So soll es dann einen offiz. Funktionssatz (der Kleine) geben aber auch einen "Großer Funktionssatz".
Beispielsweise finde ich gut, dass es math(math.cos,... gibt, so bleibt alles in der Funktion math und man kommt nur mit math(... aus.
Auf der anderen Seite fände ich es auf Dauer wohl unpraktisch, wenn man nicht einfach nur cos( schreiben könnte. Natürlich könnte man nun proc cos f definieren mit return math(math.cos,f) aber das macht das Programm an dieser Stelle natürlich langsamer da eine weitere Funktion gerufen wird. Also muss eine Lösung her.
Da bekommt die xprofan.api-Include vielleicht eine Sonderrolle, sodass die darin enthaltenen Funktionen dann den sog. "Großer Funktionssatz" bereitstellen. Diesen kann man dann ja zuschalten insofern erwünscht.
Nur müssten die Funktionen darin dann auch so schnell sein wie die regulären Funktionen - also das cos( kein Umweg ist zu return math(math.cos.
Dazu überlege ich noch wie ich das optimal Lösen kann. Vielleicht sogar sowas wie Makros wie in ASM - muss aber noch eine Syntax für her.
Der große Funktionssatz aus der xprofan.api würde dann auch als großer Funktionssatz links in der Navigation [...]  erscheinen als neuer Punkt etwa unter "Sprachelemente".
So kann es dann also ganz offiziell z.B. auch eine Funktion mid( geben, die dann wie str(string,from,to) reagiert aber ohne Geschwindigkeitsverlusst. So auch explode,.... lauter Funktionen halt wie sie aus XProfan bekannt sind oder in XProfan mal bekannt werden.
Gibt danach also einen harten/ kleinen Sprachkern mit dem man alles programmieren kann und _zudem den großen Funktionssatz für Einsteiger/ Umsteiger/ Tippfaule. |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | Wäre da nicht sowas wie die ph-Dateien von Profan nützlich?
Statt math(cos... wird dann eine Zeile in der ph festgelegt:
~cos( = math(cos,;
und der Präcompiler (so es ihn hier auch gibt...) setzt das entsprechend um. |
|
| |
| |
| |
|
|
| Ja, mal überlegen, dank Spaceoperator vlt. sogar einfacher als ich fürchtete:
print(math(math.cos,x))
makro cos=math math.cos
wird per spaceop ja
makro cos=math(math.cos)
käme dann ein
cos(x)
könnte ich cos erkennen als undeklarierte Funktion,
dann aber ein Makro cos finden und schlicht ersetzen:
math(math.cos)(x)
bliebe noch ein )( Ungetüm am Ende der Ersetzung -
also leicht zu erkennen und in ein Komma umzuwandeln:
math(math.cos,x)
klingt interessant.
makro test=mufflon(10,20,30)
test 100
test(100)
test undeklarierte Funktion wird zu
mufflon(10,20,30)(100)
Stringende vom Makro ist ), folgt ein ( ersetzen zu ,
ergäbe:
mufflon(10,20,30,100)
könnte vmtl. jedem gefallen.
mal anhand explode schauen:
makro explode=arr()
explode("te|st","|")
würde zu:
arr()("te|st","|")
) am ende der Makros gefolgt von ( ersetzen in ,
ergäbe
arr(,"te|st","|")
wäre also arr(null,"te|st","|") -
haut also net hin. 
Sei denn ich schaue ob eine ( vor dem Ende meiner Ersetzung steht -
was ja nicht sein kann in anderen Fällen,
dann könnte ich auch das Komma sparen wenn vor dem Ende der
Ersetzung eine Klammer öffnet.
Ich glaube das ist (Adj.) "integer" und die Makrosyntax wäre auch sehr gut.
Genau genommen bräuchte ich dann nichtmal das neue Schlüsselwort
"makro", da proc name=todo eineindeutig erkennbar ist und zu
unterscheiden von
proc name x=todo
was ja bedeuten würde proc name(x=todo),
proc name(=todo) wiederum kann es ja nicht geben,
ergo muss es ein makro sein.
cool. |
|
| |
| |
| |
|
|
HofK | Was ich da jetzt nicht überschaue:
Wie fügen sich die Konstanten in dieses Konzept ein, Punktschreibweise ausführlich oder die seinerzeit angepeilte Kurzform.
math.cos --> cos
event.keydown = 100 --> keydown
event.touchdown =200 --> touchdown
gui.width --> width
usw.  |
|
| |
| |
| |
|
|
| bei cos=math.cos komme ich noch mit, event.keydown etc ist auch noch
klar - width aber wird dann eher kein Makro sondern eben eine normale
Funktion die schaut von was genau da die "Breite" abgefrägt wird.
Vlt. sollte ich die xprofan.api-Datei auch zerfleddern in Threads und autom.
zusammensetzen als Projektdatei. |
|
| |
| |
| |
|
|
HofK | iF (26.11.15)
...
Vlt. sollte ich die xprofan.api-Datei auch zerfleddern in Threads und autom.
zusammensetzen als Projektdatei.
Seit der Präkompilierer für mich sichtbar arbeitet, war mein Gedanke warum immer mit include
xprofan.api die gesamte xprofan.api drangeklatscht wir, wenn nur eine/wenige Funktionen daraus
wirklich benutzt werden. Ist ja in einem Durchlauf zu ermitteln ob es die jeweilige Funktion in
dieser speziellen api gibt. Dann ok, sonst Fehler.
Noch ist die xprofan.api klein, aber wenn sie wächst wäre es sicher relevant.
iF (26.11.15)
Ich möchte etwas Grundlegendes an Infinity ändern, da ich mit dem Sprachschatz noch nicht
zufrieden bin.
...
So soll es dann einen offiz. Funktionssatz (der Kleine) geben aber auch einen "Großer
Funktionssatz".
...
Nur müssten die Funktionen darin dann auch so schnell sein wie die regulären Funktionen - also das cos(
kein Umweg ist zu return math(math.cos.
...
Diese Änderung finde ich von der Richtung voll ok, auch wenn ich dann die Anfangskapitel vom Buch
teilweise recht stark "umstricken" muss - gerade im Hinblick auf Erklärungen /Zusammenhänge. Aber
die Sprache gewinnt deutlich. Diese Richtung steckte ja schon am Anfang irgendwie drin:
Klaus Hoffmeister (18.01.15)
"... eine mächtige Sprache mit wenig Befehlen..."
ist für die innere Logik/Sprachentwicklung sicher günstiger und die Idee mit "include
xprofan.util.aprf, ...include java.util.aprf" finde ich prinzipiell gut.
Zu den Funktionen stellt sich die Struktur für mich derzeit so dar:
Je "Sachverhalt" möglichst nur eine/wenige Funktion/en und die Feingliederung mit den Parametern:
array, directory, event, file, message, print, rgb, string, time, var
Bei übergreifenden Dingen: len, del, long auf Strings & Arrays anwenden.
Wenn die programmieranfängerfreundlichen Schreibweisen vorab in die kompakte Funktionssyntax mit
den sehr variablen Parameterkonstellationen übertragen werden, steigt höchsten die
Präkompiliererzeit ein wenig. Dazu noch die Gliederung des Funktionssatzes in den Sprachkern und
die Sprachhülle -wie ich es bezeichnen würde- um auch den Spezialisten sofort die interne
Gliederung deutlich zu machen. |
|
| |
| |
| |
|
|
Unterthema: Funktionssatz 1 (ursprünglich), Test auf Näherung Satz 2 [...] erzeugt. |
|
| |
| |
| |
|
(851)
Deutsch
English
Français
Español
Italia